我的公司支持團隊告訴我，當打開-verbose:gc時，某些版本的java會對性能產生重大影響。但是我無法弄清楚這是否是這種情況。什麼版本的java對於gc日誌記錄很慢？
這個記錄在某個時刻是否緩慢（ish），什麼時候停止？
我之所以會問，是因爲將此應用於生產環境以調查潛在的內存泄漏（以及我們是否可以停止定期重新啓動系統......）存在一些猶豫。
具體來說，我正在談論Java 1.4.2，我認爲它引入了參數，以及它適用的是什麼服務包。
我建議你做到以下幾點：
寫一些基準，很可能強調垃圾收集。 （創建具有弱引用的大型鏈接數據結構等等）。
在某些測試框上安裝與您在生產中使用的相同版本JVM的副本。
使用各種GC日誌記錄設置運行基準測試，包括要在生產中運行的設置，測量對基準測試的性能影響。
如果你這樣做的話，它會給你一些關於可能對你的生產服務器性能產生影響的可靠證據。
我知道你問過詳細的影響：gc（Amir是正確的），但基於評論我看到你正在調查內存泄漏。
您是否可以獲取環境的直方圖？詳細的GC只會告訴你存在內存泄漏，而不是內存所在的位置。
你提到java 1.4.2，是你目前的版本嗎？如果您使用的是1.5或更高版本，則可以使用
jmap -histo <pid> > file.txt
這將爲您提供內存中所有對象的細分。您將凍結您的JVM一段時間，這取決於系統中的內存量。 （2GB甚至更好的硬件可以凍結一分鐘左右）首先在一個開發系統上進行測試。我知道你不想影響你的生產環境，但這是找到問題根源的必要罪惡。在定期重新啓動前執行捕捉，以汲取影響。
這是他們說的嗎？根據我的經驗，有一半的時間他們不知道他們在說什麼。在沒有證據的情況下，這種說法只是八卦。 – msw 2010-08-20 00:04:50
這個特別的支持人員足夠可靠使得這個權證得到進一步的調查。然而，有可能這只是垃圾收集的一些其他方面，可以改變爲嚴重影響性能。我當然不記得那麼久。 – Stephen 2010-08-20 00:11:38
我擔心你誤會了我的觀點。我毫不懷疑你的支持者相信這是真實的，當然，伐木總是比不伐木慢。你沒有提到你爲什麼在意，所以這個問題可以被表達爲一種歷史的好奇心，這會產生更直接的答案。 – msw 2010-08-20 00:22:07