Oracle JVM加载类时出现的一个异常退出问题



  • JDK-7129299 : JVM crash issue related to jar files

    This may be another cases where a zip/JAR file is overwritten while it is being used. In JDK7 the property can be used to disable the mmapping of the central directory to avoid this when there is stepping on toes.

  • Java SE 6 Advanced and Java SE 6 Support (formerly known as Java SE for Business 6) Release Notes

    Changes in 6u21-rev-b09
    Disabling mmap Usage (on Solaris or Linux)
    This release includes a new system property,, which allows the user to disable the mmap usage in Sun’s implementation (on Solaris and Linux platforms). Solaris or Linux applications that use may experience a SIGBUS VM crash if the application accidentally overwrites any zip or jar files that are still being used by the same Java runtime.
    Although this is a programming error of the offending application, this system property provides a solution to avoid the VM crash. With the property set to true (, or simply the Sun JDK/JRE runtime disables the mmap usage and the VM crash that might otherwise occur by overwriting the jar or zip file can be avoided.
    类似的现象并非由JVM自身的Bug导致,但Oracle JVM开发团队仍然提供了规避方案(从其它文章看,JVM的开发团队其实并不是非常情愿)。启动应用时,为JVM传入参数或者,可以避免jar或者zip文件操作时引发的JVM异常退出现象。

  • [Bug 190481] New: Consider using

    See Java bugs #4425695, #6929479. As of JDK 6u21 or 7, a system property can be set to prevent JVM crashes when overwriting an open JAR. (Only applies to Unix, since on Windows you could not open the JAR for writing to begin with.) This may be helpful to avoid crashes caused by buggy Ant scripts, etc. But needs to be checked to see if performance degrades as a result.

  • JVM crashes due to corrupted JAR file

    The reason why JAR files cannot be modified underneath the JVM is because the JVM caches each JAR file’s central directory structure (using mmap) for performance reasons. The central directory is the part of the JAR file that describes its contents – i.e. entry locations, sizes and so on. Caching it in memory means that the JVM does not have to read it from the disk every time an entry in that JAR file needs to be accessed.
    If the JAR file is modified after this region has been cached, then the JVM’s version of the central directory will no longer be an accurate description of the JAR file as it exists on disk and the end result is a SIGBUS or SIGSEGV when the JVM attempts to load an entry from the modified JAR file (usually during class loading).
    Note: This has been a well known limitation of the HotSpot JVM for a long time but Oracle did recently introduce an option to work around the issue. From 1.6.0_23 onwards, the following option can be added to the command line to completely disable memory mapping for ZIP/JAR files:
    Enabling this option will impact performance because the VM will have to conduct some additional disk IO every time it reads an entry from a JAR file (to interrogate the central directory structure).
    As a result, you should verify whether any jar files were modified some time prior to the crashes starting, while the JVM was still running.

  • weblogic jvm

    There are three possible scenarios here:
    1. While a class is in use it is dynamically reloaded from a jar file.
    2. While a jar file is being accessed by the class loader, the jar file is being modified.
    3. A Jarfile which was bigger than 4GB was accessed (applies to Java 6 and earlier only).


若非注明,均为原创,欢迎转载,转载请注明来源:Oracle JVM加载类时出现的一个异常退出问题

关于 JackieAtHome


此条目发表在 JVM 分类目录,贴了 , 标签。将固定链接加入收藏夹。