除了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
- jps 输出所有java进程名和进程id
- jps -q 只输出所有java进程id
- jps -m 输出传入main方法的参数
- jps -l 输出完全的包名，应用主类名和jar的完全路径名
- jps -v 输出jvm参数
- 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无法监控等问题
原因：
- 磁盘读写、目录权限问题 若该用户没有权限写/tmp目录或是磁盘已满，则无法创建/tmp/hsperfdata_userName/pid文件。或该文件已经生成，但用户没有读权限
- 临时文件丢失，被删除或是定期清理 对于linux机器，一般都会存在定时任务对临时文件夹进行清理，导致/tmp目录被清空。这也是我第一次碰到该现象的原因。常用的可能定时删除临时目录的工具为crontab、redhat的tmpwatch、ubuntu的tmpreaper等等
- 这个导致的现象可能会是这样，用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: RUNNABLE
at 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: RUNNABLE
No 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: RUNNABLE
at 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: RUNNABLE
at 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: RUNNABLE
at 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主要名词解释
- os_prio:操作系统别的优先级，越小优先
- prio:线程优先度，越小优先
- cpu：占用cpu时间（占用时间长，说明消耗cpu资源大）
- tid：java内线程的id
- nid:tid的十六进制id（操作系统内的id）
- elapsed：线程花费时间
进程状态
- new:未启动，不会出现在日志内
- runnable:正在运行
- blocked：线程被阻塞
- waiting:线程正在等待
- time_wating
Jstat
作用：轻量级对堆内存和gc回收情况监控的工具
原理：同jps一样，监控临时文件（/tmp/hsperfdata_userName/pid）。
局限性：不能获取gc的详细过程信息。（不知道多少个gc线程工作，且占用时间，每次gc，回收了多少空间等等），这也是jstat使用较少原因，最好还是看gc日志
具体指令：
jstat -options 列出当前JVM版本支持的选项。
- jstat -class(类加载器)
- jstat -compiler(JIT)
- jstat -gc(GC堆状态)
- jstat -gccapacity(各区大小)
- jstat -gccause(最近一次gc统计和原因)
- jstat -gcmetacapacity(元空区大小)
- jstat -gcnew(新区统计)
- jstat -gcnewcapacity(新区大小)
- jstat -gcold(老区统计)
- jstat -gcoldcapacity(老区大小)
- jstat -gcutil(gc统计汇总)
- jstat -printcompilation(HotSpot编译统计)
- 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信息
- soc 年轻代第一个survivor的容量
- s1c 年轻代第二个survivor的容量
- sou 年轻代第一个survivor的已使用容量
- s1u 年轻代第二个survivor的已使用容量
- ec 年轻代eden区容量
- eu 年轻代eden区已使用容量
- oc 老年区容量
- ou 老年区已使用容量
- mc 元空区容量
- mu 元空区已使用容量
- ccsc 压缩类容量
- ccsu 压缩类已使用空间
- ygc 年轻代gc次数
- ygct 年轻代gc总时间
- fgc full gc次数
- fgct full gc总时间
- cgc 并发收集次数
- cgct 并发收集总时间
- gct gc总用时
jstat -class 17048：查看jvm加载类信息
- Loaded 装载的类数量
- Bytes 装载类占用的空间
- Unloaded 卸载类的数量
- Bytes 卸载类占用的空间
- Time 装载和卸载类共花费的时间
jstat -compiler 17048：查看jvm编译信息
- compiled 编译任务执行数量
- failed 编译失败数量
- invaild 编译失效数量
- time 编译花费时间
- failedtype 最后一个编译失败类型
- failedmethod 最后一个编译失败所在类及方法
jstat -gc 17048：显示各个区的gc次数
当前jvm设置，没有配置survivor区数量，采用默认配置2个
- soc 年轻代第一个survivor的容量
- s1c 年轻代第二个survivor的容量
- sou 年轻代第一个survivor的已使用容量
- s1u 年轻代第二个survivor的已使用容量
- ec 年轻代eden区容量
- eu 年轻代eden区已使用容量
- oc 老年区容量
- ou 老年区已使用容量
- mc 元空区容量
- mu 元空区已使用容量
- ccsc 压缩类容量
- ccsu 压缩类已使用空间
- ygc 年轻代gc次数
- ygct 年轻代gc总时间
- fgc full gc次数
- fgct full gc总时间
- cgc 并发收集次数
- cgct 并发收集总时间
- gct gc总用时
jstat -gccapacity 17048:显示jvm三区的对象使用和占用大小
- ngcmn 年轻代最小空间
- ngcmx 年轻代最大空间
- ngc 年轻代当前容量
- soc survivor1区的容量
- s1c survivor2区的容量
- ec eden区的容量
- ogcmn 年老区最小空间
- ogcmx 年老区最大空间
- ogc 当前年老区容量
- oc 当前年老区容量
- mcmn 元空区最小空间
- mcmx 元空区最大空间
- mc 当前元空区空间大小
- ccsmn 压缩区最小空间
- ccsmx 压缩区最大空间
- ccsc 当前压缩区的大小
- ygc 年轻区gc次数
- fgc 年老区/full gc 次数
- cgc 压缩区gc次数
jstat -gcutil 17048 统计gc信息
- so survivor0区使用比例
- s1 survivor1区使用比例
- e eden区使用比例
- o old区使用比例
- m 元空区使用比例
- ccs 压缩区使用比例
- ygc 年轻区gc次数
- fgc full gc次数
- fgct full gc时间
- cgc 压缩gc次数
- cgct 压缩gc时 间
- gct gc总时间
jstat -gcnew 17048:年轻代对象信息
- soc survivor0区空间
- s1c survivor1区空间
- sou survivor0区已使用空间
- s1u survivor1区已使用空间
- tt 对象在年轻区存活次数限制
- mtt 对象在年轻区存活次数最大限制
- dss 期望的survivor大小
- ec eden区大小
- eu eden区已使用大小
- ygc 年轻区gc次数
- ygct 年轻区gc时间
jstat -gcnewcapacity 17048:年轻代对象的信息和占用了
- ngcmn 年轻代最小空间
- ngcmx 年轻代最大空间
- ngc 当前年轻代容量
- soc 当前survivor1区的容量
- socmx survivor1区的最大容量
- s1c 当前survivor2区的容量
- s1cmx survivor2区的最大容量
- ec eden区的容量
- ygc 年轻区gc次数
- fgc 年老区/full gc 次数
- cgc 压缩区gc次数
jstat -gcold 17048:年老区对象信息
- mc 当前元空区空间
- mu 元空区已使用空间
- oc 当前老年区容量
- ou 老年区已使用容量
- ygc 年轻区gc次数
- fgc 年老区/full gc 次数
- cgc 压缩区gc次数
jstat -gcoldcapacity 17048:年老区对象信息及占用空间 
- ogcmn 年老区最小空间
- ogcmx 年老区最大空间
- ogc 年老区新生成的容量
- oc 年老区容量
- ygc 年轻区gc次数
- fgc 年老区/full gc 次数
- cgc 压缩区gc次数
- cgct 压缩区时间
- gct gc总时间
jstat -printcompilation 17048
compiled 编译任务数目
size 方法生成的字节码大小
type 编译类型
method 类名和方法名用来标识编译的方法。类名使用/做为一个命名空间分隔符。方法名是给定类中的方法。上述格式是由-XX:+PrintComplation选项进行设置的
Jconsole
一个可视化监控jvm工具，地址在jdk的bin目录下
4198
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
