前言
現(xiàn)實(shí)企業(yè)級(jí)
Java項(xiàng)目中，有時(shí)候會(huì)碰到下面這些問(wèn)題：
●OutOfMemoryError，內(nèi)存不足
●內(nèi)存泄露
●線程死鎖
●鎖爭(zhēng)用（Lock Contention）
●Java進(jìn)程消耗CPU過(guò)高
●......
這些問(wèn)題在日常開(kāi)發(fā)中可能被很多人忽視（比如有的人遇到上面的問(wèn)題只是重啟服務(wù)器或者調(diào)大內(nèi)存，而不會(huì)深究問(wèn)題根源），但作為一名優(yōu)秀的
性能測(cè)試工程師，必須能夠定位并分析這些問(wèn)題。那么在性能測(cè)試的整個(gè)流程當(dāng)中，如何來(lái)監(jiān)控這些問(wèn)題呢?這里介紹如何使用 JVisualVM 進(jìn)行性能監(jiān)控分析。
jvisualvm 安裝
JDK中還藏著一個(gè)寶貝,它的名字叫做VisualVM，自從 JDK 6 Update 7 以后已經(jīng)作為
Oracle JDK 的一部分，它主要用來(lái)監(jiān)控JVM的運(yùn)行情況，可以用它來(lái)查看和瀏覽Heap Dump、Thread Dump、內(nèi)存對(duì)象實(shí)例情況、GC執(zhí)行情況、CPU消耗以及類的裝載情況。該工具位于 JDK 根目錄的 bin 文件夾下，無(wú)需安裝，正常安裝完jdk后，至jdk的bin目錄下直接運(yùn)行jvisualvm.exe即可。
jvisualvm 插件安裝，選擇【工具】——【插件】——【可用插件】，打開(kāi)后如下圖，沒(méi)有檢測(cè)到可用插件
然后點(diǎn)擊檢測(cè)最新版本，提示無(wú)法連接到j(luò)ava visualvm插件中心，這是因?yàn)閖ava.net網(wǎng)站已經(jīng)被Oracle關(guān)閉了，visualvm已經(jīng)遷移到了github上，地址是https://visualvm.github.io/index.html，點(diǎn)擊Plugins進(jìn)入插件頁(yè)面
因?yàn)槲业膉dk是1.7.0_80，所以找到對(duì)應(yīng)插件更新地址https://visualvm.github.io/archive/uc/8u40/updates.xml.gz
再次回到j(luò)visualvm-》工具-》插件，找到設(shè)置
把紅色框中的url地址改成剛才找到的https://visualvm.github.io/archive/uc/8u40/updates.xml.gz，修改之后，更新可用插件，安裝即可。重啟jvisualvm。
jvisualvm遠(yuǎn)程監(jiān)控
jvisualvm可以監(jiān)控所有的java進(jìn)程，本地機(jī)器的程序直接可以監(jiān)聽(tīng)到，遠(yuǎn)程機(jī)器的程序需要加上JVM參數(shù)，下面以監(jiān)控遠(yuǎn)程tomcat為例介紹如何添加遠(yuǎn)程監(jiān)控。
1、遠(yuǎn)程服務(wù)器配置
在tomcat/bin/catalina.sh加入以下配置：
JAVA_OPTS="-Djava.rmi.server.hostname=10.1.60.63 -Dcom.sun.management.jmxremote.port=1099 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false"
端口號(hào)可以自己定義，如果沖突了，修改下就好了。配置好后，重啟tomcat。那問(wèn)題又來(lái)了，jar包如何配置監(jiān)聽(tīng)呢？比如我們的前置機(jī)。其實(shí)很簡(jiǎn)單，只要啟動(dòng)jar包時(shí)加上上面的配置參數(shù)就好了。命令如下：nohup java -jar Djava.rmi.server.hostname=192.168.1.24 -Dcom.sun.management.jmxremote.port=1099 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false /home/webapps/test_front_end_service/front-end-service.jar &
2、在jvisualvm中進(jìn)行遠(yuǎn)程配置
具體如下：
到此遠(yuǎn)程監(jiān)控添加完成了,在遠(yuǎn)程主機(jī)下會(huì)有一個(gè)jmx連接，打開(kāi)連接，點(diǎn)擊監(jiān)視tab，可以看到如下界面了.
在上圖中可以看到cpu利用率和垃圾回收活動(dòng),然后是堆棧使用情況(這兩個(gè)在分析tomcat性能時(shí)很重要)。下面是類的使用情況，最后一個(gè)是線程活動(dòng)情況。
點(diǎn)擊線程tab可以看到：下圖可以非常清晰的看到線程活動(dòng)情況，那些線程正在執(zhí)行，哪些線程正在等待中，以及執(zhí)行完畢的線程等。這里可以看到每個(gè)線程的狀態(tài)，點(diǎn)擊某個(gè)線程右鍵可以查看該線程的詳細(xì)情況：
線程死鎖檢測(cè)
前面已經(jīng)介紹如何安裝插件，jvisualvm推薦16種插件，其中Threads Inspector插件可以輕松地檢測(cè)到死鎖，當(dāng)壓測(cè)過(guò)程中出現(xiàn)死鎖，在線程tab頁(yè)會(huì)出現(xiàn)如下的提示
從上圖可知，檢測(cè)到死鎖，可以通過(guò)【線程Dump】查看具體的死鎖線程的信息
Main.Java 21行：Thread-0當(dāng)前鎖定了
<0x00000000dbb308f0>，并且在等待鎖定<0x00000000dbb308c0>
Main.Java 32行：Thread-1當(dāng)前鎖定了
<0x00000000dbb308c0> ，并且在等待鎖定
<0x00000000dbb308f0>
兩個(gè)進(jìn)程互相都需要對(duì)方線程釋放其所占有資源(java.lang.String)，而根據(jù)【請(qǐng)求與保持條件】原則，顯然不會(huì)釋放已經(jīng)到手的資源，可以說(shuō)是吃著碗里的，看著鍋里的，兩邊都想占有。
內(nèi)存分析
jvisualvm 通過(guò)檢測(cè) JVM 中加載的類和對(duì)象信息等幫助分析內(nèi)存使用情況，可以通過(guò) jvisualvm的監(jiān)視標(biāo)簽和 抽樣器對(duì)應(yīng)用程序進(jìn)行內(nèi)存分析。下面以分析內(nèi)存泄漏為例。
性能測(cè)試過(guò)程中，如何去發(fā)現(xiàn)內(nèi)存問(wèn)題：jvm分配的內(nèi)存是否夠用，是否有大對(duì)象占用太多內(nèi)存，監(jiān)控時(shí)哪樣的圖形反映內(nèi)存泄漏的風(fēng)險(xiǎn)？
如上圖中，堆大小和使用的堆大小一目了然。當(dāng)壓力穩(wěn)定的情況下，出現(xiàn)如上的圖形，說(shuō)明有內(nèi)存泄漏的風(fēng)險(xiǎn)。從上圖可以看到，雖然每次Full GC，JVM內(nèi)存會(huì)有部分回收，但回收并不徹底，不可回收的內(nèi)存對(duì)象會(huì)越來(lái)越多，這樣便會(huì)出現(xiàn)以上的一個(gè)步步高的趨勢(shì)。在Full GC無(wú)法回收的對(duì)象越來(lái)越多時(shí)，最終已使用內(nèi)存達(dá)到系統(tǒng)分配的內(nèi)存最大值，系統(tǒng)最后無(wú)內(nèi)存可分配，最終內(nèi)存溢出，導(dǎo)致down機(jī)。Java盡管采用自動(dòng)的內(nèi)存管理方式，但是仍然存在泄露的可能，JVM認(rèn)為對(duì)象沒(méi)有引用時(shí)，會(huì)把這個(gè)對(duì)象視為垃圾。Java內(nèi)存泄露就存在于，這個(gè)對(duì)象實(shí)際上已經(jīng)不再需要，但是仍然存在引用，此時(shí)就會(huì)產(chǎn)生內(nèi)存泄露。
如何找到導(dǎo)致內(nèi)存泄漏的程序？打開(kāi)抽樣器標(biāo)簽：點(diǎn)擊內(nèi)存后如下圖：
多次執(zhí)行g(shù)c前后分別堆dump一次，進(jìn)入最后dump出來(lái)的堆標(biāo)簽，點(diǎn)擊類：點(diǎn)擊右上角：“與另一個(gè)堆存儲(chǔ)對(duì)比”。如圖選擇第一次導(dǎo)出的dump內(nèi)容比較：
比較結(jié)果如下：
dump出來(lái)的類中看到有很多是jdk的基礎(chǔ)類型，那么分析程序的時(shí)候顯然只分析和程序員相關(guān)的，按實(shí)例數(shù)或大小排序優(yōu)先分析，找到我們程序自定義的包名，如上圖中com.memory.test?？梢钥吹蕉啻蝕c后，TestMemory對(duì)象實(shí)例一直在增加，說(shuō)明該對(duì)象引用的方法可能存在內(nèi)存泄漏。如何查看對(duì)象引用關(guān)系呢？雙擊選擇類TestMemory，如下所示：
左側(cè)是創(chuàng)建的實(shí)例總數(shù)，右側(cè)上部為該實(shí)例的結(jié)構(gòu)，下面為引用說(shuō)明，從圖中可以看出在類CyclicDependencies里面被引用了，并且被HashMap引用。
如此可以確定泄漏的位置，進(jìn)而根據(jù)實(shí)際情況進(jìn)行分析解決。
cpu分析
jvisualvm 能夠監(jiān)控應(yīng)用程序在一段時(shí)間的 CPU 的使用情況，顯示 CPU 的使用率、方法的執(zhí)行效率和頻率等相關(guān)數(shù)據(jù)幫助發(fā)現(xiàn)應(yīng)用程序的性能瓶頸?？梢酝ㄟ^(guò) jvisualvm的監(jiān)視標(biāo)簽和 抽樣器對(duì)應(yīng)用程序進(jìn)行 CPU 性能分析。
在監(jiān)視標(biāo)簽內(nèi)，可以查看 CPU 的使用率以及垃圾回收活動(dòng)對(duì)性能的影響。過(guò)高的 CPU 使用率可能是由于項(xiàng)目中存在低效的代碼，可以通過(guò) 抽樣器對(duì) CPU抽樣進(jìn)行詳細(xì)的分析。如果垃圾回收活動(dòng)過(guò)于頻繁，占用了較高的 CPU 資源，可能是由內(nèi)存不足或者是新生代和舊生代分配不合理導(dǎo)致的等。如下圖中：
觀察右邊的使用堆圖形，圖形呈鋸齒狀，說(shuō)明垃圾不斷地被回收，cpu圖形中也發(fā)現(xiàn)頻繁的gc導(dǎo)致cpu不穩(wěn)定，再通過(guò)監(jiān)控gc情況進(jìn)一步分析是否內(nèi)存分配不合理，使用的是什么垃圾回收策，是否有回收不掉的對(duì)象。關(guān)于gc需要理解java內(nèi)存模型、垃圾回收機(jī)制，這里不再詳述。
項(xiàng)目實(shí)例分析
以近期前置機(jī)接口性能測(cè)試為例，圍繞如何根據(jù)性能指標(biāo)通過(guò)監(jiān)控jvm分析系統(tǒng)性能瓶頸。下面是投標(biāo)接口壓測(cè)過(guò)程中表現(xiàn)出來(lái)的前端指標(biāo)
上圖中圖1為并發(fā)用戶數(shù)，2圖為點(diǎn)擊率，圖3為tps。并發(fā)用戶數(shù)與點(diǎn)擊率，與tpsf都是正相關(guān)的關(guān)系。即當(dāng)并發(fā)用戶數(shù)不斷增加時(shí)，點(diǎn)擊率也應(yīng)線性地增加，如果用戶數(shù)增加點(diǎn)擊率增加長(zhǎng)緩慢或平穩(wěn)或下降，都是性能不良好的表現(xiàn)。圖中當(dāng)并發(fā)用戶加載到40個(gè)左右時(shí)，點(diǎn)擊率都是跟隨著性能增漲，用戶數(shù)再往上增加時(shí)，點(diǎn)擊率不增漲反而有所下降。說(shuō)明服務(wù)器處理能力遇到瓶頸。這時(shí)通過(guò)jvisualvm工具監(jiān)控到cpu不足，jvm內(nèi)存頻繁的回收，如下圖
結(jié)合打印gc信息，發(fā)現(xiàn)ygc每秒1次
優(yōu)化的思路從減少ygc入手，可通過(guò)調(diào)整gc算法，增大年輕代大小來(lái)優(yōu)化。gc是一個(gè)復(fù)雜的過(guò)程，調(diào)整參數(shù)后需要經(jīng)過(guò)詳細(xì)的測(cè)試，驗(yàn)證是否達(dá)到優(yōu)化的目的。本人水平也非常有限，講得不對(duì)的地方，還望大家指教一起探討。
cpu方面結(jié)合top,可發(fā)現(xiàn)cpu load過(guò)高，如下圖：
再進(jìn)行cpu抽樣，可查看哪些方法占用cpu高，那么優(yōu)化cpu就可從兩方面入手：1、硬件上增加cpu 2、代碼上對(duì)占用cpu的高方法進(jìn)行代碼分析優(yōu)化，當(dāng)然這個(gè)得開(kāi)發(fā)人員進(jìn)行配合分析了。如下圖中，打印日志的方法消耗cpu比較高，可把日志級(jí)別調(diào)低。
增加cpu后，性能指標(biāo)得到明顯提升，最高tps可達(dá)到190。如下圖
上文內(nèi)容不用于商業(yè)目的，如涉及知識(shí)產(chǎn)權(quán)問(wèn)題，請(qǐng)權(quán)利人聯(lián)系博為峰小編(021-64471599-8017)，我們將立即處理。
