第五章   調優案例分析與實戰 5.1   高效能硬體上的程式部署策略       在高效能硬體部署程式，目前主要有兩種方式： 1) 通過64位JDK來使用大記憶體； 2) 使用若干個32位虛擬機器建立邏輯叢集來利用硬體資源。       對於第一種方式，需考慮以下可能面臨的問題：

• 記憶體回收導致的長時間停頓；
• 現階段，64位JDK的效能測試結果普遍低於32位JDK；
• 需要保證程式足夠穩定，因為這種應用若產生堆溢位幾乎無法產生堆轉儲快照(因為要產生幾十G甚至更大的dump檔案)，即使產生了快照也無法進行分析；
• 相同的程式在64位JDK中消耗的記憶體一般比在32位JDK大，這是由指標膨脹及資料型別對齊補白等因素導致的。

      對於第二種方式，也需考慮如下問題：

• 儘量避免節點競爭全域性資源，如磁碟競爭，各節點若同時訪問某個檔案的話，很容易導致I/O異常；
• 很難最高效率地利用某些資源，如連線池，一般都是在各節點建立自己獨立的連線池，這可能導致一些節點池滿了而另外一些節點仍有較多的空餘；
• 各節點不可避免的收到32位的記憶體限制，32位windows平臺每個程序最多隻能使用2GB記憶體；
• 大量使用本地快取的應用，在邏輯叢集中會造成較大的記憶體浪費，因為每個邏輯節點都有一份快取，可考慮把本地快取改為集中式快取。

5.2   叢集間同步導致的記憶體溢位       使用類似JBossCache叢集快取來進行同步時，可以允許讀操作頻繁，因為資料在本地記憶體有一份副本，讀取的操作不會耗費多少資源，但不應有過於頻繁的寫操作，這會帶來很大的網路同步開銷。 5.3   堆外記憶體導致的記憶體溢位錯誤

       虛擬機器回收的記憶體包括堆記憶體和非堆記憶體，但是對於非堆記憶體，只能等到老年代滿了後Full GC，然後才會幫它清理掉廢棄的物件，否則，就會丟擲記憶體溢位異常。另外，若打開了-XX:+DisableExplicitGC，則虛擬機器不會對其進行回收。        從實踐經驗的角度出發，除了Java堆和永久代之外，我們還應關注以下區域也會佔用較多的記憶體，都受到作業系統的最大記憶體限制：

• Direct Memory：可通過-XX:MaxDirectMemeorySize調整大小，記憶體不足時丟擲OutOfMemoryError或OutOfMemoryError:Direct buffer memory；
• 執行緒堆疊：可通過-Xss調整大小，記憶體不足時丟擲StackOverFlowError或StackOverFlowError:unable to create new native thread；
• Socket快取區：每個Socket連線都Recieve和Send兩個快取區，分別佔大約37KB和25KB，無法分配時丟擲IOException:Too many open files；
• JNI程式碼：若程式碼中使用JNI呼叫本地庫，那本地庫使用的記憶體也不在堆中；
• 虛擬機器和GC：虛擬機器和GC程式碼的執行也要耗費一定的記憶體。

5.4   外部命令導致系統緩慢        通常情況下，使用者應用的CPU佔用率應該佔主要地位，才能說明系統是正常工作的。在Java虛擬機器中，使用者編寫的Java程式碼最多隻有執行緒的概念，不應當有程序的產生。 5.5   伺服器JVM程序崩潰 5.6   實戰：Eclipse執行速度調優

• 調優前的程式執行狀態：運用VisualVM及其擴充套件外掛VisualGC進行Eclipse執行狀態的採集；
• 升級JDK的效能變化及相容問題：進行Exclipse調優時首先選擇升級虛擬機器的版本；
• 編譯時間和類載入時間的變化：虛擬機器在進行類載入時會進行位元組碼驗證，可通過引數-Xverify:none方式禁止掉位元組碼的驗證過程以提高載入效能；對於編譯時間可通過引數-Xint禁止編譯器動作，這雖然提高了編譯效率，但是卻降低了執行效率；
• 調整記憶體設定控制垃圾收集頻率：Eclipse啟動時Full GC大多數是由於老年代容量擴容而導致的，由永久代空間擴充套件而導致的也有一部分，為了避免因擴充套件帶來的效能浪費，可以把-Xms和-XX:PermSize的引數值分別設定為-Xmx和-XX:PermSizeMax引數值，強制虛擬機器在啟動時把老年代和永久代的容量固定下來，避免執行時自動擴充套件；
• 選擇收集器降低延遲。

核心內容出處：《深入理解Java虛擬機器:JVM高階特性與最佳實踐》