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
著作權歸作者所有，轉載請聯系作者獲得授權，並標注“簡書作者”。