使用JProfiler进行Java应用性能分析

(JProfiler分析的对象是Java应用程序，而这些程序都运行在JVM之上，JProfiler通过与JVM交互，收集有关CPU使用、内存分配、线程状态等详细信息。JVM提供的这些数据是JProfiler分析性能瓶颈、内存泄漏、线程死锁等问题的基础。由于JVM执行的是Java字节码，JProfiler可以直接分析字节码级别的代码执行情况，从而精确定位到方法调用、代码路径等细节。)

内存：是计算机中用来临时存储运行程序和数据的地方，运行中的数据和程序需要载入内存，计算机才能对其进行处理。(某些对象由于逻辑问题没有被释放时，内存将逐渐耗尽，导致程序崩溃。JProfiler可以帮助检测内存泄漏，找出不再使用却没有释放的对象，也可以通过JProfiler监控内存使用的高峰时刻，帮助识别应用在负载高峰时的内存需求，确保程序在高压力环境下稳定运行。)

CPU：即"中央处理器"。它是计算机系统的核心处理单元，负责执行指令和处理数据，相当于计算机的大脑。(在JProfiler中的主要作用是分析Java应用程序对CPU资源的使用情况。JProfiler能显示各个方法的CPU使用情况，帮助开发者找到耗费CPU资源最多的代码部分，识别性能瓶颈。"热点"代码，即在CPU使用中最频繁被调用的方法或函数，可以协助开发者优化这些代码以提升整体性能。)

二、Windows系统中JProfiler的安装

1、下载exe文件

官方下载地址：ej-technologies - Download JProfiler，右上角可以选择要下载的版本，如下图所示：

**说明：**本教程使用11.0.2版本

2、安装JProfiler

下载后，双击运行，选择自定义目录安装，点击Next

选择安装路径，建议选择一个目录路径中没有中文、没有空格的目录，否则手动启动时，可能启动不了。然后一直点Next。

三、JProfiler的破解

可以参考：JProfiler11使用教程之JVM调优_jprofiler11使用图解-CSDN博客

四、IDEA中配置JProfiler

1、安装JProfiler插件

IDEA中，设置==>插件==>搜索JProfiler，点击安装按钮进行安装，然后重启IDEA

看到如下图标，则说明JProfiler插件安装完成

2、关联本地磁盘中JProfiler软件的执行文件

IDEA中，设置==>工具==>JProfiler==>JProfiler executable选择JProfiler安装目录下的可执行文件==>确定

到此，IDEA中配置JProfiler就完成了。

3、IDEA中启动JProfiler

IDEA中，打开一个现存的项目，比如一个Springboot项目，选择Springboot的启动类，点击JProfiler图标就可以运行该项目，执行性能分析。

启动完成，会自动弹出JProfiler窗口，在里面就可以监控自己代码的性能了。

五、监控本地主机中的Java应用

1、本地启动Java应用

在本地主机中，通过IDE或java -jar等方式启动一个Java应用（不论是使用Weblogic、Jboss、Tomcat、Undertow等应用服务器启动，还是使用Springboot直接启动，都可以）。

2、启动JProfiler软件

本地Java应用启动后，打开JProfiler软件，监控该Java应用

选择Sampling

JProfiler提供了两种主要的CPU性能分析方法：Instrumentation和Sampling。

Instrumentation（插桩）

工作原理：Instrumentation通过修改字节码来收集数据。在应用程序启动时，JProfiler会自动修改类文件中的方法，插入额外的代码以记录方法调用次数和执行时间。

优点：

提供精确的方法调用计数和执行时间。

适合分析具体方法级别的性能瓶颈。

能够提供详细的调用树，包括所有方法调用路径。

缺点：

因为需要修改字节码，可能会对程序的性能产生较大影响，特别是在大型应用中。

可能导致一些懒加载机制提前触发，从而改变程序的正常行为。

Sampling（抽样）

工作原理：Sampling则是通过定期检查当前线程的堆栈信息来收集数据。它不会修改字节码或程序运行流程，而是根据一定的时间间隔（如每10毫秒）捕获线程的执行状态。

优点：

对被分析的应用程序的影响较小，因为它不需要修改字节码。

更适合于长时间运行且负载较高的生产环境监控。

缺点：

数据不如Instrumentation精确，因为它是基于抽样的，可能错过某些快速执行的方法。

不支持所有功能，不提供直接的方法调用次数统计，只能估计方法的相对活跃度。

总结

如果你需要准确了解每个方法的执行时间和调用次数，尤其是在开发和测试环境中，Instrumentation是更好的选择。

如果你关心的是整体性能趋势，或者是在生产环境中进行轻量级监控，Sampling则更为合适。它提供的性能开销小，对应用的实际运行影响也较小。

六、监控远程Linux主机中的Java应用

1、下载tar.gz压缩包

官方下载地址：ej-technologies - Download JProfiler，右上角可以选择要下载的版本，然后页面下拉到Linux下载部分，点击 TAR.GZ Archive链接进行下载

2、上传tar.gz压缩包到Linux远程主机，并解压

上传tar.gz压缩包到Linux主机的某个目录，如，/opt/，并解压：

复制代码

[root@localhost ~]# tar zxfv /opt/jprofiler_linux_11_0_2.tar.gz

JProfiler解压后，位于：/opt/jprofiler11.0.2

3、远程Linux主机安装JDK

复制代码

##安装
[root@localhost ~]# yum install java-11-openjdk* -y
 
#查看安装是否成功
[root@localhost ~]# java -version

4、远程Linux主机中查看JDK安装路径

复制代码

[root@localhost ~]# whereis java

bin之前的路径就是JDK的安装路径，即上图中的/home/data/software/jdk-11.0.2（注意： 每台主机中，java目录可能不一样，请按实际来）

5、远程Linux主机中查看主机的架构类型

复制代码

[root@localhost ~]# uname -m

由上图可知，我的主机的架构是x86_64（注意： 每台主机的架构类型可能不一样，请按实际来）

6、远程Linux主机中，基于主机架构类型，查看JProfiler的本地库目录

使用下面的命令进入JProfiler的bin目录，可以看到里面有适用于aarch64、arm、x64、x86等架构的本地库目录。

复制代码

#进入JProfiler的bin目录
[root@localhost ~]# cd /opt/jprofiler11.0.2/bin

#列表查看目录/文件
[root@localhost bin]# ls -l

由于我的主机的架构是x86_64（注意： 每台主机的架构类型可能不一样，请按实际来），我这里既可以使用linux-x64目录，也可以使用linux-x86目录，我这里选择linux-x64目录，完整目录路径是：/opt/jprofiler11.0.2/bin/linux-x64

由上图可知，在该目录中是.so的本地库文件。下一步将基于该目录设置 LD_LIBRARY_PATH 环境变量。

7、远程Linux主机中设置环境变量

使用如下命令，修改环境变量

复制代码

[root@localhost ~]# vi /etc/profile

添加如下内容（注意： 根据各自主机中的实际路径来填写）：

复制代码

export INSTALL4J_JAVA_HOME=/home/data/software/jdk-11.0.2    #jdk安装目录
export LD_LIBRARY_PATH=/opt/jprofiler11.0.2/bin/linux-x64    #jprofile的本地库目录

修改完后，使环境变量生效

复制代码

[root@localhost ~]# source /etc/profile

8、远程Linux主机中确保Java应用已经启动

执行如下命令：

复制代码

[root@localhost ~]# ps -ef | grep java

9、启动JProfiler服务

执行如下命令：

复制代码

# 进入JProfiler的bin目录
[root@localhost ~]# cd /opt/jprofiler11.0.2/bin

# 执行jpenable命令启动JProfiler服务
[root@localhost bin]# ./jpenable

执行 ./jpenable 命令后，输入 1按回车键，进入GUI模式，这时会生成JProfiler的随机端口（如下图中的4495），你可以手动输入一个未使用的新端口来替换，也可以直接按回车键，使用默认生成的随机端口。

注意： 每次执行./jpenable 命令，生成的随机端口都不一样。

**注意：**执行./jpenable 命令后，JProfiler服务就在后台一直运行着。如果使用 kill 命令杀掉JProfiler服务时，也会将已启动的Java应用给杀掉。这时，若想再次启动JProfiler服务，需要重新启动Java应用。

10、本地Windows主机中使用JProfiler软件连接远程Linux主机中的JProfiler服务

Start Center==>New Session==>New Remote Integration

勾选On a remote computer==>选择远程主机的系统架构

设置JDK的厂商、版本和模式

选择Startup immediately

填写远程Linux主机的IP地址

填写远程Linux主机中JProfiler的安装路径

默认勾选第一项

填写远程Linux主机中JProfiler服务启动时分配的随机端口

配置确认

勾选第一项

推荐：开发测试环境选择Instrumentation，生产环境选择Sampling

JProfiler提供了两种主要的CPU性能分析方法：Instrumentation和Sampling。

Instrumentation（插桩）

工作原理：Instrumentation通过修改字节码来收集数据。在应用程序启动时，JProfiler会自动修改类文件中的方法，插入额外的代码以记录方法调用次数和执行时间。

优点：

提供精确的方法调用计数和执行时间。

适合分析具体方法级别的性能瓶颈。

能够提供详细的调用树，包括所有方法调用路径。

缺点：

因为需要修改字节码，可能会对程序的性能产生较大影响，特别是在大型应用中。

可能导致一些懒加载机制提前触发，从而改变程序的正常行为。

Sampling（抽样）

工作原理：Sampling则是通过定期检查当前线程的堆栈信息来收集数据。它不会修改字节码或程序运行流程，而是根据一定的时间间隔（如每10毫秒）捕获线程的执行状态。

优点：

对被分析的应用程序的影响较小，因为它不需要修改字节码。

更适合于长时间运行且负载较高的生产环境监控。

缺点：

数据不如Instrumentation精确，因为它是基于抽样的，可能错过某些快速执行的方法。

不支持所有功能，不提供直接的方法调用次数统计，只能估计方法的相对活跃度。

总结

如果你需要准确了解每个方法的执行时间和调用次数，尤其是在开发和测试环境中，Instrumentation是更好的选择。

如果你关心的是整体性能趋势，或者是在生产环境中进行轻量级监控，Sampling则更为合适。它提供的性能开销小，对应用的实际运行影响也较小。

JVM exit action中设置：Save and immediately open a snapshot

上图点击OK按钮后，JProfiler将立即进行性能监测，如下图所示：

说明： 上面第8步和第9步可以合并如下：

启动Java应用程序时，使用 VM参数-agentpath:<本地库的路径> 将.so本地库文件添加作为JProfiler代理，并使用默认的JProfiler 8849端口
复制代码
java -jar -agentpath:/opt/jprofiler11.0.2/bin/linux-x64/libjprofilerti.so=port=8849 /home/data/backend/xs/spn-xs-backend-1.0-SNAPSHOT.jar 
这时，再按第10步的操作，使用本地Windows主机中的JProfiler软件连接远程Linux主机中的JProfiler服务即可，注意，端口是8849，而不再是JProfiler的随机端口了。

七、JProfiler软件介绍

1、Telemetries遥测视图

观察遥测可以让你更好地理解分析的软件，你可以通过不同的测量关联重要事件。如果注意到有异常的行为，可能会促使你使用JProfiler中的其他视图进行更深入的分析。

Memory(内存)

显示堆栈的使用状况和堆栈尺寸大小活动时间表。

Recorded Objects（记录的对象）

显示一张关于活动对象与数组的图表的活动时间表。

Recorded Throughput （记录的吞吐量）

显示一段时间累计的JVM生产和释放的活动时间表。

GC Activity（垃圾回收活动）

显示一张关于垃圾回收活动的活动时间表。

Classes （类）

显示一个与已装载类的图表的活动时间表。

Threads （线程）

显示一个与动态线程图表的活动时间表。

CPU Load （CPU负载）

显示一段时间中CPU的负载图表。

2、Live memory实时内存视图

JProfiler的实时内存视图部分可以提供动态的内存使用状况更新视图和显示关于内存分配状况信息的视图。所有的视图都有几个聚集层并且能够显示现有存在的对象和作为垃圾回收的对象。

All Objects (所有对象)

显示类或在状况统计和尺码信息堆上所有对象的包。你可以标记当前值并显示差异值。

Recorded Objects (记录的对象 )

显示类或所有已记录对象的包。你可以标记出当前值并且显示差异值。

Allocation Call Tree (分配调用树)

显示一棵请求树或者方法、类、包或对已选择类有带注释的分配信息的J2EE组件。

Allocation Hot Spots (分配热点)

显示一个列表，包括方法、类、包或分配已选类的J2EE组件。你可以标注当前值并且显示差异值。对于每个热点都可以显示它的跟踪记录树。

Class Tracker (类跟踪器)

类跟踪器可以包含任意数量的图表，显示选定的类和包的实例与时间。

3、Heap walker堆遍历器视图

在JProfiler的堆遍历器(Heap Walker)中，你可以对堆的状况进行快照并且可以通过选择步骤下寻找感兴趣的对象。堆遍历器有多个视图.

Classes (类):

显示所有类和它们的实例，可以右击具体的类"Used Selected Instance"实现进一步跟踪。

Allocations(分配)

为所有记录对象显示分配树和分配热点。

Biggest Objects（最大对象）

显示了当前对象集中最重要的对象列表。这里的"最大"指的是，如果从堆中删除这些对象，会释放最多的内存。

References(引用)

为单个对象和"显示到垃圾回收根目录的路径"提供引用图的显示功能。还能提供传入引用（Incoming references）、传出引用（Outgoing references）、合并引用等功能。

Time(时间)

显示一个对已记录对象的解决时间的柱状图。

Inspections(检查 )

"检查"视图本身并不显示数据。它提供了一些堆分析，这些分析根据其他视图中没有的规则创建新的对象集。

Graph(图表)

你需要在引用视图和最大对象视图手动添加对象到图表，它可以显示对象的传入和传出引用，能方便的找到垃圾收集器根源。

在工具栏点击"Go To Start"可以使堆内存重新计数，也就是回到初始状态。

4、CPU views CPU分析视图

Call Tree(调用树)

显示一个积累的自顶向下的树，树中包含所有在JVM中已记录的访问队列。JDBC、JMS和JNDI服务请求都被注释在请求树中。请求树可以根据Servlet和JSP对URL的不同需要进行拆分。

Hot Spots(热点)

显示消耗时间最多的方法的列表。对每个热点都能够显示回溯树。该热点可以按照方法请求，JDBC、JMS和JNDI服务请求以及按照URL请求来进行计算。

Call Graph（调用图）

显示一个从已选方法、类、包或J2EE组件开始的访问队列的图。

Method Statistis（方法统计）

显示一段时间内记录的方法的调用时间细节

5、Thread 线程视图

JProfiler通过对线程历史的监控判断其运行状态，并监控是否有线程阻塞产生，还能将一个线程所管理的方法以树状形式呈现。对线程剖析。

Thread History(线程历史)

显示一个与线程活动和线程状态在一起的活动时间表。

Thread Monitor(线程监控)

显示一个列表，包括所有的活动线程以及它们目前的活动状况。

Thread Dumps(线程转储)

显示所有线程的堆栈跟踪。

6、Monitors & locks 监视器和锁视图

Current Locking Graph (当前锁状态图)

显示JVM中的当前锁定情况。

Current Monitors (当前监视器)

显示当前正在等待或阻塞中的线程操作。

Locking History Graph(锁状态历史图)

显示记录在JVM中的锁定历史。

Monitor History(监控器历史)

显示等待或者阻塞的历史。

Monitor Usage Statistics(监控器使用情况统计)

计算统计监控器监控的数据。

八、JProfiler应用

1、内存分析

系统的内存消耗过多往往有以下几种原因：

频繁创建Java对象，如：数据库查询时，没分页，导致查出表中所有记录；代码中存在死循环或循环产生过多重复的对象实体；
存在大对象，如：读取文件时，不是边读边写而是先读到一个byte数组，这样如果读取的文件是50M，则仅此一项操作就会占有JVM 50M内存。
存在内存泄漏，导致已不被使用的对象不被GC回收，从而随着系统使用时间的增长，内存不断受到挤压，最终OutOfMemory。

说明：

**内存溢出：**第1、2种情况。程序向系统申请的内存空间超出了系统能给的。比如内存只能分配一个int类型，我却要塞给他一个long类型，系统就出现OutOfMemory。又比如，一车最多能坐5个人，你却非要塞下10个，车就挤爆了。

**内存泄漏：**第3种情况。所谓内存泄漏是指由于疏忽或错误造成程序未能释放已经不再使用的内存的情况。内存泄漏并不是指内存在物理上的消失，而是应用程序分配某段内存后，因为设计错误，失去了对该段内存的控制，因而造成了内存的浪费。

针对1、2种情况，可以通过 Live Memory 实时内存视图来分析。

首先通过观察Size列可以找到系统中占用内存最大的对象。然后再分析Instance count列。

如果Size过大，并且它对应的Instance Count比较小，则说明该对象是大对象。如果Size过大，同时它对应的Instance Count 也很大，则说明这个对象在被频繁创建。这时，可以对应Name列指示的Java类路径，找到项目里的Java类进行分析。如果发现有不合理的地方，则改之。

在该视图下方的Recorded Objects子视图中可以记录对象，从而查看类在一段时间里的总实例数、GC数和活动数。但是，在使用这些功能时会导致系统的性能严重降低。例如：没开此功能时，1000并发的响应时间为1s。开此功能后，500并发时响应时间才能达到1s。因此，只有当存在内存泄漏时才开启该功能。

针对第3种情况，如果怀疑内存泄漏，第一步就是查看Telemetries遥感视图中的 "Memory"和"Recorded objects" 。当应用程序出现内存泄漏时，视图中会显示出带有震荡的线性积极趋势。大多数的内存泄漏可以被追溯到对象集群。这将产生一些大的retained size的对象。最大的对象视图列出了带有最大retained size的对象。你可以利用该树形向下钻取从而发现错误引用。

首先查看Telemetries遥感视图中的 "Memory"

在Memory中，可以知道JVM的总内存分配大小、内存占用大小和内存空闲大小以及GC后内存占用的变化。蓝色区域表示占用的内存，下坡表示此时刻可能经历了一次GC。

当发现GC后，回收的力度越来越小，则说明很有可能存在内存泄漏。这时需要开启Live Memory实时内存视图下的Recorded Objects子视图。

右键不断切换Garbage Collected Objects、Live Objects和Live And Garbage Collected Objects这三种模式，并结合项目的Java类，找出本该被回收但却没有得到回收的对象的对应Java类，从而找出问题根源。

内存泄露的真因是：持有对象的强引用，且没有及时释放，进而造成内存单元一直被占用，浪费空间，甚至可能造成内存溢出！

2、CPU分析

通常一个方法的执行时间越长，则占用CPU的资源则越多。在JProfiler里就是通过方法的执行时间来描述对CPU的使用情况。

通过CPU views视图的Method Statistics子视图，可以看到一段时间里，涉及类方法的执行时间，这些时间是从开始记录到查看该视图这段时间所发生的执行时间的合计，如此可以准确反映出真实场景下的方法执行情况。

一般是用LoadRunner压一段时间后再查看该视图，通过占用时间的不同，找出系统里最耗时的类方法进行调优解决问题。

发现执行一次请求，响应时间不能满足需求时，通过这种CPU时间占用的方式分析可优化点，是一种简单而有效的方式。

3、线程分析

线程的运行情况可以直接反应出系统的瓶颈所在。对线程一般有以下三个关注点：

Web容器的线程最大数管理。Web容器允许开启的线程数与系统要求的最大并发数有一定的对应关系，通常Web容器运行的线程数略大于最大并发数。以Tomcat为例，在{$tomcat}/conf/server.xml文件的Connector选项里配置maxThreads，它的默认值时150。
线程阻塞；
线程死锁。

通过Threads视图可以观察到项目的线程情况。

如图，在Threads 的Thread History视图里，可以查看Web容器共打开的线程数以及这些线程的使用情况。

九、文档参考

1、参考官方中文链接：JProfiler帮助文档 - 前言

2、JVM监控及诊断工具GUI篇之JProfiler_jprofiler 线程转储颜色