Java 7剛剛發布沒兩天，但來自Lucene和Solr 社區的某些人立即報料了一些Java 7中的嚴重bug。甚至Apache Lucene項目管理委員會成員Uwe Schindler發布了暫時不要使用Java 7的警告信息。那么到底Java 7是有什么問題，為什么我們等了5年的Java 7現在卻不能使用呢？讓我們來看看實際的情況。

這個問題跟Java 7無關，而是跟JVM有關

首先這個問題是跟HotSpot JVM有關，而不是Java 7語言本身的問題。此次發布的GA版本包含三個bug：7070134, 7044738和7068051，這三個bug直接導致JVM崩潰或者進行錯誤的計算。

Hotspot是因為PorterStemmer的sigsegv而崩潰的

第一個問題(7070134)是關于錯誤的編譯器對循環的優化，該特性在Hotspot JVM中是默認啟用的，你可以通過-XX:-UseLoopPredicate參數來關閉這個特性。如果你想了解關于這個問題的詳情，請看Stemmer.java，編譯并允許這個類你將會重現JVM崩潰并報嚴重錯誤，信息如下：

代碼：

# A fatal error has been detected by the Java Runtime Environment:  
#  
#  EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x00000000026536da, pid=5432, t  
id=6568 
#  
# JRE version: 7.0-b135  
# Java VM: Java HotSpot(TM) 64-Bit Server VM (21.0-b05 mixed mode windows-amd64  
compressed oops)  
# Problematic frame:  
# J  Stemmer.step4()V 

這個錯誤直接在代碼執行過程中發生，在JDK 1.6是體驗不到的。而最近Lucene做了一些更靈活的基于PulsingCodec算法的索引機制，而這個機制相當大的程度上會導致上述的錯誤。

循環展開優化會導致不正確的結果

第二個bug(7044738)是“錯誤的計算”，這個錯誤極為罕見的發生在OSR(On-Stack Replacement)編譯嵌套循環上，控制流退出且對應的內存沒有被考慮到，這直接導致重復的克隆結果，想了解編譯細節請看older overview (PDF)

一個最簡單的解決辦法就是使用-XX:LoopUnrollLimit=1參數來避免這個問題。

Clone loop predicate during loop unswitch

第三個bug(7068051)跟一些老的feature request相關，由于一些無效的JVM統計導致使用循環優化后的JVM崩潰。

結論

根據這些bug的情況，只有在你大量的使用這些優化方法，那么你才可能已經受Java 7中存在的問題所影響。一般情況下是不受影響的。事實上Java 6的用戶使用了某些優化選項也會存在問題，但因為這些優化選項在Java 7中是默認啟用的才導致這個問題影響那么大，例如(-XX:+OptimizeStringConcat or -XX:+AggressiveOpts)，由于這些問題在Java 7發布的前5天才被發現，因此Oracle來不及解決這些bug，目前Oracle似乎也正在準備下一個補丁版本，但對一些高級用戶來說，這些都不是問題，因為源碼是開放的，你可以做你想做的。



360知識網