B、 jstack
jstack主要用来查看某个Java进程内的线程堆栈信息。语法格式如下:
1 |
jstack [option] pid |
2 |
jstack [option] executable core |
3 |
jstack [option] [server- id @]remote- hostname -or-ip |
现实企业级Java开发中,有时候我们会碰到下面这些问题:
-
OutOfMemoryError,内存不足
-
内存泄露
-
线程死锁
-
锁争用(Lock Contention)
-
Java进程消耗CPU过高
jstat:一个极强的监视VM内存工具。可以用来监视VM内存内的各种堆和非堆的大小及其内存使用量。
jmap:打印出某个java进程(使用pid)内存内的所有’对象’的情况(如:产生那些对象,及其数量)。
1. jstat这个命令对于查看Jvm的堆栈信息很有用。能够查看eden,survivor,old,perm等heap的capacity,utility信息对于查看系统是不是有能存泄漏以及参数设置是否合理有不错的意义2. jstack这个是用来查看jvm当前的thread dump的。可以看到当前Jvm里面的线程状况。这个对于查找blocked线程比较有意义3. jmap .这个是用来查看jvm当前的heap dump的。可以看出当前jvm中各种对象的数量,所占空间等等。
本文部分转自https://www.cnblogs.com/rainy-shurun/p/5732341.html
Linux使用jstat命令查看jvm的GC情况
本文转自https://blog.csdn.net/zlzlei/article/details/46471627原创 2015年06月12日 15:07:19
- 55097
命令格式
jstat命令命令格式:
jstat [Options] vmid [interval] [count]
参数说明:
Options,选项,我们一般使用 -gcutil 查看gc情况
vmid,VM的进程号,即当前运行的java进程号
interval,间隔时间,单位为秒或者毫秒
count,打印次数,如果缺省则打印无数次
示例说明
示例
通常运行命令如下:jstat -gc 12538 5000即会每5秒一次显示进程号为12538的java进成的GC情况,显示内容如下图:
结果说明
显示内容说明如下(部分结果是通过其他其他参数显示的,暂不说明): S0C:年轻代中第一个survivor(幸存区)的容量 (字节)
S1C:年轻代中第二个survivor(幸存区)的容量 (字节)
S0U:年轻代中第一个survivor(幸存区)目前已使用空间 (字节)
S1U:年轻代中第二个survivor(幸存区)目前已使用空间 (字节)
EC:年轻代中Eden(伊甸园)的容量 (字节)
EU:年轻代中Eden(伊甸园)目前已使用空间 (字节)
OC:Old代的容量 (字节)
OU:Old代目前已使用空间 (字节)
PC:Perm(持久代)的容量 (字节)
PU:Perm(持久代)目前已使用空间 (字节)
YGC:从应用程序启动到采样时年轻代中gc次数
YGCT:从应用程序启动到采样时年轻代中gc所用时间(s)
FGC:从应用程序启动到采样时old代(全gc)gc次数
FGCT:从应用程序启动到采样时old代(全gc)gc所用时间(s)
GCT:从应用程序启动到采样时gc用的总时间(s)
NGCMN:年轻代(young)中初始化(最小)的大小 (字节)
NGCMX:年轻代(young)的最大容量 (字节)
NGC:年轻代(young)中当前的容量 (字节)
OGCMN:old代中初始化(最小)的大小 (字节)
OGCMX:old代的最大容量 (字节)
OGC:old代当前新生成的容量 (字节)
PGCMN:perm代中初始化(最小)的大小 (字节)
PGCMX:perm代的最大容量 (字节)
PGC:perm代当前新生成的容量 (字节)
S0:年轻代中第一个survivor(幸存区)已使用的占当前容量百分比
S1:年轻代中第二个survivor(幸存区)已使用的占当前容量百分比
E:年轻代中Eden(伊甸园)已使用的占当前容量百分比
O:old代已使用的占当前容量百分比
P:perm代已使用的占当前容量百分比
S0CMX:年轻代中第一个survivor(幸存区)的最大容量 (字节)
S1CMX :年轻代中第二个survivor(幸存区)的最大容量 (字节)
ECMX:年轻代中Eden(伊甸园)的最大容量 (字节)
DSS:当前需要survivor(幸存区)的容量 (字节)(Eden区已满)
TT: 持有次数限制
MTT : 最大持有次数限制
jstack可以定位到线程堆栈,根据堆栈信息我们可以定位到具体代码,所以它在JVM性能调优中使用得非常多。下面我们来一个实例找出某个Java进程中最耗费CPU的Java线程并定位堆栈信息,用到的命令有ps、top、printf、jstack、grep。
第一步先找出Java进程ID,我部署在服务器上的Java应用名称为mrf-center:
1 |
root@ubuntu:/ # ps -ef | grep mrf-center | grep -v grep |
2 |
root 21711 1 1 14:47 pts/3 00:02:10 java -jar mrf-center.jar |
得到进程ID为21711,第二步找出该进程内最耗费CPU的线程,可以使用ps -Lfp pid或者ps -mp pid -o THREAD, tid, time或者top -Hp pid,我这里用第三个,输出如下:
TIME列就是各个Java线程耗费的CPU时间,CPU时间最长的是线程ID为21742的线程
得到21742的十六进制值为54ee,下面会用到。
OK,下一步终于轮到jstack上场了,它用来输出进程21711的堆栈信息,然后根据线程ID的十六进制值grep,如下:
1 |
root@ubuntu:/ # jstack 21711 | grep 54ee |
2 |
"PollIntervalRetrySchedulerThread" prio=10 tid=0x00007f950043e000 nid=0x54ee in Object.wait() [0x00007f94c6eda000] |
可以看到CPU消耗在PollIntervalRetrySchedulerThread这个类的Object.wait(),我找了下我的代码,定位到下面的代码:
01 |
// Idle wait |
02 |
getLog().info( "Thread [" + getName() + "] is idle waiting..." ); |
03 |
schedulerThreadState = PollTaskSchedulerThreadState.IdleWaiting; |
04 |
long now = System.currentTimeMillis(); |
05 |
long waitTime = now + getIdleWaitTime(); |
06 |
long timeUntilContinue = waitTime - now; |
07 |
synchronized (sigLock) { |
08 |
try { |
09 |
if (!halted.get()) { |
10 |
sigLock.wait(timeUntilContinue); |
11 |
} |
12 |
} |
13 |
catch (InterruptedException ignore) { |
14 |
} |
15 |
} |