国产一级a片免费看高清,亚洲熟女中文字幕在线视频,黄三级高清在线播放,免费黄色视频在线看

　　前言

　　現(xiàn)實企業(yè)級Java項目中，有時候會碰到下面這些問題：

　　●OutOfMemoryError，內(nèi)存不足

　　●內(nèi)存泄露

　　●線程死鎖

　　●鎖爭用（Lock Contention）

　　●Java進(jìn)程消耗CPU過高

　　●......

　　這些問題在日常開發(fā)中可能被很多人忽視（比如有的人遇到上面的問題只是重啟服務(wù)器或者調(diào)大內(nèi)存，而不會深究問題根源），但作為一名優(yōu)秀的性能測試工程師，必須能夠定位并分析這些問題。那么在性能測試的整個流程當(dāng)中，如何來監(jiān)控這些問題呢?這里介紹如何使用 JVisualVM 進(jìn)行性能監(jiān)控分析。

　　jvisualvm 安裝

　　JDK中還藏著一個寶貝,它的名字叫做VisualVM，自從 JDK 6 Update 7 以后已經(jīng)作為 Oracle JDK 的一部分，它主要用來監(jiān)控JVM的運行情況，可以用它來查看和瀏覽Heap Dump、Thread Dump、內(nèi)存對象實例情況、GC執(zhí)行情況、CPU消耗以及類的裝載情況。該工具位于 JDK 根目錄的 bin 文件夾下，無需安裝，正常安裝完jdk后，至jdk的bin目錄下直接運行jvisualvm.exe即可。

　　jvisualvm 插件安裝，選擇【工具】——【插件】——【可用插件】，打開后如下圖，沒有檢測到可用插件

　　然后點擊檢測最新版本，提示無法連接到j(luò)ava visualvm插件中心，這是因為java.net網(wǎng)站已經(jīng)被Oracle關(guān)閉了，visualvm已經(jīng)遷移到了github上，地址是https://visualvm.github.io/index.html，點擊Plugins進(jìn)入插件頁面

　　因為我的jdk是1.7.0_80，所以找到對應(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)程，本地機器的程序直接可以監(jiān)聽到，遠(yuǎn)程機器的程序需要加上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"

　　端口號可以自己定義，如果沖突了，修改下就好了。配置好后，重啟tomcat。那問題又來了，jar包如何配置監(jiān)聽呢？比如我們的前置機。其實很簡單，只要啟動jar包時加上上面的配置參數(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)程主機下會有一個jmx連接，打開連接，點擊監(jiān)視tab，可以看到如下界面了.

　　在上圖中可以看到cpu利用率和垃圾回收活動,然后是堆棧使用情況(這兩個在分析tomcat性能時很重要)。下面是類的使用情況，最后一個是線程活動情況。

　　點擊線程tab可以看到：下圖可以非常清晰的看到線程活動情況，那些線程正在執(zhí)行，哪些線程正在等待中，以及執(zhí)行完畢的線程等。這里可以看到每個線程的狀態(tài)，點擊某個線程右鍵可以查看該線程的詳細(xì)情況：

　　線程死鎖檢測

　　前面已經(jīng)介紹如何安裝插件，jvisualvm推薦16種插件，其中Threads Inspector插件可以輕松地檢測到死鎖，當(dāng)壓測過程中出現(xiàn)死鎖，在線程tab頁會出現(xiàn)如下的提示

　　從上圖可知，檢測到死鎖，可以通過【線程Dump】查看具體的死鎖線程的信息

　　Main.Java 21行：Thread-0當(dāng)前鎖定了

　　<0x00000000dbb308f0>，并且在等待鎖定<0x00000000dbb308c0>

　　Main.Java 32行：Thread-1當(dāng)前鎖定了

　　<0x00000000dbb308c0> ，并且在等待鎖定

　　<0x00000000dbb308f0>

　　兩個進(jìn)程互相都需要對方線程釋放其所占有資源(java.lang.String)，而根據(jù)【請求與保持條件】原則，顯然不會釋放已經(jīng)到手的資源，可以說是吃著碗里的，看著鍋里的，兩邊都想占有。

　　內(nèi)存分析

　　jvisualvm 通過檢測 JVM 中加載的類和對象信息等幫助分析內(nèi)存使用情況，可以通過  jvisualvm的監(jiān)視標(biāo)簽和 抽樣器對應(yīng)用程序進(jìn)行內(nèi)存分析。下面以分析內(nèi)存泄漏為例。

　　性能測試過程中，如何去發(fā)現(xiàn)內(nèi)存問題：jvm分配的內(nèi)存是否夠用，是否有大對象占用太多內(nèi)存，監(jiān)控時哪樣的圖形反映內(nèi)存泄漏的風(fēng)險？

　　如上圖中，堆大小和使用的堆大小一目了然。當(dāng)壓力穩(wěn)定的情況下，出現(xiàn)如上的圖形，說明有內(nèi)存泄漏的風(fēng)險。從上圖可以看到，雖然每次Full GC，JVM內(nèi)存會有部分回收，但回收并不徹底，不可回收的內(nèi)存對象會越來越多，這樣便會出現(xiàn)以上的一個步步高的趨勢。在Full GC無法回收的對象越來越多時，最終已使用內(nèi)存達(dá)到系統(tǒng)分配的內(nèi)存最大值，系統(tǒng)最后無內(nèi)存可分配，最終內(nèi)存溢出，導(dǎo)致down機。Java盡管采用自動的內(nèi)存管理方式，但是仍然存在泄露的可能，JVM認(rèn)為對象沒有引用時，會把這個對象視為垃圾。Java內(nèi)存泄露就存在于，這個對象實際上已經(jīng)不再需要，但是仍然存在引用，此時就會產(chǎn)生內(nèi)存泄露。

　　如何找到導(dǎo)致內(nèi)存泄漏的程序？打開抽樣器標(biāo)簽：點擊內(nèi)存后如下圖：

　　多次執(zhí)行g(shù)c前后分別堆dump一次，進(jìn)入最后dump出來的堆標(biāo)簽，點擊類：點擊右上角：“與另一個堆存儲對比”。如圖選擇第一次導(dǎo)出的dump內(nèi)容比較：

　　比較結(jié)果如下：

　　dump出來的類中看到有很多是jdk的基礎(chǔ)類型，那么分析程序的時候顯然只分析和程序員相關(guān)的，按實例數(shù)或大小排序優(yōu)先分析，找到我們程序自定義的包名，如上圖中com.memory.test?？梢钥吹蕉啻蝕c后，TestMemory對象實例一直在增加，說明該對象引用的方法可能存在內(nèi)存泄漏。如何查看對象引用關(guān)系呢？雙擊選擇類TestMemory，如下所示：

　　左側(cè)是創(chuàng)建的實例總數(shù)，右側(cè)上部為該實例的結(jié)構(gòu)，下面為引用說明，從圖中可以看出在類CyclicDependencies里面被引用了，并且被HashMap引用。

　　如此可以確定泄漏的位置，進(jìn)而根據(jù)實際情況進(jìn)行分析解決。

　　cpu分析

　　jvisualvm 能夠監(jiān)控應(yīng)用程序在一段時間的 CPU 的使用情況，顯示 CPU 的使用率、方法的執(zhí)行效率和頻率等相關(guān)數(shù)據(jù)幫助發(fā)現(xiàn)應(yīng)用程序的性能瓶頸。可以通過 jvisualvm的監(jiān)視標(biāo)簽和 抽樣器對應(yīng)用程序進(jìn)行 CPU 性能分析。

　　在監(jiān)視標(biāo)簽內(nèi)，可以查看 CPU 的使用率以及垃圾回收活動對性能的影響。過高的 CPU 使用率可能是由于項目中存在低效的代碼，可以通過 抽樣器對 CPU抽樣進(jìn)行詳細(xì)的分析。如果垃圾回收活動過于頻繁，占用了較高的 CPU 資源，可能是由內(nèi)存不足或者是新生代和舊生代分配不合理導(dǎo)致的等。如下圖中：

　　觀察右邊的使用堆圖形，圖形呈鋸齒狀，說明垃圾不斷地被回收，cpu圖形中也發(fā)現(xiàn)頻繁的gc導(dǎo)致cpu不穩(wěn)定，再通過監(jiān)控gc情況進(jìn)一步分析是否內(nèi)存分配不合理，使用的是什么垃圾回收策，是否有回收不掉的對象。關(guān)于gc需要理解java內(nèi)存模型、垃圾回收機制，這里不再詳述。

　　項目實例分析

　　以近期前置機接口性能測試為例，圍繞如何根據(jù)性能指標(biāo)通過監(jiān)控jvm分析系統(tǒng)性能瓶頸。下面是投標(biāo)接口壓測過程中表現(xiàn)出來的前端指標(biāo)

　　上圖中圖1為并發(fā)用戶數(shù)，2圖為點擊率，圖3為tps。并發(fā)用戶數(shù)與點擊率，與tpsf都是正相關(guān)的關(guān)系。即當(dāng)并發(fā)用戶數(shù)不斷增加時，點擊率也應(yīng)線性地增加，如果用戶數(shù)增加點擊率增加長緩慢或平穩(wěn)或下降，都是性能不良好的表現(xiàn)。圖中當(dāng)并發(fā)用戶加載到40個左右時，點擊率都是跟隨著性能增漲，用戶數(shù)再往上增加時，點擊率不增漲反而有所下降。說明服務(wù)器處理能力遇到瓶頸。這時通過jvisualvm工具監(jiān)控到cpu不足，jvm內(nèi)存頻繁的回收，如下圖

　　結(jié)合打印gc信息，發(fā)現(xiàn)ygc每秒1次

　　優(yōu)化的思路從減少ygc入手，可通過調(diào)整gc算法，增大年輕代大小來優(yōu)化。gc是一個復(fù)雜的過程，調(diào)整參數(shù)后需要經(jīng)過詳細(xì)的測試，驗證是否達(dá)到優(yōu)化的目的。本人水平也非常有限，講得不對的地方，還望大家指教一起探討。

　　cpu方面結(jié)合top,可發(fā)現(xiàn)cpu load過高，如下圖：

　　再進(jìn)行cpu抽樣，可查看哪些方法占用cpu高，那么優(yōu)化cpu就可從兩方面入手：1、硬件上增加cpu 2、代碼上對占用cpu的高方法進(jìn)行代碼分析優(yōu)化，當(dāng)然這個得開發(fā)人員進(jìn)行配合分析了。如下圖中，打印日志的方法消耗cpu比較高，可把日志級別調(diào)低。

　　增加cpu后，性能指標(biāo)得到明顯提升，最高tps可達(dá)到190。如下圖

本站僅提供存儲服務(wù)，所有內(nèi)容均由用戶發(fā)布，如發(fā)現(xiàn)有害或侵權(quán)內(nèi)容，請點擊舉報。