如何使用JProfiler查找内存泄漏

很久之前用过的，参考:

第一种、本地程序由jprofiler来引导程序启动，

第二种、在客户端远程监控服务端的CS模式，必须在客户端和服务端都安装jprofiler，服务端需要在环境变量里加入LD_LIBRARY_PATH 值为JProfiler 的库文件所在路径，比如 $JPROFILER_HOME/bin/linux-x86，然后将服务端的启动脚本考到客户端上，在客户端配置时有一步选择这个脚本(locate the start script)，jprofiler会给脚本添加一些自己的配置，然后服务端使用jprofiler改好的这个脚本启动，这时候是不会真正启动的，他在等待客户端的触发，客户端jprofiler再启动的时候就可以远程监控到服务端jvm了。本地的程序的话按照向导就很容易做了。

分析:

1、揣测、在Memory Views这个页面右键点击比较有可能出现泄漏的类，然后add selection to class tracker。有几项最常出现泄漏的最好加进来:String，char[],HashMap的entry，以及用过滤器通过包名筛选出自己的项目里用到的类

2、跟踪、经过过一段时间后，查看memeory views里的class tracker的tab页，可以看到对象数量在这一段时间内的记录，如果有增长过快、或持续增长而不释放的则会造成泄漏

3、追溯、定位了这个类后再就看一下是谁引用他导致内存没有释放，在heap walker里，找到刚才的class，右键它查看他的引用references，针对可能出现问题的类进行源码浏览、确定根源在哪里

很久之前用过的，参考：

第一种、本地程序由jprofiler来引导程序启动，

第二种、在客户端远程监控服务端的CS模式，必须在客户端和服务端都安装jprofiler，服务端需要在环境变量里加入LD_LIBRARY_PATH 值为JProfiler 的库文件所在路径，比如 $JPROFILER_HOME/bin/linux-x86，然后将服务端的启动脚本考到客户端上，在客户端配置时有一步选择这个脚本（locate the start script），jprofiler会给脚本添加一些自己的配置，然后服务端使用jprofiler改好的这个脚本启动，这时候是不会真正启动的，他在等待客户端的触发，客户端jprofiler再启动的时候就可以远程监控到服务端jvm了。本地的程序的话按照向导就很容易做了。

分析：

1、揣测、在Memory Views这个页面右键点击比较有可能出现泄漏的类，然后add selection to class tracker。有几项最常出现泄漏的最好加进来：String，char[],HashMap的entry，以及用过滤器通过包名筛选出自己的项目里用到的类

2、跟踪、经过过一段时间后，查看memeory views里的class tracker的tab页，可以看到对象数量在这一段时间内的记录，如果有增长过快、或持续增长而不释放的则会造成泄漏

3、追溯、定位了这个类后再就看一下是谁引用他导致内存没有释放，在heap walker里，找到刚才的class，右键它查看他的引用references，针对可能出现问题的类进行源码浏览、确定根源在哪里

JProfiler 是一个商业授权的 Java剖析工具,用于分析Java EE和Java SE应用程序.

JDK 本身定义了目标明确并功能完善的JNI( Java Native Interface ) 与虚拟机直接进行交互,这些 API 能很方便的进行扩展,从而满足开发者各式的需求.

JVMTI( JVM Tool Interface) ,是JAVA虚拟机提供的本地接口,它是实现调度器以及其它Java运行测试与分析 工具 的基础.

并不一定在所有的JDK提供商都有实现,但在主流的Oracle JDK、Open JDK上都有其实现.

1.用户在JProfiler GUI中下达监控命令( 对应用户的一个点击 ).

2.JProfiler GUI通过自身Socket的8849端口向位于JVM的JProfiler Agent发送监控指令.

3.JProfiler Agent收到指令后向JVMTI注册事件或执行相关的命令.

4.JVMTI根据事件和命令的类型返回相对应的数据( 线程状态、对象实例、CPU负荷、GC状态信息等)

5.JProfiler Agent从JVMTI中得到相应数据后将对其进行计算,最终通过Socket传输给JProfiler GUI中进行展示.

https://www.ej-technologies.com/download/jprofiler/files

激活码： L-Larry_Lau@163.com #23874-hrwpdp1sh1wrn#0620

***** Linux *** 作系统无须激活

Select from all local JVMs模式：将扫描本地所有正在运行的JVM实例

Attach to profiled JVM模式：选择本地或远程正在运行的JVM实例,远程被监控的机器一定要预先安装JProfiler.

***** 需指定远程 服务器的JProfiler的通讯端口

步骤一：Session-->Integration Wizards-->New Server Integration

步骤二：选择应用服务器的类型以及版本号

步骤三：选择与本地或远程服务器的服务进行集成

***** 本文将使用远程服务器模式.

***** 若 选择与远程服务器的服务进行集成则需要选择远程服务器的 *** 作系统类型.

步骤四：选择服务器使用的JVM供应商以及版本号

步骤五：选择JProfiler的启动模式

JVM将等待JProfiler Agent接收到JProfiler GUI发送的配置信息后再进行启动( 即Lauch Type连接模式 ,启动一个新的JVM实例)

立即启动JVM,稍后再与JProfiler GUI进行连接并向JProfiler Agent发送配置信息( 数据的采集方式、过滤器、触发器等信息 )

***** 若使用此模式则需要让JVM在启动时自动加载JProfiler Agent,因此需要在startup.bat/startup.sh文件中添加命令

startup.bat：set CATALINA_OPTS=-agentpath:{JProfiler安装目录}\bin\windows-x64\jprofilerti.dll=port=8849,nowait %CATALINA_OPTS%

startup.sh：CATALINA_OPTS=-agentpath:/{JProfiler安装目录}/bin/linux-x64/libjprofilerti.so=port=8849,nowait $CATALINA_OPTS

export CATALINA_OPTS

离线分析,JProfiler GUI无法与JProfiler Agent进行连接,因此需要将数据的采集方式、过滤器、触发器等信息打包成config.xml配置文件,在启动该JVM实例时加载JProfiler Agent以及配置文件,使用此模式需要配合triggers触发器使用,当发生指定的事件后触发指定的 *** 作.

***** 若使用此模式则需要让JVM在启动时自动加载JProfiler Agent和context.xml配置文件,因此需要在startup.bat/startup.sh文件中添加命令

startup.bat：set CATALINA_OPTS=-agentpath:{JProfiler安装目录}\bin\windows-x64\jprofilerti.dll=port=8849,nowait,config=C:\Users{用户名}.jprofiler9\config.xml %CATALINA_OPTS%

startup.sh：CATALINA_OPTS=-agentpath:/{JProfiler安装目录}/bin/linux-x64/libjprofilerti.so=port=8849,config={预定义目录}\config.xml $CATALINA_OPTS

export CATALINA_OPTS

步骤六：填写远程服务器的IP地址

步骤七：输入远程服务器中JProfiler的安装目录( 供JProfiler生成脚本时使用 )

步骤八：选择应用服务器的启动脚本,JProfiler会根据选择的启动脚本文件生成一份适用于JProfiler特定启动模式的脚本文件.

***** 最终在本地生成startup_jprofiler.sh文件,需将此文件复制到远程服务器中应用服务器的bin目录并对文件赋予执行的权限,在服务器中直接通过JProfiler提供的startup_jprofiler.sh文件来启动服务.

***** 若使用离线启动模式则还需要将JProfiler生成的context.xml配置文件复制到远程服务器中,然后修改startup_jprofiler.sh文件中JVM加载context.xml文件的路径.

步骤九：设置JProfiler GUI通讯的端口

步骤十：检查配置项

步骤十一：选择数据的采集方式

JProfiler将对需要分析的class字节码文件中写入自己的bytecode, 对于正在运行的JVM实例选择此模式将会重新加载字节码文件到JVM的运行时数据区域结构中 .

***** 这是JProfiler全功能模式,在此设置中,调用堆栈信息是准确的,但是CPU开销可能很高( 取决于Filter的控制 ),若要分析的类较多,则对应用的性能产生影响,因此使用此模式一般配合Filter使用,只对特定的类或包进行分析.

此模式对CPU的开销非常低,但不支持某些功能( 方法的执行次数、执行时间等 ), 这种模式在连接正在运行的JVM实例时更为安全.

步骤十二：选择配置Filter和Trigger

配置Filter( 适用于Instrumentation数据采集模式 )

配置Trigger( 多用在离线的启动模式 )

1.选择触发器的类型

2.选择触发的动作

步骤十三：完成配置,连接JProfiler Agent,对程序进行监控.

***** 每个Session表示一次会话,Session可以通过人工创建 ( New Session ) 或者与服务应用进行集成来产生( Integration Wizards ).

***** 支持将当前JVM实例的运行状态保存为快照( Save Snapshot )并提供快照与快照之间的对比功能.

Telemetries视图：包含JMM内存的使用情况( 全局堆与非堆、局部伊甸园区、幸存者区、老年代)、GC线程的活动情况( 发生GC的时间,是属于Minor GC还是Full GC )、当前JVM实例的线程概况、CPU的负载等信息.

Live Memory视图：展示当前堆中实例的个数、方法的调用链等信息.

方法调用链信息：

Heap Walker视图：用于堆的快照分析,可以选择在Live Memory中记录的对象或者当前运行状态时堆的对象也可以直接在对象视图右键对象Show Selection In Heap Walker.

CPU Views视图：可以按运行顺序逐级查看当前程序运行时的耗时、在一定时间内统计方法的执行效率.

程序运行耗时：

一定时间内统计方法的执行效率( 单位：微秒 )：

Total Time：执行总时长.

Inv：执行的次数.

Avg Time：方法平均执行时长.

Median Time：第中间次数的执行时长.

Min Time：最短执行时长.

Max Time：最大执行时长.

---