适用版本

 通用

问题描述

实例宕机，产生hs日志，内容如下：

Problematic frame:

# C  [libc.so.6+0x8995b]  memcpy+0x15b

…………………………..

Stack: [0x00007f477a7e8000,0x00007f477a8e9000],  sp=0x00007f477a8e4038,  free space=1008k

Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)

C  [libc.so.6+0x8995b]  memcpy+0x15b

C  [libzip.so+0x4cb0]  ZIP_GetEntry+0xd0

C  [libzip.so+0x3aed]  Java_java_util_zip_ZipFile_getEntry+0xad

J 110  java.util.zip.ZipFile.getEntry(J[BZ)J (0 bytes) @ 0x00007f47cd088c6e [0x00007f47cd088ba0+0xce]

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)

J 110  java.util.zip.ZipFile.getEntry(J[BZ)J (0 bytes) @ 0x00007f47cd088bf8 [0x00007f47cd088ba0+0x58]

J 123 C2 java.util.jar.JarFile.getEntry(Ljava/lang/String;)Ljava/util/zip/ZipEntry; (22 bytes) @ 0x00007f47cd0bbae4 [0x00007f47cd0bba20+0xc4]

J 1650 C2 com.kingdee.bos.metadata.MetaDataClassLoader.findResourceInLocal(Ljava/lang/String;)Ljava/net/URL; (258 bytes) @ 0x00007f47cd458b84 [0x00007f47cd458a20+0x164]

原因分析

从hs日志可以判断是因为EAS运行过程中，有人上传了jar覆盖了已有的文件导致的。（堆栈显示是正在解压元数据相关的jar，正常情况下，不可能出错的，因为jar包读取太频繁。）热替换jar包的时间并不一定是奔溃的时间点，在EAS启动后，奔溃前的任何时间替换，都可能引发问题。

参考https://stackoverflow.com/questions/38326183/jvm-crashed-in-java-util-zip-zipfile-getentry

解决方案

规范部署jar包，不在eas正常运行过程中去替换jar包。