通過之前相關(guān)JVM的基礎(chǔ)知識(shí)學(xué)習(xí)我們可以結(jié)合一些實(shí)際生產(chǎn)案例來進(jìn)行結(jié)合鞏固和說明殉农，我們?cè)谏暇€一個(gè)生產(chǎn)系統(tǒng)的時(shí)候，針對(duì)預(yù)估的并發(fā)壓力局荚，到底應(yīng)該如何合理的給出一個(gè)未經(jīng)過調(diào)優(yōu)的比較合理的初始值超凳。

另外我們會(huì)分析各種參數(shù)在設(shè)置的時(shí)候有哪些考慮的點(diǎn)，Java堆內(nèi)存到底需要多大耀态？新生代和老年代的內(nèi)存分別需要多大轮傍？永久代和虛擬機(jī)棧分別需要多大？這些我們都會(huì)結(jié)合案例來一步一步的分析首装。

注意：JVM參數(shù)到底該如何設(shè)置创夜，一定是根據(jù)不同的業(yè)務(wù)系統(tǒng)具體的一些場(chǎng)景來調(diào)整的，不是說有一個(gè)通用的配置和模板仙逻，照著設(shè)就沒問題了驰吓，這個(gè)思路是肯定不對(duì)的，一定要結(jié)合案例和業(yè)務(wù)場(chǎng)景來分析系奉。

1.如何抗住雙11一天幾十億的訂單量檬贰？JVM該如何設(shè)置內(nèi)存？

我們先來看一個(gè)數(shù)據(jù)缺亮，2020天貓雙11全球狂歡季實(shí)時(shí)物流訂單總量定格在23.21億翁涤。這是什么概念！一天成交23.21億個(gè)訂單萌踱！更夸張的是天貓訂單在2020年創(chuàng)建峰值達(dá)58.3萬筆/秒葵礼！

image

54.4 萬筆/秒訂單背后的秘密

雙11前兩個(gè)月，阿里巴巴完成了將數(shù)以十萬計(jì)的物理服務(wù)器從線下數(shù)據(jù)中心遷移到云上并鸵。這是一個(gè)浩大的工程鸳粉，但前端的消費(fèi)者毫無感知。

阿里云近三年投入巨大資源研發(fā)出來的神龍服務(wù)器能真，是54.4萬筆/秒訂單的峰值能夠平穩(wěn)度過的保障赁严。54.4 萬筆/秒訂單是什么概念扰柠？阿里云智能基礎(chǔ)產(chǎn)品事業(yè)部研究員張獻(xiàn)濤表示，其他公司可能還在為1000筆/秒的訂單做斗爭(zhēng)疼约。

不可忽視的算力

雙11當(dāng)天卤档，阿里巴巴處理了970PB的數(shù)據(jù)。一個(gè)可以對(duì)比的數(shù)字是程剥，央視拍了幾十年的節(jié)目劝枣，存下來的數(shù)據(jù)是80PB。

支撐雙11大規(guī)模算力的是流計(jì)算系統(tǒng)和飛天大數(shù)據(jù)平臺(tái)织鲸。在系統(tǒng)和商家調(diào)度上舔腾，流計(jì)算系統(tǒng)發(fā)揮了重要作用。比如搂擦，雙11當(dāng)天商家會(huì)提前備貨稳诚，當(dāng)預(yù)測(cè)商家主推的商品賣得太快時(shí)，飛天大數(shù)據(jù)平臺(tái)會(huì)給商家提示改變一下策略瀑踢，不要開場(chǎng)就缺貨扳还；當(dāng)預(yù)測(cè)主推的商品銷量達(dá)不到預(yù)期時(shí)，飛天大數(shù)據(jù)平臺(tái)會(huì)提醒考慮商家發(fā)優(yōu)惠券拉動(dòng)銷量橱夭。

不一樣的雙11

在今年雙11的媒體溝通會(huì)上氨距，阿里巴巴集團(tuán)CTO張建鋒表示，阿里云在技術(shù)上完成了四個(gè)方面核心突破：

第一棘劣、在核心虛擬機(jī)系統(tǒng)上俏让，自研神龍架構(gòu)，用自研的服務(wù)器來做虛擬化茬暇。神龍服務(wù)器在壓力很大的情況下首昔，輸出也是非常線性的。

第二而钞、自研了云原生的數(shù)據(jù)庫(kù)沙廉，今年雙11上拘荡，沒有任何問題臼节。

第三、計(jì)算與存儲(chǔ)做了分離珊皿，數(shù)據(jù)都是從遠(yuǎn)端存取的网缝，存儲(chǔ)可以很方便的擴(kuò)容。

第四蟋定、做了RDMA網(wǎng)絡(luò)粉臊，能夠做到在遠(yuǎn)端存儲(chǔ)，能夠比本地讀寫磁盤更快驶兜。

雙11期間扼仲，近200萬個(gè)容器支撐著電商的核心系統(tǒng)远寸，在商家側(cè)阿里巴巴的技術(shù)團(tuán)隊(duì)為商家快速的擴(kuò)容了5.4萬核，峰值每秒幫助商家處理87萬筆訂單屠凶，向商家提供了410億次的調(diào)用驰后。

這些都是雙十一背后的技術(shù)力量。

2.每日百萬的支付系統(tǒng)應(yīng)該如何設(shè)置JVM內(nèi)存矗愧？

現(xiàn)在的系統(tǒng)基本很多都離不開支付灶芝，那么支付系統(tǒng)的開發(fā)也幾乎是我們必須掌握的一個(gè)技能，這里我們以一個(gè)電商系統(tǒng)的開發(fā)為背景唉韭，針對(duì)一個(gè)日交易量在百萬的支付系統(tǒng)作為一個(gè)實(shí)戰(zhàn)案例來進(jìn)行分析夜涕。

針對(duì)雙11這樣一天的訂單量顯然不僅僅是靠控制JVM內(nèi)存和服務(wù)器臺(tái)數(shù)就能解決的，這里筆者以平均每日百萬量的交易支付訂單來做實(shí)戰(zhàn)案例分析属愤，注意：每日支付訂單量能達(dá)到百萬的也基本上是現(xiàn)在國(guó)內(nèi)最大的互聯(lián)網(wǎng)公司女器，或者是一個(gè)通用型第三方支付平臺(tái)，對(duì)接各種APP的支付交易住诸。

進(jìn)入正題分析：

首先大家正常上網(wǎng)購(gòu)物的流程是：添加商品到購(gòu)物車 → 下單 → 結(jié)算支付 → 顯示支付結(jié)果

而對(duì)于我們的系統(tǒng)開發(fā)來講整個(gè)過程應(yīng)該如何進(jìn)行呢晓避？我們先來看一張之前開發(fā)我做的一張微信支付的全流程圖：

image

是不是感覺有點(diǎn)復(fù)雜？而且這里出現(xiàn)了三個(gè)系統(tǒng)的交互只壳，我們將上圖再精簡(jiǎn)一下俏拱，那么其實(shí)整個(gè)過程就是如下這樣的：

image

這樣一提取是不是感覺非常清晰了？

訂單系統(tǒng)你可以理解為就是我們的電商后臺(tái)系統(tǒng)吼句，而我們的支付系統(tǒng)也可以看做是電商系統(tǒng)中的一部分锅必，不過這部分卻非常重要，通常我們提取出來單獨(dú)作為一個(gè)獨(dú)立的系統(tǒng)進(jìn)行開發(fā)和維護(hù)惕艳。

支付系統(tǒng)是連接消費(fèi)者搞隐、商家（或平臺(tái)）和金融機(jī)構(gòu)的橋梁，管理支付數(shù)據(jù)远搪，調(diào)用第三方支付平臺(tái)接口劣纲，記錄支付信息（對(duì)應(yīng)訂單號(hào)，支付金額等）谁鳍，金額對(duì)賬等功能癞季。

我們把整個(gè)流程從用戶到訂單系統(tǒng)到支付系統(tǒng)以及三方支付系統(tǒng)的流程先梳理下，大家先有個(gè)整體的支付邏輯：

image

1. 用戶提交訂單支付到我們的訂單系統(tǒng)
2. 訂單系統(tǒng)將該支付請(qǐng)求提交給支付系統(tǒng)
3. 支付系統(tǒng)生成一個(gè)支付訂單倘潜，此時(shí)訂單狀態(tài)是“待支付“狀態(tài)绷柒，返回用戶跳轉(zhuǎn)到付款頁(yè)面，選擇支付方式
4. 用戶選擇微信or支付寶確定付款方式
5. 支付系統(tǒng)把實(shí)際支付請(qǐng)求提交到第三方支付渠道：處理請(qǐng)求涮因、資金轉(zhuǎn)移
6. 返回處理結(jié)果废睦，支付系統(tǒng)修改訂單為“已完成"

以上僅僅是我們簡(jiǎn)化的一個(gè)簡(jiǎn)單支付流程，實(shí)際一個(gè)完整支付系統(tǒng)還包含很多東西（比如賬戶管理养泡、對(duì)賬管理嗜湃、清算管理奈应、結(jié)算管理等），我們重點(diǎn)關(guān)注核心的支付流程即可购披。

一個(gè)每日百萬交易的支付系統(tǒng)壓力在哪里钥组？

首先通過上述的流程圖我們知道，用戶提交支付請(qǐng)求今瀑，到訂單系統(tǒng)提交真正的支付訂單到支付系統(tǒng)程梦，那么這個(gè)時(shí)候支付系統(tǒng)才算是真正開始工作以及處理，那么每天有一百萬個(gè)支付請(qǐng)求對(duì)應(yīng)著支付系統(tǒng)就會(huì)接收到一百萬個(gè)支付訂單橘荠，從而要去存儲(chǔ)和處理這一百萬個(gè)支付訂單屿附，那么說的更直白點(diǎn)就是我們的JVM內(nèi)存中每天會(huì)有百萬個(gè)支付訂單對(duì)象需要?jiǎng)?chuàng)建（每個(gè)訂單對(duì)象包含用戶信息、商品信息哥童、支付渠道信息挺份、支付時(shí)間、價(jià)格等各類信息的匯總）,因此我們聚焦在JVM的管理中來看贮懈，每一天我們的JVM內(nèi)存中就會(huì)有上百萬個(gè)支付訂單對(duì)象的創(chuàng)建和銷毀匀泊，那么我們需要思考以下幾個(gè)核心問題：

1. 我們的JVM內(nèi)存空間需要多大才能支撐起這么多訂單對(duì)象的創(chuàng)建？堆內(nèi)存空間是關(guān)鍵朵你，又該分配多少各聘？
2. 每臺(tái)機(jī)器需要多大的內(nèi)存空間，以及需要部署多少臺(tái)機(jī)器抡医？

明確了兩個(gè)核心問題后躲因，我們想要去分析和確定內(nèi)存的分配，就必須知道我們的系統(tǒng)高峰期在哪兒忌傻？因?yàn)橐话銇碇v用戶在購(gòu)物的時(shí)候都會(huì)有個(gè)峰值進(jìn)行購(gòu)買大脉，比如中午和晚上，統(tǒng)計(jì)在一起也就大概幾個(gè)小時(shí)水孩，也就是說在幾個(gè)小時(shí)內(nèi)就能產(chǎn)生差不多一百萬個(gè)訂單镰矿，我們按照4個(gè)小時(shí)來計(jì)算差不多在60~70筆訂單/秒，這里我們直接取整俘种，按照每秒有100筆訂單產(chǎn)生來進(jìn)行計(jì)算和處理秤标。

一個(gè)支付訂單的處理需要多久以及占用多大空間

接下來我們必須要清楚的知道一個(gè)訂單大概要處理的時(shí)間，當(dāng)用戶點(diǎn)擊提交訂單的時(shí)候安疗，這時(shí)會(huì)攜帶訂單相關(guān)參數(shù)到電商后臺(tái)系統(tǒng)抛杨，由電商系統(tǒng)創(chuàng)建訂單够委，并做移除購(gòu)物車商品的操作荐类，以及保存訂單到數(shù)據(jù)庫(kù)的操作等，接著才會(huì)向支付系統(tǒng)發(fā)送當(dāng)前訂單茁帽，整個(gè)過程從發(fā)起請(qǐng)求到創(chuàng)建訂單到支付系統(tǒng)中玉罐，我們粗略計(jì)算為1秒差不多了屈嗤。

那一個(gè)訂單所占據(jù)的對(duì)象大小是多少呢？一般一個(gè)訂單對(duì)象中核心的實(shí)例變量也就20多個(gè)差不多了吊输，根據(jù)基本數(shù)據(jù)類型所對(duì)應(yīng)的字節(jié)大小來計(jì)算饶号，一般一個(gè)訂單對(duì)象也就差不多在500字節(jié)的大小。那每秒100筆訂單到來季蚂，也就是差不多一秒能產(chǎn)生 100*500 = 50000大概也就50KB而已茫船，其實(shí)非常的小。

那么結(jié)合以上兩點(diǎn)分析我們可以知道扭屁，系統(tǒng)每1秒會(huì)來100個(gè)支付訂單算谈，而每個(gè)支付訂單的創(chuàng)建需要1秒，那也就是1秒過后料滥，就會(huì)在內(nèi)存中產(chǎn)生50KB的垃圾對(duì)象然眼，因?yàn)?秒過后這100個(gè)對(duì)象就沒人引用了，成為新生代中的垃圾對(duì)象了葵腹。

image

下一秒過后又會(huì)持續(xù)產(chǎn)生100個(gè)訂單對(duì)象高每，那么接著又繼續(xù)產(chǎn)生50KB的垃圾對(duì)象，如此一來新生代里就會(huì)持續(xù)的產(chǎn)生堆積垃圾對(duì)象践宴，直到裝滿為止觸發(fā)Minor GC進(jìn)行回收鲸匿。

支付系統(tǒng)內(nèi)存占用預(yù)估

按照上述所分析，1秒產(chǎn)生50KB垃圾對(duì)象阻肩，那么100秒就有差不多5MB垃圾對(duì)象了晒骇，可能大家覺得有點(diǎn)不足為懼，但是我們以上僅僅只是分析了一個(gè)支付訂單對(duì)象的占用大小磺浙，實(shí)際運(yùn)行中每秒還會(huì)產(chǎn)生其他大量的對(duì)象（系統(tǒng)本身的+我們攜帶關(guān)聯(lián)的各種對(duì)象）洪囤，所以我們真正要估算內(nèi)存占用的話，還得將之前的計(jì)算結(jié)果放大10~20倍撕氧！

那這樣估算的話瘤缩，我們每秒鐘創(chuàng)建的對(duì)象大概就在500KB~1MB之間。按最大1MB來計(jì)算好了伦泥，1秒產(chǎn)生1MB垃圾對(duì)象剥啤，那100秒就能產(chǎn)生出來100MB垃圾對(duì)象，按新生代內(nèi)存為1個(gè)G來計(jì)算不脯，Eden區(qū)分配800MB府怯，那也就是800秒就得觸發(fā)一次Minor GC了，如果頻繁的觸發(fā)Minor GC肯定不是一個(gè)好事防楷！會(huì)影響我們線上的性能穩(wěn)定牺丙。

支付系統(tǒng)JVM內(nèi)存如何設(shè)置？

那我們?cè)谡嬲到y(tǒng)上線的時(shí)候應(yīng)該如何進(jìn)行部署以及分配JVM內(nèi)存呢？這里假如我們經(jīng)濟(jì)有限僅僅分配一臺(tái)2核4G的機(jī)器來部署冲簿，4G的內(nèi)存能真正分配到JVM上的也就最多2G粟判，而這2G還不能全都給堆內(nèi)存，還有方法區(qū)峦剔、棧內(nèi)存等區(qū)域档礁，堆內(nèi)存最多也就能分配到個(gè)1G左右，而且堆內(nèi)存還分新生代和老年代吝沫，這樣算下來我們的新生代最多也就幾百M(fèi)b大小了呻澜，根據(jù)我們之前的分析，1秒就能消耗1MB左右的內(nèi)存惨险，幾百秒就能撐滿導(dǎo)致垃圾回收易迹，影響我們系統(tǒng)的性能穩(wěn)定性。（一旦觸發(fā)垃圾回收就會(huì)導(dǎo)致STW平道，系統(tǒng)線程停止睹欲，這塊我們后續(xù)會(huì)講解）

那么如何解決和優(yōu)化呢？

1. 可以考慮提升成本一屋，使用4核8G的機(jī)器來進(jìn)行部署窘疮，那么我們的JVM至少可以分配到4G以上內(nèi)存，新生代也至少能分配到2G內(nèi)存冀墨，那么可以將Minor GC的觸發(fā)時(shí)間由幾百秒提升到半小時(shí)~1小時(shí)觸發(fā)闸衫，降低GC的頻率
2. 擴(kuò)展服務(wù)器數(shù)量，我們可以部署3~5臺(tái)機(jī)器來進(jìn)行橫向擴(kuò)展诽嘉，當(dāng)然機(jī)器數(shù)量越多蔚出，每天機(jī)器處理的請(qǐng)求就更少，這樣對(duì)JVM內(nèi)存的壓力就更小虫腋。

當(dāng)然實(shí)際需要根據(jù)各位自己的業(yè)務(wù)量以及系統(tǒng)性能進(jìn)行合理配置骄酗，針對(duì)每個(gè)系統(tǒng)上線前都要做一次JVM內(nèi)存的模擬估算（如何通過工具來查看實(shí)際JVM內(nèi)存的變化過程后續(xù)我們?cè)僦v解）并且是多次測(cè)試得出一個(gè)合理的數(shù)據(jù)再通過預(yù)估的用戶請(qǐng)求量來進(jìn)行模擬估算，提前設(shè)置有一個(gè)合理的值悦冀，減少GC的頻繁觸發(fā)趋翻，保障系統(tǒng)的穩(wěn)定運(yùn)行。

3.雙11大促盒蟆，瞬時(shí)訪問量增加10倍

除了日常的平均支付交易量需要預(yù)估設(shè)置以外踏烙，還需要思考的就是大促的時(shí)候如何保障服務(wù)器的穩(wěn)定。比如雙11來臨历等，很可能導(dǎo)致服務(wù)器壓力瞬間增大10倍讨惩，都在這一時(shí)段或這一天來買東西了，那么這個(gè)時(shí)候可能計(jì)算出來的就不是每秒100筆支付訂單的問題了寒屯，可能是每秒1000筆訂單甚至更大荐捻！這個(gè)時(shí)候就不光是我們的內(nèi)存壓力大，特別是線程資源，CPU資源幾乎都會(huì)占滿靴患，內(nèi)存也是岌岌可危仍侥！

之前我們計(jì)算過每一秒產(chǎn)生的對(duì)象是在1MB要出，那遇到大促的時(shí)候鸳君，每一秒的內(nèi)存占用有可能就能達(dá)到10MB甚至幾十MB（得往大一點(diǎn)預(yù)估不要考慮剛剛好），并且這個(gè)時(shí)候還有個(gè)問題就是患蹂，以前差不多1秒能處理完我們100個(gè)訂單或颊，但是現(xiàn)在1000個(gè)訂單1秒是肯定處理不完的，剛才也分析過传于，CPU囱挑、線程、內(nèi)存都吃緊沼溜，系統(tǒng)性能也會(huì)跟著不穩(wěn)定平挑，那1000個(gè)訂單至少需要幾秒甚至幾十秒才可能處理完畢。

那么當(dāng)我們的新生代快滿的時(shí)候系草，這個(gè)時(shí)候還在往里進(jìn)對(duì)象就會(huì)出現(xiàn)問題通熄，因?yàn)樯弦徊ǖ膶?duì)象可能還未處理完這時(shí)有來一波對(duì)象，而新生代中也被垃圾對(duì)象給填滿了找都，那么就會(huì)觸發(fā)Minor GC唇辨，假設(shè)我們的新生代和老年代內(nèi)存分配分別為1G，現(xiàn)在的情況如下：

image

新的請(qǐng)求過來分配空間不足觸發(fā)MinorGC能耻，回收部分對(duì)象赏枚，而我們的少部分對(duì)象由于系統(tǒng)處理較慢還在引用，而每秒還在產(chǎn)生大量對(duì)象不斷進(jìn)來晓猛，假如我們預(yù)估每秒創(chuàng)建新對(duì)象100MB饿幅，1個(gè)G的新生代中Eden區(qū)占800MB，不到8S就會(huì)觸發(fā)一次MinorGC戒职，那么這么大量頻繁的觸發(fā)MinorGC诫睬，加上少數(shù)對(duì)象處理較慢就會(huì)導(dǎo)致部分對(duì)象由于多次經(jīng)歷Minor GC后依然存活，最終進(jìn)入老年代：

image

而當(dāng)那部分對(duì)象處理完畢后失去引用就成為垃圾對(duì)象了帕涌，但是已經(jīng)存在于我們的老年代了摄凡。

image

那么按照這個(gè)頻率老年代被占滿的速度也很快！而一旦老年代被占滿就會(huì)觸發(fā)Full GC蚓曼，這個(gè)比Minor GC更恐怖亲澡，導(dǎo)致系統(tǒng)暫停的時(shí)長(zhǎng)更久！你試想下纫版，在大促秒殺搶單的過程中你的系統(tǒng)卡死床绪，正在執(zhí)行垃圾回收，而用戶這邊一直無法進(jìn)入付款頁(yè)面是什么感受？ 等系統(tǒng)恢復(fù)癞己，再進(jìn)行付款這時(shí)也過秒殺時(shí)段或商品已售空膀斋，嚴(yán)重影響用戶體驗(yàn)。

至于新生代和老年代的垃圾回收規(guī)則以及如何優(yōu)化我們放在后續(xù)講解痹雅。

因此大家在公司進(jìn)行項(xiàng)目開發(fā)上線的時(shí)候一定要結(jié)合JVM內(nèi)存進(jìn)行思考和預(yù)估仰担，特別是用戶量大的項(xiàng)目，不合理的預(yù)估業(yè)務(wù)系統(tǒng)壓力绩社，等真正壓力來臨的時(shí)候摔蓝，系統(tǒng)隨時(shí)面臨崩盤。這也是為什么很多大廠面試都要考核JVM這塊的原因愉耙，考核你是否真正做到對(duì)你自己的系統(tǒng)足夠了解贮尉，對(duì)線上的內(nèi)存預(yù)估是否準(zhǔn)確。