1. 需求分析

大促在即，擁有億級流量的電商平臺開發(fā)了一個訂單系統(tǒng)，我們應該如何來預估其并發(fā)量？如何根據并發(fā)量來合理配置JVM參數呢？

假設，現在有一個場景，一個電商平臺，比如京東，需要承擔每天上億的流量。現在開發(fā)了一個訂單系統(tǒng)，那么這個訂單系統(tǒng)每秒的并發(fā)量是多少呢？我們應該如何分配其內存空間呢？先來分析一下

每日億級流量，平均一個用戶點擊量在20-30左右，通過這個計算出日活用戶數約1億/20=500萬, 看的人多，買的人少，通常下單率不超過10%，我們按照留存率10%來計算，日均訂單約50萬單。這是分兩種情況：

一種是普通流量，非特殊節(jié)假日，通常早上、中午、晚上非工作時間有1個小時的時間集中購買。我們按照早上1小時，中午1小時，晚上1小時來計算，也就是3小時。這樣平均到每秒就是50萬/3/3600=46, 也就是及時并發(fā)，通常我們的服務都是一個集群，有好幾臺服務器承受著幾十并發(fā)，應該不成問題。

另一種是大促流量，比如雙十一，基本流量都集中在雙十一當天的投幾分鐘。這時每秒的并發(fā)量大概在50萬/10/60=866，平均每秒并發(fā)量不到1000。這時服務集群有3臺服務器，沒太服務器承受的壓力是400單/s。

2. 常規(guī)方案及問題暴露

對于這每秒400但會產生多大的對象呢？

我們假設訂單對象的大小是1kb，實際上訂單對象的大小和訂單對象中的字段有關系，我們假設是1kb。每秒400單，也就是會產生400kb的訂單對象。下單還涉及到其他對象，比如庫存，優(yōu)惠券，積分等等，我們將對象擴大20倍, 大約是(400kb*20)/秒. 可能同時還有其他操作，比如查詢訂單的操作，我們再講其擴大10倍，大約是80M，也就是每秒產生約80M的對象，這些對象在1s后都會變?yōu)槔?/p>

對于一臺4核8G的服務器來說，通常我們不設置JVM參數，也可能會根據物理機的8G內存來設置JVM參數。如果根據JVM參數來設置參數如何設置呢？

之前說過開啟逃逸分析會將對象分配到棧上，我們這里計算分析的時候暫且忽略逃逸分析分配到棧上的對象，因為這部分對象相對來說比較少。下面我們來驗證上面的預估算法是否準確，會有什么樣的問題呢？

物理機有8G，分給os操作系統(tǒng)3G，分給JVM5G，然后JVM中給堆分配3G，元數據空間分配512M，線程棧分配1M等等。這是估算，不夠精細，到底分配這么多空間夠不夠呢，會不會浪費呢？會產生什么樣的問題呢？

設置jvm參數大致如下：? -Xms3072M -Xmx3072M -Xss1M -XX:MetaspaceSize=512M -XX:MaxMetaspaceSize=512M

這樣設置到底行不行呢？有沒有問題呢？我們來看看運行時數據區(qū)：

根據計算

整個堆空間3G

Eden區(qū)800M

s1/s2各100M

方法區(qū)512M

一個線程1M

按照這個模型來分析，得到如下結果：

大促期間1s產生80M的對象數據。我們知道對象數據都是放在Eden園區(qū)，Eden園區(qū)一共800M，那么大約10s就放滿了，放滿了就會觸發(fā)Minor GC

觸發(fā)Minor GC的期間，會Stop The World暫停業(yè)務線程。在第10s觸發(fā)MinorGC的時候，前9s的720M數據都已經變成垃圾了，會被回收掉，最后1s的80M數據由于還有對象引用，只是暫停了業(yè)務線程，因此不是垃圾，不能被回收。會被放入S1區(qū)。

在Survivor區(qū)有一個對象動態(tài)年齡判斷機制。什么是對象動態(tài)年齡判斷機制呢？

當前放對象的Survivor區(qū)域里(其中一塊區(qū)域，放對象的那塊s區(qū))，一批對象的總大小大于這塊Survivor區(qū)域內存大小的50%(-XX:TargetSurvivorRatio可以指定)，那么此時大于等于這批對象年齡最大值的對象，就可以直接進入老年代了，

例如：Survivor區(qū)域里現在有一批對象，年齡1+年齡2+年齡n的多個年齡對象總和超過了Survivor區(qū)域的50%，此時就會把年齡n(含)以上的對象都放入老年代。這個規(guī)則其實是希望那些可能是長期存活的對象，盡早進入老年代。

對象動態(tài)年齡判斷機制一般是在minor gc之后觸發(fā)的。

也就是說當在Survivor區(qū)經過幾代的回收以后，如果對象總和大于Survivor區(qū)域的一半，則會直接放入到老年代。Survivor是100M，第10s的對象是80M，大于100M，會直接將這個對象放入到老年代。

老年代一共有2G空間，2G空間執(zhí)行多少次會滿呢？2G/80M=25次，也就是發(fā)生25次（25秒）Minor GC就會觸發(fā)一次Full GC。這個頻率就太高了，通常應該要很少觸發(fā)Full GC，起碼也得1個小時觸發(fā)一次。而觸發(fā)的原因是因為垃圾對象（這些對象1s后都變成垃圾了），這樣肯定是不行的。我們需要優(yōu)化JVM參數。

3. JVM優(yōu)化

有問題有就解決問題。問題的根本原因是老年代發(fā)生了Full GC，為什么會發(fā)生Full GC呢？

之所以80M對象會放到了老年代是因為每秒產生的數據 大于 Survivor區(qū)空間的一半。所以，我們可以調整Survivor區(qū)大小。通常我們不會修改默認的Eden：S1：S2的比例，所以，我們可以考慮從整體擴大新生代的內存空間。假設我們擴大到2G，讓老年代是1G。

這時會怎么樣呢？

Young區(qū)占2G，Eden區(qū)有1.6G， S1、S2各有200M。

這時在分析：

Eden區(qū)有1.6G，每秒產生80M的對象放到Eden區(qū)，大約1.6G/80=20s放滿。

放滿以后觸發(fā)Minor GC, 此時前19s的對象都已經成為垃圾被回收，第20s的對象被轉移到S1區(qū)。

此時，S1區(qū)有200M，80<S1區(qū)空間的一半，所以不會轉移到老年代。這樣第一次GC結束

又過了20s，進行第二次Minor GC，這次Eden區(qū)又產生了1.52G的垃圾被回收，之前在S1區(qū)的80M對象也已經變成垃圾被回收。新的80M對象被放入到S2區(qū)。沒有進入到老年代。

以此類推，第三次，第四次，垃圾對象不會再進入老年代，因此也不會在發(fā)生Full GC.

由此分析，大大降低了Full GC發(fā)生的頻率。

最終參數設置：

4. 總結

通過上面的數據分析，我們要養(yǎng)成一個習慣，做任何事情都是要有理有據，不能是拍腦袋就說出來的。一定要能夠經得起驗證的。