您好，我是湘王，這是我的CSDN博客，歡迎您來，歡迎您再來～

---

上回說到了年輕代和老年代的兩個垃圾回收器：ParNew和CMS，并且將CMS的GC過程也一并介紹了，現在來看個訂單系統的案例。

假設有這樣的訂單系統：

1、每日億級流量，500萬DAU，每日50萬單集中在4小時高峰期；

2、大促（如雙11）期間，就可能產生1000單/秒的峰值；

3、假設需增加3臺機器，平均300單/臺，4C8G。

案例目標：優化JVM，盡量避免Full GC。

按500單/秒的請求來估算的話，也就是：

500 * 1K * 20倍（單個開銷） * 10倍（相關對象） = 100M

即每秒會產生100M（垃圾）。

按此消費水平，內存模型是：

1、4C8G內存，JVM內存 = 物理內存 / 2 = 4G內存；

2、JVM堆分配3G（年輕代1.5G，老年代1.5G）；

3、JVM棧每線程分配1M；

4、剩余內存再配置其他JVM參數

所以常規的JVM參數配置就是這樣的：

-Xms3072M -Xmx3072M -Xmn1536M -Xss1M -XX:MetaspaceSize=256M -XX:MaxMetaspaceSize=256M

但按此配置，年輕代15秒后就會被填滿。

所以稍稍調整下，增加-XX:SurvivorRatio參數：

-Xms3072M -Xmx3072M -Xmn1536M -Xss1M -XX:MetaspaceSize=256M -XX:MaxMetaspaceSize=256M -XX:SurvivorRatio=8

-XX:SurvivorRatio=8，導致Eden只有1.2G，會提前觸發Minor GC：

接下來可以再考慮優化Survivor。它的問題是：

1、會經常出現Survivor空間不足而直接進入老年代；

2、超過Survivor空間50%規則（會直接進入老年代）。

建議：

1、調整年輕代和老年代空間大小；

2、因為普通業務系統的大部分對象生成周期都很短，根本不應該頻繁進入老年代；

3、盡量讓對象留在年輕代里。

因此，對于任何系統，首要考慮的就是盡量讓對象都留在Survivor里。調整后的JVM配置：

-Xms3072M -Xmx3072M -Xmn2048M -Xss1M -XX:MetaspaceSize=256M -XX:MaxMetaspaceSize=256M -XX:SurvivorRatio=8

同時，可以降低進入老年代的“年齡”大小，給Survivor騰空間。調整后的JVM配置：

-Xms3072M -Xmx3072M -Xmn2048M -Xss1M -XX:MetaspaceSize=256M -XX:MaxMetaspaceSize=256M -XX:SurvivorRatio=8 -XX:MaxTenuringThreshold=5

另一方面，為了不讓過大的對象進入老年代，可以考慮對進入老年代的對象大小進行調整，當有超過指定大小的內存對象時，就直接進入老年代。調整后的JVM配置：

-Xms3072M -Xmx3072M -Xmn2048M -Xss1M -XX:MetaspaceSize=256M -XX:MaxMetaspaceSize=256M -XX:SurvivorRatio=8 -XX:MaxTenuringThreshold=5 -XX:PretenureSizeThreshold=1M

之前說過默認超過Survivor空間大小的50%時，存活對象就會進入老年代，因此這里也可以優化。調整后的JVM配置：

-Xms3072M -Xmx3072M -Xmn2048M -Xss1M -XX:MetaspaceSize=256M -XX:MaxMetaspaceSize=256M -XX:SurvivorRatio=8 -XX:MaxTenuringThreshold=5 -XX:PretenureSizeThreshold=1M -XX:TargetSurvivorRatio=50

最后別忘了指定GC，年輕代用ParNew，老年代用CMS。調整后的JVM配置：

-Xms3072M -Xmx3072M -Xmn2048M -Xss1M -XX:MetaspaceSize=256M -XX:MaxMetaspaceSize=256M -XX:SurvivorRatio=8 -XX:MaxTenuringThreshold=5 -XX:PretenureSizeThreshold=1M -XX:TargetSurvivorRatio=50 -XX:+UseParNewGC -XX:+UseConcMarkSweepGC

那么各位可以根據這個思路，估算一下自己公司的生產系統，合理設置并優化JVM參數。

總結一下：

1、對象進入老年代的一般規律：

• -XX:MaxTenuringThreshold=N，該參數值讓年輕代對象躲過N次GC之后進入老年代。這些對象一般是@Entity、@Component、@Service、@Controller等注解標注出來的系統組件；

• -XX:PretenureSizeThreshold=1M，年輕代中超過該值的對象就進入老年代；

• -XX:TargetSurvivorRatio=50，Minor GC后存活對象的總大小如果超過該值就進老年代。

2、什么時候會觸發Full GC？

• -XX:HandlePromotionFailure，該參數沒打開時觸發Full GC（JDK1.6后已廢棄）；

• 老年代可用空間＜歷次Minor GC后進入老年代的對象的平均大小時觸發Full GC；

• 老年代可用空間＜要進入的老年代的存活對象大小時觸發Full GC；

• -XX:+UseCMSCompactAtFullCollection和XX:CMSInitiatingOccupancyFraction=92，老年代可用空間超過該值時觸發Full GC，這兩個必須配對出現（JDK1.8已不建議使用）。

大促期間，真正的系統壓力峰值時間是有限的，比如持續2小時。如果JVM能做到500單/秒，大約1小時才觸發一次Full GC，那么峰值過后，JVM的壓力就會小很多，就不會觸發Full GC了。

3、老年代GC時發生Concurrent Mode Failure的問題。

• 當老年代使用空間超過92%時進行CMS，可用空間不足100M；

• 有一批存活對象要進入老年代，大小200M；

• 此時就發生Concurrent Mode Failure；

• 但這種概率極小，不需要為極小概率事件調整JVM參數設置；

• 也沒有必要修改執行多少次Full GC之后進行碎片清理，因為經過優化后， Full GC執行次數大大降低了。

那么訂單系統的最終配置是：

---

感謝您的大駕光臨！咨詢技術、產品、運營和管理相關問題，請關注后留言。歡迎騷擾，不勝榮幸～

總結

以上是生活随笔為你收集整理的JVM系统优化实践（8）：订单系统的垃圾回收案例的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。