weblogic jvm -Dsun.zip.disableMemoryMapping=true

      weblogic 12c的环境，通过管理服务看到此节点状态为unkown，分析日志，结论是：JVM crash了，需要加上参数

  

-Dsun.zip.disableMemoryMapping=true

原因是

1. While a class is in use it is dynamically reloaded from a jar file. 动态加载了jar文件
2. While a jar file is being accessed by the class loader, the jar file is being modified. 当访问jar文件时,修改了jar
3. A Jarfile which was bigger than 4GB was accessed (applies to Java 6 and earlier only)  jar文件非常大，超过4G

   在nohup.out日志看到内容:
# An error report file with more information is saved as:
# /data/wls1212/user_projects/domains/_domain/hs_err_pid8027.log
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.sun.com/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#
/data/wls1212/user_projects/domains/domain/bin/startWebLogic.sh: line 195:  8027 已放弃                  (core dumped) ${JAVA_HOME}/bin/java ${JAVA_VM} ${MEM_ARGS} -Dweblogic.Name=${SERVER_NAME} -Djava.security.policy=${WLS_POLICY_FILE} ${JAVA_OPTIONS} ${PROXY_SETTINGS} ${SERVER_CLASS}

  hs_err_pid8027.log的内容：

Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C  [libc.so.6+0x89aab]  memcpy+0x15b
C  [libzip.so+0x50b0]  ZIP_GetEntry+0xd0
C  [libzip.so+0x3eed]  Java_java_util_zip_ZipFile_getEntry+0xad
J 117  java.util.zip.ZipFile.getEntry(J[BZ)J (0 bytes) @ 0x00007f580109f1ee [0x00007f580109f120+0xce]

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
J 117  java.util.zip.ZipFile.getEntry(J[BZ)J (0 bytes) @ 0x00007f580109f178 [0x00007f580109f120+0x58]
J 119 C2 java.util.jar.JarFile.getEntry(Ljava/lang/String;)Ljava/util/zip/ZipEntry; (22 bytes) @ 0x00007f58010a3ee8 [0x00007f58010a3e20+0xc8]
J 1078 C2 weblogic.utils.classloaders.ZipClassFinder.getSource(Ljava/lang/String;)Lweblogic/utils/classloaders/Source; (84 bytes) @ 0x00007f58012be9a4 [0x00007f58012be860+0x144]
J 1334 C2 weblogic.utils.classloaders.MultiClassFinder.getSource(Ljava/lang/String;)Lweblogic/utils/classloaders/Source; (49 bytes) @ 0x00007f580132ee60 [0x00007f580132ed00+0x160]
J 1334 C2 weblogic.utils.classloaders.MultiClassFinder.getSource(Ljava/lang/String;)Lweblogic/utils/classloaders/Source; (49 bytes) @ 0x00007f580132ef18 [0x00007f580132ed00+0x218]
J 1334 C2 weblogic.utils.classloaders.MultiClassFinder.getSource(Ljava/lang/String;)Lweblogic/utils/classloaders/Source; (49 bytes) @ 0x00007f580132ef18 [0x00007f580132ed00+0x218]
J 2020 C2 weblogic.application.utils.CompositeWebAppFinder.getSource(Ljava/lang/String;)Lweblogic/utils/classloaders/Source; (31 bytes) @ 0x00007f58016a5ef0 [0x00007f58016a5ea0+0x50]
J 1334 C2 weblogic.utils.classloaders.MultiClassFinder.getSource(Ljava/lang/String;)Lweblogic/utils/classloaders/Source; (49 bytes) @ 0x00007f580132ef18 [0x00007f580132ed00+0x218]
J 1334 C2 weblogic.utils.classloaders.MultiClassFinder.getSource(Ljava/lang/String;)Lweblogic/utils/classloaders/Source; (49 bytes) @ 0x00007f580132ef18 [0x00007f580132ed00+0x218]
J 4834 C2 weblogic.utils.classloaders.GenericClassLoader.findResource(Ljava/lang/String;)Ljava/net/URL; (100 bytes) @ 0x00007f5802018428 [0x00007f5802017fa0+0x488]
J 6887 C2 weblogic.utils.classloaders.GenericClassLoader.getResourceInternal(Ljava/lang/String;)Ljava/net/URL; (145 bytes) @ 0x00007f5801a92660 [0x00007f5801a92580+0xe0]
J 2507 C2 weblogic.utils.classloaders.ChangeAwareClassLoader.getResource(Ljava/lang/String;)Ljava/net/URL; (77 bytes) @ 0x00007f5801895b48 [0x00007f5801895b00+0x48]

官方的解析：

Java Virtual Machine (JVM) crashes in java.util.zip.ZipFile.getEntry() during Class Loading (文档 ID 1296729.1)

转到底部

In this Document Symptoms   Cause   Solution APPLIES TO: Java Platform, Standard Edition - Version 1.4.2 and later Oracle WebLogic Server - Version 12.1.3.0.0 to 12.1.3.0.0 [Release 12c] Information in this document applies to any platform. SYMPTOMS Random crashes during classloading while a jar/zip file is being accessed.  Here is a typical stack trace. Please notice that a custom classloader calls java.util.zip.ZipFile.getEntry() and the crash happens somewhere in libzip or libc or a native windows dll: Stack: [0xfffffffe4e900000,0xfffffffe4e940000], sp=0xfffffffe4e93b1a0, free space=236k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [libc_psr.so.1+0xbf4] C [libzip.so+0xe280] C [libzip.so+0x28e8] C [libzip.so+0x2d9c] J java.util.zip.ZipFile.getEntry(JLjava/lang/String;Z)J J java.util.zip.ZipFile.getEntry(Ljava/lang/String;)Ljava/util/zip/ZipEntry; J weblogic.utils.classloaders.JarClassFinder.getSource(Ljava/lang/String;)Lweblogic/utils/classloaders/Source; J weblogic.utils.classloaders.AbstractClassFinder.getClassSource(Ljava/lang/String;)Lweblogic/utils/classloaders/Source; J weblogic.utils.classloaders.MultiClassFinder.getClassSource(Ljava/lang/String;)Lweblogic/utils/classloaders/Source; J weblogic.utils.classloaders.MultiClassFinder.getClassSource(Ljava/lang/String;)Lweblogic/utils/classloaders/Source; J weblogic.utils.classloaders.MultiClassFinder.getClassSource(Ljava/lang/String;)Lweblogic/utils/classloaders/Source; j weblogic.application.utils.CompositeWebAppFinder.getClassSource(Ljava/lang/String;)Lweblogic/utils/classloaders/Source;+5 J weblogic.utils.classloaders.MultiClassFinder.getClassSource(Ljava/lang/String;)Lweblogic/utils/classloaders/Source; J weblogic.utils.classloaders.MultiClassFinder.getClassSource(Ljava/lang/String;)Lweblogic/utils/classloaders/Source; j weblogic.utils.classloaders.CodeGenClassFinder.getClassSource(Ljava/lang/String;)Lweblogic/utils/classloaders/Source;+43 j weblogic.utils.classloaders.GenericClassLoader.findLocalClass(Ljava/lang/String;)Ljava/lang/Class;+87 j weblogic.utils.classloaders.GenericClassLoader.findClass(Ljava/lang/String;)Ljava/lang/Class;+117 j weblogic.utils.classloaders.ChangeAwareClassLoader.findClass(Ljava/lang/String;)Ljava/lang/Class;+60 J java.lang.ClassLoader.loadClass(Ljava/lang/String;Z)Ljava/lang/Class; J weblogic.utils.classloaders.ChangeAwareClassLoader.loadClass(Ljava/lang/String;)Ljava/lang/Class; j java.lang.ClassLoader.loadClassInternal(Ljava/lang/String;)Ljava/lang/Class;+2   CAUSE 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) None of the above are Java bugs. It's the application's responsibility to prevent this from happening. A crash is unavoidable if a Jarfile is being modified while it's in use. It's similar to modifying a shared library or dll while a program is running. This will also lead to an application crash. Please note that a crash may happen even a long time after a jarfile was modified as classloaders keep references to jarfiles. Another possible sceanrio is when Java or the application itself is being patched while the application is running. Java 6 and earlier have a imitation that only Jarfiles less than 4GB can be accessed. See also: https://bugs.openjdk.java.net/browse/JDK-4681995     SOLUTION Make sure the application code does not reload a class while it's in use.  In addition, make sure that a jar file is not being updated while it's being accessed by the class loader. Starting with 6u21-rev-b09 (non-public build) and 6u23 (public) there is a new property -Dsun.zip.disableMemoryMapping=true which can be used to work around this problem. However, this should not serve as an excuse to not fix the misbehaving application. Overwriting and/or modifying a file that is still in use remains an application side bug. See also: http://www.oracle.com/us/technologies/java/overview-156328.html . Look for "Disabling mmap Usage (on Solaris or Linux)" http://www.oracle.com/us/technologies/java/overview-156328.html 的内容： Disabling mmap Usage (on Solaris or Linux) Thisrelease includes a new system property, sun.zip.disableMemoryMapping, which allows the user to disable the mmap usage in Sun's java.util.zip.Zipfile implementation (onSolaris and Linux platforms). Solaris or Linux applications that use java.util.zip.ZipFile may experience a SIGBUS VM crash if the application accidentally overwritesany 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 systemproperty provides a solution to avoid the VM crash. With the property set totrue (-Dsun.zip.disableMemoryMapping=true, or simply -Dsun.zip.disableMemoryMapping) the Sun JDK/JRE runtime disables the mmap usage and the VM crash that might otherwise occur byoverwriting the jar or zip file can be avoided.