JDK中自带的JVM分析工具

简介: 解决常规的JVM异常时,通常依赖JDK中基础工具即可完成问题的定位,从而进行分析和解决,不过这些需要对基础工具熟练使用才行,而很多JDK自身的能力又是经常被忽略的;
内存溢出,妥妥的名场面;

一、业务背景

对于分布式架构中的文件服务来说,由于涉及大量的IO流操作,很容易引发JVM的相关异常,尤其是内存溢出的问题;

1.png

在最近的一次版本迭代中,真实的业务处理场景和上述几乎一致,由于在文件服务中添加批量处理的动作,直接唤醒了隐藏许久的BUG,就是最常见的内存溢出;

问题的起因:在word文档完成内容识别后,转换为pdf文件,然后进行页面分割转为一组图片,在这个复杂并且超长的流程中存在一个数组容器未销毁;

解决的方式:分析JVM的dump文件,定位OOM问题引发的根本原因,结合文件服务的异常日志分析,添加资源的释放动作,从而解决问题;

二、Jdk-Bin目录

对于相当一部分新手来说,看到JVM的问题都是Bug不知所起一脸懵的,其实这种心态大可不必,从职场几年的开发经验上看,JVM的问题大致分为两种:

  • 开发轻松解决:可以升级内存资源或者调整分配,又或者对程序优化,完成相关资源的管理和释放,这是最常用的手段;
  • 轻松解决开发:由于经验不足,程序出现重大BUG导致JVM异常,进而引起系列的连锁反应,这种不会绝地反弹,只有一地鸡毛;

在解决常规的JVM异常时,通常依赖JDK中基础工具即可完成问题的定位,从而进行分析和解决,不过这些需要对基础工具熟练使用才行,而很多JDK自身的能力又是经常被忽略的;

在jdk的bin目录中,有很多自带工具可以用于对JVM的分析;

2.png

上述是基于jdk1.8的目录,里面有很多开发经常用到命令,下面围绕一个微服务的启动和运行,来看看基于JDK中自带JVM工具的用法;

三、命令行工具

1、jps命令

jps:虚拟机进程状态工具,该命令在Java环境部署和服务启动查看时经常用到,首先在本地启动一个facade门面微服务,然后在命令行中执行查询;

  • jps:命令默认输出的是进程ID和应用主类的名称;
  • -l:输出进程ID和应用主类的完整路径;
  • -v:输出向jvm传递的参数,此处展示为idea中显式配置的VM-options参数,其他内容自行查看即可;
  • -m:输出向main方法传递的参数,服务启动前可以在idea的Program-arguments配置;
$ jps
1281 FacadeApp

$ jps -l
1281 com.explore.facade.FacadeApp

$ jps -v
1281 FacadeApp -Xms128m -Xmx256m -XX:MaxNewSize=256m -XX:MaxPermSize=256m

$ jps -m
1281 FacadeApp hello,main-method

2、jinfo命令

jinfo:在命令后面带pid进程号,可以输出指定进程的配置信息,在应用启动时通常不会指定过多的配置参数,就可以使用该命令查询很多参数的默认值;该命令还可以在运行时动态调整部分参数,只是很少被使用;

$ jinfo 1281            # 只粘贴个别参数
Java System Properties: # 系统参数
    java.runtime.version=1.8.0_144-b01
    file.encoding=UTF-8
    sun.java.command=com.explore.facade.FacadeApp hello,main-method
    
VM Flags:               # 虚拟机参数
    -XX:InitialHeapSize=134217728 -XX:MaxHeapSize=268435456 -XX:MaxNewSize=267911168
    
VM Arguments:           # 运行时参数
    jvm_args: -Xms128m -Xmx256m -XX:MaxNewSize=256m -XX:MaxPermSize=256m
    java_command: com.explore.facade.FacadeApp hello,main-method

$ jinfo -sysprops 1281  # 只输出【Java System Properties】参数

$ jinfo -flags 1281     # 只输出【VM Flags】参数

3、jstat命令

jstat:以指定的频率输出JVM的监控指标,下述命令输出内存占用和GC相关信息,每隔3秒输出一次,连续打印5次;由于这里只是启动一个简单的微服务,没有执行业务逻辑,所以各项指标比较平稳;

$ jstat -gcutil 1281 3000 5
S0     S1     E      O      M     CCS    YGC     YGCT    FGC    FGCT    CGC    CGCT     GCT   
0.00   0.00  57.97  64.16  92.82  88.75    3    0.028     9    0.516     -        -    0.544
0.00   0.00  57.97  64.16  92.82  88.75    3    0.028     9    0.516     -        -    0.544

该命令是比较常用的,这里各项指标的统计逻辑,在tools.jar包中有jstat_options参考文档,相对路径sun/tools/jstat/resources/目录下;

option gcutil {
  column {
    header "^S0^"    /* Survivor 0 Space - Percent Used */
    data (1-((sun.gc.generation.0.space.1.capacity - sun.gc.generation.0.space.1.used)/sun.gc.generation.0.space.1.capacity)) * 100
  }
  column {
    header "^S1^"    /* Survivor 1 Space - Percent Used */
    data (1-((sun.gc.generation.0.space.2.capacity - sun.gc.generation.0.space.2.used)/sun.gc.generation.0.space.2.capacity)) * 100
  }
  ......
}

4、jstack命令

jstack:输出指定进程当前时刻在JVM中的线程信息,为了清楚的展示其效果,在服务启动时创建线程死锁,然后通过该命令就会把发生死锁的线程打印出来,通过输出可以发现两条互相等待的线程信息;

$ jstack 1281
Found one Java-level deadlock:
=============================
"test-thread-02":
  waiting for ownable synchronizer 0x00000007b00a35d0, (a java.util.concurrent.locks.ReentrantLock$NonfairSync),
  which is held by "test-thread-01"
"test-thread-01":
  waiting for ownable synchronizer 0x00000007b00a35a0, (a java.util.concurrent.locks.ReentrantLock$NonfairSync),
  which is held by "test-thread-02"

Java stack information for the threads listed above:
===================================================
"test-thread-02":
    at sun.misc.Unsafe.park(Native Method)
    - parking to wait for  <0x00000007b00a35d0> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)

"test-thread-01":
    at sun.misc.Unsafe.park(Native Method)
    - parking to wait for  <0x00000007b00a35a0> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)

Found 1 deadlock.

5、jmap命令

jmap:可以输出指定进程的内存中对象映射信息,或者堆的关键信息、内存的使用统计、GC算法、配置、类的实例信息及内存占用等,该命令在解决JVM问题时也经常使用;

$ jmap 1281

$ jmap -heap 1281
Heap Configuration:
   MinHeapFreeRatio         = 0
   MaxHeapFreeRatio         = 100
   MaxHeapSize              = 536870912 (512.0MB)
   
Heap Usage:
    PS Young Generation
    Eden Space:
    From Space:
    To Space:
    PS Old Generation

$ jmap -histo:live 1281
 num     #instances         #bytes  class name
----------------------------------------------
1311:             1             32  com.explore.facade.FacadeApp$$EnhancerBySpringCGLIB$$313d9e3

四、可视化工具

1、jconsole

Java内置的JVM性能监控工具,在熟悉上述的命令行工具之后,对于该可视化工具的使用不会太陌生,在命令中可以查看到的默认参数或者应用自定义配置,在该工具中也可以找到,并且以图形化的方式呈现;

$ jconsole  # 通过该命令会唤起jconsole界面

3.png

这里选择线程一栏,可以直观的看到线程数量的变化曲线,也可以在下方查看某个线程的具体信息,并且可以通过检测死锁功能,发现在服务中创建的test-thread-01和test-thread-02两条线程;

4.png

2、visualvm

VisualVM作为解决JVM问题的常用工具,集成的功能丰富且强大,此处通过Idea插件的方式启动FacadeApp微服务,在进程主页可以看到自定义的配置,线程一栏因为检测到死锁直接给到异常提示;

5.png

在监视一栏可以通过【堆dump】查看详细的信息,可以查看类的实例数和大小,并且完成了结果排序和占用统计;此处信息在定位和解决JVM问题时非常重要;

6.png

对于JVM的监控工具来说,其能力与常用的命令行语法差异很小,并且这些命令在jdk中tools.jar包也可以找到其对应的类,对于一些更高级的监控平台来说,例如Kuboard、Skywalking等,也对这些底层能力做了集成,其原理应该也是大同小异。

五、参考源码

编程文档:
https://gitee.com/cicadasmile/butte-java-note

应用仓库:
https://gitee.com/cicadasmile/butte-flyer-parent
相关文章
|
20天前
|
存储 算法 Java
jvm性能优化(一)-基于JDK1.8
jvm性能优化(一)-基于JDK1.8
|
5天前
|
JavaScript 前端开发 Java
jvm的jshell,学生的工具
本文介绍了JVM的jshell工具,它为Java平台添加了REPL(读取-评估-打印循环)功能,使得学习、探索编码和原型代码变得更加便捷,但作者认为其在实际开发中较为鸡肋。
18 1
jvm的jshell,学生的工具
|
4天前
|
存储 Java PHP
【JVM】垃圾回收机制(GC)之引用计数和可达性分析
【JVM】垃圾回收机制(GC)之引用计数和可达性分析
16 0
|
1月前
|
监控 IDE Java
【Java性能调优新工具】JDK 22性能分析器:深度剖析,优化无死角!
【9月更文挑战第9天】JDK 22中的性能分析器为Java应用的性能调优提供了强大的支持。通过深度集成、全面监控、精细化分析和灵活报告生成等核心优势,性能分析器帮助开发者实现了对应用性能的全面掌控和深度优化。在未来的Java开发过程中,我们期待性能分析器能够继续发挥重要作用,为Java应用的性能提升贡献更多力量。
|
2月前
|
存储 安全 Java
JVM常见面试题(二):JVM是什么、由哪些部分组成、运行流程,JDK、JRE、JVM关系;程序计数器,堆,虚拟机栈,堆栈的区别是什么,方法区,直接内存
JVM常见面试题(二):JVM是什么、由哪些部分组成、运行流程是什么,JDK、JRE、JVM的联系与区别;什么是程序计数器,堆,虚拟机栈,栈内存溢出,堆栈的区别是什么,方法区,直接内存
JVM常见面试题(二):JVM是什么、由哪些部分组成、运行流程,JDK、JRE、JVM关系;程序计数器,堆,虚拟机栈,堆栈的区别是什么,方法区,直接内存
|
2月前
|
缓存 监控 算法
吃透 JVM 诊断方法与工具使用
【8月更文挑战第4天】深入了解并掌握JVM诊断需把握几大要点:1) 熟悉JVM内存模型,如堆、栈及方法区;2) 掌握垃圾回收机制与算法;3) 运用工具如`jps`(查看Java进程)、`jstat`(监控运行状态)、`jmap`(生成堆快照)、`jhat`(分析堆快照)、`jstack`(检查线程栈); 4) 利用专业工具如Eclipse Memory Analyzer分析堆转储文件查找内存泄漏; 5) 动态监控与调整JVM参数; 6) 结合日志分析性能瓶颈。通过实战案例加深理解,有效应对JVM性能问题。
|
2月前
|
Java 编译器 测试技术
Java零基础教学(03):如何正确区别JDK、JRE和JVM??
【8月更文挑战第3天】Java零基础教学篇,手把手实践教学!
49 2
|
2月前
|
人工智能 Java 编译器
Java零基础(3) - 区别JDK、JRE和JVM
【8月更文挑战第3天】🏆本文收录于「滚雪球学Java」专栏,专业攻坚指数级提升,希望能够助你一臂之力,帮你早日登顶实现财富自由🚀;同时,欢迎大家关注&&收藏&&订阅!持续更新中,up!up!up!!
58 1
|
2月前
|
缓存 Java 编译器
JRE、JDK、JVM 和 JIT 之间的区别详解
【8月更文挑战第22天】
48 0
|
2月前
|
监控 JavaScript Java
JVM源码级别分析G1发生FullGC元凶的是什么
线上系统遭遇频繁Old GC问题,监控显示出现多次“to-space exhausted”日志,这表明垃圾回收过程中因年轻代 Survivor 区或老年代空间不足导致对象晋升失败。通过 JVM 源码分析,此问题源于对象转移至老年代失败时,JVM 无法找到足够的空间存放存活对象。进一步排查发现大对象分配占用了预留空间,加剧了空间不足的情况。使用 JFR 分析工具定位到定期报表序列化导致大量大对象生成,通过改用堆外内存进行序列化输出,最终解决了频繁 Old GC 问题。