有幾種方法可以改善您的產品。 一種方法是仔細跟蹤用戶的體驗并在此基礎上進行改進。 我們確實自己應用了此技術，并再次花了一些時間查看不同的數據

除了我們追求的許多其他方面之外，我們還提出了一個問題“延遲GC觸發應用程序的最壞情況是什么”。 為了回答這個問題，我們分析了過去兩個月中來自312個連接Plumbr Agent的JVM的數據。 結果很有趣，我們決定與您分享結果：

在X軸上，此JVM中有最大的暫停長度，分為多個存儲區。 在Y軸上，有特定數量的最大暫停的應用程序。 使用上面的數據，我們可以例如對被監控的312個JVM聲明以下內容：

• 57個JVM（18％）設法使GC停頓了一下，最大停頓時間不到256ms
• 73個JVM（23％）面臨的最大GC暫停時間為1024毫秒至4095毫秒
• 由于GC，105個JVM（33％）停止了應用程序線程4秒鐘或更長時間。
• 43個JVM（ 14％ ）面臨的最大GC暫停時間超過16秒
• 18個JVM（ 6％）包含GC暫停時間超過一分鐘
• 由于垃圾回收暫停，當前記錄保存者設法將所有應用程序線程停止了16分鐘以上。

我們確實承認我們的數據可能存在偏見-Plumbr最終監視的JVM更可能遭受觸發更長GC暫停的性能問題。 因此，您需要花些力氣才能得出這些結果，但是總的來說，發現仍然很有趣。 畢竟，對于那里的大多數應用程序，不能認為延遲增加了數十秒。

我們有幾個假設，說明情況為何如此糟糕：

• 在第一種情況下，工程師甚至都沒有意識到他們的應用程序性能如此差。 無法訪問GC日志并與客戶支持隔離開來可能完全使那些可能會改善情況的人員隱瞞問題
• 第二種情況是人們在努力重現問題。 與往常一樣，尋求解決方案的第一步是在可以進行進一步實驗的環境中構建可重現的測試用例。 當持久的GC暫停僅在生產環境中發生時，提出一個解決方案是一項艱巨的任務。
• 第三組問題落在意識到問題的工程師的肩膀上，他們甚至可以隨意重現行為，但不知道如何實際改善情況。 調優GC是一項棘手的任務，需要大量有關JVM內部的知識，因此，在這種情況下，大多數工程師會陷入困境。

好消息是，我們正在努力使所有這些原因都過時-Plumbr發現表現不佳的GC問題，在發現這些問題時提醒您，并且更好地為您提供了量身定制的解決方案，以改善行為。 因此，您無需花費數周的反復試驗，就可以在幾分鐘內浮出水面并解決這些案件。

翻譯自: https://www.javacodegeeks.com/2014/10/revealing-the-length-of-garbage-collection-pauses.html

總結

以上是生活随笔為你收集整理的揭示垃圾收集暂停的时间长度的全部內容，希望文章能夠幫你解決所遇到的問題。

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