动态加载jar包的一个坑

具体场景

最近项目中基于jarslink做实时算法的加载,为了方便jar包更新测试,我们把jar包开发完后以snapshot版本推送到maven中央仓库中。jarslink查询器根据配置动态从maven仓库加载算法jar包及其依赖。为了在jar包发生改变时动态刷新,代码中农将对应jar包的md5作为版本version的一部分。在代码发生修改时,重新推送jar包到maven仓库,代码中的maven加载器动态刷新插件jar包,并重新加载子容器,此时意外发生了,jvm crash,多次试验,java虚拟机不是crash就是报ClassNotFoundException,原因为何?这就是本文要说的:不要在java虚拟机运行时替换正在使用的jar包!

具体原因探索

既然jar包名称和原来的一模一样,jar包里面的类也一致,为什么jvm就加载不到这个jar包里面的类呢?要回答这个问题,我们可以先通过lsof来查看一下某个java进程打开的文件句柄:

lsof | grep java 6213

20190322225128453.png

我们可以看到,这个java进程维护了多个jar包文件的句柄。通过这个,我们可以想到应该是jvm在运行中维护了这些jar包的inputstream,在需要某个类的时候,就从这些inputstream中获取某个类的字节码然后加载。这个维护的inputstream是针对原先旧jar包打开的输入流,如果这时jar包被替换了,那么对应的句柄就会失效,ClassPathXmlApplication在去加载这个jar包并初始化容器便会报错了!

另外我还发现,你把这个jar包删除,但是拷贝一模一样的jar包回去,代码不会出现任何问题,jvm对应的jar包是mem内存映射的方式打开对应的jar包文件的,只要文件内容完全相同(字节数没变),那么就不会出现类找不好或者非法内存访问造成jvm崩溃。

总结

其实,如果jvm程序后面在运行时不需要再从这个jar包加载什么类的话,就算替换了jar包也不会造成什么影响。但是应该没有哪个程序员敢说对要维护的java服务是了如指掌的,加上jvm是按需加载的。我们很难断定jvm在运行过程中就不会再从我们要替换的这个jar包中加载类了。因此,再做jarlink插件加载时,最好不同的子容器之间不要共用同一个jar包,免得一个子模块刷新时,对应的jar包发生SNAPSHOT版本更新,造成后面代码运行崩溃。线上最好使用release版本,并且将jar包拷贝到不同子模块目录下,做jar包之间的物理隔离。

你可能感兴趣的:(动态加载jar包的一个坑)