今天一個同學問我:"我排查問題時總是遇到，jmap -heap或-histo 不能用，是不是我們機器配置有啥問題哇？ " 分享下這個case的解決過程。

登上同學說的那臺不能用的機器，執行jstack，報錯：

“get_thread_regs failed for a lwp”

這個問題以前碰到過，但忘了當時是什么原因了，執行其他的jmap -histo什么也卡著不動。

既然jstack沒法弄，就pstack看看進程到底什么狀況吧，于是pstack [pid]看，發現有一個線程的堆棧信息有點奇怪：

#0 0x00000038e720cd91 in sem_wait ()

對系統函數不太懂，但總覺得sem_wait這個有點奇怪，于是Google之，基本明白了這個是由于進程在等信號，這個時候通常會block住其他所有的線程，于是立刻ps看了下進程的狀態，果然進程的狀態變成了T，那上面碰到的所有現象都很容易解釋了，于是執行：kill -CONT [pid]，一切恢復正常。

繼續查為什么進程狀態會變成T，問問題的同學告訴了下我他在機器上執行過的一些命令，我看到其中一個很熟悉的命令：jmap -heap，看過我之前文章的同學估計會記得我很早以前分享過，在用cms gc的情況下，執行jmap -heap有些時候會導致進程變T，因此強烈建議別執行這個命令，如果想獲取內存目前每個區域的使用狀況，可通過jstat -gc或jstat -gccapacity來拿到。

到此為止，問題終于搞定，以后碰到jstack/jmap等不能用的時候，可以先看看進程的狀態，因此還是那句話，執行任何一句命令都要清楚它帶來的影響。

手頭還有另外一個case，折騰了一個多星期了還是沒太有頭緒，case的現象是ygc越來越慢，但可以肯定不是由于cms gc碎片問題造成的，感興趣的同學可以拿這個case去玩玩，如果能告訴我原因就更好了，:)，執行下面的代碼，啟動參數可以為

-XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xms512m -Xmx512m -Xmn100m -XX:+UseConcMarkSweepGC；

import com.thoughtworks.xstream.XStream;public class XStreamTest {public static void main(String[] args) throws Exception {while(true){XStream xs = new XStream();xs.toString();xs = null;}} }

應該就可以看到ygc的速度從10+ms一直增長到100+ms之類的...

?

案例分析：

上篇文章中ygc越來越慢的case的原因解讀

深入JVM徹底剖析前面ygc越來越慢的case

?

總結

以上是生活随笔為你收集整理的一个jstack/jmap等不能用的case的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。