[[71844]]

Java性能問題被冠以某種黑暗魔法的稱謂。一部分是因為其平臺的復(fù)雜性，在很多情況下，無法定位其性能問題根源。然而，在以前對于 Java性能的技巧，有一種趨向：認(rèn)為其由人們的智慧，經(jīng)驗構(gòu)成，而不是應(yīng)用統(tǒng)計和實證推理。在這篇文章中，我希望去驗證一些最荒謬的技術(shù)神話。

1. Java運行慢

在所有最過時的Java性能謬論當(dāng)中，這可能是最明顯的言論。

是的，在90年代和20年代初期，Java確實有點慢。

然而，在那之后，我們有超過10年的時間來改進虛擬機和JIT技術(shù)，現(xiàn)在Java整個體系的性能已經(jīng)快的令人驚訝。

在6個單獨的web性能測試基準(zhǔn)中，Java框架占據(jù)了24個當(dāng)中的22個前四的位置。

JVM性能分析組件的使用不僅優(yōu)化了通用的代碼路徑，而且在優(yōu)化那些嚴(yán)重領(lǐng)域也很有成效。JIT編譯代碼的速度在大多數(shù)情況下跟C++一樣快了。

盡管這樣，關(guān)于Java運行慢的言論還是存在，估計是由于歷史原因造成的偏見，這個偏見來自當(dāng)時那些使用Java早期版本的人們。

我們建議，在匆忙下結(jié)論之前先保留意見和評估一下***的性能結(jié)果。

2. 單行java代碼意味著任何事都是孤立的

考慮以下一小段代碼：

MyObject obj = new MyObject();

對一個Java開發(fā)者而言，很明顯能看出這行代碼需要分配一個對象和運行一個對應(yīng)的構(gòu)造方法。

從這來看，我們可以開始推出性能邊界。我們知道有一些精確數(shù)量的工作必須繼續(xù)，因此基于我們的推測，我們可以計算出性能影響。

這兒有個認(rèn)知偏見，那就是根據(jù)以往的經(jīng)驗，任何工作都需要被做。

實際上，javac和JIT編譯器都可以優(yōu)化無效代碼。就拿JIT編譯器來說，代碼甚至可以基于數(shù)據(jù)分析而被優(yōu)化掉，在這種情況下，該行代碼將不會被運行，因此它就不會有什么性能方面的影響。

而且，在一些Java虛擬機(JVM)中，例如JRockit中,即使代碼路徑?jīng)]有完全失效，JIT編譯器為了避免分配對象甚至可以執(zhí)行分解對象操作。

這段文字在這里的意義就是當(dāng)處理Java性能方面的問題時，上下文很重要。而且過早的優(yōu)化可能會產(chǎn)生意料之外的結(jié)果。所以為了獲得***的結(jié)果，不要試圖過早的優(yōu)化。與其不斷構(gòu)建你的代碼不如用性能調(diào)整技術(shù)去定位并且改正代碼性能的潛在危險區(qū)。

3. 一個微基準(zhǔn)測試意味著你認(rèn)為它是什么

正如以上看到的，推理一小段程序比分析應(yīng)用程序的整體性能更不準(zhǔn)確。盡管如此，開發(fā)者還是喜歡寫為基準(zhǔn)測試。有些人似乎從擺弄平臺的某些低層次方面獲取無窮無盡的內(nèi)心快感。

理查德·費曼曾說：“***個原則是,不要欺騙自己，而且自己是最容易被騙的人”。沒有比編寫Java為基準(zhǔn)測試更切合這個的例子了。

寫好微基準(zhǔn)測試是極其困難的。Java平臺很復(fù)雜，而且很多微基準(zhǔn)測試只對測量瞬態(tài)效應(yīng)或平臺的其他意外方面有效。

例如，一個想當(dāng)然的微基準(zhǔn)測試頻繁地在測量子系統(tǒng)時間或垃圾回收，而不是在試圖捕捉效果時結(jié)束。

只有當(dāng)開發(fā)者和團隊有真正基準(zhǔn)需求的時候才需要寫微基準(zhǔn)測試。這些基準(zhǔn)測試應(yīng)該打包到項目（包括源代碼）隨項目一起發(fā)布，并且這些基準(zhǔn)測試應(yīng)該是可重現(xiàn)的并可提供給他人審閱和進一步的審查。

Java平臺的許多優(yōu)化結(jié)果都指的是只運行單一基準(zhǔn)測試用例時所得到的統(tǒng)計結(jié)果。一個單獨的基準(zhǔn)測試必須要多次運行才能得到一個比較趨近于真實答案的結(jié)果。

如果你認(rèn)為到了必須要寫微基準(zhǔn)測試的時候，首先請讀一下Georges, Buytaert, Eeckhout所著的”Statistically Rigorous Java Performance Evaluation”。如果沒有統(tǒng)計學(xué)的知識，你會很容易誤入歧途的。

網(wǎng)上有很多好的工具和社區(qū)來幫助你進行基準(zhǔn)測試，例如Google的Caliper。如果你不得不寫基準(zhǔn)測試時，不要埋頭苦干，你需要從他人那里汲取意見和經(jīng)驗。

4.算法慢是性能問題的最普遍原因

在程序員（和普通大眾）中普遍存在一個錯誤觀點就是他們總是理所當(dāng)然地認(rèn)為自己所負(fù)責(zé)的那部分系統(tǒng)才是最重要的。

就Java性能這個問題來說，Java開發(fā)者認(rèn)為算法的質(zhì)量是性能問題的主要原因。開發(fā)者會考慮如何編碼，因此他們本性上就會潛意識地去考慮算法。

實際上，當(dāng)處理現(xiàn)實中的性能問題時，算法設(shè)計占用了解決基本問題不到10%的時間。

相反，相對于算法，垃圾回收，數(shù)據(jù)庫訪問和配置錯誤會更可能造成程序緩慢。

大多數(shù)應(yīng)用程序處理相對少量的數(shù)據(jù)，因此即使主算法有缺陷也不會導(dǎo)致嚴(yán)重的性能問題。因此，我們得承認(rèn)算法對于性能問題來說是次要的;因為算法帶來的低效相對于其他部分造成的影響來說是相對較小的，大多的性能問題來自于應(yīng)用程序棧的其他部分。

因此我們的***建議就是依靠經(jīng)驗和產(chǎn)品數(shù)據(jù)來找到引起性能問題的真正原因。要動手采集數(shù)據(jù)而不是憑空猜測。

緩存能解決一切問題

“關(guān)于計算機科學(xué)的每一個問題都可以通過附加另外一個層面間接的方式被解決”

這句程序員的格言，來至于David Wheeler（幸虧有因特網(wǎng)，至少有另外兩位計算機科學(xué)家），是驚人的相似，特別是在web開發(fā)者中。

通常出現(xiàn)這種謬論是因為當(dāng)面對一個現(xiàn)有的，理解不夠透徹的架構(gòu)時出現(xiàn)的分析癱瘓。

與其處理一個令人生畏的現(xiàn)存系統(tǒng)，開發(fā)者經(jīng)常會選擇躲避它通過添加一個緩存并且抱著***的希望。當(dāng)然，這個方法僅僅使整個架構(gòu)變的更復(fù)雜，并且對試圖理解產(chǎn)品架構(gòu)現(xiàn)狀的下一位開發(fā)者而言是一件很糟糕的事情。

夸大的說，不規(guī)則架構(gòu)每次被寫入一行和一個子系統(tǒng)。然而，在許多情況下，更簡單的重構(gòu)架構(gòu)會有更好的性能，而且它們幾乎也更易于被理解。

因此當(dāng)你評估是不是需要緩存時，計劃去收集基本用法統(tǒng)計（缺失率，命中率等）去證明實際上緩存層是個附加值。

6. 所有應(yīng)用都要考慮到STW

(譯注：“stop-the-world” 機制簡稱STW,即,在執(zhí)行垃圾收集算法時,Java應(yīng)用程序的其他所有除了垃圾收集幫助器線程之外的線程都被掛起)

Java平臺的一個存在事實是，所有應(yīng)用線程必須周期性的停止以便讓垃圾搜集器GC運行。這有時被夸大為嚴(yán)重的弱點，即使是在缺少真實證據(jù)的情況下。

實證研究已經(jīng)說明，人類通常無法察覺到頻率超過每200毫秒一次的數(shù)字?jǐn)?shù)據(jù)的變化（例如價格變動）。

因此對以人類作為首要用戶的應(yīng)用，一條有用的經(jīng)驗就是200毫秒或低于200毫秒的 Stop-The-World (STW)停頓通常無需考慮。有些應(yīng)用（例如視頻流）需要比這個更低的GC波動，但是很多GUI應(yīng)用不是的。

有少數(shù)應(yīng)用（比如低延遲交易，或者機械控制系統(tǒng)）對200毫秒停頓是不可接受的。除非你的應(yīng)用屬于那個少數(shù)，否則你的用戶察覺到任何由垃圾回收帶來的影響是不太可能的。

值得注意的是，在具有比物理內(nèi)核更多應(yīng)用線程的系統(tǒng)中，操作系統(tǒng)任務(wù)計劃將會干涉對CPU的時間分片訪問。Stop-The-World聽起來嚇人，但實際上，每個應(yīng)用（無論是不是JVM）都必須處理對稀缺計算資源的內(nèi)容訪問。

如果不做測量，JVM的方法對應(yīng)用性能帶來的額外影響具有何等意義將無法看清。

總體來說，判斷停頓的次數(shù)實際對應(yīng)用的影響是通過打開GC日志的辦法。分析此日志（或者手工，或者用腳本或工具）來確定停頓的次數(shù)。然后再判定這些是否確實給你的應(yīng)用域帶來問題。最重要的是，問自己一個最尖銳的問題：有用戶確實抱怨了嗎？

7. 手工處理的對象池對很大范圍內(nèi)的應(yīng)用都是合適的

對Stop-The-World停頓的壞感覺引起一個常見的應(yīng)對，即在java堆的范圍內(nèi)，為應(yīng)用程序組發(fā)明它們自己的內(nèi)存管理技術(shù)。經(jīng)常這會歸結(jié)為實現(xiàn)一個對象池（或甚至是全面引用計數(shù)）的方法，并且需要讓任何使用了領(lǐng)域?qū)ο蟮拇a參與進來。

這種技術(shù)幾乎總是被誤導(dǎo)。它通常具有自身久遠(yuǎn)以前的根源，那時對象定位代價昂貴，突然的變化被認(rèn)為是不重要的。但現(xiàn)在的世界已經(jīng)非常不同。

現(xiàn)代的硬件具有難以想象的定位效率；近來桌面或服務(wù)器硬件的內(nèi)存容量至少達到了2到3GB。這是一個很大的數(shù)字；除了專業(yè)的使用情形，讓實際的應(yīng)用充滿那么大的容量不是很容易。

對象池一般很難正確的實現(xiàn)（特別是有多個線程在工作的時候），并且有幾個消極的要求使得把它作為一般場景使用成為一個艱難選擇：

• 所有接觸到代碼的開發(fā)者都必須清楚對象池并正確的處理它
• “對池清醒”代碼與“對池不清醒”代碼之間的界限必須要通曉并明文規(guī)定
• 所有這些附加的復(fù)雜性必須保持***，并定期評估
• 如果這里任何地方失敗了，無聲損壞的風(fēng)險（類似C中的指針重用）將被再次引入

總之，只有在GC停頓不能被接受，而且在調(diào)試與重構(gòu)過程中聰明的嘗試也不能縮減停頓到可接受水平的時候，對象池才可以使用。

8. 在GC中CMS總是比Parallel Old更好

Oracle JDK默認(rèn)使用一個并行的，全部停止（stop-the-world STW)垃圾收集器來收集老年代的垃圾。

另外一個選擇是并發(fā)標(biāo)記清除（CMS）收集器。這個收集器允許程序線程在大部分的GC周期中仍然繼續(xù)工作，但它需要付出一些代價和帶來一些警告。

允許程序線程和GC線程一起運行不可避免地導(dǎo)致對象表的變異同時又影響到對象的活躍性。這不得不在發(fā)生后進行清楚，所以CMS實際上有兩個STW階段（通常非常短）。

這會帶來一些后果：

1. 所有程序線程不得不放進一個安全點并且在每次完全收集時停止兩次；
2. 在收集并發(fā)運行地同時，程序吞吐量會減少（通常是50%）
3. 在JVM從事通過CMS來收集垃圾的總體數(shù)據(jù)上（包括CPU周期）比并行收集更加高的。

依據(jù)程序的情況這些成本或者是值得的或者又不是。但并沒有免費的午餐。CMS收集器是一個卓越的工程品，但它不是***藥。

所以在介紹前，CMS是你正確的GC策略，你得首先考慮Parallel Old的STW是不可接收的和不能調(diào)和的。***，（我不能足夠地強調(diào)），確定所有的指標(biāo)都從相當(dāng)?shù)纳a(chǎn)系統(tǒng)上得到。

9. 增加堆內(nèi)存會解決你內(nèi)存溢出的問題

當(dāng)一個應(yīng)用程序崩潰，GC中止運行時，許多應(yīng)用組會通過增加堆內(nèi)存來解決問題。在許多情況下，這可以很快解決問題，并爭取時間來考慮出一個更深的解決方案。然而，在沒有真正理解性能產(chǎn)生的根源時，這種解決策略實際上會使情況更糟糕。

試想一下，一個編碼很爛的應(yīng)用構(gòu)造了非常多的領(lǐng)域?qū)ο螅ㄉ芷诖蟾啪S持2，3秒）。如果內(nèi)存分配率足夠高，垃圾回收就會很快地執(zhí)行，并把這些領(lǐng)域?qū)ο蠓诺侥昀洗Ｒ坏┻M入了老年代，對象就會立即死去，但直到下一次完全回收才會被垃圾回收器回收。

如果這個應(yīng)用增加其堆內(nèi)存，那么我們能做的是增加空間，為了存放那些相對短期存在，然后消逝的領(lǐng)域?qū)ο蟆＿@會使得 Stop-The-World 的時間更長，對應(yīng)用毫無益處。

在改變堆內(nèi)存和或其他參數(shù)之前，理解一下對象的動態(tài)分配和生命周期是很有必要的。沒做調(diào)查就行動，只會使事情更糟。在這里，垃圾回收器的老年分布信息是非常重要的。

總結(jié)

當(dāng)說道Java性能調(diào)優(yōu)時直覺通常會誤導(dǎo)人。我們需要經(jīng)驗數(shù)據(jù)和工具來幫助我們具象化和了解平臺的特性。

垃圾收集也許提供了這方面***的例子。GC子系統(tǒng)對于調(diào)優(yōu)和生產(chǎn)數(shù)據(jù)指導(dǎo)調(diào)整有驚人的潛力，但對于生產(chǎn)程序它是很難去不借助工具來讓產(chǎn)生的數(shù)據(jù)有意義。

運行任何Java進程，默認(rèn)都應(yīng)該最少有這些標(biāo)記：

-verbose:gc(打印GC日志）

-Xloggc:（更全面的GC日志）

-XX:+PringGCDetail(更詳細(xì)的輸出）

-XX:+PrintTenuringDistribution(顯示由JVM設(shè)定的保有閾值）

然后使用工具來分析日志——手寫腳本和一些生成圖，或一個可視化工具如（開源的）GCViewer或JClarity Censum。

英文原文：9 Fallacies of Java Performance

譯文連接：http://www.oschina.net/translate/9_fallacies_java_performance