高编译低运行错误(ConcurrentHashMap.keySet)
问题
本地使用maven编译和运行时一切都正常,但是通过ci的方式,编译、打包、发布到部署环境,运行时抛出了一条一眼便知是关于JDK版本的错误。
错误是这个样子:
1 | java.lang.NoSuchMethodError: java.util.concurrent.ConcurrentHashMap.keySet() |
报的是的NoSuchMethodError的错误,且是关于java.util.concurrent.ConcurrentHashMap的。所以不难排查出原因是ci使用了JDK 8来进行编译,导致生成的字节码包含了JDK 8更改的新方法keySet——ConcurrentHashMap$KeySetView这个新增内部类作为其返回值的类型。
为了进一步验证部署服务器上的class文件都是JDK 8编译的,我使用javap这个JDK自带的工具做了如下的验证:
1 | javap -v a.class |grep major |
返回的结果是
1 | major version: 51 |
问题初露端倪,51对应的JDK版本号应该是1.7(或者7),52才是JDK 8的major版本。这里出现了两个疑惑:
- 为什么ci使用JDK 8编译的class会是JDK 7的编译结果?
- 既然是JDK 7编译的class文件,那为何会出现JDK 8才有的内部类?
先看第一个疑惑。之前说到ci也是通过maven compiler plugin进行编译的,pom.xml中可以配置language level如下:
1 | <plugin> |
这实际对应于javac的-source和-target参数,那么这两个参数具体代表什么呢?
1 | javac -help |
source参数指的是源代码级别的语法兼容,而target参数指的是生成release版本的兼容性的class文件,不过只确保目标VM能够加载class文件,却无法保证运行时的正确性。接下来,我们尝试使用javac加上这些参数来编译源码。
首先我们写一段程序,如下:
1 | // App.java |
我本机的java版本是1.8,直接使用javac来编译App.java,结果如下
1 | javac App.java |
如果指定source和target参数,再用javac编译App.java
1 | java -version |
这里有个警告,我们暂时不看。先使用javap反编译App.class,观察major version以及keySet()这个方法的返回值。
1 | javap -v App.class |
这样,第二个疑惑也解开了。可以初步得出一个结论。
小结
在javac指定了这些参数,降低版本号来编译,会导致生成class文件被标识为较低版本以供指定的JVM加载。但是,基于JDK 8的bootstrap class编译而成的keySet()方法,其返回值依旧是JDK 8中ConcurrentHashMap$KeySetView这个新增内部类。运行时,1.7的JVM尝试加载这个class文件,一定找不到KeySetView作为返回值的keySet()方法,出错。
解决方式
既然知道错在那里,就比较容易寻找到解决方案了。
- 编译期间,替换掉bootstrap class
- 使用父类/接口替换子类,即ConcurrentMap替换ConcurrentHashMap声明
编译期间,替换掉bootstrap clas
javac编译时,可以指定bootclasspath,来替换默认的加载路径,如下:
1 | javac -bootclasspath /Library/Java/JavaVirtualMachines/jdk1.7.0_60.jdk/Contents/Home/jre/lib/rt.jar \ |
这时候,再去看看反编译的结果,就会是这样:
1 | ... |
此时major是51(JDK 7),而keySet()的返回值也是JDK 7中的java.util.Set类型了。
使用父类/接口替换子类,即ConcurrentMap替换ConcurrentHashMap声明
上一种方案虽然可行,但是却不实用——因为不能要求ci服务器上有两个不同版本的JDK,也不能要求在maven构建时传递与安装路径如此紧耦合的值作为bootclasspath的参数值。所以可以采取将具体实现类的声明替换成为其接口的方式,如下:
1 | package com.lambeta; |
这样编译好的字节码中就不会有ConcurrentHashMap$KeySetView这样的返回值类型了。在JDK 7上运行时,JVM动态调用的一定是ConcurrentHashMap的keySet():java.util.Set方法了。
结论
- 保证编译、打包环境和最终部署环境JDK版本的一致性
- 如果无法保证,就尽量面向接口编程,尤其是JDK中提供的类。原因是接口不易改变,而实现类遵循“宽收严发”原则,方法的入参和出参都是易变的。