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

2023-10-30 02:10

本文主要是介绍技术自查番外篇三:其他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方向)

这篇关于技术自查番外篇三:其他JVM监控工具的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!


原文地址:https://blog.csdn.net/banbeisudashui/article/details/119994093
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.chinasem.cn/article/304916

相关文章

Python办公自动化实战之打造智能邮件发送工具

《Python办公自动化实战之打造智能邮件发送工具》在数字化办公场景中,邮件自动化是提升工作效率的关键技能,本文将演示如何使用Python的smtplib和email库构建一个支持图文混排,多附件,多... 目录前言一、基础配置:搭建邮件发送框架1.1 邮箱服务准备1.2 核心库导入1.3 基础发送函数二、

java使用protobuf-maven-plugin的插件编译proto文件详解

《java使用protobuf-maven-plugin的插件编译proto文件详解》:本文主要介绍java使用protobuf-maven-plugin的插件编译proto文件,具有很好的参考价... 目录protobuf文件作为数据传输和存储的协议主要介绍在Java使用maven编译proto文件的插件

Java中的数组与集合基本用法详解

《Java中的数组与集合基本用法详解》本文介绍了Java数组和集合框架的基础知识,数组部分涵盖了一维、二维及多维数组的声明、初始化、访问与遍历方法,以及Arrays类的常用操作,对Java数组与集合相... 目录一、Java数组基础1.1 数组结构概述1.2 一维数组1.2.1 声明与初始化1.2.2 访问

Javaee多线程之进程和线程之间的区别和联系(最新整理)

《Javaee多线程之进程和线程之间的区别和联系(最新整理)》进程是资源分配单位,线程是调度执行单位,共享资源更高效,创建线程五种方式:继承Thread、Runnable接口、匿名类、lambda,r... 目录进程和线程进程线程进程和线程的区别创建线程的五种写法继承Thread,重写run实现Runnab

Java 方法重载Overload常见误区及注意事项

《Java方法重载Overload常见误区及注意事项》Java方法重载允许同一类中同名方法通过参数类型、数量、顺序差异实现功能扩展,提升代码灵活性,核心条件为参数列表不同,不涉及返回类型、访问修饰符... 目录Java 方法重载(Overload)详解一、方法重载的核心条件二、构成方法重载的具体情况三、不构

如何在Ubuntu 24.04上部署Zabbix 7.0对服务器进行监控

《如何在Ubuntu24.04上部署Zabbix7.0对服务器进行监控》在Ubuntu24.04上部署Zabbix7.0监控阿里云ECS服务器,需配置MariaDB数据库、开放10050/1005... 目录软硬件信息部署步骤步骤 1:安装并配置mariadb步骤 2:安装Zabbix 7.0 Server

Java通过驱动包(jar包)连接MySQL数据库的步骤总结及验证方式

《Java通过驱动包(jar包)连接MySQL数据库的步骤总结及验证方式》本文详细介绍如何使用Java通过JDBC连接MySQL数据库,包括下载驱动、配置Eclipse环境、检测数据库连接等关键步骤,... 目录一、下载驱动包二、放jar包三、检测数据库连接JavaJava 如何使用 JDBC 连接 mys

SpringBoot线程池配置使用示例详解

《SpringBoot线程池配置使用示例详解》SpringBoot集成@Async注解,支持线程池参数配置(核心数、队列容量、拒绝策略等)及生命周期管理,结合监控与任务装饰器,提升异步处理效率与系统... 目录一、核心特性二、添加依赖三、参数详解四、配置线程池五、应用实践代码说明拒绝策略(Rejected

基于Python实现一个图片拆分工具

《基于Python实现一个图片拆分工具》这篇文章主要为大家详细介绍了如何基于Python实现一个图片拆分工具,可以根据需要的行数和列数进行拆分,感兴趣的小伙伴可以跟随小编一起学习一下... 简单介绍先自己选择输入的图片,默认是输出到项目文件夹中,可以自己选择其他的文件夹,选择需要拆分的行数和列数,可以通过

一文详解SpringBoot中控制器的动态注册与卸载

《一文详解SpringBoot中控制器的动态注册与卸载》在项目开发中,通过动态注册和卸载控制器功能,可以根据业务场景和项目需要实现功能的动态增加、删除,提高系统的灵活性和可扩展性,下面我们就来看看Sp... 目录项目结构1. 创建 Spring Boot 启动类2. 创建一个测试控制器3. 创建动态控制器注