问题描述

某个大型项目（Use Case用例超过300个），在项目上线后，其Web应用服务器经常宕机。表现为：

1. 应用服务器内存长期不合理占用，内存经常处于高位占用，很难回收到低位；

2. 应用服务器极为不稳定，几乎每两天重新启动一次，有时甚至每天重新启动一次；

3. 应用服务器经常做Full GC(Garbage Collection)，而且时间很长，大约需要30-40秒，应用服务器在做Full GC的时候是不响应客户的交易请求的，非常影响系统性能。

Web应用服务器的物理部署

      一台Unix服务器（4CPU，8G Memory）来部署本Web应用程序；Web应用程序部署在中间件应用服务器上；部署了一个节点（Node），只配置一个应用服务器实例（Instance），没有做Cluster部署。

Web应用服务器启动脚本中的内存参数

MEM_ARGS="-XX:MaxPermSize=128m -XX:MaxNewSize=512m -Xms3096m -Xmx3096m -XX:+Printetails -Xloggc:./inwebapp1/gc.$$"

可以看出目前生产系统中Web应用服务器的内存分配为3G Memory。

Web应用服务器的重要部署参数

参数名称	参数值	参数解释
kernel.default(Thread Count)	120	执行线程数目，是并发处理能力的重要参数
Session Timeout	240分钟（4小时）	HttpSession会话超时

分析

分析方法

内存长期占用并导致系统不稳定一般有两种可能：

1. 对象被大量创建而且被缓存，在旧的对象释放前又有大量新的对象被创建使得内存长期高位占用。

• 表现为：内存不断被消耗、在高位时也很难回归到低位，有大量的对象在不断的创建，经过很长时间后又被回收。例如：在HttpSession中保存了大量的分页查询数据，而HttpSession的会话超时时间设置过长（例如：1天），那么在旧的对象释放前又有大量新的对象在第二天产生。
• 解决办法：对共享的对象可以采用池机制进行缓存，避免各自创建；缓存的临时对象应该及时释放；另一种办法是扩大系统的内存容量。

2. 另一种情况就是内存泄漏问题

• 表现为：内存回收低位点不断升高（以每次内存回收的最低点连成一条直线，那么它是一条上升线）；内存回收的频率也越来越高，内存占用也越来越高，最终出现"Out of Memory Exception"的系统异常。
• 解决办法：定位那些有内存泄漏的类或对象并修改完善这些类以避免内存泄漏。方法是：经过一段时间的测试、监控，如果某个类的对象数目屡创新高，即使在JVM Full GC后仍然数目降不下来，这些对象基本上是属于内存泄漏的对象了。

问题定位

这里请看5月份 Web应用服务器的内存回收图形：

《注意：5月18日早上10点重新启动了Web服务器，5月20日早上又重新启动了Web服务器。》

• 在Web应用重要部署参数中，我们知道：Session的超时时间为4个小时，我们在监控平台也观测到：在18日晚上10点左右所有的会话都过期了，从图形一中也能看出18日晚上确实系统的内存有回收到40%（就象股票的高位跳水）；
• 从图形一（5月18日）中我们也能看到Full GC回收后的内存占用率走势（红色曲线），上午基本平滑上升到20%（内存占用率），中午开始上升到30%，下午上升到40%
• 从图形二（5月19日）中我们也能看到Full GC回收后的内存占用率走势（红色曲线），上午又上升到了60%，到下午上升到了70%。
• 从黄色曲线（GC花费的时间，以秒为单位），Full GC的频率也在增快，时间耗费也越来越长，在图形一中基本高位在20秒左右，到19日基本都是30-40秒之间了。

 图形一 5月18日


图二

通过上述分析，我们基本定位到了Web应用服务器的内存在高位长期占用的原因了：是内存泄露！并且正是由于这个原因导致系统不稳定、响应客户请求越来越慢的。

解决方法

方法如下：

• 我们从图形二中发现，在8.95(将近9点钟)到9.66（将近9点40）期间有几次Full GC，但是有内存泄漏，从占用率40%上升到50%左右，泄漏了大约10%的内存，约300M；
• 我们在自己搭建的Web应用服务器平台（应用软件版本和生产版本一致）做这一阶段相同的查询交易；表明对同一个黑盒（Web应用）施加同样的刺激（相同的操作过程和查询交易）以期重现现象；
• 我们使用Jprofiler工具对Web应用服务器的内存进行实时监控；
• 做完这些交易后，用户退出系统，并等待Web应用服务器的HttpSession超时（我们这里设置为15分钟）；
• 我们对Web应用服务器做了两次强制性的内存回收操作。

发现如下：

图三

如图三所示，内存经过HttpSession超时后，并强制gc后，仍然有大量的对象没有释放。例如：gov.gdlt.taxcore.comm.security.MenuNode，仍然有807个实例没有释放。

我们继续追溯发现，这些MenuNode首先存放在一个ArrayList对象中，然后发现这个ArrayList对象又是存放在WHsessionAttrVO对象的Map中，WHsessionAttrVO 对象又是存放在ExternalSessionManager的staic Map中（名称为sessionMap），如图四所示。

图四

我们发现gov.gdlt.taxcore.taxevent.xtgl.comm.WHsessionAttrVO中保存了EJBSessionId信息(登录用户的唯一标志，由用户id+登录时间戳组成，每天都不同)和一个HashMap，这个HashMap中的内容有：

• ArrayList: 内有MenuTreeNodes（菜单树节点）
• HashMap: 内有操作人员代码信息
• CurrentVersion:当前版本号
• CurrentTime:当前系统时间

WHsessionAttrVO这个对象的最终存放在ExternalSessionManager的static Map sessionMap中，由于ExternalSessionManager是一个全局的单实例，不会释放，所以它的成员变量sessionMap中的数据也不会释放，而Map中的Key值为EJBSessionId，每天登录的用户EJBSessionId都不同，就造成了每天的登录信息（包括菜单信息）都保存在sessionMap中不会被释放，最终造成了内存的泄漏。

图五

如上图所示：WHsessionAttrsVO对象中除了有一个String对象（内容是EJBSessionId），还有一个HashMap对象。

图六

如上图所示，这个HashMap中的内容主要有menuTreeNodes为key，value为ArrayList的对象和以czrydminfo为key，value为HashMap对象的数据。

图七

如上图所示：menuTreeNodes为key，value为ArrayList对象中包含的对象有许多的MenuNode对象，封装的都是用户的菜单节点。

图八

如上图所示，最顶层（Root）的初始对象为一个ExternalSessionManager对象，其中的一个成员变量为static (静态的)，名称为：sessionMap，这个对象是singleton方式的，全局只有一个。

初步估量

我们从图形一和图形二中可以看出，每天应用服务器损失大约40%的内存，大约1G左右。

从图形四可以看出，当前用户（Id=24400001129）有807个菜单项（每个菜单项为一个MenuNode 对象实例，图形四中的这个实例的size为592 Byte），这些菜单数据和用户基本登录信息（czrydmInfo HashMap）也都存放在WHsessionAttrVO对象中，当前这个WHsessionAttrVO对象的size为457K。

我们做如下估算：

假设平均每天有4千人（估计值，这个数值仅仅是5月19日峰值的1/2左右）登录系统（有重复登录的现象，例如：上午登录一次，中午退出系统，下午登录一次），以平均每人占用200K（估计值，是用户id=24400001129 的Size的1/2左右）来计算，一天泄漏的内存约800M，比较符合目前内存泄漏的情况。当然，这种估计仍然需要经过实践的检验，方法是：当这次发现的内存泄漏问题解决后看系统是否还有其它内存泄漏问题。

方案

ExternalSessionManager类是当初某某软件商设计的用来解决Web服务器负载均衡的模块，这个类主要用来保存客户的基本登录信息（包括会话的EJBSessionId），以维护多个Web服务器之间的会话信息一致。

改进方案有两种：

• 从架构设计方面改进

  实现Web层的负载均衡有很多标准的实现方式。例如：采用负载均衡设备(硬件或软件)来实现。

  如果采用新的Web层的负载均衡方式，那么就可以去掉ExternalSessionManager这个类了。

• 从应用实现方面改进

  保留当前的Web层的负载均衡设计机制，仅仅从应用实现方面解决内存泄漏问题，首先菜单信息不应该保存在ExternalSessionManager中。其次，增加对ExternalSessionManager类中用户会话登录信息的清除，有几种方式可以选择：

  • 被动方式，当HttpSession会话超时（或过期）被Web应用服务器回收时清除相应的ExternalSessionManager中的过期会话登录信息。
  • 主动方式，可以采用任务定时清理每天的过期会话登录信息或线程轮询清理。
  • 采用新的会话登录信息存储方式，ExternalSessionManager的sessionMap中的key值不再以EJBSessionId作为键值，而是以用户id（EJBSessionId的前11位）代替。由于用户id每天都是一样的，所以不会造成内存泄漏。保存得登录信息也不再包含菜单节点信息，而只是登录基本信息。最多也只是保存整个系统所有的用户id及其基本登录信息（大约每个用户的登录信息只有1.5K左右，而目前这个系统的营业网点用户为1万左右，所以大约只占用Web服务器15M内存）。

实施情况

采用的方案：某某软件商采用了新的会话登录信息存贮方案，即:ExternalSessionManager的成员变量sessionMap中不再保存用户菜单信息，只保存基本的登录信息；存储方式采用用户id（11位）作为键值（key）来保留用户基本登录信息。

基本分析：由于基本登录信息只有1K左右，而目前内网登录的用户总数也只有8887个，所以只保存了大约10M-15M的信息在内存，占用量很小，并且不会有内存泄漏。用户菜单信息保存在session中，如果用户退出时点击logout页面，那么应用服务器可以很快地释放这部分内存；如果用户直接关闭窗口，那么保存在session中的菜单信息只有等会话超时后才会由系统清除并回收内存。

监控状况：

图九

如图九所示，ExternalSessionManager中只保留了简单的登录信息（Map中保存了WHsessionAttrVO对象），包括：当前版本(currentversion)，操作人员代码基本信息（czrydmInfo），当前时间（currenttime）。

图十

如图十所示，这个登录用户的基本信息只有1368 bytes，大约1.3K

图十一

如图十一所示，一共有两个用户（相同的用户id）登录系统，当一个用户使用logout页面退出时，保留在session中的菜单信息(MenuNode)立刻释放了，所以Difference一栏减少了806个菜单项。

图十二

如图十二所示，当另外一个会话超时后，应用服务器回收了整个会话的菜单信息（MenuNode），图上已经没有MenuNode对象了。并且由于是同一个用户登录，所以保留在ExternalSessionManager成员变量sessionMap中的对象WHsessionAttrVO只有一个(id=24400001129)，而没有产生多个，没有因为多次登录而产生多个对象的后果，避免了内存泄漏问题的出现，解决了前期定位的内存泄漏问题。

图十三

如图十三所示，经过gc内存回收后，发现内存回收比较稳定，基本都回收到了最低点，也证明了内存没有泄露。

结论与建议：从测试情况看，解决了前期定位的内存泄漏问题。

生产系统实施后的监控与分析

经过调优后，我们发现：在2005年6月2日晚9点40左右重新部署、启动了Web应用服务器（采用了新的调优方案）。经过几天的监控运行，发现Web应用服务器目前运行基本稳定，目前没有出现新的内存泄漏问题，下列图示说明了这一点

图十四 2005年6月2日

如图十四所示，6月2日晚21.7（21点42分）重新启动应用服务器，内存占用很少，大约为15%（请看红色曲线），每次GC消耗的时间也很短，大约在5秒以内（请看黄色曲线）。

图十五 2005年6月3日周五

如图十五所示，在6月3日周五的整个工作日内，内存的回收基本到位，回收位置控制在20%-30%之间，也就是在600M-900M之间（请看红色曲线的最低点），始终可以回收2G的内存供应用程序使用，每次GC的时间最高不超过20秒，Full GC平均在10秒左右，时间消耗比较短（请看黄色曲线）。

图十六2005年6月5日周日

如图十六所示，在周日休息日期间，Web应用服务器全天只做了大约4次Full GC（黄色曲线中的小山峰），时间都在10秒以内；大的Full GC后，内存只占用10%，内存回收很彻底。

图十七 2005年6月6日周一

如图十七所示，在周一工作日期间，内存回收还是不错的，基本可以回收到30%（见红色曲线的最低点），即：占用900M内存空间，剩余2G的内存空间；Full GC的时间大部分控制在20秒以内，平均15秒（见黄色曲线）。

图十八 2005年6月7日周二

如图十八所示，在6月7日周二早上，大约8:30左右，Web应用服务器作了一次Full GC，用了10秒的时间，把内存回收到了10%的位置，为后续的使用腾出了90%的内存空间。内存回收仍然比较彻底，说明基本没有内存泄漏问题。

经过这几天的监控分析，我们可以看出：

• Web应用服务器的内存使用已经比较合理，内存在工作日的占用在20%至30%之间，约1G的内存占用，有2G的内存空间富裕；而在空闲时间（周日，每天的凌晨等）内存可以回收到10%，有90%的内存空间富裕；
• Web应用服务器的Full GC的次数明显减少了并且每次Full GC占用的时间也很少，基本控制在10-20秒之间，有的甚至在10秒以内，明显改善了内网应用服务器内存的使用；
• 从6月2日重新部署之后，Web应用服务器没有出现宕机重启的现象。

总结

 通过本文，我们可以看到，内存的泄露将会导致服务器的宕机，系统性能就更别说了。对于系统内存泄露问题应该从服务器GC日志方面进行早诊断，使用工具早确认并提出解决方案，排除内存泄露问题，提高系统性能，以规避项目风险。

本文转自：http://yufeimen.javaeye.com/blog/70721

时间： 2006/01/05

1、摘要..........................................................................1
2、改善服务器的性能...........................................................1
3、分析器原理...................................................................2
4、JProfiler 简介...............................................................2
5、JProfiler 特征...............................................................3
6、本地监控.....................................................................4
7、远程监控.....................................................................7
8、参考..........................................................................9

1 、 摘要

       改善 Java 服务器的性能需要模拟负载下的服务器。创建一个模拟环境、搜集数据并且分析结果可能是对许多开发人员的挑战。这篇文章介绍了使用 JProfiler 跟踪分析 Java 服务器的性能。

简单的性能问题很容易分离并解决，然而，大的性能问题，如内存溢出或者系统的罢工，通常在系统处于高负载情况下发生，就不能这么简单的处理了。这些问题需要一个独立的测试环境、一个模拟的负载，并且需要仔细地分析和跟踪。

在这篇文章中，我使用比较通用的工具（ JProfiler 和 JBuilder ）和设备创建了一个性能监控分析环境，跟踪本地和远程的服务器程序，专注于三个性能问题：内存、垃圾回收和多线程运行状况，从而很好的监视 JVM 运行情况及其性能。

2 、改善服务器的性能

服务器的性能改善是依赖于数据的。没有可靠的数据基础而更改应用或环境会导致更差的结果。分析器提供有用的 Java 服务器应用信息，但由于从单用户负载下的数据与多用户负载下得到的数据是完全不同的，这导致分析器的数据并不精确。在开发阶段使用分析器来优化应用的性能是一个好的方式，但在高负载下的应用分析可以取到更好的效果。

在负载下分析服务器应用的性能需要一些基本的元素：

1、  可控的进行应用负载测试的环境。

2、  可控的人造负载使得应用满负荷运行。

3、  来自监视器、应用和负载测试工具自身的数据搜集。

4、  性能改变的跟踪。

不要低估最后一个需求（性能跟踪）的重要性因为如果不能跟踪性能你就不能实际的管理项目。性能上 10-20% 的改善对单用户环境来说并没有什么不同，但对支持人员来说就不一样了。 20% 的改善是非常大的，而且通过跟踪性能的改善，你可以提供重要的反馈和持续跟踪。

虽然性能跟踪很重要，但有时为了使后续的测试更加精确而不得不抛弃先前的测试结果。在性能测试中，改善负载测试的精确性可能需要修改模拟环境，而这些变化是必须的，通过变化前后的负载测试你可以观察到其中的转变。

3 、 分析器原理

现在几乎所有的分析器都是从同一个起点和约束开始的： Java 虚拟机分析器界面 (JVMPI) ( 参考 "The Java Virtual Machine Profiler Interface") 。 Sun 微系统的 API 允许工具开发商接口或者连接到遵循 JVMPI 的 JVM 上，并且监控运作的方式以及 JVM 运行任何 Java 程序时的关键事件 -- 从单独的应用程序到 Applet 、 Servlet 和企业 JavaBeans (EJB) 组件。

在分析器内启动一个程序意味着生成、捕捉、和观察大量数据，所以所有的分析器都包含着不同的方法来控制数据的流动，在不同的标准以及每一封装包的基础上进行过滤。同样 也可以使用灵活的正规表达式类型模式来完成。

4 、 JProfiler 简介

是一个全功能的 Java 剖析工具（ profiler ），专用于分析 J2SE 和 J2EE 应用程序。它把 CPU 、执行绪和内存的剖析组合在一个强大的 应用中。 JProfiler 可提供许多 IDE 整合和应用服务器整合用途。 JProfiler 直觉式的 GUI 让你可以找到效能瓶颈、抓出内存漏失 (memory leaks) 、并解决执行绪的问题。它让你得以对 heap walker 作资源回收器的 root analysis ，可以轻易找出内存溢出； heap 快照（ snapshot ）模式让未被参照（ reference ）的对象、稍微被参照的对象、或在终结（ finalization ）队列的对象 都会被移除；整合精灵以便剖析浏览器的 Java 外挂功能。

目前最新的版本是 4.1.2 ，几乎支持所有常用的 IDE 和 Application Server ，可以到其 EJ 官方网站 http://www.ej-technologies.com/ 下载，申请一个十天的试用注册码。

5 、 JProfiler 特征

5.1 内存剖析 Memory profiler

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

• 所有对象
  显示类或在状况统计和尺码信息堆上所有对象的包。你可以标记当前值并显示差异值。
• 记录对象 Record objects
  显示类或所有已记录对象的包。你可以标记出当前值并且显示差异值。
• 分配访问树 Allocation call tree
  显示一棵请求树或者方法、类、包或对已选择类有带注释的分配信息的J2EE组件。
• 分配热点 Allocation hot spots
  显示一个列表，包括方法、类、包或分配已选类的J2EE组件。你可以标注当前值并且显示差异值。对于每个热点都可以显示它的跟踪记录树。

5.2 堆遍历 Heap walker

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

• 类 Classes
  显示所有类和它们的实例。
• 分配 Allocations
  为所有记录对象显示分配树和分配热点。
• 索引 References
  为单个对象和“显示到垃圾回收根目录的路径”提供索引图的显示功能。还能提供合并输入视图和输出视图的功能。
• 数据 Data
  为单个对象显示实例和类数据。
• 时间 Time
  显示一个对已记录对象的解决时间的柱状图。

5.3 CPU 剖析 CPU profiler

JProfiler 提供不同的方法来记录访问树以优化性能和细节。线程或者线程组以及线程状况可以被所有的视图选择。所有的视图都可以聚集到方法、类、包或J2EE组件等不同层上。CPU视图部分包括：

• 访问树 Call tree
  显示一个积累的自顶向下的树,树中包含所有在JVM中已记录的访问队列。JDBC,JMS和JNDI服务请求都被注释在请求树中。请求树可以根据Servlet和JSP对URL的不同需要进行拆分。
• 热点 Hot spots
  显示消耗时间最多的方法的列表。对每个热点都能够显示回溯树。该热点可以按照方法请求，JDBC，JMS和JNDI服务请求以及按照URL请求来进行计算。
• 访问图 Call graph
  显示一个从已选方法、类、包或J2EE组件开始的访问队列的图。

5.4 线程剖析 Thread profiler

对线程剖析，JProfiler提供以下视图:

• 线程历史 Thread history
  显示一个与线程活动和线程状态在一起的活动时间表。
• 线程监控 Thread monitor
  显示一个列表，包括所有的活动线程以及它们目前的活动状况。
• 死锁探测图表 Deadlock Detection
  显示一个包含了所有在JVM里的死锁图表。
• 目前使用的监测器 Current monitor useage
  显示目前使用的监测器并且包括它们的关联线程。
• 历史检测记录 History usage history
  显示重大的等待事件和阻塞事件的历史记录。
• 监测使用状态 Monitor usage statistics
  显示分组监测，线程和监测类的统计监测数据。

5.5 VM 遥感勘测技术 VM telemetry

观察JVM的内部状态，JProfiler提供了不同的遥感勘测视图，如下所示:

• 堆 Heap
  显示一个堆的使用状况和堆尺寸大小活动时间表。
• 记录的对象 Recorded objects
  显示一张关于活动对象与数组的图表的活动时间表。
• 垃圾回收 Garbage collector
  显示一张关于垃圾回收活动的活动时间表。
• 类 Classes
  显示一个与已装载类的图表的活动时间表。
• 线程 Threads
  显示一个与动态线程图表的活动时间表。

6 、 本地监控

系统环境 Windows OS ；软件 JBuilderX/2005 和 JProfiler 4.1.2

1 、安装 JBuilderX 和 JProfiler 4.1.2

2 、运行 JProfiler ， Session-> IDE integration tab, IDE 选择Borland JBuilder7 to 2005，点击Integrate按钮，选择JBuilder的安装目录，确认，会看到已经将JProfiler以OpenTool的形式，成功整合到JBuilder中，见下图。

3 、运行 JBuilder ，打开 Run->Configurations ，选择或新建一个 Runtime ，在 Optimize 选项中就可以看到 JProfiler ，可以选择每次运行程序新建一个 JProfiler 窗口的提示设置。

4 、点击 Optimize Project 按钮，运行程序。

5 、弹出如下的 JProfiler 窗口，确认相关的信息即可。

6 、至此，就可以监控本地服务器的各个方面的性能了。

7 、 远程监控

服务器程序一般运行在远程的服务器设备上，有时候我们还需要远程监控商用的服务器资源。

服务器操作系统 Linux OS ，安装步骤如下：
1、./jprofiler_linux_4_1_2.sh，出现如下提示：
testing JVM in /usr/jdk1.4 ...
Starting Installer ...
注：对于没有安装X Server的机器，需要执行./jprofiler_linux_4_1_2.sh -q，否则会提示，
testing JVM in /usr/jdk1.4 ...
Starting Installer ...
This installer needs access to an X Server.
If this is not possible, you can run the installer in unattended mode
by passing the argument -q to the installer.
2、安装完毕后，会在/opt目录下，找到jprofiler的安装目录，/opt/jprofiler4。

本地操作系统 WindowXP ，相关的配置如下：

1 、本地安装 JProfiler ， Linux 服务器上也安装 JProfiler （只有本地 / 监控者的需要输入序列号）。

2 、打开本地的 JProfiler ， session->Integration wizards-> New Remote integration

3 、选择 on a remote computer ， platform 选择 linux x86/AMD64 ，点击 next

4 、输入远程 ip 地址，点击 next

5 、输入远程 JProfiler 的安装目录，默认都安装在 /opt/jprofiler4 下，一路NEXT

6 、出现下面提示框，按照要求配置下服务器的设置，界面如下：

Java 执行语句中加入下列运行参数

 -Xint -Xrunjprofiler:port=8849 -Xbootclasspath/a:/opt/jprofiler4/bin/agent.jar ；

/etc/profile 中加入 export LD_LIBRARY_PATH=/opt/jprofiler4/bin/linux-x86 ，退出、重新登陆。

7 、好了，全部配置完毕，先运行远程服务器程序，再打开本地的 JProfiler 程序，握手成功后，远程程序正常运行了。

服务器信息如下：

[root@ns 55556]# tail -f nohup.out

JProfiler> Protocol version 21

JProfiler> Using JVMPI

JProfiler> 32-bit library

JProfiler> Listening on port: 8849.

JProfiler> Native library initialized

JProfiler> Waiting for a connection from the JProfiler GUI ...

// 以上为本地 JProfiler 连上前的系统提示

JProfiler> Using dynamic instrumentation

JProfiler> Time measurement: elapsed time

JProfiler> CPU profiling enabled

JProfiler> Starting org/anymobile/server/cmwap/CmwapServer ...

2005/12/15 17:05:46 [ INFO] - Starting Cmwap Stand Server ...
2005/12/15 17:05:47 [ INFO] - HandleThread runing ......

8 、补充说明及参考

8.1 补充说明

如果你希望动态保存当前 Session 的运行数据的快照，点击 JProfiler 的保存按钮即可；

可以通过 JProfiler Start Center 的 Open snapshot tab 打开保存的 Session ；

你也可以右键点击某个视图，静态保存到 HTML 文件，文字描述加视图图片；

有一些视图的数据只会运行一次，不会动态的刷新，如内存视图中的分配访问树等视图；

WinXP 下 JProfiler 似乎不支持中文， 2K 下支持的，上面有一些图片是在 2K 系统上截取的；

另外， JProfiler 还可以监控某个 Application Server 、 Applet ，功能非常强大，可以参考软件自带的 Help 。

一 介绍

        在Java的广泛应用中，一个关键驱动因素是由于使用标准类库和应用框架从而提高了生产效率。通过减少必要的设计，实现和调试等软件开发任务，Java在各种平台之间极大地改善了集成性和互操作性；其它的开发环境都不能提供象Java那样的强大功能。实际上，没有一个环境象J2EE那样具有明显的基于框架开发的优点，J2EE能够快速地构建可扩展，分布式的安全企业级应用。

        虽然这些优点一直在促进J2EE的空前发展，但也经常出现一些麻烦，那就是人们经常对J2EE应用的性能感到失望。因此，我们需要一些工具和调查策略来帮助J2EE开发团队解决这些性能问题。这就是Quest JProbe Profiler和Jprobe Memory Debugger所要解决的问题。

1.1 J2EE性能概揽

        一般情况下，最终用户对J2EE应用性能的体验与下面层次是紧密相关的:

JProbe Coverage-通过提供的语句级执行信息验证测试框架的完整性。

        虽然本文集中讨论了JProbe Memory Debugger和Profiler，但所有四个工具都采用了相同的体系结构设计，并且与BEA WebLogic服务器的集成方法是相同的。

 

2.1.1 JProbe的体系结构

 

        一个基于JProbe的调查会话由两个程序组成:

                                                图2 JProbe体系结构

 

        JProbe控制台是一个基于Swing的Java应用，它提供了用户图形界面（GUI），用于建立调查会话，在程序运行时查看分析信息和深入分析Snapshot文件中的信息内容。

        测试型Java虚拟机-JProbe通过JVMPI(Java Virtual Machine Profiling Interface)提供的回调方法，使用标准的Java虚拟机运行Java应用并收集分析信息，该虚拟机是由厂商提供的。在剖析基于WLS的J2EE应用中，Java应用运行在Java虚拟机中，该虚拟机由WebLogic服务器的基本框架组成，就象J2EE应用部署到上面一样。

        这种结构具有非常灵活的启动方式。你可以从用户图形界面本身启动测试型Java虚拟机，也可以单独启动测试型Java虚拟机并且使它连接上JProbe控制台。

 

2.2 使用JProbe Application Server Integration Tool

 

        1. 启动JProbe Application Server Integration。

        2. 从左上角下拉列表中选择你要集成的BEA Weblogic服务器版本。

        3. 点击"Create"按钮。编辑窗口右边的内容，如图3所示。

        4. 编辑下面区域或使用默认值。

Integration ID:	JProbe Demo 1	Integration ID ，便于重用每次集成过程
Server Directory:	D:\bea\wlserver6.1	直接输入 WLS 服务器根路径或者通过 " 浏览 " 方式输入。
Domain Name:	Mydomain	输入你想分析的域名。
Startup Script:	StartWeblogic.cmd	直接输入要调查的服务器的启动脚本或者通过 " 浏览 " 方式输入。
JProbe Settings: (JPL File)	check the VAR checkbox	集成工具允许你使用先前创建的 JPL(JProbe Launchpad) 文件。 如果要使用由每个工具在启动时默认创建的 JPL 文件，选择 VAR 复选框。
Java Executable:	d:\sun\jdk1.3.1\bin\Java.exe	可直接输入或通过浏览方式输入 Java 虚拟机的执行文件路径。

 

         5. 点击"Advanced>>"按钮。

        6. 填写下面这区域。

Java Options:

-classic -mx128m -ms64m

有选择地给 Java 虚拟机输入参数。

 

         7. 点击"Save"按钮。

                         图 4 ． JProbe Application Server Intergation 窗口

        你已经成功创建和BEA Weblogic6.1的集成， 所有四个工具都可以使用这个集成过程。

        8. 点击"Close"按钮。

 

3. 识别J2EE应用性能下降

 

        JProbe Memory Debugger能帮助你追踪到游离对象（loitering objects）和减少创建过多的对象，并且JProbe Profiler能帮助你发现性能瓶颈。根据具体情况，需要具体分析。在这里，我们简单地概括用于解决对象循环和性能瓶颈这两个常见问题的步骤。更多的信息和其它使用JProbe Memory Debugger和Jprobe Profiler的方法，可以参考在线帮助或者阅读JProbe Memory Debugger Guide和JProbe Profiler Developer's Guide。

 

3.1 对象循环（Object Cycling）

 

        Java应用性能下降的一个主要原因是创建过多的对象 (或称为对象循环)。Java虚拟机分配了过多的内存，创建了不必要的对象并对这些对象的初始化，加大了垃圾回收活动，从而引起性能下降。

        作为一个性能分析人员，你首先需要识别出创建大量短期对象的方法。这些方法是进一步做减少创建对象数量分析的理想入手点。。JProbe Memory Debugger提供的一个垃圾监视功能可以把对象和分配它们的方法连接起来，并且当你的应用运行时，可以追踪有多少对象已经被垃圾回收了。

 

3.1.1 启动JProbe Memory Debugger的研究会话

 

        1. 启动JProbe Memory Debugger。当欢迎界面出现的时候，点击"Run"开始启动。

                         图 5 ． JProbe 欢迎界面

        2. 在JProbe LaunchPad窗口中:

                        a． 选择"Using Application Server"

                        b． 从"Application Server"下拉的菜单中选择BEA Weblogic6.1

                        c． 注意在"Integration ID"下拉的菜单中填写JProbe Demo 1

        3. 选择"Filter"

                        a． 点击"Please enter a package，or method to display data for"。输入你要调查的包:profiler.com.quoteme.stockwatch

                        b． 在"Display"栏的下拉菜单里选择"Display"

        4. 选中"Monitor Garbage Collections from Program Start"复选框。

        5. 选择"Snapshot Directory:"为d:\temp。

        6. 点击"Run"按钮。

                        图7．JProbe LaunchPad Pad窗口

        当WebLogic Server初始化时，Runtime Heap Graph将增高，这反映了对象创建和垃圾回收活动。一旦WebLogic Server已经被充分初始化后，你就可以开始着手分析了。

 

3.1.2 运行时交互

 

        一旦WebLogic Server已经充分初始化，选择你想要用于分析对象循环的应用用例。选择Grabage Monitor标签，按下面的步骤:

        1. 首先运行一次Garbage Collection ，回收在Java堆中分配的，但不再使用的对象。Garbage Monitor表随时更新反映这些被回收对象的情况。

        2. 点击"Clear Table"清空Garbage Monitor表。

        3. 运行你的应用用例。当Java虚拟机开始垃圾回收时，Grabage Monitor表将随之更新。

        提示:在Heap Usage Chart中寻找负载峰值。急剧升降的负载峰值意味着一些对象在被垃圾回收之前只存活了很短的时间。连在一起的一些急剧升降的负载峰值是一个明确的信号，意味着是一个对象循环问题。

        4. 在完成你应用用例后，再次运行Garbage Collection ，回收最后分配但不再使用的对象。

 

3.1.3 分析结果

 

        当会话结束时，Garbage Monitor中包含了已回收最多实例的前十个类。通常，这些类不是你自己应用的类，准确地说，它们是被你的一些方法(直接地或间接地)分配的第三方的类。最后一列是分配这些已回收对象的方法名。

        提示:如果被不同方法分配的实例属于同一个类，并且都是前十个类的话，你将见到两行相同的类。

        1. 使用Filter Allocating Methods，只显示你包中的一些方法，屏蔽掉其它包中的方法。在我们的例子中，客户J2EE应用定义在profiler.com.quoteme.stockwatch包里面，所以我们把过滤规范profiler.com.quoteme.stockwatch.*.*输入到Filter Allocating Methods文本输入控制中。

        2. 在GC'ed列中，你能看到你的方法分配了多少实例。作为比较，查看Alive列就能看到还有多少实例仍在堆中。Java开发者通常会对创建和移走了多少对象而感到惊奇。

3. 现在你已经识别到你有问题的方法。想想你可能怎样修改这些分配对象的方法，从而减少或排除对象循环？例如，你可以尝试重用某个对象或者创建一个可重用的对象池。

        4. WebLogic Server6.1编译JSP后，自动产生了一个servlet类名，并赋予一个包名和类名。例如，如果有一个名为TestJSP.jsp的JSP文件，将被编译成名为jsp_servlet.__testjsp的类(JSP名跟着两个下划线，并且都是小写字母)。

        用Filtering Classes为jsp_servlet.*限制Garbage Monitor中的内容，可以看到已经被垃圾回收到Garbage Monitor中的JSP。在Filtering Allocating Methods设置jsp_servlet.*.*或jsp_servlet._<你的JSP名>.* 限制Garbage Monitor中的内容，可以从分配的角度在指定的JSP中查看垃圾回收对象。

        更深入的研究

        如果你分配的方法没有一个出现在Garbage Monitor中，或者在修改明显的问题后，仍然有对象循环的问题；你需要进行堆栈跟踪，检查哪个方法的调用导致了创建实例并分配了空间。需要使用heap snapshot查看堆栈跟踪。要了解更多的信息，请看在线帮助里的Garbage Collection Tutorial或者JProbe Memory Debugger Developer's Guide。

3.2 性能分析           解决对象循环问题有助于性能的改进，但你可能仍然面临着性能瓶颈。进行一次性能分析可帮助你在J2EE应用中识别低效率的算法。JProbe Profiler提供了应用的方法级和源代码行级度量值。   3.2.1 启动JProbe Profiler调查会话。                   1. 启动JProbe Profiler。当欢迎界面出现时，点击"Run"开始。                 图9。JProbe欢迎窗口         2. 在JProbe LaunchPad窗口中:                 a. 选择"Using Application Server"                 b. 从Application Server下拉菜单中选择BEA Weblogic6.1                 c. 注意在Integration ID下拉菜单中填JProbe Demo 1"         4. 选择Filter                 a. 点击Please enter a package，class，or method to display data for。输入你要调查的包profiler.com.quoteme.stockwatch                 d. 从Detail Level列的下拉菜单中选择Line Lever                 这个元素定义了我们想要把所有运行在环境中的Java软件看作基础结构。因为我们不想详细了解它们的性能信息 (我们只是想知道在代码上的影响，我们不想更细地分析) 提示:在WLS6.1中的JSP Profiling                 当JSP被WebLogic Server6.1编译时，产生的servlet被给予一个产生的包和类名。例如，如果有一个名为TestJSP.jsp的JSP文件，它被编译后，生成名为jsp_servlet._testjsp的类(两个底线被JSP名跟着，都是小写字母)。 如果你想跟踪你的JSP里的方法在执行中花了多少时间，你必须指定正确的过滤策略，用于捕获数据。         5. 选择"CPU Time"         6. 选择"Record Performance at Program Start"复选框         7. 选择"a Snapshot Directory:"为d:\temp         8. 点击"Run"按钮                 图11。 JProbe Profiler LaunchPad窗口 3.2.2 运行时交互             在性能分析中，Heap Usage Chart就象一个执行进度的监视器，与上节介绍的Garbage Monitor不同，这里不提供类似的运行时性能信息。使WebLogic Server自己初始化到完全启动。         作为对象循环分析，我们推荐使用应用级的，以用例为中心的方法进行性能分析，具体如下:         1. 清空累积的性能数据。         2. 运行你的应用用例。         3. 执行一次性能快照，保存性能信息。         性能快照包括时间和在用例运行期间对象创建等度量数据(这个运行期间从重新设置性能信息开始-第一步，一直到执行快照结束，第三步)。   3.2.3 解释结果           JProbe Profiler提供两个工具，以不同的格式显示收集到的数据；可根据具体情况选择: Method List是指以表的形式显示与方法有关的数据信息。使用Method List可以按照名称或度量值排序，或显示只显示其中部分方法。 Call Graph--是指以有向图的形式显示方法。可以使用Call Graph查看并跟踪程序中方法间的调用关系。          从Method List或Call Graph中，你能使用下面这些工具深入到更多的细节数据。 Method Detail View是指对于所选的方法，显示它们是被哪些方法(也称父方法)调用了或它们调用了哪些方法(也称子方法)。 Source Window显示所选方法的语句级性能信息。     3.2.3.1 Time and Object Creation Metrics           JProbe Profiler在方法方面收集了三个基本度量值: Number of Calls是指在会话期间该方法被调用的次数 Method Time是指执行该方法所花费的总时间         Method Objects是指该方法创建的对象总数         在这些基本的度量值基础上，JProbe Profiler计算出两种度量值表示方法调用树: Cumulative Time是指执行这些方法的时间，和执行它们直接或间接调用的方法所花费时间的总和。 Cumulative Objects是指这些方法创建的对象，和这些方法直接或间接调用其它方法创建的对象的总合         基于Number of Calls用四种平均度量值: Avg.Method Time是指调用方法的时间除以调用次数 Avg.Method Objects是指方法对象除以调用次数（方法对象指方法执行期间创建的对象数，不包括派生对象创建的数） Avg.Cumulative Time是指累积时间除以调用次数 Avg.Cumulative Objects是指累积对象除以调用次数         在默认情况下，Call Graph显示的数据是在性能快照中的数据。我们建议你关闭Call Graph一会再打开Method List窗口。   3.2.3.2 Method List           Method List窗口(见图12)以表的形式显示性能数据。                 图12。JProbe Profiler Method List窗口         每一行显示了方法的时间和方法创建对象的度量值。使用Method List能很快识别你最耗时的方法。通常你会发现你的性能瓶颈和这些方法有关。         如果你是第一次调查，跟着下面这些步骤将使你能更有效地使用Method List。         1. 选中你的snapshot，打开"Method List"。         2. "Filter"区域只用于显示在你包中或在你感兴趣的类中的方法。         3. 点击"Method Time"列名，把你最消耗时间的方法排在最前面。仔细查看前十个。是不是有一些度量值令你惊讶?你能改进你方法中的算法吗?         4. 点击"Cumulative Time"列名，把最消耗时间的调用树排在最前面。比较一下"Method Time"和"Cumulative Time"。虽然方法本身可能效率很高，但也可能调用了低效率的方法，这些低效率的方法可能在你的代码中，或者在第三方的包或应用框架中。         5. 点击"Number of Calls"列名，查看一下你哪个方法被调用最多。如果一个或多个度量值同时反映这些方法是低效率的，需要考虑减少调用这些方法，或调用那些效率稍好的方法。   3.2.3.3. Call Graph           Call Graph(见图13)提供一个非常有力的方法调用关系视图。它把J2EE应用放到WebLogic Server上下文环境中，所以你能看到WebLogic启动的所有线程，包括调用J2EE应用的线程。为了方便查找，Call Graph下面有"Method List"。         当分析性能时，在定位J2EE应用的入口点和排除与WebLogic线程有关的数据方面， Call Method是最有效的。在分离出应用的数据基础上，可快速画出执行流程，并用图形清晰地显示出来。         下面是使用Call Method的有效技巧:         1. 选中你的snapshot，打开"Call Graph"。         2. 点击"Find"并且定位你的J2EE应用的入口位置。通常是servlet中的doGet()或doPost()方法。         3. 选择方法并分离出数据形成图形。         4. 显示方法的一个子集作为开始，这些方法按照"Cumulative Time"排序是最耗时的方法。当你分析一个方法，在方法的调用树上将增加额外的节点。         5. 在"Method List"中，根据你发现的瓶颈位置，在"Color By"的下拉列表中选择相同度量值。根据你选择的度量值，现在最耗时的方法都以鲜艳的颜色突出显示出来。         6. 选择最耗时的方法。展开父方法树(通过点击节点部分或节点左边部分的空箭头记号)，就能看到哪个方法调用它了。你可以调用不同的，耗时比较少的方法吗?你需要经常调用这些方法吗?         7. 展开子方法树(指向节点的右边)，可以看到调用了哪个耗时的方法。还有哪些子方法也是耗时的呢?你意识到第三方的方法实际的耗时情况吗?你能调用一个实现了更有效率算法的不同方法吗?                 图13。JProbe Profiler Call Graph窗口         从Method List或Call Graph中，你都能深入地分析，在一个视图中很方便地看到耗时的方法的度量值，还有它们子方法和父方法的度量值。选择方法并打开"Method Detail View"。         "Method Detail View"(见图14)在窗口的中心显示了选择方法，它的父方法在上面，它的子方法在下面。我们对列的头部已经熟悉了，它们和你在其它工具中看到的度量值相同。一个重要的区别是：用于显示父方法和子方法度量值表示对所选方法的贡献值，不是对它们自己的度量值。所以，如果一个方法被调用了12次，这些调用它的方法，和12次调用分别显示在父方法的图中。如果你想继续分析父方法或子方法，双击该方法，使该方法在"Method Detail View"的中心显示。                 图14 JProbe Profiler Method Detail窗口   3.2.3.5 Source Window           要查看你方法中的代码，选择方法并且打开Source Window。你需要指出你的源代码具体位置。         如果你是按行收集数据，你能在Source Window(见图15)中看到这些数据。在左列中，显示了每条语句的数据度量值。行级度量值是方法级度量值的细化，包括调用次数，执行该行的时间，执行该行时创建的对象数量，累积时间和累计对象数量。         提示:如果需要编辑你的代码，并且已经把集成开发环境IDE和JProbe Profiler集成在一起了，你可以通过选择Edit>Edit Source打开你的集成开发环境。当然，需要运行你重写的代码，并建立新的JProbe Profiler分析会话时，你做的改变才反映在JProbe Profiler上。                 图15 Jprobe Profiler Source Window

本文转自:http://tb.blog.csdn.net/TrackBack.aspx?PostId=599690