运行新鲜jar文件时从openjdk发生致命错误

Question

我想实现一个ApplicationChangeMonitor，它监视文件系统中当前执行的jar文件中的更改。当检测到更改时，应用程序应该重新启动。我正在使用WatchService来检测更改。

的设置：

• 发展（Windows）中与Samba共享工作区的Eclipse（Linux系统）
• 由Eclipse的行家（M2E）对桑巴的份额产生的jar文件
• jar文件从Linux系统上壳（使用OpenJDK的）

所以每次创建一个新的JAR文件，运行应用程序应该在Linux系统上重新启动执行。首先，我试图让应用程序自行重启，但大部分时间我都遇到了来自JVM的致命错误。于是我选择了一个更简单的方法：我只是做了检测到变化后结束应用程序本身并实施使用bash的重启机制：

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

奇怪的是，我还申请后得到致命错误一次或两次更改。例如：

• Java的罐子application.jar < - 初始启动，应用程序运行
• 新的JAR文件创建
• Java的罐子application.jar < - 致命错误
• 的java -jar application.jar < - 致命错误
• java -jar application.jar < - 应用程序启动
• 新的JAR文件创建
• Java的罐子application.jar < - 致命错误
• Java的罐子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 
}