最佳化Java堆大小的5個技巧

摘要：Java堆容量不足可以對效能造成很大影響，這樣無疑就給程式帶來不可必要的麻煩，本文總結了影響Java堆容量不足的五大原因以及巧妙地去最佳化？

本文作者Pierre是一名有10多年經驗的進階系統架構師，他的主要專業領域是Java EE、中介軟體和JVM技術。根據他多年的工作實踐經驗，他發現許多效能問題都是由Java堆容量不足和調優引起的。下面他將和大家分享非常實用的5個Java堆最佳化技巧。

1.JVM：對難以理解的東西產生恐懼感

千萬不要以為，通過配置，調優，就可以排除那些你所不明白的問題。有些人認為Java程式員不需要知道內部JVM記憶體管理。毫無疑問，這種觀點明顯是錯誤的，如果想拓寬知識面和提升排除故障能力，你就必須要瞭解和學習一下JVM記憶體管理。

對於Java或者是Java EE新手來說，Java Heap調優和故障排除是一項非常有挑戰的工作。下面會提供一些典型的案例情境：

用戶端環境面臨著有規律的OutOfMemoryError錯誤並且對業務造成了很大的影響。

你的Team Dev要在如此大的壓力下去解決這個問題，通常會怎麼做？

到底是哪裡錯了呢？

首先，沒有摸清問題根源所在？對開發環境沒有正確地進行深層面（規格、負載情況等）理解。網路搜尋是一個非常優秀的學習方法和知識分享工具，但是你必須結合自己的實際項目，從根本上進行分析解決。

可能缺乏基本的JVM和JVM記憶體管理技能，阻止你把所有的點給串連起來。

今天講的第一條技巧是協助你理解基本的JVM原則及其與眾不同的記憶體空間。這些知識都是相當重要的，它可以協助你做出有效調優策略、更加正確合理的預測將來會產生的影響、提前知道未來需要做哪些調優工作。下面來看一下JVM參考指南：

JVM記憶體分為3個記憶體空間

• Java Heap：適用於所有的JVM廠商，通常用來拆分YoungGen（幼苗）和OldGen（終身享用）空間。
• PermGen（永久代）：適用於Sun HotSpot VM（(PermGen空間在Java7或者Java8更新中將會被刪除）
• Native Heap（C-Heap）：適用於所有的JVM廠商。

建議把下面的文章都能看一遍，最好把Sun的Java記憶體管理白皮書和OpenJDKS實現下載下來並仔細閱讀。

• Sun HotSpot VM
• IBM VM
• Oracle JRockit VM
• Sun(Oracle)–Java memory management white paper
• OpenJDK–Open-source Java implementation

正如你所看到的，JVM記憶體管理比使用Xmx設定最大值更為複雜。你需要查看每個角度，包括本地和PermGen需求以及從主機上查看實體記憶體可用性（CPU core）。

在較大的Java Heap和較小的本地Heap比賽中，32位虛擬機器可能會變得相當棘手。試圖在一個32位VM如2.5GB+上設定一個大型堆，根據應用程式佔用和線程數量等因素會增加OutOfMemoryError這個異常拋出。64位JVM可以解決這個問題，但實體資源可用性和記憶體回收成本仍然是有限制的（成本主要集中在GC大小收集上）。最大並不表示是最好的，所以請不要假設在一個16GB的64位虛擬機器上可以運行20個Java EE應用程式。

2.資料和應用程式為王：回顧靜態佔用需求

應用程式以及相關資料將決定Java堆空間佔用需求。通過靜態記憶體，可“預測”下面的記憶體需求：

• 確定將會有多少不同的應用程式部署到預先計劃的一個單獨的JVM進程上，例如有多少個ear檔案、war檔案、jar檔案等。在一個JVM上部署的應用程式越多，對本機堆的需求就越多。
• 確定有多少個類需要在運行時載入：包括第三方API。越多的類載入器和類在運行時被載入，在HotSpot VM PermGen空間和內部JIT相關最佳化對象上的需求就越高。
• 確定資料緩衝佔用，如應用程式載入內部快取資料結構（和第三方API），例如資料庫中的資料緩衝，從檔案中讀取資料等。資料緩衝使用越多，Java Heap OldGen空間需求就越高。
• 確定允許建立的中介軟體線程數量。這是非常重要的，因為Java線程需要足夠的本機記憶體，否則會拋OutOfMemoryError異常。

在JVM進程上部署的應用程式越多，對本地記憶體和PermGen空間的要求就越高。資料緩衝並不是序列化為一個磁碟或資料庫，它將從OldGen空間裡面需要額外的記憶體。

設法對靜態記憶體佔用進行合理的評估，在真正進行資料測試之前，設定一些JVM能力起點是非常有用的。對於32位JVM,通常不推薦一個Java堆大小超過2 GB(-Xms2048m,-Xmx2048m)，對於Java EE應用程式和線程來說這樣將需要足夠的記憶體和本機堆PermGen。

這個評估是非常重要因為太多的應用程式部署在一個32位JVM進程上很容易導致本機堆耗盡；尤其是在多重線程環境。

對於64位JVM， 一個3GB或者4GB的Java堆/JVM進程是推薦的起點。

3.業務流量設定規則：審查動態記憶體佔用需求

業務流量通常會決定動態記憶體佔用。通過觀察各種監控工具可以發現並發使用者與請求產生的JVM GC“心跳”，這是由於頻繁的建立和記憶體回收短期或者長期對象。

一個典型的32位JVM，Java堆大小設定在2 GB(使用分代&並發收集器)通常為500 MB YoungGen分配空間和1.5 GB的OldGen空間。

最大限度地減少重大GC收集的頻率是獲得最佳效能的關鍵因素，所以在高峰的時候理解和評估需要多少記憶體是非常重要的。

再次聲明，應用程式類型和資料將決定記憶體需求。購物車的應用程式類型（長期居住的對象）涉及大型和非序列化會話資料，這個通常需要大型Java堆和很多OldGen空間。無狀態和XML處理（很多短命的對象）繁重的應用程式需要適當YoungGen空間，以盡量減少頻率主要集合。

例如：

你有5個ear應用程式（2000多個Java類）要部署（包含中介軟體代碼）

正如你所看到的一樣，在如此情況下，32位JVM進程就無法滿足。一個典型的解決方案是進行流量拆分，在幾個JVM進程或物理主機（假設有足夠的硬體和CPU core可用）上。

大多數時候，業務流量將推動記憶體佔用。除非你需要大量的資料緩衝來實現適當的效能，典型的門戶應用網站（媒體）繁重的應用程式需求。資料緩衝太多的時候應該用一個黃色的標誌標註一下，最好早點去重新審視一下一些設計項目。

4.量體裁衣

這一條，你應該做到：

如果需要多個JVM（中介軟體）過程。

等一下，這樣做並不足夠。雖然上面的資訊是至關重要的，並且關於Java堆的設定進行了“最佳猜測”，對應用程式的行為進行類比並且進行適當的分析、負載和效能測試來驗證Java堆記憶體要求。

推薦Jprofiler工具給大家，學習如何使用一個分析器的最好方法是正確理解應用程式的記憶體佔用。另一個方法是使用Eclipse MAT工具根據現有的環境進行堆轉儲分析。堆轉儲非常強大，它可以允許你查看和理解Java堆的整個記憶體佔用，包含類載入器相關資料和在記憶體佔用分析中必須要做的，特別是記憶體流失。

Java分析器和堆轉儲分析工具允許你理解和驗證應用程式記憶體足跡，包含記憶體流失的檢測和解決方案。負載測試和效能測試是必不可少的，通過類比並發使用者來驗證早期評估是否正確，它也會把應用程式瓶頸暴露出來並且允許你進行微調。推薦一個非常容易上手的工具：Apache Jmeter。

最後將看一下這樣的情況，應用程式在Java EE環境非常正常，直到有一天完全正常的裝置啟動失敗，例如硬體問題。突然的環境運行能力下降和整體環境下降，到底發生了什嗎？

引起“多米諾效應”的原因有很多，但缺少JVM調優和處理容錯移轉的能力（短期額外負荷）是很常見的。如果JVM進程運行在80% + OldGen空間容量和頻繁的垃圾收集,你如何預期容錯移轉情境?

前面類比的負載和效能測試應該類比這樣的情境，調整你的調優設定使您的Java堆有足夠的緩衝來處理額外的負載(額外的對象)在短期內。這主要適用於動態記憶體佔用，由於容錯移轉意味著將重新導向一些固定的並發使用者給可利用的JVM進程（中介軟體執行個體）。

5.分而治之

這一條的前提是你已經完成了幾十個負載測試。JVM已經不存在泄露，你的應用程式記憶體不能再進行任何減少。你已經嘗試了幾個調優策略，例如使用一個64位的Java堆空間在10GB以上。多個GC策略，儘管這樣，仍然沒有找到合適的可以接受的效能水平？

與當前的JVM規範相比，適當的垂直和水平伸縮，包括在每個物理主機和跨多個主機上建立JVM進程來滿足整個輸送量和容量。如果在幾個邏輯倉、自身的JVM進程、線程和調優值裡打破應用程式列表那麼IT環境的容錯能力將更強大。

“分而治之”策略包括拆分應用程式流程量到多個JVM進程，下面提供一些拆分技巧：

當你發現已經花費了大量的時間在64位JVM進程調優上，是時候該好好審視一下你的中介軟體和JVM部署策略並且利用垂直和水平縮放。這條策略的實現需要更多的硬體支援，但是從長遠角度來看，是非常有效和有益的。（張紅月/編譯）