技术自查番外篇三：其他JVM监控工具

除了MAT，还有一些其他常用的JVM监控工具

Jps

作用：显示当前系统的Java进程的情况（仅查找Java进程，不能查找系统的所有进程）

位置：Jps位于jdk的bin目录下，由于我们已配置Jdk环境，故可直接使用jps指令进行操作

原理：

java程序在启动后，会在java.io.tempdir指定的目录（临时文件夹），生成一个hsperfdata_{UserName}的文件夹，里面包含进程名的文件

window环境下（一般在AppData/local/temp/hsperfdata_用户名）

Linux环境下（一般在temp/hsperfdata_用户名）

jsp只要分析该临时进程文件，就可以获取系统参数，jvm参数等等

jps用法

jsp -help

1. jps 输出所有java进程名和进程id
2. jps -q 只输出所有java进程id
3. jps -m 输出传入main方法的参数
4. jps -l 输出完全的包名，应用主类名和jar的完全路径名
5. jps -v 输出jvm参数
6. jps -V 输出通过flag文件传递到JVM参数

jps:输出java进程名和进程id

 jps -q：只输出java进程id

jps -m:输出传入main方法的参数

jps -l：输出完全的包名，应用主类名和jar的完全路径名

jps -v:输出jvm参数

额外知识点

获取远程服务器jps信息

jps支持查看远程服务的jvm进程信息，如果需要查看其它机器上的jvm进程，需要在被查看机器上启动jstad服务（但一般直接通过xshell等软件直接登上机器）

启动jstatd服务，需要有足够的权限，需要使用java的安全策略分配相应的权限。

1. 创建jstatd.all.policy策略文件

grant codebase "file:${java.home}/../lib/tools.jar" {permission java.security.AllPermission;
};

2. 启动jstatd服务器

jstatd -J-Djava.security.policy=jstatd.all.policy -J-Djava.rmi.server.hostname=192.168.31.241

-J 参数是一个公共的参数，如 jps、 jstat 等命令都可以接收这个参数。 由于 jps、 jstat 命令本身也是 Java 应用程序， -J 参数可以为 jps 等命令本身设置 Java 虚拟机参数。

-Djava.security.policy：指定策略文件

-Djava.rmi.server.hostname：指定服务器的ip地址（可忽略）

默认情况下， jstatd 开启在 1099 端口上开启 RMI 服务器。

开启完毕后，指令无变化，

Jps失效处理

现象： 用ps -ef|grep java能看到启动的java进程，但是用jps查看却不存在该进程的id。待会儿解释过之后就能知道在该情况下，jconsole、jvisualvm可能无法监控该进程，其他java自带工具也可能无法使用

分析： jps、jconsole、jvisualvm等工具的数据来源就是这个文件（/tmp/hsperfdata_userName/pid)。所以当该文件不存在或是无法读取时就会出现jps无法查看该进程号，jconsole无法监控等问题

原因：

1. 磁盘读写、目录权限问题 若该用户没有权限写/tmp目录或是磁盘已满，则无法创建/tmp/hsperfdata_userName/pid文件。或该文件已经生成，但用户没有读权限
2. 临时文件丢失，被删除或是定期清理 对于linux机器，一般都会存在定时任务对临时文件夹进行清理，导致/tmp目录被清空。这也是我第一次碰到该现象的原因。常用的可能定时删除临时目录的工具为crontab、redhat的tmpwatch、ubuntu的tmpreaper等等
3. 这个导致的现象可能会是这样，用jconsole监控进程，发现在某一时段后进程仍然存在，但是却没有监控信息了。

Jstack

比较常用的jvm监控工具，主要用于监控jvm的线程（是否出现死锁，线程优先度等）,这里单独开一篇章讲，涉及到多线程，比较重要，详细看  技术自查番外篇四：Jstack与线程

jstack pid ./stack.log

会在当前文件夹生成一个stack.log日志文件

打开stack.log文件

正常的项目日志，没有发生线程异常。

2021-08-29 21:11:54
Full thread dump OpenJDK 64-Bit Server VM (11.0.2+9 mixed mode):
Threads class SMR info:
_java_thread_list=0x0000026f05668a70, length=19, elements={
0x0000026f7ee88000, 0x0000026f7f741800, 0x0000026f7f7a6800, 0x0000026f7f7a8800,
0x0000026f7f7ab800, 0x0000026f7f7b1800, 0x0000026f7f730800, 0x0000026f7f997800,
0x0000026f7f996800, 0x0000026f7f99a000, 0x0000026f04084800, 0x0000026f04460800,
0x0000026f056eb800, 0x0000026f057a1800, 0x0000026f057c9800, 0x0000026f057ca000,
0x0000026f058af800, 0x0000026f058b1000, 0x0000026f5e98a800
}
"Reference Handler" #2 daemon prio=10 os_prio=2 cpu=0.00ms elapsed=201.74s tid=0x0000026f7ee88000 nid=0x3b4 waiting on condition  [0x000000e3744fe000]java.lang.Thread.State: RUNNABLEat java.lang.ref.Reference.waitForReferencePendingList(java.base@11.0.2/Native Method)at java.lang.ref.Reference.processPendingReferences(java.base@11.0.2/Reference.java:241)at java.lang.ref.Reference$ReferenceHandler.run(java.base@11.0.2/Reference.java:213)
"Finalizer" #3 daemon prio=8 os_prio=1 cpu=0.00ms elapsed=201.74s tid=0x0000026f7f741800 nid=0x3b68 in Object.wait()  [0x000000e3745fe000]java.lang.Thread.State: WAITING (on object monitor)at java.lang.Object.wait(java.base@11.0.2/Native Method)- waiting on <0x0000000701394368> (a java.lang.ref.ReferenceQueue$Lock)at java.lang.ref.ReferenceQueue.remove(java.base@11.0.2/ReferenceQueue.java:155)- waiting to re-lock in wait() <0x0000000701394368> (a java.lang.ref.ReferenceQueue$Lock)at java.lang.ref.ReferenceQueue.remove(java.base@11.0.2/ReferenceQueue.java:176)at java.lang.ref.Finalizer$FinalizerThread.run(java.base@11.0.2/Finalizer.java:170)
"Signal Dispatcher" #4 daemon prio=9 os_prio=2 cpu=0.00ms elapsed=201.72s tid=0x0000026f7f7a6800 nid=0x1c4c runnable  [0x0000000000000000]java.lang.Thread.State: RUNNABLE
"Attach Listener" #5 daemon prio=5 os_prio=2 cpu=0.00ms elapsed=201.72s tid=0x0000026f7f7a8800 nid=0x1cb0 waiting on condition  [0x0000000000000000]java.lang.Thread.State: RUNNABLE
"C1 CompilerThread0" #6 daemon prio=9 os_prio=2 cpu=171.88ms elapsed=201.72s tid=0x0000026f7f7ab800 nid=0x34c8 waiting on condition  [0x0000000000000000]java.lang.Thread.State: RUNNABLENo compile task
"Sweeper thread" #10 daemon prio=9 os_prio=2 cpu=0.00ms elapsed=201.72s tid=0x0000026f7f7b1800 nid=0x3bbc runnable  [0x0000000000000000]java.lang.Thread.State: RUNNABLE
"Common-Cleaner" #11 daemon prio=8 os_prio=1 cpu=0.00ms elapsed=201.69s tid=0x0000026f7f730800 nid=0x3f5c in Object.wait()  [0x000000e374afe000]java.lang.Thread.State: TIMED_WAITING (on object monitor)at java.lang.Object.wait(java.base@11.0.2/Native Method)- waiting on <0x00000007013970d8> (a java.lang.ref.ReferenceQueue$Lock)at java.lang.ref.ReferenceQueue.remove(java.base@11.0.2/ReferenceQueue.java:155)- waiting to re-lock in wait() <0x00000007013970d8> (a java.lang.ref.ReferenceQueue$Lock)at jdk.internal.ref.CleanerImpl.run(java.base@11.0.2/CleanerImpl.java:148)at java.lang.Thread.run(java.base@11.0.2/Thread.java:834)at jdk.internal.misc.InnocuousThread.run(java.base@11.0.2/InnocuousThread.java:134)
"JDWP Transport Listener: dt_socket" #12 daemon prio=10 os_prio=0 cpu=15.63ms elapsed=201.67s tid=0x0000026f7f997800 nid=0x37ec runnable  [0x0000000000000000]java.lang.Thread.State: RUNNABLE
"JDWP Event Helper Thread" #13 daemon prio=10 os_prio=0 cpu=109.38ms elapsed=201.67s tid=0x0000026f7f996800 nid=0x3f4c runnable  [0x0000000000000000]java.lang.Thread.State: RUNNABLE
"JDWP Command Reader" #14 daemon prio=10 os_prio=0 cpu=15.63ms elapsed=201.67s tid=0x0000026f7f99a000 nid=0x3d50 runnable  [0x0000000000000000]java.lang.Thread.State: RUNNABLE
"Service Thread" #15 daemon prio=9 os_prio=0 cpu=0.00ms elapsed=201.58s tid=0x0000026f04084800 nid=0x568 runnable  [0x0000000000000000]java.lang.Thread.State: RUNNABLE
"RMI TCP Accept-0" #17 daemon prio=5 os_prio=0 cpu=15.63ms elapsed=201.40s tid=0x0000026f04460800 nid=0x3fa4 runnable  [0x000000e3752ff000]java.lang.Thread.State: RUNNABLEat java.net.PlainSocketImpl.accept0(java.base@11.0.2/Native Method)at java.net.PlainSocketImpl.socketAccept(java.base@11.0.2/PlainSocketImpl.java:159)at java.net.AbstractPlainSocketImpl.accept(java.base@11.0.2/AbstractPlainSocketImpl.java:458)at java.net.ServerSocket.implAccept(java.base@11.0.2/ServerSocket.java:551)at java.net.ServerSocket.accept(java.base@11.0.2/ServerSocket.java:519)at sun.management.jmxremote.LocalRMIServerSocketFactory$1.accept(jdk.management.agent@11.0.2/LocalRMIServerSocketFactory.java:52)at sun.rmi.transport.tcp.TCPTransport$AcceptLoop.executeAcceptLoop(java.rmi@11.0.2/TCPTransport.java:394)at sun.rmi.transport.tcp.TCPTransport$AcceptLoop.run(java.rmi@11.0.2/TCPTransport.java:366)at java.lang.Thread.run(java.base@11.0.2/Thread.java:834)
"RMI Scheduler(0)" #22 daemon prio=5 os_prio=0 cpu=0.00ms elapsed=200.65s tid=0x0000026f056eb800 nid=0x20d0 waiting on condition  [0x000000e375cff000]java.lang.Thread.State: TIMED_WAITING (parking)at jdk.internal.misc.Unsafe.park(java.base@11.0.2/Native Method)- parking to wait for  <0x0000000701318208> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)at java.util.concurrent.locks.LockSupport.parkNanos(java.base@11.0.2/LockSupport.java:234)at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(java.base@11.0.2/AbstractQueuedSynchronizer.java:2123)at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(java.base@11.0.2/ScheduledThreadPoolExecutor.java:1182)at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(java.base@11.0.2/ScheduledThreadPoolExecutor.java:899)at java.util.concurrent.ThreadPoolExecutor.getTask(java.base@11.0.2/ThreadPoolExecutor.java:1054)at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base@11.0.2/ThreadPoolExecutor.java:1114)at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base@11.0.2/ThreadPoolExecutor.java:628)at java.lang.Thread.run(java.base@11.0.2/Thread.java:834)
"Catalina-utility-1" #24 prio=1 os_prio=-2 cpu=0.00ms elapsed=200.63s tid=0x0000026f057a1800 nid=0x328c waiting on condition  [0x000000e375dff000]java.lang.Thread.State: WAITING (parking)at jdk.internal.misc.Unsafe.park(java.base@11.0.2/Native Method)- parking to wait for  <0x000000070ff6abe8> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)at java.util.concurrent.locks.LockSupport.park(java.base@11.0.2/LockSupport.java:194)at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(java.base@11.0.2/AbstractQueuedSynchronizer.java:2081)at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(java.base@11.0.2/ScheduledThreadPoolExecutor.java:1177)at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(java.base@11.0.2/ScheduledThreadPoolExecutor.java:899)at java.util.concurrent.ThreadPoolExecutor.getTask(java.base@11.0.2/ThreadPoolExecutor.java:1054)at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base@11.0.2/ThreadPoolExecutor.java:1114)at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base@11.0.2/ThreadPoolExecutor.java:628)at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)at java.lang.Thread.run(java.base@11.0.2/Thread.java:834)
"Catalina-utility-2" #25 prio=1 os_prio=-2 cpu=0.00ms elapsed=200.63s tid=0x0000026f057c9800 nid=0x34e8 waiting on condition  [0x000000e375efe000]java.lang.Thread.State: TIMED_WAITING (parking)at jdk.internal.misc.Unsafe.park(java.base@11.0.2/Native Method)- parking to wait for  <0x000000070ff6abe8> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)at java.util.concurrent.locks.LockSupport.parkNanos(java.base@11.0.2/LockSupport.java:234)at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(java.base@11.0.2/AbstractQueuedSynchronizer.java:2123)at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(java.base@11.0.2/ScheduledThreadPoolExecutor.java:1182)at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(java.base@11.0.2/ScheduledThreadPoolExecutor.java:899)at java.util.concurrent.ThreadPoolExecutor.getTask(java.base@11.0.2/ThreadPoolExecutor.java:1054)at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base@11.0.2/ThreadPoolExecutor.java:1114)at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base@11.0.2/ThreadPoolExecutor.java:628)at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)at java.lang.Thread.run(java.base@11.0.2/Thread.java:834)
"container-0" #26 prio=5 os_prio=0 cpu=0.00ms elapsed=200.63s tid=0x0000026f057ca000 nid=0x2db4 waiting on condition  [0x000000e375ffe000]java.lang.Thread.State: TIMED_WAITING (sleeping)at java.lang.Thread.sleep(java.base@11.0.2/Native Method)at org.apache.catalina.core.StandardServer.await(StandardServer.java:563)at org.springframework.boot.web.embedded.tomcat.TomcatWebServer$1.run(TomcatWebServer.java:197)
"http-nio-8080-Poller" #27 daemon prio=5 os_prio=0 cpu=0.00ms elapsed=200.31s tid=0x0000026f058af800 nid=0x3d40 runnable  [0x000000e3760fe000]java.lang.Thread.State: RUNNABLEat sun.nio.ch.WindowsSelectorImpl$SubSelector.poll0(java.base@11.0.2/Native Method)at sun.nio.ch.WindowsSelectorImpl$SubSelector.poll(java.base@11.0.2/WindowsSelectorImpl.java:339)at sun.nio.ch.WindowsSelectorImpl.doSelect(java.base@11.0.2/WindowsSelectorImpl.java:167)at sun.nio.ch.SelectorImpl.lockAndDoSelect(java.base@11.0.2/SelectorImpl.java:124)- locked <0x000000070dbaf9c0> (a sun.nio.ch.Util$2)- locked <0x000000070dbaecd0> (a sun.nio.ch.WindowsSelectorImpl)at sun.nio.ch.SelectorImpl.select(java.base@11.0.2/SelectorImpl.java:136)at org.apache.tomcat.util.net.NioEndpoint$Poller.run(NioEndpoint.java:787)at java.lang.Thread.run(java.base@11.0.2/Thread.java:834)
"http-nio-8080-Acceptor" #28 daemon prio=5 os_prio=0 cpu=0.00ms elapsed=200.30s tid=0x0000026f058b1000 nid=0x2e18 runnable  [0x000000e3761fe000]java.lang.Thread.State: RUNNABLEat sun.nio.ch.ServerSocketChannelImpl.accept0(java.base@11.0.2/Native Method)at sun.nio.ch.ServerSocketChannelImpl.accept(java.base@11.0.2/ServerSocketChannelImpl.java:533)at sun.nio.ch.ServerSocketChannelImpl.accept(java.base@11.0.2/ServerSocketChannelImpl.java:285)at org.apache.tomcat.util.net.NioEndpoint.serverSocketAccept(NioEndpoint.java:540)at org.apache.tomcat.util.net.NioEndpoint.serverSocketAccept(NioEndpoint.java:78)at org.apache.tomcat.util.net.Acceptor.run(Acceptor.java:106)at java.lang.Thread.run(java.base@11.0.2/Thread.java:834)
"DestroyJavaVM" #29 prio=5 os_prio=0 cpu=1187.50ms elapsed=200.28s tid=0x0000026f5e98a800 nid=0x3c2c waiting on condition  [0x0000000000000000]java.lang.Thread.State: RUNNABLE
"VM Thread" os_prio=2 cpu=15.63ms elapsed=201.74s tid=0x0000026f7eead000 nid=0x818 runnable  
"GC Thread#0" os_prio=2 cpu=0.00ms elapsed=201.75s tid=0x0000026f5e9a3000 nid=0x3c44 runnable  
"GC Thread#1" os_prio=2 cpu=0.00ms elapsed=201.30s tid=0x0000026f046cb800 nid=0x3f50 runnable  
"GC Thread#2" os_prio=2 cpu=0.00ms elapsed=201.30s tid=0x0000026f046f0800 nid=0x3f38 runnable  
"GC Thread#3" os_prio=2 cpu=0.00ms elapsed=201.30s tid=0x0000026f046f1800 nid=0x3bc0 runnable  
"GC Thread#4" os_prio=2 cpu=0.00ms elapsed=201.30s tid=0x0000026f046f2000 nid=0x3194 runnable  
"GC Thread#5" os_prio=2 cpu=0.00ms elapsed=201.30s tid=0x0000026f046f3000 nid=0x3f90 runnable  
"G1 Main Marker" os_prio=2 cpu=0.00ms elapsed=201.75s tid=0x0000026f5ea00000 nid=0x3c48 runnable  
"G1 Conc#0" os_prio=2 cpu=0.00ms elapsed=201.75s tid=0x0000026f5ea01800 nid=0x4e4 runnable  
"G1 Conc#1" os_prio=2 cpu=0.00ms elapsed=201.09s tid=0x0000026f04700800 nid=0xdd4 runnable  
"G1 Conc#2" os_prio=2 cpu=0.00ms elapsed=201.09s tid=0x0000026f0516b800 nid=0x3f88 runnable  
"G1 Refine#0" os_prio=2 cpu=0.00ms elapsed=201.75s tid=0x0000026f7ed6e000 nid=0x144c runnable  
"G1 Young RemSet Sampling" os_prio=2 cpu=0.00ms elapsed=201.75s tid=0x0000026f7ed6f000 nid=0x39f8 runnable  
"VM Periodic Task Thread" os_prio=2 cpu=0.00ms elapsed=201.39s tid=0x0000026f0446d800 nid=0x3f98 waiting on condition  
JNI global refs: 52, weak refs: 11675

主要名词解释

1. os_prio:操作系统别的优先级，越小优先
2. prio:线程优先度，越小优先
3. cpu：占用cpu时间（占用时间长，说明消耗cpu资源大）
4. tid：java内线程的id
5. nid:tid的十六进制id（操作系统内的id）
6. elapsed：线程花费时间

进程状态

1. new:未启动，不会出现在日志内
2. runnable:正在运行
3. blocked：线程被阻塞
4. waiting:线程正在等待
5. time_wating

Jstat

作用：轻量级对堆内存和gc回收情况监控的工具

原理：同jps一样，监控临时文件（/tmp/hsperfdata_userName/pid）。

局限性：不能获取gc的详细过程信息。（不知道多少个gc线程工作，且占用时间，每次gc，回收了多少空间等等），这也是jstat使用较少原因，最好还是看gc日志

具体指令：

jstat -options 列出当前JVM版本支持的选项。

1. jstat -class(类加载器)
2. jstat -compiler(JIT)
3. jstat -gc(GC堆状态)
4. jstat -gccapacity(各区大小)
5. jstat -gccause(最近一次gc统计和原因)
6. jstat -gcmetacapacity(元空区大小)
7. jstat -gcnew(新区统计)
8. jstat -gcnewcapacity(新区大小)
9. jstat -gcold(老区统计)
10. jstat -gcoldcapacity(老区大小)
11. jstat -gcutil(gc统计汇总)
12. jstat -printcompilation(HotSpot编译统计)
13. jstat -gc -t pid m n（监控java进程id，m毫秒一次刷新，n次迭代统计信息）/（监控java进程n*m秒，每m毫秒刷新一次gc信息）

先用jps获取当前系统的java进程，找出项目所在进程

jps

 

17048就是当前项目java进程

jstat -gc -t 17048 1000 5：监控17048线程5秒，每一秒打印堆和gc信息

1. soc 年轻代第一个survivor的容量
2. s1c 年轻代第二个survivor的容量
3. sou 年轻代第一个survivor的已使用容量
4. s1u 年轻代第二个survivor的已使用容量
5. ec 年轻代eden区容量
6. eu 年轻代eden区已使用容量
7. oc 老年区容量
8. ou 老年区已使用容量
9. mc 元空区容量
10. mu 元空区已使用容量
11. ccsc 压缩类容量
12. ccsu 压缩类已使用空间
13. ygc 年轻代gc次数
14. ygct 年轻代gc总时间
15. fgc full gc次数
16. fgct full gc总时间
17. cgc 并发收集次数
18. cgct 并发收集总时间
19. gct gc总用时

jstat -class 17048：查看jvm加载类信息

1. Loaded 装载的类数量
2. Bytes 装载类占用的空间
3. Unloaded 卸载类的数量
4. Bytes 卸载类占用的空间
5. Time 装载和卸载类共花费的时间

jstat -compiler 17048：查看jvm编译信息

1. compiled 编译任务执行数量
2. failed 编译失败数量
3. invaild 编译失效数量
4. time 编译花费时间
5. failedtype 最后一个编译失败类型
6. failedmethod 最后一个编译失败所在类及方法

jstat -gc 17048：显示各个区的gc次数

当前jvm设置，没有配置survivor区数量，采用默认配置2个

1. soc 年轻代第一个survivor的容量
2. s1c 年轻代第二个survivor的容量
3. sou 年轻代第一个survivor的已使用容量
4. s1u 年轻代第二个survivor的已使用容量
5. ec 年轻代eden区容量
6. eu 年轻代eden区已使用容量
7. oc 老年区容量
8. ou 老年区已使用容量
9. mc 元空区容量
10. mu 元空区已使用容量
11. ccsc 压缩类容量
12. ccsu 压缩类已使用空间
13. ygc 年轻代gc次数
14. ygct 年轻代gc总时间
15. fgc full gc次数
16. fgct full gc总时间
17. cgc 并发收集次数
18. cgct 并发收集总时间
19. gct gc总用时

jstat -gccapacity 17048:显示jvm三区的对象使用和占用大小

1. ngcmn 年轻代最小空间
2. ngcmx 年轻代最大空间
3. ngc 年轻代当前容量
4. soc survivor1区的容量
5. s1c survivor2区的容量
6. ec eden区的容量
7. ogcmn 年老区最小空间
8. ogcmx 年老区最大空间
9. ogc 当前年老区容量
10. oc 当前年老区容量
11. mcmn 元空区最小空间
12. mcmx 元空区最大空间
13. mc 当前元空区空间大小
14. ccsmn 压缩区最小空间
15. ccsmx 压缩区最大空间
16. ccsc 当前压缩区的大小
17. ygc 年轻区gc次数
18. fgc 年老区/full gc 次数
19. cgc 压缩区gc次数

jstat -gcutil 17048 统计gc信息

1.  so survivor0区使用比例
2. s1 survivor1区使用比例
3. e eden区使用比例
4. o old区使用比例
5. m 元空区使用比例
6. ccs 压缩区使用比例
7. ygc 年轻区gc次数
8. fgc full gc次数
9. fgct full gc时间
10. cgc 压缩gc次数
11. cgct 压缩gc时 间
12. gct gc总时间

jstat -gcnew 17048:年轻代对象信息

1.  soc survivor0区空间
2. s1c survivor1区空间
3. sou survivor0区已使用空间
4. s1u survivor1区已使用空间
5. tt 对象在年轻区存活次数限制
6. mtt 对象在年轻区存活次数最大限制
7. dss 期望的survivor大小
8. ec eden区大小
9. eu eden区已使用大小
10. ygc 年轻区gc次数
11. ygct 年轻区gc时间

jstat -gcnewcapacity 17048:年轻代对象的信息和占用了

1. ngcmn 年轻代最小空间
2. ngcmx 年轻代最大空间
3. ngc 当前年轻代容量
4. soc 当前survivor1区的容量
5. socmx survivor1区的最大容量
6. s1c 当前survivor2区的容量
7. s1cmx survivor2区的最大容量
8. ec eden区的容量
9. ygc 年轻区gc次数
10. fgc 年老区/full gc 次数
11. cgc 压缩区gc次数

jstat -gcold 17048:年老区对象信息

1. mc 当前元空区空间
2. mu 元空区已使用空间
3. oc 当前老年区容量
4. ou 老年区已使用容量
5. ygc 年轻区gc次数
6. fgc 年老区/full gc 次数
7. cgc 压缩区gc次数

jstat -gcoldcapacity 17048:年老区对象信息及占用空间 

1. ogcmn 年老区最小空间
2. ogcmx 年老区最大空间
3. ogc 年老区新生成的容量
4. oc 年老区容量
5. ygc 年轻区gc次数
6. fgc 年老区/full gc 次数
7. cgc 压缩区gc次数
8. cgct 压缩区时间
9. gct gc总时间

jstat -printcompilation 17048

compiled 编译任务数目

size 方法生成的字节码大小

type 编译类型

method 类名和方法名用来标识编译的方法。类名使用/做为一个命名空间分隔符。方法名是给定类中的方法。上述格式是由-XX:+PrintComplation选项进行设置的

Jconsole

一个可视化监控jvm工具，地址在jdk的bin目录下

 

附其他自查篇章

技术自查（JAVA方向）