Java垃圾收集「真正」的時間比「用戶」 +「系統」

這就是GC如何充滿詳細GC啓用貌似更大 -Java垃圾收集「真正」的時間比「用戶」 +「系統」

13463.547: [Full GC [PSYoungGen: 323053K->0K(325952K)] 
      [PSOldGen: 653170K->331738K(655360K)] 976224K->331738K(981312K) 
      [PSPermGen: 238715K->238715K(264448K)], 385.4631490 secs] 
      [Times: user=2.19 sys=1.35, real=385.50 secs]

實時怎麼能比用戶這麼多的大+ sys？

我的第一個想法是垃圾收集器正在等待資源，但這個資源似乎不是IO或CPU，因爲當發生gc時，「top」輸出不顯示任何cpu或內存問題。

來源

2011-08-30 Artiom Gourevitch

如果它不在IO上等待並且它不受CPU限制，那麼我唯一能想到的其他事情就是等待信號量/互斥量，或者真的非常慢地訪問內存。 – Jonathan

你在你的應用中使用JNI嗎？你的堆的大小是多少，你有多少物理RAM？ – Ron

Xmx = 960 Mb，RAM = 4GB我們使用JNI但不是太頻繁，JNI如何影響垃圾收集？ –

要完整收集，您需要停止所有線程。（它叫停止世界收藏的原因之一）

停止所有線程可能需要很長時間，尤其是如果您擁有數千個線程。每個線程都必須達到「安全點」來停止它。

這種行爲通常意味着你有太多的線程。您也可以考慮ConcurrenntMarkSweep收集器或不需要經常停止應用程序的新的G1收集器。

來源

2011-08-30 16:39:30

這可能是一個線索。長GC發生在啓用Yourkit代理的QA環境中。它可以防止線程達到安全點，因爲我們之前有性能問題。 –

嘗試閱讀本文（更多鏈接包含在白皮書中）：Java 1.5 GC Internals。
我想大多數東西仍然適用於Java 1.6的虛擬機，它可以很好地瞭解GC的工作原理。
另外，請閱讀：Tuning JVM's 1.6 Heap space
（也有另一個白皮書鏈接與說明性基準，但我只是無法找到它:(:(/
我會嘗試，看看它是否彈出某處，但我想這是位於甲骨文網站的某個地方）

一般來說，不要太奇怪，試着嘗試不同的選項，然後看看它是如何工作的，除非你有超過10％的性能增益，並且你的應用程序很關鍵。
原因很簡單：在幾個LOC中簡單的代碼重寫可能會顯着改變GC的行爲。
花點時間盡情玩樂吧！:)

來源

2011-08-30 17:28:55 Kounavi

Java垃圾收集「真正」的時間比「用戶」 +「系統」

回答

相關問題