troubleshoot之:使用JFR分析性能问题
简介
java程序的性能问题分析是一个很困难的问题。尤其是对于一个非常复杂的程序来说,分析起来更是头疼。
还好JVM引入了JFR,可以通过JFR来监控和分析JVM的各种事件。通过这些事件的分析,我们可以找出潜在的问题。
今天我们就来介绍一下对java性能分析比较重要的一些JFR事件。
GC性能事件
一般来说,GC会对java程序的性能操作产生比较重要的影响。我们可以使用jfr监控jdk.GCPhasePause事件。
下面是一个jdk.GCPhasePause的例子:
jfr print --events jdk.GCPhasePause flight_recording_1401comflydeanTestMemoryLeak89268.jfr
输出结果:
jdk.GCPhasePause { startTime = 19:51:49.798 duration = 41.1 ms gcId = 2 name = "GC Pause" }
通过GCPhasePause事件,我们可以统计总的GC pause时间和平均每一次GC pause的时间。
一般来说GC是在后台执行的,所以GC本身的执行时间我们并不需要关注,因为这并不会影响到程序的性能。我们需要关注的是应用程序因为GC暂停的时间。
考虑下面两种情况,第一种单独的GC导致GC pause时间过长。第二种是总的GC pause时间过长。
如果是第一种情况,那么可能需要考虑换一个GC类型,因为不同的GC类型在pause时间和吞吐量的平衡直接会有不同的处理。同时我们需要减少finalizers的使用。
如果是第二种情况,我们可以从下面几个方面来解决。
- 增加heap空间大小。heap空间越大,GC的间隔时间就越长。总的GC pause时间就会越短。
- 尽量减少tmp对象的分配。我们知道为了提升多线程的性能,JVM会使用TLAB技术。一般来说小对象会分配在TLAB中,但如果是大对象,则会直接分配在heap空间中。但是大部分对象都是在TLAB中分配的。所以我们可以同时关注TLAB和TLAB之外的两个事件:jdk.ObjectAllocationInNewTLAB和dk.ObjectAllocationOutsideTLAB。
- 减少分配频率。我们可以通过jdk.ThreadAllocationStatistics来分析。
同步性能
在多线程环境中,因为多线程会竞争共享资源,所以对资源的同步,或者锁的使用都会影响程序的性能。
我们可以监控jdk.JavaMonitorWait事件。
jfr print --events jdk.JavaMonitorWait flight_recording_1401comflydeanTestMemoryLeak89268.jfr
我们看一个结果:
jdk.JavaMonitorWait { startTime = 19:51:25.395 duration = 2 m 0 s monitorClass = java.util.TaskQueue (classLoader = bootstrap) notifier = N/A timeout = 2 m 0 s timedOut = true address = 0x7FFBB7007F08 eventThread = "JFR Recording Scheduler" (javaThreadId = 17) stackTrace = [ java.lang.Object.wait(long) java.util.TimerThread.mainLoop() line: 553 java.util.TimerThread.run() line: 506 ] }
通过分析JavaMonitorWait事件,我们可以找到竞争最激烈的锁,从而进行更深层次的分析。
IO性能
如果应用程序有很多IO操作,那么IO操作也是会影响性能的关键一环。
我们可以监控两种IO类型:socket IO和File IO。
相对应的事件有:dk.SocketWrite,jdk.SocketRead,jdk.FileWrite,jdk.FileRead。
代码执行的性能
代码是通过CPU来运行的,如果CPU使用过高,也可能会影响到程序的性能。
我们可以通过监听jdk.CPULoad事件来对CPULoad进行分析。
jfr print --events jdk.CPULoad flight_recording_1401comflydeanTestMemoryLeak89268.jfr
看下运行结果:
jdk.CPULoad { startTime = 19:53:25.519 jvmUser = 0.63% jvmSystem = 0.37% machineTotal = 20.54% }
如果jvm使用的cpu比较少,但是整个machine的CPU使用率比较高,这说明了有其他的程序在占用CPU。
如果JVM自己的CPU使用就很高的话,那么就需要找到这个占用CPU的线程进行进一步分析。
其他有用的event
除了上面提到的event之外,还有一些其他有用的我们可以关注的event。
比如线程相关的:jdk.ThreadStart,jdk.ThreadEnd,jdk.ThreadSleep,jdk.ThreadPark。
如果你使用JMC,那么可以很直观的查看JFR的各种事件。
所以推荐大家使用JMC。
本文作者:flydean程序那些事
本文链接:http://www.flydean.com/jvm-diagnostic-perform-issue/
本文来源:flydean的博客
欢迎关注我的公众号:程序那些事,更多精彩等着您!

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
Scala语言入门三(集合)
一、数组 Scala 语言中提供的数组是用来存储固定大小的同类型元素,数组对于每一门编辑应语言来说都是重要的数据结构之一。数组的第一个元素索引为0,最后一个元素的索引为元素总数减1 1、声明数组 不可变数组 /** * @author Gjing **/ object ArrayApp { def main(args: Array[String]): Unit = { // 声明一个长度为2的不可变数组 val arr = new Array[String](2) // 赋值 arr(0) = "java" arr(1) = "scala" // 使用另外一种方式声明数组 val arr2 = Array("java","scala") } } 不可变数组 /** * @author Gjing **/ object ArrayApp { def main(args: Array[String]): Unit = { val buffer = ArrayBuffer[String]() // 追加一个值 buffer += "java" // 追加一个数组 buffer ++= Arr...
- 下一篇
troubleshoot之:GC调优到底是什么
简介 我们经常会听到甚至需要自己动手去做GC调优。那么GC调优的目的到底是什么呢?让程序跑得更快?让GC消耗更少的资源?还是让程序更加稳定? 带着这些疑问来读一下这篇文章,将会得到一个系统的甚至是不一样的结果。 那些GC的默认值 其实GC或者说JVM的参数非常非常的多,有控制内存使用的: 有控制JIT的: 有控制分代比例的,也有控制GC并发的: 当然,大部分的参数其实并不需要我们自行去调整,JVM会很好的动态帮我们设置这些变量的值。 如果我们不去设置这些值,那么对GC性能比较有影响的参数和他们的默认值有哪些呢? GC的选择 我们知道JVM中的GC有很多种,不同的GC选择对java程序的性能影响还是比较大的。 在JDK9之后,G1已经是默认的垃圾回收器了。 我们看一下G1的调优参数。 G1是基于分代技术的,其实JVM还在开发一些不再基于分代技术的GC算法,比如ZGC,我们可以根据需要来选择适合我们的GC算法。 GC的最大线程个数 GC是由专门的GC线程来执行的,并不是说GC线程越多越好,这个默认线程的最大值是由heap size和可用的CPU资源动态决定的。 当然你可以使用下面两个选项来...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- Eclipse初始化配置,告别卡顿、闪退、编译时间过长
- SpringBoot2整合Thymeleaf,官方推荐html解决方案
- Hadoop3单机部署,实现最简伪集群
- Springboot2将连接池hikari替换为druid,体验最强大的数据库连接池
- Docker安装Oracle12C,快速搭建Oracle学习环境
- CentOS8安装MyCat,轻松搞定数据库的读写分离、垂直分库、水平分库
- CentOS7设置SWAP分区,小内存服务器的救世主
- SpringBoot2整合Redis,开启缓存,提高访问速度
- CentOS8,CentOS7,CentOS6编译安装Redis5.0.7
- CentOS7,CentOS8安装Elasticsearch6.8.6