JProfiler(Java剖析工具) v9.2 64位

JProfiler是一个商业授权的Java剖析工具，由EJ技术有限公司，针对的Java EE和Java SE应用程序开发的,它能将cpu、执行绪、内存的剖析组合在一个强大的应用中，可以同多种IDE整合和应用服务器整合用途，是一个不可多得的剖析工具。

JProfiler特色：

JProfiler可提供许多IDE整合和应用服务器整合用途。JProfiler直觉式的GUI让你可以找到效能瓶颈、抓出内存漏失 （memory leaks）、并解决执行绪的问题。它让你得以对heap walker作资源回收器的root analysis,可以轻易找出内存漏失；heap快照（snapshot）模式让未被参照（reference）的对象、稍微被参照的对象、或在终结 （finalization）队列的对象都会被移除；整合精灵以便剖析浏览器的Java外挂功能。

JProfiler功能

卓越的易用性

Profiler简单而强大，同时它的配置会话是直接的，第三方集成使得开始轻松，分析数据以自然的方式呈现。在各个层次上，JProfiler经过精心设计，可以帮助您开始解决问题。

JDBC、JPA和NOSQL的数据库分析

JProfiler的JDBC和JPA/Hibernate探测器以及MongoDB，Cassandra和HBase的NoSQL探测器显示了数据库访问缓慢以及代码缓慢的语句调用原因。从JDBC时间线视图显示所有与其活动的JDBC连接，通过热点视图，显示各种遥测视图的慢速语句和单个事件列表，数据库探针是深入了解数据库层的重要工具。

极好的支持JAVA企业版

在JProfiler中的大多数视图中存在JEE的专用支持。例如，在JEE聚合级别中，您可以根据应用程序中的JEE组件看到调用树。另外，每个请求URI都会分配调用树。此外，JProfiler在低级别分析数据之上添加了语义层，如在CPU分析视图中呈现的JDBC，JPA/Hibernate，JMS和JNDI调用。凭借其JEE支持，JProfiler弥合了代码分析器和高级JEE监视工具之间的差距。

更高级别的分析数据

JProfiler有许多探针可以显示JRE中有趣子系统的更高级别的数据。除了JavaEE子系统，如JDBC，JPA/Hibernate，JSP/Servlets，JMS，Web服务和JNDI之外，JProfiler还提供了有关RMI调用，文件，套接字和进程的高级信息。这些探针中的每一个都有自己的一组有用的视图。所有这些视图也可用于您可以在JProfiler中即时配置的自定义探针。

内存泄漏分析

JProfiler的堆步行器为您提供了一个直观的界面来解决简单和复杂的内存问题。5个不同的视图和大量的检查显示当前对象集的不同方面。每个视图都提供对所选对象的基本见解，并允许您切换到不同的对象集。

广泛的质量保证能力

快照的丰富功能可以轻松跟踪进度。JProfiler对命令行操作有很强的支持。这包括配置，导出快照数据和从命令行创建快照比较的功能。与JProfiler绑定的ant任务允许您从构建脚本执行所有命令行操作。

最广泛的支持平台，IDE和应用服务器

集成到所有流行的IDE中，使开发过程中的分析与运行应用程序一样简单。并且市场上几乎所有应用服务器的大量集成向导确保您可以开始点击几次，而不是阅读文档。

低开销

JProfiler只在需要时记录数据。实际上，您可以使用JProfiler代理启动应用程序，并在以后连接JProfilerGUI。当您不记录任何数据时，开销非常小。JProfiler显示您的性能分析设置如何影响性能，并为您提供模板以快速选择常见用例的性能分析设置。

强大的CPU分析器

修复性能瓶颈是分析器最常用的用例。使用JProfiler，当您尝试找到问题的原因时，您将具有决定性的优势。调用树视图过滤器，聚合级别和线程状态选择器只是JProfiler在此领域的多功能性的一些示例。

集成螺纹轮廓仪

使用JProfiler可以解决一系列不透明的问题，例如在使用过多锁定的多线程应用程序中增加活动性。线程分析不仅在JProfiler中有一个单独的视图部分，它也被紧密地集成到CPU分析视图中。

JProfiler安装教程

1、根据自己的需要下载对应的版本，小编是32位系统故双击“jprofiler_windows_9_2_1.exe”安装

2、稍等一会儿进入jprofiler 9.2的安装向导，如下图是要让你设置软件的安装目录，默认是装在C盘，如果你想更改盘符可以点击customize installation

3、点击next出现软件的许可协议，我们选择i accept

4、下面就开始安装了，稍等一会儿安装完成

5、完成后就可以运行jprofiler 9.2了

JProfiler配置教程

配置测试用例

1. 点击d:/jprofiler5/bin/jprofiler.exe

2. 执行菜单SessionàIntegration WizardsàNew ServerIntegration

选择是本地测试还是远程测试：

选择tomcat运行的脚本文件：

选择虚拟机的类型:

选择监控端口：

用默认的即可

选择Web容器是否和Jprofiler一起运行：

默认即可

配置提示：

在“远程控制”的时侯要仔细阅读一下。

然后选择立即起动，开始运行。

点击“OK”，我们可以看到另外一个小窗口出来了：

Jprofiler的窗口为：

这样我们就可以进行监控了!

开始测试

1. 在IE地址栏中输入：http://localhost/test/init1.jsp，执行一次，我们可以在内存视图中看到cn.test.TestBean对象被创建了10000次：

2.标记现在的状态，然后再执行init1.jsp和,init2.jsp可以让我们找到哪些类在调用后没有被释放(很重要!!!)

查看哪些类被发生了变化：

红色的变成是发生变化的对象及其数量。

我刚才执行了4次init1.jsp和1次init2.jsp，正好产生了50000个TestBean对象，和图示显示的一样。

3. 过一会后，按F4键进行垃圾回收。但回收完成后，这些对象依然存在，说明某些地方对这个类的引用没有被释放!

4. 找出是哪些地方使用了TestBean类，并且没有释放它们

在cn.test.TestBean对象上点击右键选择“Take Heap Snapshot for Selection”，观察它的heap

下一步：

点击“OK”：

在该类中点击右键，在出现的菜单中选择“Use Selected Objects”：

出现如下窗口：

选择”Allocations”，点击“OK”,然后我们要的结果就出来了

图中显示调用此类的地方是init1.jsp和init2.jsp，并且各自占用的比率都列出来了。

JProfiler使用教程

分析内存：

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

频繁创建Java对象，如：数据库查询时，没分页，导致查出表中所有记录;

存在大对象，如：读取文件时，不是边读边写而是先读到一个byte数组，这样如果读取的文件时50M则仅此一项操作就会占有JVM50M内存。

存在内存泄漏，导致已不被使用的对象不被GC回收，从而随着系统使用时间的增长，内存不断受到解压，最终OutOfMemory。

当需要预判或者问题发生需要解决系统的内存问题时，可以借助JProfiler的Memory Views和VM Telemetry Views两种视图：

解决问题1和2，需借助Memory Views视图，如下：

图：1

图1主体表格的三列是解决问题的关键，可以通过如下步骤分析：

通过单击Size列列名可排列出最占内存的对象，查看所占内存大小，如果过大并且它对应的Instance Count比较小则说明该对象是大对象，这时可以对应Name列指示的Java类路径找到项目里的Java类进行分析，如果不合理则改之。

通过单击Instance Count列列名可排列出内存中实例数最多的Java对象，通过Name列指示的Java类路径逐一排查可能存在的设计问题。

注：在JProfiler的下方可以通过包路径过滤需要关注的对象，如图：

图：2

在图2中的ViewFilters输入框中输入“org.sotower”回车，则在列表中只有列出sotower包下的对象相关信息。

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

图：3

解决问题3说明的内存溢出问题，需要同时借助Memory Views和VM Telemetry Views视图。

图：4

在VM Telemetry Views试图里，可以看出JVM的总共内存分配大小、内存占用大小和内存空闲大小以及GC后内存占用的变化。在图4中可以看出蓝色区域上线有一个陡降的坡度，这时GC后内存占用下降的结果，在分析是否存在内存泄漏问题时，该下坡具有重要意义，在用LoadRunner疲劳测试时，在稳压期间，良好的系统内存占用应该是比较稳定，并且GC后下坡的幅度也应该比较一致，比如：前次GC释放200M，下次GC大致也是200M，这是一般规律，具体在分析时或有不同，性能分析人员应灵活运用。

当发现GC后回收的力度越来越小，则说明很有可能存在内存泄漏，这时需要开启该视图的Memory Views视图的Recorded Objects子视图，开启前的视图请见：图3，开启后视图如下：

图：5

图：6

如图6，在该视图里打开右键菜单，不断切换GC、Live和GC Live这三种模式，并结合项目的Java类，找出本该被回收但却没有得到回收的对象的对应Java类，从而找出问题根源。

分析CPU：

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

图：7

在图7中，可以发现JProfiler以很清楚的层级结构描述出在一段时间里涉及类方法的执行时间，这些时间是从开始记录到查看该视图这段时间所发生的执行时间的合计，如此可以准确反映出真实场景下的方法执行情况。

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

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

分析线程：

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

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

线程阻塞;

线程死锁。

在JProfiler里有专门的线程视图：Thread Views，该视图能很好的发现并解决线程相关的大多问题。线程运行历史图：

图：8

如图8在Thread Views的Thread History视图里可以查看Web容器共打开的线程数以及这些线程的使用情况，在视图里红色表示阻塞的时间段，红色线条越长代表阻塞的时间越长，说明在存在阻塞情况这时切换到Current Monitor Usage或者Monitor Usage History视图，如：

图：9

通过视图上方的

指定只显示阻塞时间超过一定s(秒)数的线程，在本例中指定5s，在线程表格中选中一行，一般会在下方表格里显示出等待线程和拥有线程的执行堆栈，通过分析这些执行堆栈并在项目中找到对应的Java类方法，分析阻塞原因(往往是使用synchronized同步关键字导致阻塞，因此在用到synchronized关键字时一定要谨慎)，从而解决问题。

如果系统里存在线程死锁情况，则会显示在Deadlock Detection视图：

图：10

在该视图里会把死锁线程的Java对象调用关系以关系网的方式展示，并能定位到造成死锁的类方法，通过结合该图和Java代码分析解决问题。

更新日志

jprofiler v9.2更新日志

修复了调用树分析的内存泄漏

修复了eclipse 4.5首选项页面上的JProfiler可执行文件选择

改进了探针热点视图的性能

现在可以读取包含缺少类的实例的HPROF堆转储

取消快速启动对话框后，显示起始中心

支持新的Java9版本方案

改进了对PostgreSQL和MariaDB驱动程序的支持

在热点视图中删除呼叫树根目录不会更新显示的数据

修复其他Bug