別用Java 7？你是在開玩笑嗎？
Java 7 剛剛發(fā)布沒兩天，但來自Lucene 和Solr 社區(qū)的某些人立即報料了一些Java 7 中的嚴(yán)重bug。甚至 Apache Lucene 項(xiàng)目管理委員會成員Uwe Schindler 發(fā)布了暫時不要使用Java 7 的警告信息。那么到底Java 7 是有什么問題，為什么我們等了5 年的 Java 7 現(xiàn)在卻不能使用呢?讓我們來看看實(shí)際的情況：
51CTO推薦專題：Java 7正式發(fā)布
這個問題跟Java 7 無關(guān)，而是跟JVM 有關(guān)
首先這個問題是跟HotSpot JVM 有關(guān)，而不是Java 7 語言本身的問題。此次發(fā)布的 GA 版本包含三個bug：7070134, 7044738 和 7068051 ，這三個bug直接導(dǎo)致JVM 崩潰或者進(jìn)行錯誤的計算。
Hotspot是因?yàn)镻orterStemmer 的sigsegv 而崩潰的
第一個問題(7070134) 是關(guān)于錯誤的編譯器對循環(huán)的優(yōu)化，該特性在Hotspot JVM 中是默認(rèn)啟用的，你可以通過 -XX:-UseLoopPredicate 參數(shù)來關(guān)閉這個特性。如果你想了解關(guān)于這個問題的詳情，請看Stemmer.java ，編譯并允許這個類你將會重現(xiàn) JVM 崩潰并報嚴(yán)重錯誤，信息如下：
- # 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
這個錯誤直接在代碼執(zhí)行過程中發(fā)生，在JDK 1.6 是體驗(yàn)不到的。而最近Lucene 做了一些更靈活的基于 PulsingCodec 算法的索引機(jī)制，而這個機(jī)制相當(dāng)大的程度上會導(dǎo)致上述的錯誤。
循環(huán)展開優(yōu)化會導(dǎo)致不正確的結(jié)果
第二個bug (7044738) 是“錯誤的計算”，這個錯誤極為罕見的發(fā)生在OSR (On-Stack Replacement) 編譯嵌套循環(huán)上，控制流退出且對應(yīng)的內(nèi)存沒有被考慮到，這直接導(dǎo)致重復(fù)的克隆結(jié)果，想了解編譯細(xì)節(jié)請看older overview (PDF)
一個最簡單的解決辦法就是使用 -XX:LoopUnrollLimit=1 參數(shù)來避免這個問題。
Clone loop predicate during loop unswitch
第三個bug(7068051) 跟一些老的 feature request 相關(guān)，由于一些無效的JVM 統(tǒng)計導(dǎo)致使用循環(huán)優(yōu)化后的JVM 崩潰。
結(jié)論
根據(jù)這些bug的情況，只有在你大量的使用這些優(yōu)化方法，那么你才可能已經(jīng)受 Java 7 中存在的問題所影響。一般情況下是不受影響的。事實(shí)上 Java 6 的用戶使用了某些優(yōu)化選項(xiàng)也會存在問題，但因?yàn)檫@些優(yōu)化選項(xiàng)在 Java 7 中是默認(rèn)啟用的才導(dǎo)致這個問題影響那么大，例如 (-XX:+OptimizeStringConcat or -XX:+AggressiveOpts) ，由于這些問題在 Java 7 發(fā)布的前 5 天才被發(fā)現(xiàn)，因此 Oracle 來不及解決這些bug，目前 Oracle 似乎也正在準(zhǔn)備下一個補(bǔ)丁版本，但對一些高級用戶來說，這些都不是問題，因?yàn)樵创a是開放的，你可以做你想做的。
本文譯自 http://blog.eisele.net/2011/07/dont-use-java-7-are-you-kidding-me.html
【編輯推薦】
