可能的內存泄漏？

Question

我有一個正在運行的java webapp，我正在使用visualVM進行監控。

這是堆的圖：

用兩組請求測試，一組在3:20，另一組在4:40 aprox（它們在圖中表示為唯一的兩個峰）。

我的問題是：這是否意味着我有內存泄漏？ 我擔心中間部分，盡管GC運行，堆仍然一直保持在250MB。

非常感謝您的見解。

Answer 1

3:20的第一個請求導致了一些內存，但請注意第二個請求后的GC回收了大部分內存。 另外我認為主要GC僅在4:40的第二次請求之后才執行。

看起來沒有泄漏。 我的理論是，3：20的請求導致年輕一代填滿，由此產生的次要GC將一些對象提升到老一代。 由4:40的請求引起的下一個主要GC清除了大部分。

您可以使用分析器在發出與3:20處的請求相同的請求之前標記堆，強制執行完整的GC，然后檢查哪些對象處於延遲狀態來驗證這一點。 我不確定VisualVM是否允許您（1）標記堆並且（2）強制使用完整的GC，但OptimizeIt曾經這樣做過。

Answer 2

你是說在3:20之前沒有請求嗎？ 如果是這樣，我會說我沒有看到任何泄漏的證據。

我不知道你的應用程序，但它是典型的（基於體系結構/設計）一些對象，它們會在第一次使用應用程序時初始化JVM的生命周期。

Answer 3

您使用的JRE是什么？ 將哪些堆/ GC相關參數傳遞給應用程序？

峰值並不差（如果服務器有更多的待辦事項，那么峰值增加是有道理的）。 但是看起來不太好，4：40之后的水平（當負荷再次低時）隨着負荷上升之前的水平而升高。 但它不需要......

現在您應該查看更多細節，哪些對象或對象圖保存在堆中。 所以再次進行相同的測試運行，包括（使用分析器）：

• 在負載上升之前獲取堆快照
• 在負載下降后獲取堆快照（確保執行手動GC觸發器）

現在你應該分析差異，以及你是否看到了奇怪的物體，這些物體本應該被塗抹。

Answer 4

JvisualVM允許您強制進行垃圾回收。

嘗試使用它來看看會發生什么。

Answer 5

這里的內存泄漏是什么意思？ 我認為任何像SUN這樣的JVM實現都不會有這樣一個瘋狂的bug。 當你沒有引用內存位置（僵屍）或者你沒有任何回收它的可能性時，理想情況下使用內存泄漏字。 如果你有錯誤的編程習慣，你持有對不再使用的對象的引用，並且它們在更大的范圍內（生命周期），那么你會占用更多的內存而不給GC重新收集它的選項。