目前，我大部分時(shí)間在Java虛擬機(jī) （JVM）內(nèi)或周圍進(jìn)行大量工作，大部分時(shí)間是在Linux上。

當(dāng)事情變得不對勁并且我試圖確定原因時(shí)，我接觸了Java性能分析工具。 這些工具有兩種形式，一種是精美的GUI（稱為visualvm） ，當(dāng)我在本地計(jì)算機(jī)上工作時(shí)會(huì)使用它；另一種是Java開發(fā)工具包（JDK）附帶的cli工具（當(dāng)我在遠(yuǎn)程工作時(shí)使用）。

我指的CLI工具是：

• jps – JVM進(jìn)程狀態(tài)工具
• jstat – JVM統(tǒng)計(jì)信息監(jiān)視工具
• jhat – Java堆分析工具
• jstack – Java堆棧跟蹤工具

我最常用的工具是jps，jstat和jstack，jahat工具也非常方便，但實(shí)際上確實(shí)需要一個(gè)完整的博客文章，因?yàn)槟偪竦厥褂盟梢宰鍪裁础?在這篇文章中，我整理了一些技巧，觀察和示例輸出，以說明如何使用它們。

當(dāng)我使用ubuntu 11.10（僅安裝Java運(yùn)行時(shí)環(huán)境（JRE））時(shí)，我將需要安裝JDK。 就我而言，我決定嘗試一下openjdk 7，但是版本6可以正常工作。

root@oneric:~# apt-get install openjdk-7-jdk

要嘗試這些命令，我??已經(jīng)安裝了tomcat7，可以通過ubuntu上的apt來完成，同樣，以前的版本是tomcat 6。

root@oneric:~# apt-get install tomcat7

現(xiàn)在我已經(jīng)安裝了tomcat，我想列出Java進(jìn)程，請注意，這樣做時(shí)最好假定使用與服務(wù)相同的用戶帳戶。 在ubuntu上，我將使用用戶帳戶，因?yàn)閠omcat7用戶是系統(tǒng)帳戶，我必須覆蓋shell，因?yàn)槟J(rèn)情況下它是/ bin / nologin ，然后我可以以該用戶身份運(yùn)行jps。

jps命令輸出java進(jìn)程的PID以及啟動(dòng)時(shí)傳遞給它的主類名稱和參數(shù)。

root@oneric:~# su - tomcat7 -s /bin/bash tomcat7@oneric:~$ jps -ml 12728 org.apache.catalina.startup.Bootstrap start 13926 sun.tools.jps.Jps -ml tomcat7@oneric:~$

現(xiàn)在我們有了這些進(jìn)程的PID，可以運(yùn)行jstat了，我使用的第一個(gè)開關(guān)是-gcutil，這使我對jvm中的堆使用有了一個(gè)總體了解。 如果出現(xiàn)暫停或性能下降的情況，我將查看最后兩列。 其中包含垃圾收集時(shí)間（GCT）和完整垃圾收集時(shí)間（FGCT）。 如果FGCT列每秒增加一次，則可能是我們遇到了問題。

下面的示例針對tomcat的PID運(yùn)行jstat 。 我還指示該命令每20行顯示表頭并以1000毫秒的間隔連續(xù)打印統(tǒng)計(jì)信息，就像正常的控件C一樣，在輸出末尾顯示。

此示例顯示了一個(gè)很少發(fā)生的新啟動(dòng)的tomcat 7，這從完全垃圾收集時(shí)間（FGCT）和垃圾收集時(shí)間（GCT）列中的值可以清楚地看出。

還要注意的是，目前的Permgen空間（P）占70％。 permgen空間是堆的重要區(qū)域，因?yàn)樗４嬗脩纛?#xff0c;方法名稱和內(nèi)部jvm對象。 如果您使用tomcat已有一段時(shí)間，您將看到j(luò)ava.lang.OutOfMemoryError：PermGen空間錯(cuò)誤，該錯(cuò)誤指示何時(shí)該空間被填滿并且無法被垃圾回收。 重新部署大型Web應(yīng)用程序時(shí)經(jīng)常發(fā)生這種情況。

同樣在示例中，我們可以看到幸存者0（S0），幸存者1（S1），伊甸園和舊空間具有相當(dāng)大的可用空間。

tomcat7@oneric:~$ jstat -gcutil -h20 12728 1000S0 S1 E O P YGC YGCT FGC FGCT GCT 0.00 17.90 32.12 4.81 71.41 5 0.009 1 0.023 0.0320.00 17.90 32.12 4.81 71.41 5 0.009 1 0.023 0.0320.00 17.90 32.12 4.81 71.41 5 0.009 1 0.023 0.032

為了說明相比之下，tomcat的負(fù)載情況，我們可以安裝一個(gè)稱為Apache Bench的工具。

root@oneric:~# apt-get install apache2-utils

并運(yùn)行以下命令以同時(shí)訪問具有大量請求的基本頁面。

markw@oneric:~$ ab -n 1000000 -c 100 http://localhost:8080/

下面是該測試運(yùn)行了一段時(shí)間后的輸出，因?yàn)槲覀兛梢钥吹叫掖嬲?，伊甸園和舊空間有了相當(dāng)大的增長，但是服務(wù)器并沒有花費(fèi)很多時(shí)間來進(jìn)行完整的垃圾收集，如下所示完整垃圾收集計(jì)數(shù)（FGC）的值只有10，從年輕一代收集計(jì)數(shù)（YGC）的增加可以看出，大部分工作是在年輕一代中進(jìn)行的。

還要注意的是，permgen空間沒有太多變化，實(shí)際上下降了，這是由于堆大小的增加。

tomcat7@oneric:~$ jstat -gcutil -h20 12728 1000S0 S1 E O P YGC YGCT FGC FGCT GCT 0.00 100.00 52.02 81.84 59.62 117 1.176 10 0.074 1.2500.00 100.00 52.02 81.84 59.62 117 1.176 10 0.074 1.2500.00 100.00 52.02 81.84 59.62 117 1.176 10 0.074 1.2500.00 100.00 52.02 81.84 59.62 117 1.176 10 0.074 1.250

為了更深入地了解垃圾收集的原因，我們使用了帶有-gccause選項(xiàng)的jstat命令，該命令顯示的列與上一個(gè)命令相同，但有兩個(gè)額外的列提供了GC的原因。

在下面的示例中，我們可以看到分配失敗的示例，這表明由于堆太小，正在執(zhí)行完整的gc。

tomcat7@oneric:~$ jstat -gccause -h20 12728 1000 100.00 0.00 0.00 78.91 59.67 168 1.680 14 0.083 1.763 unknown GCCause No GC 100.00 0.00 72.61 83.73 59.67 170 1.698 14 0.083 1.781 unknown GCCause No GC 0.00 100.00 46.24 91.83 59.67 173 1.729 14 0.083 1.811 unknown GCCause No GC 100.00 0.00 11.39 29.80 59.67 176 1.759 16 0.086 1.846 unknown GCCause No GC 100.00 0.00 92.41 35.30 59.67 179 1.777 16 0.086 1.864 unknown GCCause Allocation Failure 0.00 100.00 62.58 43.05 59.67 181 1.803 16 0.086 1.889 unknown GCCause No GC

診斷性能問題時(shí)，我還想研究的另一個(gè)領(lǐng)域是虛擬機(jī)中運(yùn)行的線程。 這可以幫助我理解是否有任何組件超載，因此可以運(yùn)行許多線程來追趕。 這主要僅適用于異步過程，例如消息傳遞或調(diào)度例程。

要轉(zhuǎn)儲(chǔ)線程及其當(dāng)前堆棧的列表，請使用jstack命令，如下面的示例所示，我通常再次以進(jìn)程所有者的身份運(yùn)行它。

tomcat7@oneric:~$ jstack 12728 2011-10-16 14:53:58 Full thread dump OpenJDK 64-Bit Server VM (20.0-b11 mixed mode):"Attach Listener" daemon prio=10 tid=0x00000000015be800 nid=0x4004 waiting on condition [0x0000000000000000]java.lang.Thread.State: RUNNABLE"http-bio-8080-exec-182" daemon prio=10 tid=0x00007f9d84274800 nid=0x3cd3 waiting on condition [0x00007f9d7a0df000]java.lang.Thread.State: WAITING (parking)at sun.misc.Unsafe.park(Native Method)- parking to wait for <0x00000000ef16da38> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject. await(AbstractQueuedSynchronizer.java:2043)at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:386)at org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:104)at org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:32)at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1043)at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1103)at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)at java.lang.Thread.run(Thread.java:679) ...

我計(jì)劃用jruby在一些可視化工具上做一些工作，但是這可能是我下一篇文章的重點(diǎn)。 在撰寫本文的過程中，我找到了一些有趣的文章，這些文章鏈接如下：

• Sun Microsystems的Chuk-Munn Lee對Java SE 6部署進(jìn)行故障排除
• 解釋java.lang.OutOfMemoryError：PermGen空間

參考： Mark Wolfe博客上的 JCG合作伙伴 Mark Wolfe 從CLI監(jiān)視OpenJDK 。

相關(guān)文章 ：

• 任何軟件開發(fā)公司應(yīng)存在的服務(wù)，實(shí)踐和工具，第1部分
• 這是在您的業(yè)務(wù)邏輯之前！
• 您的代碼中有幾個(gè)錯(cuò)誤？
• 使用FindBugs產(chǎn)生更少的錯(cuò)誤代碼
• 引入新技術(shù)–如何抵抗阻力
• Java工具：源代碼優(yōu)化和分析
• 我們可以更好地理解需求規(guī)范嗎？
• 每個(gè)程序員都應(yīng)該知道的事情
• 為什么自動(dòng)化測試可以提高您的開發(fā)速度

翻譯自: https://www.javacodegeeks.com/2011/10/monitoring-openjdk-from-cli.html

總結(jié)

以上是生活随笔為你收集整理的从CLI监视OpenJDK的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。