這篇文章是關于最近的性能調整練習的。 與往常一樣，這些開始于關于癥狀的模糊表述。 這次，魔鬼采取了“應用程序速度慢，我們無法訪問源代碼的形式。 我們有什么改善情況的選擇”。

對該應用程序進行仔細研究后發現，它由捆綁在一起的幾個批處理作業組成。 深入研究“績效”標準表明，執行特定工作所花費的時間過長。 稍后再仔細檢查，我得到了一個可衡量的目標。 我需要從特定的作業運行時間中抽出兩分鐘，以適應預先分配的時間窗口。

陷入困境的應用程序是一個看起來非常無辜的小型JAR文件。 幸運的是，這也捆綁了負載測試。

在打開GC日志記錄的情況下運行該應用程序（ -XX：+ PrintGCTimeStamps -Xloggc：/path-to/gc.log -XX：+ PrintGCDetails ）并快速查看日志，這是優化的第一個目標。 累積的GC暫停時間總計為三分半鐘，暗示我可能會有機會。

在這種情況下，他可以使用幾種工具，其中一些簡單明了：

• 修改堆/ permgen的大小
• 更改GC算法
• 配置內存區域之間的比率

我采取了改變堆大小的方法。 除了幸運的猜測外，它還基于最近學到的有關實時數據集大小和建議堆大小之間的相關性的課程。 從GC日志中，我還注意到該應用程序的實時數據集約為240m。 因此，根據我最近獲得的知識，此應用程序堆的最佳結合點在720至960m之間。

但是在配置中，我發現-Xmx設置為僅300m。 稍微調整一下參數，我再次運行測試，結果如下：

堆大小 總GC暫停時間 通量

300m	207.48秒	92.25％
384m	54.13秒	97.97％
720m	20.52秒	99.11％
1,440m	* 11.37秒	* 99.55％

*表示此配置在運行期間未觸發Full GC。

現在，如果您查看結果，可能會將結果轉換為“越大越好”。 如果僅以毫秒為單位進行測量，那的確是正確的。 如果成功標準之一與金錢有關，那么可能就不那么容易了。 在大型部署中將數百或數千臺這些機器放在一起，您可能會單單在電費賬單上就感到討厭。

除此之外，本文是性能調優教科書中的教科書案例。 如果您有可衡量的目標，并且可以衡量結果而不是猜測，那么您將成功。 如果我被迫在沒有明確目標或負載測試能力的情況下跳入，那么我仍然會調整配置的隨機位。

參考： 為JVM分配內存：來自我們的JCG合作伙伴 Nikita Salnikov Tarnovski （來自Plumbr Blog博客） 的案例研究 。

翻譯自: https://www.javacodegeeks.com/2014/03/allocating-memory-for-the-jvm-a-case-study.html

總結

以上是生活随笔為你收集整理的为JVM分配内存：一个案例研究的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。