1. 系統崩潰前的現象
- 垃圾回收時間延長：從原本的約10ms增長至50ms，Full GC時間也由0.5s增加至4-5s。
- Full GC頻率增加：最短間隔可縮短至1分鐘內發生一次。
- 年老代內存持續增長：即使經過Full GC，年老代內存未見明顯釋放。
- 系統響應遲緩直至崩潰：最終因內存耗盡引發OutOfMemoryError錯誤。
2. 生成堆Dump文件
- 使用JMX或jmap：當有JMX監控時，可通過其MBean生成堆信息文件（如3GB的hprof文件）。若無JMX，可利用Java自帶的
jmap命令實現。
3. 分析Dump文件
- 工具選擇：起初嘗試了Visual VM、IBM HeapAnalyzer和JDK自帶的Hprof工具，但這些工具或是無法直觀展示內存泄漏，或是處理大文件能力有限。
- 采用MAT：最終選用Eclipse Memory Analyzer Tool (MAT)，它能清晰展示疑似內存泄漏的對象、內存占用最大的對象以及它們之間的調用關系。在此案中，發現大量未關閉的JbpmContext實例存儲于ThreadLocal中，這是由JBPM的Context管理不當所致。
4. 深入分析內存泄漏
- 利用MAT和JMX：不僅能識別內存泄漏的具體對象，還能分析線程狀態，幫助定位系統性能瓶頸，如識別線程阻塞源。
5. 問題回歸與解答
-
為何垃圾回收時間增長？
答：隨著內存中無法回收對象的增多，垃圾回收的復制部分所需時間增加，因為每次回收都需要處理更多未被清理的對象，導致整體回收時間延長。 -
為何Full GC頻次增多？
答：內存累積占用，尤其是年輕代對象不斷轉移到年老代，導致年老代空間緊張，系統不得不頻繁執行Full GC以騰出空間給新對象。 -
年老代內存為何持續膨脹？
答：年輕代中的內存由于未能有效回收，逐漸堆積并轉移至年老代，造成年老代內存占用持續增大。
解決方法總結
- 定位問題：使用專業工具（如MAT）分析堆轉儲文件，識別內存泄漏的具體源頭。
- 代碼審查與修復：針對發現的問題（如未關閉的資源），修正代碼邏輯，確保資源得到有效管理與釋放。
- 優化配置：根據應用特性調整JVM參數，如適當增大年輕代空間，減少對象過早晉升到年老代的可能性。
- 持續監控：實施定期的內存監控與分析，及早發現潛在的內存泄漏問題，防止系統崩潰。
)
