關于Java性能方面的9個謬論
Java性能問題被冠以某種黑暗魔法的稱謂。一部分是因為其平臺的復雜性，在很多情況下，無法定位其性能問題根源。然而，在以前對于 Java性能的技巧，有一種趨向：認為其由人們的智慧，經驗構成，而不是應用統計和實證推理。在這篇文章中，我希望去驗證一些最荒謬的技術神話。
1. Java運行慢
在所有最過時的Java性能謬論當中，這可能是最明顯的言論。
是的，在90年代和20年代初期，Java確實有點慢。
然而，在那之后，我們有超過10年的時間來改進虛擬機和JIT技術，現在Java整個體系的性能已經快的令人驚訝。
在6個單獨的web性能測試基準中，Java框架占據了24個當中的22個前四的位置。
JVM性能分析組件的使用不僅優化了通用的代碼路徑，而且在優化那些嚴重領域也很有成效。JIT編譯代碼的速度在大多數情況下跟C++一樣快了。
盡管這樣，關于Java運行慢的言論還是存在，估計是由于歷史原因造成的偏見，這個偏見來自當時那些使用Java早期版本的人們。
我們建議，在匆忙下結論之前先保留意見和評估一下***的性能結果。
2. 單行java代碼意味著任何事都是孤立的
考慮以下一小段代碼：
MyObject obj = new MyObject();
對一個Java開發者而言，很明顯能看出這行代碼需要分配一個對象和運行一個對應的構造方法。
從這來看，我們可以開始推出性能邊界。我們知道有一些精確數量的工作必須繼續，因此基于我們的推測，我們可以計算出性能影響。
這兒有個認知偏見，那就是根據以往的經驗，任何工作都需要被做。
實際上，javac和JIT編譯器都可以優化無效代碼。就拿JIT編譯器來說，代碼甚至可以基于數據分析而被優化掉，在這種情況下，該行代碼將不會被運行，因此它就不會有什么性能方面的影響。
而且，在一些Java虛擬機(JVM)中，例如JRockit中,即使代碼路徑沒有完全失效，JIT編譯器為了避免分配對象甚至可以執行分解對象操作。
這段文字在這里的意義就是當處理Java性能方面的問題時，上下文很重要。而且過早的優化可能會產生意料之外的結果。所以為了獲得***的結果，不要試圖過早的優化。與其不斷構建你的代碼不如用性能調整技術去定位并且改正代碼性能的潛在危險區。
3. 一個微基準測試意味著你認為它是什么
正如以上看到的，推理一小段程序比分析應用程序的整體性能更不準確。盡管如此，開發者還是喜歡寫為基準測試。有些人似乎從擺弄平臺的某些低層次方面獲取無窮無盡的內心快感。
理查德·費曼曾說：“***個原則是,不要欺騙自己，而且自己是最容易被騙的人”。沒有比編寫Java為基準測試更切合這個的例子了。
寫好微基準測試是極其困難的。Java平臺很復雜，而且很多微基準測試只對測量瞬態效應或平臺的其他意外方面有效。
例如，一個想當然的微基準測試頻繁地在測量子系統時間或垃圾回收，而不是在試圖捕捉效果時結束。
只有當開發者和團隊有真正基準需求的時候才需要寫微基準測試。這些基準測試應該打包到項目（包括源代碼）隨項目一起發布，并且這些基準測試應該是可重現的并可提供給他人審閱和進一步的審查。
Java平臺的許多優化結果都指的是只運行單一基準測試用例時所得到的統計結果。一個單獨的基準測試必須要多次運行才能得到一個比較趨近于真實答案的結果。
如果你認為到了必須要寫微基準測試的時候，首先請讀一下Georges, Buytaert, Eeckhout所著的”Statistically Rigorous Java Performance Evaluation”。如果沒有統計學的知識，你會很容易誤入歧途的。
網上有很多好的工具和社區來幫助你進行基準測試，例如Google的Caliper。如果你不得不寫基準測試時，不要埋頭苦干，你需要從他人那里汲取意見和經驗。
4.算法慢是性能問題的最普遍原因
在程序員（和普通大眾）中普遍存在一個錯誤觀點就是他們總是理所當然地認為自己所負責的那部分系統才是最重要的。
就Java性能這個問題來說，Java開發者認為算法的質量是性能問題的主要原因。開發者會考慮如何編碼，因此他們本性上就會潛意識地去考慮算法。
實際上，當處理現實中的性能問題時，算法設計占用了解決基本問題不到10%的時間。
相反，相對于算法，垃圾回收，數據庫訪問和配置錯誤會更可能造成程序緩慢。
大多數應用程序處理相對少量的數據，因此即使主算法有缺陷也不會導致嚴重的性能問題。因此，我們得承認算法對于性能問題來說是次要的;因為算法帶來的低效相對于其他部分造成的影響來說是相對較小的，大多的性能問題來自于應用程序棧的其他部分。
因此我們的***建議就是依靠經驗和產品數據來找到引起性能問題的真正原因。要動手采集數據而不是憑空猜測。
緩存能解決一切問題
“關于計算機科學的每一個問題都可以通過附加另外一個層面間接的方式被解決”
這句程序員的格言，來至于David Wheeler（幸虧有因特網，至少有另外兩位計算機科學家），是驚人的相似，特別是在web開發者中。
通常出現這種謬論是因為當面對一個現有的，理解不夠透徹的架構時出現的分析癱瘓。
與其處理一個令人生畏的現存系統，開發者經常會選擇躲避它通過添加一個緩存并且抱著***的希望。當然，這個方法僅僅使整個架構變的更復雜，并且對試圖理解產品架構現狀的下一位開發者而言是一件很糟糕的事情。
夸大的說，不規則架構每次被寫入一行和一個子系統。然而，在許多情況下，更簡單的重構架構會有更好的性能，而且它們幾乎也更易于被理解。
因此當你評估是不是需要緩存時，計劃去收集基本用法統計（缺失率，命中率等）去證明實際上緩存層是個附加值。
6. 所有應用都要考慮到STW
(譯注：“stop-the-world” 機制簡稱STW,即,在執行垃圾收集算法時,Java應用程序的其他所有除了垃圾收集幫助器線程之外的線程都被掛起)
Java平臺的一個存在事實是，所有應用線程必須周期性的停止以便讓垃圾搜集器GC運行。這有時被夸大為嚴重的弱點，即使是在缺少真實證據的情況下。
實證研究已經說明，人類通常無法察覺到頻率超過每200毫秒一次的數字數據的變化（例如價格變動）。
因此對以人類作為首要用戶的應用，一條有用的經驗就是200毫秒或低于200毫秒的 Stop-The-World (STW)停頓通常無需考慮。有些應用（例如視頻流）需要比這個更低的GC波動，但是很多GUI應用不是的。
有少數應用（比如低延遲交易，或者機械控制系統）對200毫秒停頓是不可接受的。除非你的應用屬于那個少數，否則你的用戶察覺到任何由垃圾回收帶來的影響是不太可能的。
值得注意的是，在具有比物理內核更多應用線程的系統中，操作系統任務計劃將會干涉對CPU的時間分片訪問。Stop-The-World聽起來嚇人，但實際上，每個應用（無論是不是JVM）都必須處理對稀缺計算資源的內容訪問。
如果不做測量，JVM的方法對應用性能帶來的額外影響具有何等意義將無法看清。
總體來說，判斷停頓的次數實際對應用的影響是通過打開GC日志的辦法。分析此日志（或者手工，或者用腳本或工具）來確定停頓的次數。然后再判定這些是否確實給你的應用域帶來問題。最重要的是，問自己一個最尖銳的問題：有用戶確實抱怨了嗎？
7. 手工處理的對象池對很大范圍內的應用都是合適的
對Stop-The-World停頓的壞感覺引起一個常見的應對，即在java堆的范圍內，為應用程序組發明它們自己的內存管理技術。經常這會歸結為實現一個對象池（或甚至是全面引用計數）的方法，并且需要讓任何使用了領域對象的代碼參與進來。
這種技術幾乎總是被誤導。它通常具有自身久遠以前的根源，那時對象定位代價昂貴，突然的變化被認為是不重要的。但現在的世界已經非常不同。
現代的硬件具有難以想象的定位效率；近來桌面或服務器硬件的內存容量至少達到了2到3GB。這是一個很大的數字；除了專業的使用情形，讓實際的應用充滿那么大的容量不是很容易。
對象池一般很難正確的實現（特別是有多個線程在工作的時候），并且有幾個消極的要求使得把它作為一般場景使用成為一個艱難選擇：
- 所有接觸到代碼的開發者都必須清楚對象池并正確的處理它
- “對池清醒”代碼與“對池不清醒”代碼之間的界限必須要通曉并明文規定
- 所有這些附加的復雜性必須保持***，并定期評估
- 如果這里任何地方失敗了，無聲損壞的風險（類似C中的指針重用）將被再次引入
總之，只有在GC停頓不能被接受，而且在調試與重構過程中聰明的嘗試也不能縮減停頓到可接受水平的時候，對象池才可以使用。
8. 在GC中CMS總是比Parallel Old更好
Oracle JDK默認使用一個并行的，全部停止（stop-the-world STW)垃圾收集器來收集老年代的垃圾。
另外一個選擇是并發標記清除（CMS）收集器。這個收集器允許程序線程在大部分的GC周期中仍然繼續工作，但它需要付出一些代價和帶來一些警告。
允許程序線程和GC線程一起運行不可避免地導致對象表的變異同時又影響到對象的活躍性。這不得不在發生后進行清楚，所以CMS實際上有兩個STW階段（通常非常短）。
這會帶來一些后果：
- 所有程序線程不得不放進一個安全點并且在每次完全收集時停止兩次；
- 在收集并發運行地同時，程序吞吐量會減少（通常是50%）
- 在JVM從事通過CMS來收集垃圾的總體數據上（包括CPU周期）比并行收集更加高的。
依據程序的情況這些成本或者是值得的或者又不是。但并沒有免費的午餐。CMS收集器是一個卓越的工程品，但它不是***藥。
所以在介紹前，CMS是你正確的GC策略，你得首先考慮Parallel Old的STW是不可接收的和不能調和的。***，（我不能足夠地強調），確定所有的指標都從相當的生產系統上得到。
9. 增加堆內存會解決你內存溢出的問題
當一個應用程序崩潰，GC中止運行時，許多應用組會通過增加堆內存來解決問題。在許多情況下，這可以很快解決問題，并爭取時間來考慮出一個更深的解決方案。然而，在沒有真正理解性能產生的根源時，這種解決策略實際上會使情況更糟糕。
試想一下，一個編碼很爛的應用構造了非常多的領域對象（生命周期大概維持2，3秒）。如果內存分配率足夠高，垃圾回收就會很快地執行，并把這些領域對象放到年老代。一旦進入了老年代，對象就會立即死去，但直到下一次完全回收才會被垃圾回收器回收。
如果這個應用增加其堆內存，那么我們能做的是增加空間，為了存放那些相對短期存在，然后消逝的領域對象。這會使得 Stop-The-World 的時間更長，對應用毫無益處。
在改變堆內存和或其他參數之前，理解一下對象的動態分配和生命周期是很有必要的。沒做調查就行動，只會使事情更糟。在這里，垃圾回收器的老年分布信息是非常重要的。
總結
當說道Java性能調優時直覺通常會誤導人。我們需要經驗數據和工具來幫助我們具象化和了解平臺的特性。
垃圾收集也許提供了這方面***的例子。GC子系統對于調優和生產數據指導調整有驚人的潛力，但對于生產程序它是很難去不借助工具來讓產生的數據有意義。
運行任何Java進程，默認都應該最少有這些標記：
-verbose:gc(打印GC日志）
-Xloggc:（更全面的GC日志）
-XX:+PringGCDetail(更詳細的輸出）
-XX:+PrintTenuringDistribution(顯示由JVM設定的保有閾值）
然后使用工具來分析日志——手寫腳本和一些生成圖，或一個可視化工具如（開源的）GCViewer或JClarity Censum。
英文原文：9 Fallacies of Java Performance
譯文連接：http://www.oschina.net/translate/9_fallacies_java_performance
