java g1 收集調優

JVM背后發生了什么，垃圾回收如何影響Java性能？

性能調優世界是一個危險的地方，一個JVM標志失衡，事情很快就會變得繁瑣。 因此 ，我們決定求助于Java性能調優專家， 單調 JVM探查器mjprof的創建者Haim Yadid 。 在這篇文章中，我們將分享他在實踐中經受住考驗的一些見解，并了解JVM內部在壓力下的表現。

新帖：Java性能優化–如何最大程度地利用垃圾收集器http://t.co/NnzQpuWBHz pic.twitter.com/8zqMrUfSHl

— Takipi（@takipid） 2015年4月2日

了解您要面對的問題

JVM受到垃圾回收暫停的影響，該暫停的頻率和持續時間各不相同。 在暫停過程中，一切都停止了，各種意外行為開始發揮作用。 當面對一個新的調優項目時，通常會發生以下兩種情況之一：公司已經知道它存在垃圾回收問題，或者很快就會發現它有一個問題。 在此階段，他們很可能會出現暫停，JVM卡住的不穩定行為以及性能普遍下降。 這些癥狀通常是通過響應時間慢，CPU和內存利用率高或系統在大多數情況下正常運行而具有異常行為（例如，極其緩慢的事務和斷開連接）而可見的。

主要陷阱：忽略異常值

可以通過一種常見的錯誤來忽略這種行為，并且不會向任何人發出警報，這是一個常見的錯誤：測量平均交易時間，并忽略異常值。 這就是隱藏GC問題的地方：盡管大多數情況下系統可能表現正常，但有時其他系統的響應能力卻會下降，并給許多用戶帶來不好的體驗。 例如，一個通常需要100毫秒的事務會受到GC暫停的影響，并突然花費幾秒鐘甚至一分鐘。 在電子商務站點中，如果系統的維護人員僅查看平均交易時間，則除用戶以外的任何人都不會注意到這一點。 另一個很容易忽略的問題是，當系統吞吐量受到影響時（例如命中率達到20％），并且它無法發揮其潛力。 您可能永遠不會知道出了什么問題，因為您沒有查看正確的指標。 很多時候，原因是對GC開銷的了解不足，并且只關注平均響應時間的一個指標，而忽略了第99個百分位數。

定義性能要求：頻率和持續時間

這里的主要問題是：您認為應用程序中GC暫停頻率和持續時間的可接受標準是什么？ 例如，每天暫停15秒可能是可以接受的，而30分鐘一次的頻率對產品來說絕對是災難。 這些要求來自每個系統的領域，在這些領域中，實時和高頻交易系統將具有最嚴格的要求。

總體而言，看到15到17秒的停頓并不罕見。 某些系統甚至可能達到40-50秒的暫停，Haim也有機會在具有大量批處理工作的大堆的系統中看到5分鐘的暫停。 因此，暫停持續時間在這里并不重要。

停止世界收集數據：GC日志的重要性

在基于HotSpot JVM的系統中，垃圾收集狀態最豐富的數據源是GC日志。 如果您的JVM沒有生成帶有時間戳的GC日志，那么您就錯過了用于分析和解決暫停問題的重要數據源。 這對于開發環境，登臺，負載測試以及最重要的是在生產中都是如此。 您可以獲取有關系統中所有GC事件的數據，無論這些事件是同時完成的還是導致世界停頓的：這些事件花費了多長時間，消耗了多少CPU以及釋放了多少內存。 從這些數據中，您可以了解這些暫停的頻率和持續時間，它們的開銷，并繼續采取行動來減少它們。

-XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:mygclogfilename.gc

GC日志數據收集的最低設置

從指標來看，5％通常是可接受的GC開銷的上限，而一個應用程序與另一個應用程序之間可接受的暫停時間卻大不相同。

這里值得提及的兩個用于GC日志分析的工具是Github上可用的開源GC Viewer和jClarity的Censum 。

解決方案策略

獲得所需信息后，就可以檢查可能的原因和解決方案了。 您進行的每項更改都要求進行一次新測試，并進行一輪日志收集，以評估其有效性并確定它是否有助于我們前進并達到要求。 優選在生產中和在壓力下。 我們可以通過4種主要方法來解決由GC暫停引起的問題：切換垃圾收集器，調整控制Java堆的標志，進行代碼更改以及使用替代的JVM /收集器。 以下是對HotSpot領域中考慮的方法及其解決的問題類型的快速概述：

1.錯誤的垃圾收集器正在運行

粗略地說，JVM有4個垃圾收集器，您可以選擇在啟動期間使用哪個垃圾收集器。 要了解有關每種類型的更多信息，可以在此處查看比較。 GC問題的常見原因之一是針對您正在開發的應用程序類型使用了錯誤的收集器。 HotSpot的默認值是并行/吞吐量收集器，通常它不是您的應用程序的最佳選擇。 選擇合適的收集器的行為（通過JVM標志）是對系統優先級的聲明，通常是要考慮的第一個問題。 通常，大多數并發的CMS和G1收集器將導致較少的暫停時間。 盡管出現暫停時，其持續時間可能會比Parallel收集器引起的持續時間長，因為它們的后備機制是單線程的（Ouch）。 另一方面，對于相同大小的堆，并行收集器將實現更高的吞吐量。 另一個準則與可預測性有關，如果可預測的性能是一個重要因素并且堆大小不大，那么并行收集器可能就是答案。 并且，如果平均響應時間/延遲是您的重中之重，那么CMS或G1最有可能是答案。

2.調優Java堆

選擇了首選的GC算法之后，該進行一些調整了。 測量（通過GC日志）吞吐量和暫停時間分布，如果對此感到滿意，就可以完成。 如果GC開銷很高（并且吞吐量很低），通常增加堆大小將改善這種情況。 當要解決CMS或G1的長時間停頓時，情況就更加棘手。 造成碎片化的另一個原因是，JVM無法跟上對象從新一代遷移到舊一代的速度，然后需要暫停應用程序對其進行修復。 解決方案是提早啟動GC或增加堆大小。

從經驗來看，堆大小通常在1GB到8GB之間，因此，更大的大小變得更為罕見。 在精簡過程中，通常會在調整過程中將堆大小增加到8GB以上。 較大的堆大小的一個可行原因是，當我們想要創建一個大的緩存時，但這也可以在堆外解決。

讓我們來看另一個示例，以顯示需要調整溢出率的位置。 假設應用程序需要100MB的空間來處理某些請求，而新一代的大小為50MB。 不應該出現在舊一代中的對象將很快到達那里。 需要調整新世代和幸存者空間以解決此問題，并確保壽命短的物體將在新世代中終止其壽命。 影響這里的主要因素是堆大小，新舊發電比，幸存空間大小和最大使用期限閾值–對象移動到舊發電需要多少GC周期。

我們需要考慮的另一個重要因素是應用程序的“實時設置”。 意味著長時間保留在內存中的對象的大小，例如，活動集的示例將是一個應用緩存，其中包含頻繁的數據庫查詢結果集。 在調整JVM時，需要確保“ liveset”可以方便地容納在舊版本中，并且除了消耗之外，該區域還具有足夠的可用內存。 否則，將嚴重破壞JVM的行為，從而導致低吞吐量和頻繁的暫停。

3.架構和代碼更改

一些問題將迫使我們訴諸代碼，甚至可能進行體系結構更改。 我們這里可以解決的麻煩原因之一就是碎片化。 CMS收集器的長時間停頓可能是由舊一代的碎片導致的。 每個GC周期都會釋放舊一代的內存塊，使其看起來像瑞士奶酪，直到片刻JVM 不能處理它為止 。 當JVM將來自新一代的對象移動到比這些“漏洞”更大的對象上，然后必須停止應用程序來解決問題時，就會發生這種情況。 狀態隨時間變化的應用程序必然會導致碎片化。 隨著狀態隨著時間的推移而變化，“舊狀態”對象將從舊版本中釋放，而它們的替換狀態在新一代中創建。 當它最終晉升為老一代時，它可能會不適用于正確的地方，這將導致碎片化。

對這類問題的體系結構解決方案可能是更新對象，將“狀態”移到堆外機制或拆分過程，對延遲敏感的關鍵路徑，其中有許多短期分配的對象到一個進程，大狀態到另一個進程一。

4.備用JVM和垃圾收集器

如果暫停時間對您的應用程序至關重要，并且Hotspot JVM無法提供可接受的響應時間，則還有兩個可能的選擇。 第一個是具有不間斷C4垃圾收集器的Azul Zing JVM 。 為了開始使用Zing，您將需要具有相對較大的計算機，并且堆大小必須從32GB開始。 另一個尚不成熟的選擇，但是如果您喜歡邊緣化，可能值得一試的是Shenandoah GC算法。 它使用一種稱為布魯克轉發指針的技術，該技術可導致超低的暫停時間和合理的開銷。

進一步閱讀：領先的GC專家

為了更深入地了解Garbage Collection和JVM的內部，下面是一些在GC領域最有趣的人：

• 查理·亨特 （ Charlie Hunt ）是Oracle Java平臺小組的成員，也是Java Performance一書的主要作者。
• C4不間斷垃圾收集器的創建者Azul Systems的首席技術官兼聯合創始人Gil Tene 。
• 性能調整和jClarity首席技術官兼聯合創始人Kirk Pepperdine 。
• Monica Beckwitt ，Java / JVM性能顧問。
• Twitter的JVM / GC工程師Tony Printezis ，Oracle的前G1技術負責人。
• Oracle的JVM開發人員Jon Masamitsu 。
• Christine H. Flood和Roman Kennke ，Shenandoah GC算法的開發人員。

結論

垃圾回收是JVM中最引人入勝的主題之一，我們希望本文能幫助您更好地了解各個運動部件。 非常感謝Haim Yadid ，他同意與我們分享他的經驗！ 如果您有任何疑問或想要澄清，請在下面的評論部分中告訴我們。

翻譯自: https://www.javacodegeeks.com/2015/04/java-performance-tuning-getting-the-most-out-of-your-garbage-collector.html

java g1 收集調優

總結

以上是生活随笔為你收集整理的java g1 收集调优_Java性能调优：充分利用垃圾收集器的全部內容，希望文章能夠幫你解決所遇到的問題。

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