運行新jar文件時openjdk發生致命錯誤

Question

我想實現一個ApplicationChangeMonitor ，它監視文件系統中當前執行的jar文件的變化。 檢測到更改時，應用程序應重新啟動。 我正在使用WatchService來檢測更改。

設置：

• 在（Windows）Eclipse中開發在samba共享上具有工作空間（Linux系統）
• jar文件由Eclipse maven（m2e）在samba共享上生成
• jar文件在Linux系統上從shell執行（使用openjdk）

因此，每次創建新的jar文件時，都應該在Linux系統上重新啟動正在運行的應用程序。 首先，我嘗試使應用程序自行重啟，但大多數時候我遇到了來自JVM的致命錯誤。 然后我選擇了一個更簡單的方法：我在檢測到更改后立即使應用程序結束，並使用bash實現重啟機制：

while true ; do java -jar application.jar ; done

奇怪的是，在應用程序更改后，我仍然會遇到一兩次致命錯誤。 例：

• java -jar application.jar < - 初始啟動，應用程序正在運行
• 創建了新的jar文件
• java -jar application.jar < - 致命錯誤
• java -jar application.jar < - 致命錯誤
• java -jar application.jar < - 應用程序啟動
• 創建了新的jar文件
• java -jar application.jar < - 致命錯誤
• java -jar application.jar < - 應用程序啟動

輸出：

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGBUS (0x7) at pc=0x00007f46d5e2416d, pid=28351, tid=139942266005248
#
# JRE version: 7.0_25-b30
# Java VM: OpenJDK 64-Bit Server VM (23.7-b01 mixed mode linux-amd64 compressed oops)
# Problematic frame:
# C  [libzip.so+0x516d]  Java_java_util_zip_ZipFile_getZipMessage+0x114d
#
# Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# An error report file with more information is saved as:
# /home/workspace/.../target/hs_err_pid28351.log
#
# If you would like to submit a bug report, please include
# instructions on how to reproduce the bug and visit:
#   http://icedtea.classpath.org/bugzilla
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#

OpenJDK創建轉儲文件，我猜相關部分是導致此致命錯誤的堆棧跟蹤：

 - Stack: [0x00007fbc9398f000,0x00007fbc93a90000],  sp=0x00007fbc93a8bd90,  free space=1011k
 - Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
 - C  [libzip.so+0x516d]  Java_java_util_zip_ZipFile_getZipMessage+0x114d
 - C  [libzip.so+0x5eb0]  ZIP_GetEntry+0xd0
 - C  [libzip.so+0x3af3]  Java_java_util_zip_ZipFile_getEntry+0xb3
 - j  java.util.zip.ZipFile.getEntry(J[BZ)J+0
 - j  java.util.zip.ZipFile.getEntry(Ljava/lang/String;)Ljava/util/zip/ZipEntry;+38
 - j  java.util.jar.JarFile.getEntry(Ljava/lang/String;)Ljava/util/zip/ZipEntry;+2
 - j  java.util.jar.JarFile.getJarEntry(Ljava/lang/String;)Ljava/util/jar/JarEntry;+2
 - j  sun.misc.URLClassPath$JarLoader.getResource(Ljava/lang/String;Z)Lsun/misc/Resource;+48
 - j  sun.misc.URLClassPath.getResource(Ljava/lang/String;Z)Lsun/misc/Resource;+53
 - j  java.net.URLClassLoader$1.run()Ljava/lang/Class;+26
 - j  java.net.URLClassLoader$1.run()Ljava/lang/Object;+1
 - ...

現在，有沒有人知道我為什么會遇到這些致命的錯誤？ 我想也許是因為jar文件還沒有寫完（這可以解釋為什么問題來自Java_java_util_zip_ZipFile_getZipMessage ）。 但事實並非如此，因為jar的md5sum在執行后保持不變，導致致命錯誤和工作執行。

while true; do md5sum application.jar ; java -jar application.jar ; done

Answer 1

這是因為您正在收到新文件的通知，而該文件正在寫入磁盤。 這對WatchService來說是件壞事，它會在創建新文件后立即通知您，但尚未完全寫入磁盤。

當新的jar文件被寫入磁盤時，jar文件被進程鎖定，進程將該jar文件寫入磁盤。 在文件創建者進程未解鎖文件之前，您無法訪問文件。

解決方案：您必須嘗試打開文件，如果文件被打開，則文件已完全寫入磁盤。 如果您無法打開文件，請等待一段時間（或者不要等待，請嘗試下一步），然后嘗試打開文件。

要解鎖文件，請執行以下操作：

public void unlockFile(String jarFileName){
    FileInputStream fis = null;
    while(true){
        try{
            // try to open file
            fis = new FileInputStream(jarFileName);
            // you succeed to open file
            // return
            // file will be closed in finally block, as it will always executed
            return;
        }catch(Exception e){
            // file is still locked
            // you may sleep for sometime to let other process finish with file and
            // file gets unlocked

            // if you dont have problem with this process utilizing CPU, dont sleep!
            try{
                Thread.sleep(100);
            }catch(InterruptedException ie){
            }
        }finally{
            if(fis != null){
                try{
                    fis.close();
                }catch(Exception e){
                }
            }
        }
    }

對你的問題，

你告訴我 ： “我剛剛在檢測到更改后使應用程序結束，並使用bash實現了重啟機制”

所以，在你結束java進程之前，按照我在上面的方法中建議的解鎖文件。 我相信錯誤會消失。 試着告訴我結果。

像這樣的東西：

void shutDownMethod(){
    // get file name from watcher, below line will depend on your logic and code.
    String jarFileName = watcherThread.getNewNotifiedFile();
    // unlock new jar file.
    unlockFile(jarFileName);
    // shutdown JVM
    System.exit(0);
    // bash will restart JVM
}