说明
Java跟踪分析简单的性能问题很容易分离并解决，然而，大的性能问题，如内存溢出或者系统的罢工，通常在系统处于高负载情况下发生，就不能这么简单的处理了。这些问题需要一个独立的测试环境、一个模拟的负载，并且需要仔细地分析和跟踪。
服务器的性能改善是依赖于数据的。没有可靠的数据基础而更改应用或环境会导致更差的结果。分析器提供有用的服务器应用信息，但由于从单用户负载下的数据与多用户负载下得到的数据是完全不同的，这导致分析器的数据并不精确。在开发阶段使用分析器来优化应用的性能是一个好的方式，但在高负载下的应用分析可以取到更好的效果。
可控的进行应用负载测试的环境。
、3性能改变的跟踪。
虽然性能跟踪很重要，但有时为了使后续的测试更加精确而不得不抛弃先前的测试结果。在性能测试中，改善负载测试的精确性可能需要修改模拟环境，而这些变化是必须的，通过变化前后的负载测试你可以观察到其中的转变。
分析器原理
现在几乎所有的分析器都是从同一个起点和约束开始的：虚拟机分析器界面参考。微系统的允许工具开发商接口或者连接到遵循的上，并且监控运作的方式以及运行任何程序时的关键事件从单独的应用程序到、和企业组件。
在分析器内启动一个程序意味着生成、捕捉、和观察大量数据，所以所有的分析器都包含着不同的方法来控制数据的流动，在不同的标准以及每一封装包的基础上进行过滤。同样。
、简介
应用中。可提供许多整合和应用服务器整合用途。直觉式的让你可以找到效能瓶颈、抓出内存漏失、并解决执行绪的问题。它让你得以对作资源回收器的，可以轻易找出内存溢出；快照（）模式让未被参照（）的对象、稍微被参照的对象、或在终结（）队列的对象Java5.1 Memory profiler
的内存视图部分可以提供动态的内存使用状况更新视图和显示关于内存分配状况信息的视图。所有的视图都有几个聚集层并且能够显示现有存在的对象和作为垃圾回收的对象。
显示类或在状况统计和尺码信息堆上所有对象的包。你可以标记当前值并显示差异值。
Allocation call treeJ2EE Allocation hot spotsJ2EE在(Heapwalker)类显示所有类和它们的实例。
References“提供索引图的显示功能。还能提供合并输入视图和输出视图的功能。
Time剖析J2EE视图部分包括：
树中包含所有在JDBC,JMS服务请求都被注释在请求树中。请求树可以根据JSP的不同需要进行拆分。
，JNDI请求来进行计算。
组件开始的访问队列的图。
5.4 Thread profiler
JProfiler Thread history线程监控显示一个列表，包括所有的活动线程以及它们目前的活动状况。
里的死锁图表。
History usage history监测使用状态显示分组监测，线程和监测类的统计监测数据。
5.5 观察JProfiler Heap记录的对象显示一张关于活动对象与数组的图表的活动时间表。
Classes线程显示一个与动态线程图表的活动时间表。
使用介绍
6.1 JProfiler's start center
Open session
你可以选择一个会话，点击OK来打开预定义的会话。
会话能够通过两种途径创建：
会话创建完成后可以立即运行。在Open session标签页中能够看到新建的会话。
点击New Session按钮，显示Application Settings窗体，关于ApplicationSettings配置，请参见2管理session
.2 New server integration
如果你所使用的应用服务器不在列表中，则选择“Generic applicationsever ”，并点击“下一步”；如图：
第三步、 指定远程地址
第四步、 指定远程安装目录
第六步、 选择JVM提供商，版本和模式
前端通过指定的端口连接被监测的JVM，默认端口为8849。请不要选择常用的端口，如80或8080。
在开发环境，建立选择第一项，很容易修改监测设置；如果你选择不等待，在启动应用服务器之前要先配置监测设置。VM参数依赖于JProfiler配置文件的位置； 配置文件要与远程计算机上的保持同步。
集成向导完成配置，所有必须的信息会进行通知，请检查，点击下一步。如图：
选择是否立即运行
6.1.3Convertsession
管理pplication settings dialog
6.2.1名
6.2.1类型
：
用来剖析applets，你需要提供包含applet的HTML页面的URL
也可以剖析Java Web Start 应用，只需要给出JNLP 文件的URL或者选择一个缓冲应用
（动态获取）
所有的方法调用都会被跟踪，这样可以监控到JAVA核心类(java.*),但比动态获取慢，尤其是1.4 JVMs 。在1.5 JVMs (JVMTI)中不能使用。 使用全部获取你可以随意地显示具体的类调用的方法而不是某个方法在哪个类中实现。
过滤集可以在general settings的"Filter sets" 标签中设定。
Inclusive()
6.2.3子系统
在此标签下，你可以选择JProfiler如何记录J2EE相关的JAVA子系统。
JProfiler JDBCcalls
如果选择了Split call tree for each request URL ，JProfiler将分析调用servlets 和 JSPs的URL。针对每个URL，在calltree中都创建一个新的节点。URL也能够在hot spotview选择成了一个热点类型。这样做的话，你可以在单独的页面或请求中区分性能问题。
如果要显示所有的请求，请选择Show request URLs thatare outside the call tree.
features
在此标签中，你可以调整监控的属性，以提高软件执行速度，减少内存使用
Live objects By default, only live objects canbe displayed by the allocation views. Class-resolution is enabled.
o sortobjects by allocation time in the reference graph and the data view of the heapwalker.
If the aggregation level is set to "methods"and a method calls another method multiple times in different lines of code,line number resolution will show these invocations as separate method nodes inthe call tree and the allocation call tree. Backtraces in the hotspot viewswill also show line numbers.
监测视图
6.3.1.1 包（packages）：每一行显示一个单独的包，子包不包含在内。在这个集合体等级内，表是树形的。你可以点击树节点，查看其包含的类
在表中显示三行，可以排序
大小：显示所以分配实际的总大小。只包括相应指针的大小，不包含引用数组和实例的大小。以字节显示。只包括对象数据，不包括类使用的JVM大小，也不包含类数据和本地变量大小。
你可以冻结所有的视图让所有的视图对象保持静态
.2 Recorded objects如果选择了某个包或类，你可以从记录对象视图跳转到分配调用树和分配热点。方法是右键点击，选择要跳转的视图。
垃圾回收对象（Garbage collected objects） 被显示被回收的对象
右键选择Change view mode 或者使用View->Change view mode切换三种模式
.3 Allocation calltree
6.3.1分配热点视图（）
.5 Classtracker堆遍历.1 (Classes)
为所有记录对象显示分配树和分配热点
6.3.2索引.4 (Data)
.5 (Time)
CPU6.3.3调用树视图（）
自动检测J2EE组件并在调用树中显示相关的节点。使用不同的图标显示不同的J2EE组件类型
JSPs：红色倒心形
：JSP 源文件路径
如果URL可以被细分，每个URL请求使用一个特殊的符号创建一个新的结点以URL：做前缀，后面跟上细分后的URL请求 调用树视图集合体等级选择有四种：
包：每个节点是一个单独的包。不包括子包
调用树不显示JVM中的所有方法，只显示：
未过滤的类的第一级调用： 未过滤的类对过滤的类的第一级调用，对过滤类的深一级的调用不显示。过滤的节点在左上角以红色标记。
一个特殊的结点是桥结点，本来在视图中不显示，但其子孙节点在视图中显示。
1百分比数：考虑树的根或调用节点
：显示在此路径中节点被调用的频繁程度。
是否在括号内显示平均时间
ms
） 显示极限
4绝对
名称显示依赖集合体等级：方法、类、包和J2EE组件
集合体等级为方法
你可以停止或重启CPU数据获取来清空调用数，也可以冻结所有视图让调用数保持静态
6.3.3热点视图（）
热点类型"hot spot type"下拉中可选择，包括两种：
方法调用（method calls）
方法)
J2EE显示的热点为JDBC 调用。需要在profiling settings中设置为可用。
显示的热点为JNDI 调用。需要在profiling settings中设置为可用。
6.3.3调用图（）
在图形计算之前，会启动调用图向导。结果图形是静态的，并能够重新计算。调用图向导会记录你最近一次的选项。
第一步：选择图选项
第二步：选择第一个节点：选择生成调用树的首节点，点击完成，生成调用树。
1） 按等级展现（由上到下）
4
显示此方法或类的源代码，如下图。
6.3.4
6.3.4线程历史视图
橙色
红色
蓝色
只显示死线程
在文本框中，你可以输入线程的全名或部分名称进行过滤。也可以使用通配符("*" and "?")选择线程组。可以用逗号隔开多个过滤项进行过滤，如AWT-, MyThreadGroup-*-Daemon.
固定时间范围fixed time scale
也可以使用 zooming in或zooming out来调整显示的范围。
此种模式下，在当前视图中会显示整个时间段的图形。Zooming在此模式下不能使用
6.3.4线程监控视图
组Group
Starttime
Endtime
CPUtime
Note: CPU显示线程的名字和创建此线程的线程组。
如果你监控的是JAVA1.5或以上版本（JVMTI），在屏幕的上半部分就显示上面的表，屏幕的下半部分显示所选线程的线程创建堆栈跟踪。堆栈跟踪只有线程创建时记录CPU数据才会显示。
6.3.4死锁检测图形
正常的状态如果没有死锁，就显示"No deadlocks detected"
在java.util.concurrent包中的锁机制，不使用对象的监控而是不同的实现机制
线程名
监控的类
导致线程死锁的阻塞原因使用虚线箭头来表示。前头指向从阻塞线程到线程想进行的监控器
6.3.4当前监控使用视图
事件持续时间，事件必须还在进行中
MonitorID 监控器的类。如果没有JAVA对象与此监控器相关联，刚显示 [raw monitor]
显示监控中等待和阻塞的操作
6.3.4监控使用统计
在统计开始前，会打开一个monitor usage statisticsoptions对话框，统计结果表是静态的，并能重新计算。
在统计对象框中按分组标准显示名称
Block duration 在此监控组中，等待操作的频繁程度
在此监控组中，所有等待操作的累积的待续等待时间
6.3.5遥感监测视图
6.3.5堆显示堆上对象的总数，分为数组和非数组。可以显示线性图和区域图
6.3.5垃圾回收显示JVM调用的类的总，分为过滤类和非过滤类
6.3.5线程视图导出可以导出生成HTML文件或CSV文件，并可设定导出后是否立即打开文件。查看源代码和字节码
查看字节码：需要在SessionGeneralSetting Default Java File Path 下的Class Path中设定发布的类的路径，设定后要重启JProfiler。如下图：
6.4.3内存，加快启动速度
和 hot spots view 将立即显示数据
将立即显示数据
6.5
6.5.1第一步：选择比较类型
.1 第三步：选择记录类型
第五步：查看比较结果
集成等级：类、包、组件
第五步：查看比较结果（例中无）
6.5.1分配树比较
集成等级：方法、类、包、组件
创建比较
第一步，选择比较类型
针对第二个快照，有两种选择：与第一个快照相同的线程；不同的线程，可任何选择
第四步：选择视图参数
热点类型：方法调用、JDBC 调用、JMS调用、JNDI调用
.2集成等级：方法、类、包、组件
选择FileCreate TelemetryComparison，或使用快捷键F7
对比所有可用快照。
当前值（快照存储时的值）
某个书签标记值
.2 第四步：选择要比较的度量，可以多选
非数组
6.5.3类比较
全部类
未过滤类
第五步：查看比较结果
线程比较
全部线程
不活动线程
第五步：查看比较结果
集成（）
具体安装请参见JProfiler's setupwizard
文件选择器会提醒你安装在eclipse的安装目录下。
FAQ123457JProfile下面结合一个简单的Java Application例子说明Jprofiler如何使用package my;
public static void main(String[]args) throws IOException {
char ch=' ';
while(ch!='n')
ch=(char)System.in.read();
for(int i=0;i<1000;i++)
<1000;i++)
test();
ch=' ';
while(ch!='n')
ch=(char)System.in.read();
}
经过实验，发现蓝色部分加上和不加结果是一样的。因为arr是局部变量，test()运行结束时其生命周期也结束了，arr所引用的对象也被回收。因此也没必要设置为null。
、进入下一步，设置参数
4记录对象分配情况
5在Concole窗口中按n（代码里边要求的），进入下一步对象的分配和释放阶段
在运行过程中，每一时刻回收的对象数量。（GC不是一直运行的，要在JVM的内存不够时才运行）
堆内存分配变化情况
在第6步看到，运行结束时，有42470个Integer对象尚未回收。现在按F4执行gc
图中的小的尖峰就是对之前未回收的Integer对象进行回收时产生的数据。