別用Java 7？你是在開玩笑嗎？
Java 7 剛剛發布沒兩天，但來自Lucene 和Solr 社區的某些人立即報料了一些Java 7 中的嚴重bug。甚至 Apache Lucene 項目管理委員會成員Uwe Schindler 發布了暫時不要使用Java 7 的警告信息。那么到底Java 7 是有什么問題，為什么我們等了5 年的 Java 7 現在卻不能使用呢?讓我們來看看實際的情況：
51CTO推薦專題：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 似乎也正在準備下一個補丁版本，但對一些高級用戶來說，這些都不是問題，因為源碼是開放的，你可以做你想做的。
本文譯自 http://blog.eisele.net/2011/07/dont-use-java-7-are-you-kidding-me.html
【編輯推薦】
