1. 項(xiàng)目概述JMeter內(nèi)存溢出性能測(cè)試工程師的“頭號(hào)公敵”如果你正在用JMeter做性能測(cè)試尤其是模擬高并發(fā)或者長(zhǎng)時(shí)間運(yùn)行的壓測(cè)場(chǎng)景那么屏幕前突然彈出的那個(gè)“java.lang.OutOfMemoryError: Java heap space”錯(cuò)誤大概率會(huì)讓你心頭一緊測(cè)試進(jìn)度瞬間中斷。這個(gè)錯(cuò)誤就是我們常說(shuō)的JMeter內(nèi)存溢出。它不是什么高深的玄學(xué)問(wèn)題而是每一個(gè)性能測(cè)試工程師在進(jìn)階路上幾乎必然會(huì)遇到的“攔路虎”。簡(jiǎn)單來(lái)說(shuō)它就是JMeter這個(gè)Java程序在運(yùn)行過(guò)程中向JVMJava虛擬機(jī)申請(qǐng)的內(nèi)存不夠用了導(dǎo)致程序崩潰。但背后的原因遠(yuǎn)不止“內(nèi)存不夠”這么簡(jiǎn)單可能涉及腳本設(shè)計(jì)、監(jiān)聽(tīng)器使用、測(cè)試策略乃至JVM調(diào)優(yōu)等多個(gè)層面。今天我就結(jié)合自己這些年踩過(guò)的坑和填過(guò)的坑把這個(gè)問(wèn)題的來(lái)龍去脈、解決思路和實(shí)操細(xì)節(jié)掰開(kāi)揉碎了講清楚。無(wú)論你是剛接觸JMeter的新手還是正在被大并發(fā)壓測(cè)困擾的老手這篇文章都能給你一套從診斷到根治的完整方案。2. 內(nèi)存溢出根因深度剖析不只是“內(nèi)存太小”在動(dòng)手解決問(wèn)題之前我們必須先搞清楚JMeter為什么會(huì)“吃”掉那么多內(nèi)存。很多人一看到“Java heap space”第一反應(yīng)就是去改JVM參數(shù)把-Xmx調(diào)大。這固然是一種方法但往往是治標(biāo)不治本甚至可能讓問(wèn)題惡化。我們需要像偵探一樣層層深入。2.1 JVM內(nèi)存模型與JMeter的運(yùn)行機(jī)制JMeter是一個(gè)100%純Java開(kāi)發(fā)的桌面應(yīng)用它的所有運(yùn)行都依賴于JVM。JVM的內(nèi)存區(qū)域主要分為堆Heap、棧Stack、方法區(qū)Metaspace等。對(duì)于JMeter內(nèi)存溢出我們最需要關(guān)注的是堆內(nèi)存。堆內(nèi)存Heap這是JVM中最大的一塊內(nèi)存區(qū)域幾乎所有通過(guò)new關(guān)鍵字創(chuàng)建的對(duì)象實(shí)例和數(shù)組都存放在這里。它也是垃圾回收器Garbage Collector, GC主要管理的區(qū)域。JMeter在運(yùn)行測(cè)試時(shí)會(huì)創(chuàng)建大量的對(duì)象每一個(gè)虛擬用戶線程的上下文信息、每一個(gè)HTTP請(qǐng)求和響應(yīng)的數(shù)據(jù)、監(jiān)聽(tīng)器收集的采樣結(jié)果等等都會(huì)在堆中分配內(nèi)存。內(nèi)存溢出OOM的本質(zhì)當(dāng)JMeter應(yīng)用程序創(chuàng)建的這些對(duì)象總量超過(guò)了JVM堆內(nèi)存的最大容量由-Xmx參數(shù)設(shè)定并且垃圾回收器經(jīng)過(guò)多次努力也無(wú)法回收足夠的空閑內(nèi)存來(lái)容納新對(duì)象時(shí)JVM就會(huì)拋出OutOfMemoryError: Java heap space錯(cuò)誤導(dǎo)致JMeter進(jìn)程崩潰。2.2 導(dǎo)致JMeter堆內(nèi)存暴漲的四大“元兇”根據(jù)我的經(jīng)驗(yàn)JMeter內(nèi)存溢出很少是單一原因造成的通常是以下幾個(gè)因素共同作用的結(jié)果高并發(fā)線程數(shù)這是最直接的因素。啟動(dòng)的線程數(shù)越多每個(gè)線程獨(dú)立維護(hù)的上下文如Cookie管理器、緩存、變量等就越多瞬間創(chuàng)建的對(duì)象數(shù)量呈線性甚至指數(shù)級(jí)增長(zhǎng)。一個(gè)配置不當(dāng)?shù)那Ъ?jí)并發(fā)測(cè)試足以在幾秒內(nèi)撐爆默認(rèn)的1GB堆內(nèi)存?！柏澙贰钡谋O(jiān)聽(tīng)器這是新手最容易踩的巨坑。JMeter的監(jiān)聽(tīng)器特別是查看結(jié)果樹(shù)View Results Tree和聚合報(bào)告Aggregate Report在默認(rèn)設(shè)置下會(huì)在內(nèi)存中完整保存每一個(gè)請(qǐng)求的響應(yīng)數(shù)據(jù)。想象一下你進(jìn)行一輪10萬(wàn)次請(qǐng)求的測(cè)試如果每個(gè)響應(yīng)體平均10KB“查看結(jié)果樹(shù)”監(jiān)聽(tīng)器就會(huì)試圖在內(nèi)存中保留將近1GB的原始數(shù)據(jù)這還沒(méi)算上對(duì)象本身的內(nèi)存開(kāi)銷。這就是為什么在命令行執(zhí)行壓測(cè)時(shí)必須禁用這些監(jiān)聽(tīng)器。腳本設(shè)計(jì)缺陷腳本邏輯不當(dāng)也會(huì)導(dǎo)致內(nèi)存無(wú)法釋放。不合理的循環(huán)或定時(shí)器可能導(dǎo)致請(qǐng)求無(wú)限堆積。大型文件的參數(shù)化使用CSV Data Set Config讀取一個(gè)巨大的文件如幾十萬(wàn)行的用戶數(shù)據(jù)并且設(shè)置為“All threads”共享模式這會(huì)把整個(gè)文件加載到內(nèi)存中。正則表達(dá)式或JSON提取器處理超大響應(yīng)如果從一個(gè)巨大的響應(yīng)體中提取數(shù)據(jù)提取出的變量可能會(huì)占用大量?jī)?nèi)存。JVM垃圾回收GC效率低下即使對(duì)象不再被引用也需要垃圾回收器來(lái)回收內(nèi)存。如果堆內(nèi)存設(shè)置得過(guò)小會(huì)導(dǎo)致GC異常頻繁稱為“GC Thrashing”大量CPU時(shí)間被用于垃圾回收而非執(zhí)行測(cè)試整體吞吐量下降同時(shí)GC本身也會(huì)產(chǎn)生臨時(shí)對(duì)象進(jìn)一步加劇內(nèi)存壓力。反之如果堆內(nèi)存設(shè)置得過(guò)大單次GC的停頓時(shí)間Stop-The-World會(huì)很長(zhǎng)可能導(dǎo)致JMeter響應(yīng)遲緩。注意很多人誤以為“內(nèi)存泄漏”是主因。在JMeter標(biāo)準(zhǔn)腳本中真正的內(nèi)存泄漏即對(duì)象永遠(yuǎn)無(wú)法被GC回收并不常見(jiàn)。更多情況是短期內(nèi)的對(duì)象創(chuàng)建速率遠(yuǎn)遠(yuǎn)高于垃圾回收速率屬于“內(nèi)存壓力”過(guò)大而非嚴(yán)格意義上的泄漏。但設(shè)計(jì)糟糕的插件或自定義代碼可能導(dǎo)致泄漏。3. 系統(tǒng)性解決方案從調(diào)優(yōu)到架構(gòu)的進(jìn)階之路解決內(nèi)存溢出我推薦一個(gè)從易到難、從內(nèi)到外的系統(tǒng)性排查和解決路徑先優(yōu)化腳本和配置再調(diào)整JVM參數(shù)最后考慮架構(gòu)升級(jí)。3.1 第一步腳本與配置優(yōu)化成本最低效果顯著這是你應(yīng)該首先嘗試的往往能解決80%的問(wèn)題。精簡(jiǎn)或禁用監(jiān)聽(tīng)器非GUI模式命令行執(zhí)行壓測(cè)時(shí)務(wù)必禁用所有非必要的監(jiān)聽(tīng)器。使用-l參數(shù)指定結(jié)果保存為JTL文件后續(xù)再用GUI模式打開(kāi)聚合報(bào)告等監(jiān)聽(tīng)器進(jìn)行分析。在GUI模式設(shè)計(jì)調(diào)試腳本時(shí)永遠(yuǎn)不要開(kāi)啟“查看結(jié)果樹(shù)”去進(jìn)行壓測(cè)。它僅用于調(diào)試單個(gè)請(qǐng)求。調(diào)試完畢后務(wù)必禁用或刪除它。使用更“輕量”的監(jiān)聽(tīng)器。比如用“聚合報(bào)告”代替“圖形結(jié)果”前者只存儲(chǔ)統(tǒng)計(jì)摘要不存原始數(shù)據(jù)。實(shí)操技巧我習(xí)慣在測(cè)試計(jì)劃中單獨(dú)創(chuàng)建一個(gè)“調(diào)試線程組”里面只放一兩個(gè)線程和“查看結(jié)果樹(shù)”。正式的壓測(cè)線程組里一個(gè)監(jiān)聽(tīng)器都不放。通過(guò)${__P(test.type,)}屬性來(lái)動(dòng)態(tài)控制是否啟用調(diào)試線程組。優(yōu)化腳本邏輯清理不必要的測(cè)試數(shù)據(jù)定期使用“清除”按鈕掃帚圖標(biāo)清除已有結(jié)果。合理使用CSV數(shù)據(jù)文件對(duì)于大型參數(shù)文件使用CSV Data Set Config時(shí)將“共享模式”設(shè)置為Current thread group或Current thread避免全局共享導(dǎo)致全量加載。考慮使用__StringFromFile或__File函數(shù)進(jìn)行按需讀取。限制響應(yīng)數(shù)據(jù)保存在HTTP請(qǐng)求等取樣器中可以只保存必要的部分。對(duì)于不需要檢查的響應(yīng)可以勾選“Save response as MD5 hash?”來(lái)僅保存哈希值極大減少內(nèi)存占用。謹(jǐn)慎使用后置處理器避免使用正則表達(dá)式提取器處理巨大的響應(yīng)體。如果必須處理確保表達(dá)式是精確的避免“貪婪匹配”導(dǎo)致內(nèi)存占用過(guò)高。3.2 第二步JVM堆內(nèi)存調(diào)優(yōu)對(duì)癥下藥量力而行當(dāng)腳本優(yōu)化到極致后如果仍需支撐更大規(guī)模的測(cè)試就需要調(diào)整JMeter啟動(dòng)時(shí)的JVM參數(shù)了。這是直接解決“Java heap space”錯(cuò)誤的方法。定位配置文件Windows系統(tǒng)編輯jmeter.bat或jmeter腳本如果你用的是jmeter而不是jmeter.bat。Linux/Mac系統(tǒng)編輯jmeterShell腳本或jmeter.sh。關(guān)鍵參數(shù)解析與修改 打開(kāi)配置文件找到設(shè)置HEAP環(huán)境變量的部分。通?？雌饋?lái)像這樣set HEAP-Xms1g -Xmx1g -XX:MaxMetaspaceSize256m我們需要修改的是-Xms和-Xmx以及可能添加新生代參數(shù)。-Xms: 堆內(nèi)存的初始大小。例如-Xms512m表示啟動(dòng)時(shí)分配512MB。-Xmx: 堆內(nèi)存的最大大小。例如-Xmx4g表示最大可以擴(kuò)展到4GB。-XX:NewSize 和 -XX:MaxNewSize: 設(shè)置新生代Young Generation的初始和最大大小。新生代是大部分新對(duì)象產(chǎn)生和死亡的地方頻繁的Minor GC發(fā)生于此。合理設(shè)置可以提升GC效率。一個(gè)經(jīng)過(guò)實(shí)戰(zhàn)檢驗(yàn)的配置示例針對(duì)一臺(tái)擁有16GB物理內(nèi)存的壓測(cè)機(jī)set HEAP-Xms2g -Xmx8g set NEW-XX:NewSize1g -XX:MaxNewSize2g修改說(shuō)明將最大堆內(nèi)存-Xmx從默認(rèn)的1g提升到8g。這里有個(gè)重要原則-Xmx值最好不要超過(guò)你物理內(nèi)存的50%-70%。因?yàn)椴僮飨到y(tǒng)、JMeter GUI如果使用、以及其他進(jìn)程都需要內(nèi)存。設(shè)為8g對(duì)于16g的機(jī)器是一個(gè)比較安全的值。將初始堆內(nèi)存-Xms也設(shè)為2g避免運(yùn)行時(shí)頻繁向系統(tǒng)申請(qǐng)內(nèi)存。顯式設(shè)置了新生代大小。對(duì)于JMeter這種會(huì)創(chuàng)建大量短生命周期對(duì)象如每次請(qǐng)求的響應(yīng)對(duì)象的應(yīng)用給新生代分配較大空間如堆的1/4到1/2是有益的可以讓這些對(duì)象在新生代的Minor GC中就被快速回收避免過(guò)早進(jìn)入老年代。這里設(shè)置了1g初始最大2g。修改步驟用文本編輯器如Notepad以管理員身份打開(kāi)jmeter.bat。搜索“HEAP”關(guān)鍵字。將原配置替換為上述示例配置。保存文件。重啟JMeter必須重啟修改才會(huì)生效。重要心得-Xmx不是越大越好設(shè)置過(guò)大例如超過(guò)物理內(nèi)存會(huì)導(dǎo)致操作系統(tǒng)使用硬盤(pán)交換分區(qū)Swap性能急劇下降JMeter會(huì)變得奇卡無(wú)比甚至引發(fā)更嚴(yán)重的系統(tǒng)級(jí)問(wèn)題。始終監(jiān)控壓測(cè)機(jī)的整體內(nèi)存使用情況通過(guò)任務(wù)管理器或top命令確保還有充足的空余內(nèi)存。3.3 第三步進(jìn)階與分布式壓測(cè)終極方案如果單臺(tái)機(jī)器即使優(yōu)化了腳本和JVM參數(shù)仍無(wú)法滿足你的并發(fā)要求例如需要模擬上萬(wàn)用戶那么你必須考慮分布式壓測(cè)。分布式壓測(cè)原理 由一臺(tái)機(jī)器作為控制機(jī)Controller負(fù)責(zé)管理測(cè)試、分發(fā)腳本、收集結(jié)果。其他多臺(tái)機(jī)器作為施壓機(jī)Agent/Slave實(shí)際執(zhí)行測(cè)試計(jì)劃生成負(fù)載。這樣負(fù)載和內(nèi)存消耗就被分?jǐn)偟搅硕嗯_(tái)機(jī)器上。實(shí)施步驟環(huán)境準(zhǔn)備在所有機(jī)器控制機(jī)和施壓機(jī)上安裝相同版本的JMeter和JDK。配置施壓機(jī)在每個(gè)施壓機(jī)上運(yùn)行jmeter-server.batWindows或jmeter-serverLinux/Mac啟動(dòng)服務(wù)。默認(rèn)使用1099端口。配置控制機(jī)編輯控制機(jī)上的jmeter.properties文件找到remote_hosts配置項(xiàng)添加所有施壓機(jī)的IP地址和端口例如remote_hosts192.168.1.101:1099,192.168.1.102:1099。運(yùn)行測(cè)試在控制機(jī)GUI中選擇“運(yùn)行” - “遠(yuǎn)程啟動(dòng)”來(lái)啟動(dòng)指定或所有施壓機(jī)?；蛘咴诿钚惺褂?R 192.168.1.101:1099,192.168.1.102:1099參數(shù)。分布式壓測(cè)的注意事項(xiàng)網(wǎng)絡(luò)帶寬控制機(jī)和施壓機(jī)之間、施壓機(jī)和被測(cè)系統(tǒng)之間需要有高速、穩(wěn)定的網(wǎng)絡(luò)連接否則網(wǎng)絡(luò)可能成為瓶頸。數(shù)據(jù)文件同步如果腳本中使用CSV等參數(shù)化文件需要確保所有施壓機(jī)上的文件路徑和內(nèi)容一致?？梢允褂霉蚕泶鎯?chǔ)如NFS或腳本同步工具。時(shí)鐘同步所有機(jī)器的時(shí)間應(yīng)基本同步以確保日志時(shí)間戳一致。防火墻確保1099端口以及可能用到的其他高端口在施壓機(jī)上是開(kāi)放的允許控制機(jī)訪問(wèn)。4. 實(shí)戰(zhàn)排查與監(jiān)控當(dāng)問(wèn)題發(fā)生時(shí)如何快速定位即使做好了預(yù)防在復(fù)雜的測(cè)試場(chǎng)景中內(nèi)存溢出仍可能發(fā)生。這時(shí)我們需要一套排查方法。4.1 問(wèn)題現(xiàn)象與初步判斷GUI界面卡死無(wú)響應(yīng)可能是堆內(nèi)存即將耗盡GC占用了幾乎所有CPU時(shí)間。命令行模式測(cè)試突然中止在日志中控制臺(tái)或jmeter.log文件看到明確的java.lang.OutOfMemoryError: Java heap space錯(cuò)誤。錯(cuò)誤率伴隨測(cè)試進(jìn)行逐漸升高在聚合報(bào)告中隨著測(cè)試時(shí)間推移錯(cuò)誤率特別是超時(shí)錯(cuò)誤不斷上升可能是內(nèi)存不足導(dǎo)致處理請(qǐng)求變慢。4.2 使用監(jiān)控工具定位瓶頸JMeter自身監(jiān)聽(tīng)器PerfMon Metrics Collector這是一個(gè)插件監(jiān)聽(tīng)器需要安裝。它可以監(jiān)控施壓機(jī)本身的系統(tǒng)資源包括內(nèi)存使用率、CPU、磁盤(pán)IO等。將它添加到測(cè)試計(jì)劃中連接到localhost可以實(shí)時(shí)看到JMeter進(jìn)程的內(nèi)存消耗曲線。如果曲線持續(xù)增長(zhǎng)直至接近-Xmx設(shè)定值然后崩潰這就是典型的內(nèi)存溢出。JVM內(nèi)置工具jConsole / jVisualVM隨JDK分發(fā)。連接到JMeter進(jìn)程本地或遠(yuǎn)程可以直觀看到堆內(nèi)存、永久代、線程、類的實(shí)時(shí)使用情況甚至可以進(jìn)行堆轉(zhuǎn)儲(chǔ)Heap Dump分析。命令行監(jiān)控在啟動(dòng)JMeter時(shí)添加JVM參數(shù)-XX:PrintGCDetails -XX:PrintGCDateStamps -Xloggc:gc.log可以將詳細(xì)的GC日志輸出到文件。分析這個(gè)日志可以看GC頻率、暫停時(shí)間、回收效果判斷是否是GC問(wèn)題。4.3 生成與分析堆轉(zhuǎn)儲(chǔ)Heap Dump這是最強(qiáng)大的終極手段可以告訴你堆里到底塞滿了什么對(duì)象。生成堆轉(zhuǎn)儲(chǔ)在出現(xiàn)OOM時(shí)JVM自動(dòng)生成添加JVM參數(shù)-XX:HeapDumpOnOutOfMemoryError -XX:HeapDumpPath/path/to/dump.hprof。手動(dòng)生成使用jmap工具或通過(guò)jVisualVM觸發(fā)。分析堆轉(zhuǎn)儲(chǔ) 使用專業(yè)工具分析生成的.hprof文件Eclipse MAT (Memory Analyzer Tool)功能強(qiáng)大是首選。它可以自動(dòng)分析泄漏疑點(diǎn)生成報(bào)告告訴你哪個(gè)對(duì)象占用了最多的內(nèi)存以及是誰(shuí)在引用它。jVisualVM內(nèi)置分析功能但相對(duì)簡(jiǎn)單。分析思路打開(kāi)堆轉(zhuǎn)儲(chǔ)后通常查看“Histogram”直方圖或“Dominator Tree”支配樹(shù)。按“Retained Heap”支配內(nèi)存排序排在最前面的類就是內(nèi)存消耗的“罪魁禍?zhǔn)住?。在JMeter的上下文中你很可能會(huì)發(fā)現(xiàn)大量byte[]響應(yīng)體數(shù)據(jù)、SampleResult對(duì)象采樣結(jié)果、或者某些監(jiān)聽(tīng)器相關(guān)的對(duì)象。這就能直接印證我們之前的判斷——是不是監(jiān)聽(tīng)器沒(méi)關(guān)是不是某個(gè)請(qǐng)求的響應(yīng)太大了5. 常見(jiàn)問(wèn)題與避坑指南實(shí)錄這里記錄了我自己和團(tuán)隊(duì)在多年實(shí)踐中遇到的一些典型問(wèn)題和解決技巧。Q1: 我已經(jīng)把-Xmx調(diào)到很大了比如機(jī)器32G我設(shè)了24G但JMeter啟動(dòng)很慢運(yùn)行也卡甚至還是報(bào)OOM。原因與解決這很可能觸發(fā)了“大內(nèi)存頁(yè)”和GC停頓問(wèn)題。過(guò)大的堆會(huì)導(dǎo)致單次Full GC停頓時(shí)間極長(zhǎng)表現(xiàn)為程序“卡死”。此外JVM自身管理大堆也需要開(kāi)銷。解決方案回歸根本首先嚴(yán)格執(zhí)行3.1節(jié)的腳本優(yōu)化特別是禁用監(jiān)聽(tīng)器?？紤]使用G1垃圾回收器它專為減少大堆的停頓時(shí)間而設(shè)計(jì)。在JMeter啟動(dòng)參數(shù)中添加-XX:UseG1GC -XX:MaxGCPauseMillis200。這告訴JVM使用G1回收器并目標(biāo)設(shè)定每次GC停頓不超過(guò)200毫秒。如果真的需要極大并發(fā)請(qǐng)果斷采用分布式壓測(cè)而不是無(wú)限制調(diào)高單機(jī)堆內(nèi)存。Q2: 在非GUI命令行模式下運(yùn)行已經(jīng)用了-n和-l但內(nèi)存還是增長(zhǎng)得很快。原因雖然禁用了GUI但測(cè)試計(jì)劃中可能仍然包含了消耗內(nèi)存的監(jiān)聽(tīng)器如聚合報(bào)告如果配置了保存所有數(shù)據(jù)、或者后置處理器產(chǎn)生了大量數(shù)據(jù)。排查使用-t指定測(cè)試計(jì)劃后用-p或--propfile指定一個(gè)只包含最精簡(jiǎn)配置的.properties文件。或者在GUI中創(chuàng)建一個(gè)絕對(duì)干凈的測(cè)試計(jì)劃無(wú)任何監(jiān)聽(tīng)器再保存為jmx文件用于命令行執(zhí)行。Q3: 分布式壓測(cè)時(shí)控制機(jī)也報(bào)OOM了。原因控制機(jī)雖然不產(chǎn)生負(fù)載但它要收集所有施壓機(jī)返回的樣本結(jié)果。如果線程數(shù)極多、測(cè)試時(shí)間長(zhǎng)收集的結(jié)果數(shù)據(jù)量也會(huì)非常龐大。解決在控制機(jī)的jmeter.properties中同樣需要調(diào)大-Xmx。更關(guān)鍵的是在控制機(jī)上配置結(jié)果收集的優(yōu)化。例如使用“聚合報(bào)告”監(jiān)聽(tīng)器時(shí)可以勾選“Save Table Data (CSV)”而不是將數(shù)據(jù)全留在內(nèi)存中。或者讓每個(gè)施壓機(jī)將結(jié)果直接寫(xiě)入本地文件使用-l參數(shù)測(cè)試結(jié)束后再手動(dòng)合并分析。Q4: 調(diào)整了JVM參數(shù)但似乎沒(méi)生效檢查點(diǎn)確認(rèn)你修改的是啟動(dòng)JMeter時(shí)實(shí)際使用的腳本文件。如果你通過(guò)桌面快捷方式啟動(dòng)它可能指向了另一個(gè)副本。修改后必須關(guān)閉所有JMeter窗口并重新啟動(dòng)。在JMeter啟動(dòng)時(shí)查看控制臺(tái)命令行窗口輸出的前幾行日志通常會(huì)打印出JVM參數(shù)確認(rèn)你設(shè)置的-Xms和-Xmx是否已正確加載。一個(gè)關(guān)鍵的避坑技巧始終使用版本管理對(duì)于JMeter的測(cè)試腳本.jmx和配置文件.properties, .bat我強(qiáng)烈建議使用Git等版本管理工具。在調(diào)整JVM參數(shù)、修改腳本配置后進(jìn)行提交并寫(xiě)好注釋。這樣當(dāng)某次測(cè)試出現(xiàn)內(nèi)存問(wèn)題時(shí)你可以快速回溯到之前的穩(wěn)定版本進(jìn)行對(duì)比精準(zhǔn)定位是哪個(gè)改動(dòng)引入了問(wèn)題。這比憑記憶要可靠得多。內(nèi)存溢出問(wèn)題本質(zhì)上是資源管理與需求之間的博弈。解決它沒(méi)有一勞永逸的銀彈而是一個(gè)“優(yōu)化腳本 - 調(diào)整JVM - 升級(jí)架構(gòu)”的持續(xù)過(guò)程。掌握這套方法論你就能從容應(yīng)對(duì)各種規(guī)模的性能測(cè)試挑戰(zhàn)讓JMeter真正成為你手中穩(wěn)定可靠的壓測(cè)利器。