本案例主要參考狸貓技術窩“從 0 開始帶你成爲JVM實戰高手”系列文章。
以百萬級別的交易系統爲例
上圖爲一個交易系統的核心流程概況
目前系統最大的壓力是創建上百條訂單時候系統的壓力，具體可以考慮下面幾個問題
- 需要多少臺機器
- 機器內存多少
- 如何給JVM分配內存
- JVM中年輕代、老年代等如何分配
預估系統壓力
假設每天100萬個支付訂單，那麼一般用戶交易行爲都會發生在每天的高峯期幾個小時，用100萬平均分配到幾個小時裏，那麼大概是每秒100筆訂單左右，假設部署了三臺機器，每臺機器每秒的壓力是30筆。
如果訂單表只有三個字段（Interger userId、Long createTime、Integer orderId），這樣一共是16個字節。但實際上一個訂單需要有幾十個實例變量，預估爲一個訂單需要500字節的空間。這樣每臺機器每秒的壓力爲500*30約爲15KB。而真實系統中肯定不單單僅有這一個對象，應把預估的結果擴大10-20倍，即每秒創建出的對象約爲1MB。
如何設置堆內存？
上文可知，每秒訂單系統佔用的內存約爲1MB，這樣多次請求Eden區滿後就會觸發MinorGC。以一臺4核8G的機器爲例，這時候分給JVM 4G內存，但是這4G還得分配給方法區、棧和堆等。所以堆分配3G的話比較合適。新生代可以分得大一些，分2G，老年代1G。
案例進一步分析
假如現在要雙十一了，要舉行大促活動。之前系統的壓力最大爲30筆每秒。如果這是驟增爲300筆呢？
這樣每秒對內存的佔用上升到幾十乃至幾百兆，並且由於系統壓力，原來一兩秒就能處理完的請求這時候需要幾十秒。這樣導致新生代堆積了大量的對象，這些對象也都被引用，無法被MinorGC回收，它們就會被轉移到老年代中。而老年代的內存也不是無限的，老年代的回收對性能的影響是極大的。