Java性能分析神器-JProfiler详解（一）（转）

时间  2019-11-07
标签 java 性能 分析 神器 jprofiler 详解 栏目 Java 繁體版
原文   原文链接

前段时间在给公司项目作性能分析，从简单的分析Log（GC log, postgrep log, hibernate statitistic），到经过AOP搜集软件运行数据，再到PET测试，感受时间花了很多，性能也有必定的提高，但总感受像是工做在原始时代，没法简单顺畅，又无比清晰的得到想要的结果。遂花费了必定的时间，重新梳理学习了一下以前用过的关于jvm调优和内存分析的各类工具，包括JDK自带的jps, jstack, jmap, jconsole，以及IBM的HeapAnalyzer等，这些工具虽然提供了很多功能，但其可用度，便捷度，远没达到IntelliJ之于Java开发那种地步。在偶然状况下，在云栖社区上发现有人推荐Jprofiler，装上使用版一用，发现果真是神器，特此推荐给你们。先声明，这个软件是商用的，网上有不少关于lisence的帖子，我这里转发，可是毫不推荐你们用破解版！html

L-Larry_Lau@163.com#36573-fdkscp15axjj6#25257
L-Larry_Lau@163.com#5481-ucjn4a16rvd98#6038
L-Larry_Lau@163.com#99016-hli5ay1ylizjj#27215
L-Larry_Lau@163.com#40775-3wle0g1uin5c1#0674
L-Larry_Lau@163.com#7009-14frku31ynzpfr#20176
L-Larry_Lau@163.com#49604-1jfe58we9gyb6#5814
L-Larry_Lau@163.com#25531-1qcev4yintqkj#23927
L-Larry_Lau@163.com#96496-1qsu1lb1jz7g8w#23479
L-Larry_Lau@163.com#20948-11amlvg181cw0p#171159java

 

而后，先转一篇云栖上的文章，而后再慢慢开始咱们的Jprofiler之旅。linux

 

一.JProfiler是什么

 

JProfiler是由ej-technologies GmbH公司开发的一款性能瓶颈分析工具(该公司还开发部署工具)。
其特色:网络

  • 使用方便
  • 界面操做友好
  • 对被分析的应用影响小
  • CPU,Thread,Memory分析功能尤为强大
  • 支持对jdbc,noSql, jsp, servlet, socket等进行分析
  • 支持多种模式(离线，在线)的分析
  • 跨平台 _2014_10_06_7_54_34_PM (图1)

二.数据采集

Q1. JProfiler既然是一款性能瓶颈分析工具，这些分析的相关数据来自于哪里？
Q2. JProfiler是怎么将这些数据收集并展示的?oracle

_2014_10_06_3_09_15_PM
(图2)jvm

A1. 分析的数据主要来自于下面俩部分
1. 一部分来自于jvm的分析接口**JVMTI**(JVM Tool Interface) , JDK必须>=1.6socket

JVMTI is an event-based system. The profiling agent library can register handler functions for different events. It can then enable or disable selected eventsjsp

例如: 对象的生命周期，thread的生命周期等信息
2. 一部分来自于instruments classes(可理解为class的重写,增长JProfiler相关统计功能)
例如：方法执行时间，次数，方法栈等信息ide

A2. 数据收集的原理如图2
1. 用户在JProfiler GUI中下达监控的指令(通常就是点击某个按钮)
2. JProfiler GUI JVM 经过socket(默认端口8849)，发送指令给被分析的jvm中的JProfile Agent。
3. JProfiler Agent(若是不清楚Agent请看文章第三部分"启动模式") 收到指令后，将该指令转换成相关须要监听的事件或者指令,来注册到JVMTI上或者直接让JVMTI去执行某功能(例如dump jvm内存)
4. JVMTI 根据注册的事件，来收集当前jvm的相关信息。 例如: 线程的生命周期; jvm的生命周期;classes的生命周期;对象实例的生命周期;堆内存的实时信息等等
5. JProfiler Agent将采集好的信息保存到**内存**中，按照必定规则统计好(若是发送全部数据JProfiler GUI，会对被分析的应用网络产生比较大的影响)
6. 返回给JProfiler GUI Socket.
7. JProfiler GUI Socket 将收到的信息返回 JProfiler GUI Render
8. JProfiler GUI Render 渲染成最终的展现效果工具

三. 数据采集方式和启动模式

A1. JProfier采集方式分为两种：Sampling(样本采集)和Instrumentation

  • Sampling: 相似于样本统计, 每隔必定时间(5ms)将每一个线程栈中方法栈中的信息统计出来。优势是对应用影响小(即便你不配置任何Filter, Filter可参考文章第四部分)，缺点是一些数据/特性不能提供(例如:方法的调用次数)

  • Instrumentation: 在class加载以前，JProfier把相关功能代码写入到须要分析的class中，对正在运行的jvm有必定影响。优势: 功能强大，但若是须要分析的class多，那么对应用影响较大，通常配合Filter一块儿使用。因此通常JRE class和framework的class是在Filter中一般会过滤掉。

注: JProfiler自己没有指出数据的采集类型，这里的采集类型是针对方法调用的采集类型 。由于JProfiler的绝大多数核心功能都依赖方法调用采集的数据, 因此能够直接认为是JProfiler的数据采集类型。

A2: 启动模式:

  • Attach mode
    可直接将本机正在运行的jvm加载JProfiler Agent. 优势是很方便，缺点是一些特性不能支持。若是选择Instrumentation数据采集方式，那么须要花一些额外时间来重写须要分析的class。

  • Profile at startup
    在被分析的jvm启动时，将指定的JProfiler Agent手动加载到该jvm。JProfiler GUI 将收集信息类型和策略等配置信息经过socket发送给JProfiler Agent，收到这些信息后该jvm才会启动。
    在被分析的jvm 的启动参数增长下面内容：
    语法: -agentpath:[path to jprofilerti library]
    【注】: 语法不清楚不要紧，JProfiler提供了帮助向导.
    _2014_10_06_4_15_42_PM
    (图3)

  • Prepare for profiling:
    和Profile at startup的主要区别：被分析的jvm不须要收到JProfiler GUI 的相关配置信息就能够启动。

  • Offline profiling
    通常用于适用于不能直接调试线上的场景。Offline profiling须要将信息采集内容和策略(一些Trigger, Trigger请参考文章第五部分)打包成一个配置文件(config.xml)，在线上启动该jvm 加载 JProfiler Agent时，加载该xml。那么JProfiler Agent会根据Trigger的类型会生成不一样的信息。例如: heap dump; thread dump; method call record等
    语法:
    -agentpath:/home/2080/jprofiler8/bin/Linux-x64/libjprofilerti.so=offline,id=151,config=/home/2080/config.xml
    【注】: config.xml中的每个被分析的jvm的采集信息都有一个id来标识。
    下面是使用了离线模式，并使用了每隔一秒dump heap 的Trigger：
    _2014_10_06_9_07_56_PM

四. JProfiler核心概念

  1. Filter: 什么class须要被分析。分为包含和不包含两种类型的Filter。
    _2014_10_06_4_32_15_PM
    (图4)

  2. Profiling Settings: 收据收集的策略:Sampling和 Instrumentation，一些数据采集细节能够自定义.
    _2014_10_06_4_34_28_PM
    (图5)

  3. Triggers: 通常用于**offline**模式，告知JProfiler Agent 何时触发什么行为来收集指定信息.
    _2014_10_06_4_37_47_PM
    (图6)

  4. Live memory: class/class instance的相关信息。 例如对象的个数，大小，对象建立的方法执行栈，对象建立的热点。
    _2014_10_06_4_56_09_PM
    (图7)

  5. Heap walker: 对必定时间内收集的内存对像信息进行静态分析，功能强大且使用。包含对象的outgoing reference, incoming reference, biggest object等
    _2014_10_06_4_55_39_PM
    (图8)

  6. CPU views: CPU消耗的分布及时间(cpu时间或者运行时间); 方法的执行图; 方法的执行统计(最大，最小，平均运行时间等)
    _2014_10_06_4_54_48_PM
    (图9)

  7. Thread: 当前jvm全部线程的运行状态，线程持有锁的状态，可dump线程。
    _2014_10_06_4_54_07_PM
    (图10)

  8. Monitors & locks: 全部线程持有锁的状况以及锁的信息
    _2014_10_06_4_59_15_PM
    (图11)

  9. Telemetries: 包含heap, thread, gc, class等的趋势图(遥测视图)

五. 实践

为了方便实践，直接以JProfiler8自带的一个例子来帮助理解上面的相关概念。
JProfiler 自带的例子以下：模拟了内存泄露和线程阻塞的场景：
具体源码参考: /jprofiler install path/demo/bezier

_2014_10_06_5_06_49_PM
(图12 )

_2014_10_06_5_09_43_PM
(图13 Leak Memory 模拟内存泄露, Simulate blocking 模拟线程间锁的阻塞)

A1. 首先来分析下内存泄露的场景:(勾选图13中 Leak Memory 模拟内存泄露)
1. 在**Telemetries-> Memory**视图中你会看到大体以下图的场景(在看的过程当中能够间隔一段时间去执行Run GC这个功能)：看到下图蓝色区域,老生代在gc后(**波谷**)内存的大小在慢慢的增长(理想状况下，这个值应该是稳定的)
_2014_10_06_5_18_56_PM
(图14)

  1. 在 Live memory->Recorded Objects 中点击**record allocation data**按钮，开始统计一段时间内建立的对象信息。执行一次**Run GC**后看看当前对象信息的大小，并点击工具栏中**Mark Current**按钮(其实就是给当前对象数量打个标记。执行一次Run GC，而后再继续观察;执行一次Run GC，而后再继续观察...。最后看看哪些对象在不断GC后，数量还一直上涨的。最后你看到的信息可能和下图相似
    _2014_10_06_5_26_41_PM
    (图15 绿色是标记前的数量，红色是标记后的增量)

  2. 在Heap walker中分析刚才记录的对象信息
    _2014_10_06_5_28_00_PM
    (图16)
    _2014_10_06_5_29_11_PM
    (图17)

  3. 点击上图中实例最多的class，右键**Use Selected Instances->Reference->Incoming Reference**.
    发现该Long数据最终是存放在**bezier.BeaierAnim.leakMap**中。
    _2014_10_06_5_31_54_PM
    (图18)

在Allocations tab项中，右键点击其中的某个方法，可查看到具体的源码信息.
_2014_10_06_5_36_08_PM
(图19)

【注】:到这里问题已经很是清楚了，明白了在图17中为何哪些实例的数量是同样多，而且为何内存在fullgc后仍是回收不了(一个old 区的对象leakMap，put的信息也会进入old区, leakMap如回收不掉，那么该map中包含的对象也回收不掉)。

A2. 模拟线程阻塞的场景(勾选图13中Simulate blocking 模拟线程间锁的阻塞)
为了方便区分线程，我将Demo中的BezierAnim.java的L236的线程命名为test

public void start() { thread = new Thread(this, "test"); thread.setPriority(Thread.MIN_PRIORITY); thread.start(); }

正常状况下，以下图
_2014_10_06_5_50_25_PM
(图20)

勾选了Demo中"Simulate blocking"选项后，以下图(注意看下下图中的状态图标), test线程block状态明显增长了。
_2014_10_06_5_53_19_PM
(图21)

在**Monitors & locks->Monitor History**观察了一段时间后，会发现有4种发生锁的状况。

第一种:
AWT-EventQueue-0 线程持有一个Object的锁，而且处于Waiting状态。

图下方的代码提示出Demo.block方法调用了object.wait方法。这个仍是比较容易理解的。 
_2014_10_06_6_15_59_PM
(图22)

第二种:
AWT-EventQueue-0占有了bezier.BezierAnim$Demo实例上的锁，而test线程等待该线程释放。

注意下图中下方的源代码, 这种锁的出现缘由是Demo的blcok方法在AWT和test线程
都会被执行，而且该方法是synchronized.
_2014_10_06_6_11_20_PM
(图23)

第三种和第四种:
test线程中会不断向事件Event Dispatching Thread提交任务，致使竞争java.awt.EventQueue对象锁。
提交任务的方式是下面的代码:repaint()和EventQueue.invokeLater

public void run() { Thread me = Thread.currentThread(); while (thread == me) { repaint(); if (block) { block(false); } try { Thread.sleep(10); } catch (Exception e) { break; } EventQueue.invokeLater(new Runnable() { @Override public void run() { onEDTMethod(); } }); } thread = null; }

_2014_10_06_6_20_05_PM
(图24)

六. 最佳实践

  1. JProfiler都会对一些特殊操做给予提示，这时候最好仔细阅读下说明.
  2. "Mark Current"功能在某些场景颇有效
  3. Heap walker通常是静态分析在Live memory->Recorder objects的对象信息，这些信息可能会被GC回收掉，致使Heap walker中什么也没有显示出来。这种现象是正常的。
  4. 能够才工具栏中Start Recordings配置一次性收集的信息
  5. Filter中include和exclude是有顺序的，注意使用下图**左下方**的**“Show Filter Tree”**来验证一下顺序 _2014_10_17_3_41_18_PM (图25)

七. 参考文献

    1. JProfiler helper: http://resources.ej-technologies.com/jprofiler/help/doc/index.html

    2. JVMTI: http://docs.oracle.com/javase/7/docs/platform/jvmti/jvmti.html

相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程