在實際工作中，JVM性能問題確實是比較常見的，尤其是Full GC頻繁觸發(fā)的情況，可能導(dǎo)致應(yīng)用響應(yīng)變慢甚至宕機。我可以結(jié)合一個典型案例來講解我是如何分析并解決這類問題的。

案例背景

假設(shè)我們有一個Java Web應(yīng)用，部署在Tomcat上，運行一段時間后發(fā)現(xiàn)系統(tǒng)響應(yīng)時間變長，通過監(jiān)控工具（如Prometheus+Grafana）觀察到Full GC頻繁發(fā)生，每隔幾分鐘就觸發(fā)一次，老年代內(nèi)存占用持續(xù)接近上限。

分析過程

• 初步檢查日志首先查看GC日志（通過JVM參數(shù)-XX:+PrintGCDetails -Xloggc:gc.log啟用）。日志顯示Full GC觸發(fā)頻繁，且每次回收后老年代內(nèi)存僅減少很少，說明存在大量存活對象。示例日志片段：

2025-03-30T10:00:00.123+0800: [Full GC (Ergonomics) [PSYoungGen: 2048K->0K(6144K)] [ParOldGen: 139264K->138500K(139264K)] 141312K->138500K(145408K), 0.1501234 secs]

這里可以看到，老年代從139264K只減少到138500K，幾乎沒釋放空間。

• 內(nèi)存使用分析  

使用jmap -histo:live <pid>生成堆對象統(tǒng)計，查看哪些對象占用內(nèi)存最多。結(jié)果顯示大量java.util.HashMap$Node和自定義的Order對象占據(jù)老年代。

懷疑有內(nèi)存泄漏或緩存未釋放，接下來用jmap -dump:live,format=b,file=heap.bin <pid>導(dǎo)出堆快照，然后用工具（如Eclipse MAT或VisualVM）分析。

• 堆快照分析  在MAT中打開堆快照，發(fā)現(xiàn)一個全局的ConcurrentHashMap（作為緩存）持有大量Order對象引用，且這些對象未被清理。進一步檢查代碼，發(fā)現(xiàn)緩存沒有設(shè)置過期策略，導(dǎo)致訂單數(shù)據(jù)無限累積。
• 驗證觸發(fā)原因  

通過-XX:+PrintGCApplicationStoppedTime確認Full GC確實影響了應(yīng)用停頓時間（每次約150ms）。

檢查JVM參數(shù)：-Xmx512m -Xms512m -XX:MetaspaceSize=128m，堆內(nèi)存偏小，老年代快速填滿后觸發(fā)Full GC。

解決方案

1. 優(yōu)化緩存機制修改代碼，給ConcurrentHashMap添加過期策略，比如使用Caffeine或Guava Cache，設(shè)置TTL（Time-To-Live）為1小時：

Cache<String, Order> orderCache = Caffeine.newBuilder()
    .expireAfterWrite(1, TimeUnit.HOURS)
    .maximumSize(10000)
    .build();

這確保緩存不會無限制增長。

2.調(diào)整JVM參數(shù)  

根據(jù)業(yè)務(wù)負載，將堆內(nèi)存調(diào)整為-Xmx2048m -Xms2048m，增大老年代空間，同時啟用CMS垃圾收集器（-XX:+UseConcMarkSweepGC）減少Full GC停頓時間。

3.監(jiān)控驗證  

部署調(diào)整后的應(yīng)用，觀察GC日志和響應(yīng)時間。Full GC頻率顯著降低（從幾分鐘一次變?yōu)閹仔r一次），老年代內(nèi)存占用穩(wěn)定在50%左右，應(yīng)用性能恢復(fù)正常。

總結(jié)

通過GC日志定位問題、堆分析工具找出根因，最終結(jié)合代碼優(yōu)化和JVM參數(shù)調(diào)整解決問題。遇到類似問題時，建議先從日志入手，再用工具深入分析，最后針對性優(yōu)化，既要治標（調(diào)整參數(shù)）也要治本（修復(fù)代碼邏輯）。