Java高编译低运行错误(ConcurrentHashMap.keySet)

碰到相同的问题，纠结了好几个小时。后台通过将java环境切换到1.7解决了。特此转载，记录下：http://www.jianshu.com/p/f4996b1ccf2f

 

问题

本地使用maven编译和运行时一切都正常，但是通过ci的方式，编译、打包、发布到部署环境，运行时抛出了一条一眼便知是关于JDK版本的错误。

错误是这个样子：

java.lang.NoSuchMethodError: java.util.concurrent.ConcurrentHashMap.keySet() 
Ljava/util/concurrent/ConcurrentHashMap$KeySetView;

报的是的NoSuchMethodError: java.util.concurrent.ConcurrentHashMap的错误。所以不难排查出原因是ci使用了JDK 8来进行编译，导致生成的字节码包含了JDK 8更改的新方法keySet(). 其返回值是ConcurrentHashMap$KeySetView这个JDK8新增内部类。

为了进一步验证部署服务器上的class文件都是JDK 8编译的，我使用javap这个JDK自带的工具做了如下的验证：

javap -v a.class |grep major

返回的结果是

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如下：

<plugin>
    <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-compiler-plugin</artifactId> <version>3.5.1</version> <configuration> <source>1.7</source> <target>1.7</target> </configuration> </plugin>

这实际对应于javac的-source和-target参数，那么这两个参数具体代表什么呢？

$ javac -help
-source <release> Provide source compatibility with specified release -target <release> Generate class files for specific VM version

source参数指的是源代码级别的语法兼容，而target参数指的是生成release版本的兼容性的class文件，不过只确保目标VM能够加载class文件，却无法保证运行时的正确性。接下来，我们尝试使用javac加上这些参数来编译源码。

 

首先我们写一段程序，如下：

// App.java
package com.lambeta;
import java.util.concurrent.ConcurrentHashMap;

public class App { public static void main(String[] args) { ConcurrentHashMap map = new ConcurrentHashMap(); map.keySet(); } }

我本机的java版本是1.8，直接使用javac来编译App.java，结果如下

$ javac App.java
$ javap -v App.class |grep major major version: 52

如果指定source和target参数，再用javac编译App.java

$ java -version
java version "1.8.0_45"
...
$ javac -source 7 -target 7 App.java
warning: [options] bootstrap class path not set in conjunction with -source 1.7 1 warning $ ls App.class App.java

这里有个警告，我们暂时不看。先使用javap反编译App.class，观察major version以及keySet()这个方法的返回值。

 

 

$ javap -v App.class
...
major version: 51
...
9: invokevirtual #4 // Method java/util/concurrent/ConcurrentHashMap.keySet:() Ljava/util/concurrent/ConcurrentHashMap$KeySetView; ...

这样，第二个疑惑也解开了。可以初步得出一个结论。

小结

在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，来替换默认的加载路径，如下：

javac -bootclasspath /Library/Java/JavaVirtualMachines/jdk1.7.0_60.jdk/Contents/Home/jre/lib/rt.jar \
-source 7 -target 7 App.java // or javac -Xbootclasspath:/Library/Java/JavaVirtualMachines/jdk1.7.0_60.jdk/Contents/Home/jre/lib/rt.jar \ -source 7 -target 7 App.java

这时候，再去看看反编译的结果，就会是这样：

...
major version: 51
...
9: invokevirtual #4 // Method java/util/concurrent/ConcurrentHashMap.keySet:()Ljava/util/Set;

此时major是51(JDK 7），而keySet()的返回值也是JDK 7中的java.util.Set类型了。

 

使用父类/接口替换子类，即ConcurrentMap替换ConcurrentHashMap声明

上一种方案虽然可行，但是却不实用——因为不能要求ci服务器上有两个不同版本的JDK，也不能要求在maven构建时传递与安装路径如此紧耦合的值作为bootclasspath的参数值。所以可以采取将具体实现类的声明替换成为其接口的方式，如下：

package com.lambeta;
import java.util.concurrent.ConcurrentHashMap;
import java.util.concurrent.ConcurrentMap;

public class App { public static void main(String[] args) { ConcurrentMap map = new ConcurrentHashMap(); map.keySet(); } }

这样编译好的字节码中就不会有ConcurrentHashMap$KeySetView这样的返回值类型了。在JDK 7上运行时，JVM动态调用的一定是ConcurrentHashMap的keySet():java.util.Set方法了。

---

结论

• 保证编译、打包环境和最终部署环境JDK版本的一致性
• 如果无法保证，就尽量面向接口编程，尤其是JDK中提供的类。原因是接口不易改变，而实现类遵循“宽收严发”原则，方法的入参和出参都是易变的。

 

文／lambeta（简书作者）
原文链接：http://www.jianshu.com/p/f4996b1ccf2f
著作权归作者所有，转载请联系作者获得授权，并标注“简书作者”。

转载于:https://www.cnblogs.com/superhedantou/p/5693113.html