jvm内存和线程信息查看

目录

1、通过jmap查看整体信息：jmap -heap

2、通过jstat查看gc的信息：jstat -gcutil :统计gc信息

3、通过jmap 对jvm信息进行dump，在MAP工具中查看

4、利用jstack查看jvm线程的情况

---

1、通过jmap查看整体信息：jmap -heap <pid>

[root@localhost ~]# jmap -heap 27900

Attaching to process ID 27900, please wait...

Debugger attached successfully.

Client compiler detected.

JVM version is 20.45-b01

using thread-local object allocation.

Mark Sweep Compact GC

Heap Configuration: #堆内存初始化配置

MinHeapFreeRatio = 40 #-XX:MinHeapFreeRatio设置JVM堆最小空闲比率

MaxHeapFreeRatio = 70 #-XX:MaxHeapFreeRatio设置JVM堆最大空闲比率

MaxHeapSize = 100663296 (96.0MB) #-XX:MaxHeapSize=设置JVM堆的最大大小

NewSize = 1048576 (1.0MB) #-XX:NewSize=设置JVM堆的‘新生代’的默认大小

MaxNewSize = 4294901760 (4095.9375MB) #-XX:MaxNewSize=设置JVM堆的‘新生代’的最大大小

OldSize = 4194304 (4.0MB) #-XX:OldSize=设置JVM堆的‘老生代’的大小

NewRatio = 2 #-XX:NewRatio=:老年代/新生代的内存比值。默认的，新生代 ( Young ) 与老年代 ( Old ) 的比例的值为 1:2 ( 该值可以通过参数 –XX:NewRatio 来指定 )

SurvivorRatio = 8 #-XX:SurvivorRatio=设置年轻代中Eden区与Survivor区的大小比值。即： Eden = 8/10 的新生代空间大小，from = to = 1/10 的新生代空间大小。

PermSize = 12582912 (12.0MB) #-XX:PermSize=<value>:设置JVM堆的‘持久代’的初始大小

MaxPermSize = 67108864 (64.0MB) #-XX:MaxPermSize=<value>:设置JVM堆的‘持久代’的最大大小

Heap Usage:

New Generation (Eden + 1 Survivor Space): #新生代区内存分布，包含伊甸园区+1个Survivor区

capacity = 30212096 (28.8125MB)

used = 27103784 (25.848182678222656MB)

free = 3108312 (2.9643173217773438MB)

89.71169693092462% used

Eden Space: #Eden区内存分布

capacity = 26869760 (25.625MB)

used = 26869760 (25.625MB)

free = 0 (0.0MB)

100.0% used

From Space: #其中一个Survivor区的内存分布

capacity = 3342336 (3.1875MB)

used = 234024 (0.22318267822265625MB)

free = 3108312 (2.9643173217773438MB)

7.001809512867647% used

To Space: #另一个Survivor区的内存分布

capacity = 3342336 (3.1875MB)

used = 0 (0.0MB)

free = 3342336 (3.1875MB)

0.0% used

tenured generation: #当前的Old区内存分布

capacity = 67108864 (64.0MB)

used = 67108816 (63.99995422363281MB)

free = 48 (4.57763671875E-5MB)

99.99992847442627% used

Perm Generation: #当前的 “持久代” 内存分布

capacity = 14417920 (13.75MB)

used = 14339216 (13.674942016601562MB)

free = 78704 (0.0750579833984375MB)

99.45412375710227% used

2、通过jstat查看gc的信息：jstat -gcutil <pid>:统计gc信息

显示列名	具体描述
S0	年轻代中第一个survivor（幸存区）已使用的占当前容量百分比
S1	年轻代中第二个survivor（幸存区）已使用的占当前容量百分比
E	年轻代中Eden（伊甸园）已使用的占当前容量百分比
O	old代已使用的占当前容量百分比
P	perm代已使用的占当前容量百分比
YGC	从应用程序启动到采样时年轻代中gc次数
YGCT	从应用程序启动到采样时年轻代中gc所用时间(s)
FGC	从应用程序启动到采样时old代(全gc)gc次数
FGCT	从应用程序启动到采样时old代(全gc)gc所用时间(s)
GCT	从应用程序启动到采样时gc用的总时间(s)

[@jsy19-117-143.localdomain ~]# jstat -gcutil 31257

S0 S1 E O M CCS YGC YGCT FGC FGCT GCT

0.00 100.00 20.62 2.48 95.12 92.45 8 0.237 2 0.633 0.871

3、通过jmap 对jvm信息进行dump，在MAP工具中查看

[@jsy19-117~]# jmap -dump:format=b,file=heap.bin 31257

Dumping heap to /root/heap.bin ...

Heap dump file created

[@jsy19-117-143.localdomain ~]# ll -h

total 1.5G

-rw------- 1 root root 1.5G Nov 3 18:10 heap.bin

[@jsy19-117-143.localdomain ~]# sz heap.bin

Starting zmodem transfer. Press Ctrl+C to cancel.

Transferring heap.bin...

100% 1485744 KB 9710 KB/sec 00:02:33 0 Errors

然后利用MAP工具查看具体对象占用的内存情况

4、利用jstack查看jvm线程的情况

第一步先找出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的线程，可以使用top -Hp pid，输出如下：

TIME列就是各个Java线程耗费的CPU时间，CPU时间最长的是线程ID为21742的线程，用时最长

printf "%x\n" 21742

    得到21742的十六进制值为54ee，下面会用到。    

    OK，下一步终于轮到jstack上场了，它用来输出进程21711的堆栈信息，然后根据线程ID的十六进制值grep，如下：

root@ubuntu:/ #   jstack 21711 | grep 54ee
 

2	"PollIntervalRetrySchedulerThread" prio=10 tid=0x00007f950043e000 nid=0x54ee in Object.wait() [0x00007f94c6eda000]

    可以看到CPU消耗在PollIntervalRetrySchedulerThread这个类的Object.wait()，我找了下我的代码，定位到下面的代码：

getLog().info("Thread [" + getName() + "] is idle waiting...");

schedulerThreadState = PollTaskSchedulerThreadState.IdleWaiting;

long now = System.currentTimeMillis();

long waitTime = now + getIdleWaitTime();

long timeUntilContinue = waitTime - now;

synchronized(sigLock) {

try {

if(!halted.get()) {

sigLock.wait(timeUntilContinue);

}

}

catch (InterruptedException ignore) {

}

}

上面的sigLock.wait(timeUntilContinue)就对应了前面的Object.wait()。