使用jprofiler性能优化20090512.doc

使用JProfiler监控程序运行情况Add by king 20090512我们在日常的开发过程中，难免遇到程序写得有漏洞的时候，比如数据库连接未释放啊，基于JMX,JMS的操作连接未释放啊，过多的对象创建啊，程序的性能 瓶颈啊等等，到了项目开发后期，常常会因为很早之前写得不太好得代码段而造成整个系统得运行效率下降，严重的则会造成系统崩溃。如何很好的解决这些隐藏得 问题呢？就要使用Jprofile工具对我们的系统进行从cpu，memory，thread方面的分析了。一、系统配置安装好Jprofile，操作过程如下：首先要破解jprofile，解压缩JProfiler 5.1.2 crack.zip，把其中的两个文件windows和windows-x64覆盖jprofiler5bin目录中的同名文件，然后在控制台中输入命令java Keygen，就可以取得序列号，例如: L-FLN#11360-19tzrht1k4u2z9#2010,把序列号，注意必须要在jdk1.5以上的环境才能获取序列号。下一步选择应用服务器点击finish就开始这样我们就可以看到jprofiler对我们的系统应用进行的实时的监控了，一般的最常用的要算是Memory View 和Thread View，其中都可以进行进行filter，这样，如果你看到某些对象一直在上升并得不到释放，或者某些线程在直线上升，你就应该大致的知道问题出在哪里了吧。二、主要功能简介1内存剖析 Memory profiler JProfiler 的内存视图部分可以提供动态的内存使用状况更新视图和显示关于内存分配状况信息的视图。所有的视图都有几个聚集层并且能够显示现有存在的对象和作为垃圾回收的对象。 所有对象 显示类或在状况统计和尺码信息堆上所有对象的包。你可以标记当前值并显示差异值。 记录对象 Record objects 显示类或所有已记录对象的包。你可以标记出当前值并且显示差异值。 分配访问树 Allocation call tree 显示一棵请求树或者方法、类、包或对已选择类有带注释的分配信息的J2EE组件。 分配热点 Allocation hot spots 显示一个列表，包括方法、类、包或分配已选类的J2EE组件。你可以标注当前值并且显示差异值。对于每个热点都可以显示它的跟踪记录树。 2堆遍历 Heap walker 在JProfiler的堆遍历器(Heap walker)中，你可以对堆的状况进行快照并且可以通过选择步骤下寻找感兴趣的对象。堆遍历器有五个视图： 类 Classes 显示所有类和它们的实例。 分配 Allocations 为所有记录对象显示分配树和分配热点。 索引 References 为单个对象和“显示到垃圾回收根目录的路径”提供索引图的显示功能。还能提供合并输入视图和输出视图的功能。 数据 Data 为单个对象显示实例和类数据。 时间 Time 显示一个对已记录对象的解决时间的柱状图。 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组件开始的访问队列的图。 4 线程剖析 Thread profiler ，如下图所示：对线程剖析，JProfiler提供以下视图: 线程历史 Thread history 显示一个与线程活动和线程状态在一起的活动时间表。 线程监控 Thread monitor 显示一个列表，包括所有的活动线程以及它们目前的活动状况。 死锁探测图表 Deadlock Detection 显示一个包含了所有在JVM里的死锁图表。 目前使用的监测器 Current monitor useage 显示目前使用的监测器并且包括它们的关联线程。 历史检测记录 History usage history 显示重大的等待事件和阻塞事件的历史记录。 监测使用状态 Monitor usage statistics 显示分组监测，线程和监测类的统计监测数据。 5VM 遥感勘测技术 VM telemetry 观察JVM的内部状态，JProfiler提供了不同的遥感勘测视图，如下所示: 堆 Heap 显示一个堆的使用状况和堆尺寸大小活动时间表。 记录的对象 Recorded objects 显示一张关于活动对象与数组的图表的活动时间表。 垃圾回收 Garbage collector 显示一张关于垃圾回收活动的活动时间表。 类 Classes 显示一个与已装载类的图表的活动时间表。 线程 Threads 显示一个与动态线程图表的活动时间表。三、实战Memory View应用内存长期占用并导致系统不稳定一般有两种可能： 1. 对象被大量创建而且被缓存，在旧的对象释放前又有大量新的对象被创建使得内存长期高位占用。 表现为：内存不断被消耗、在高位时也很难回归到低位，有大量的对象在不断的创建，经过很长时间后又被回收。例如：在HttpSession中保存了大量的分页查询数据，而HttpSession的会话超时时间设置过长（例如：1天），那么在旧的对象释放前又有大量新的对象在第二天产生。 2. 另一种情况就是内存泄漏问题 表现为：内存回收低位点不断升高（以每次内存回收的最低点连成一条直线，那么它是一条上升线）；内存回收的频率也越来越高，内存占用也越来越高，最终出现Out of Memory Exception的系统异常。 我们做了系统的内存泄漏的测试工作.操作步骤如下:1.Jprofiler打开系统.2.LR对系统进行压力测试,系统里的CLASS产生大量的对象3.Jprofiler中按F4进行垃圾回收4.哪个class没回收回去的当然就有问题存在了.实例如下如图所示，内存经过HttpSession超时后，并强制gc后，仍然有大量的对象没有释放。例如：m.security.MenuNode，仍然有807个实例没有释放。 我们继续追溯发现，这些MenuNode首先存放在一个ArrayList对象中，然后发现这个ArrayList对象又是存放在WHsessionAttrVO对象的Map中，WHsessionAttrVO 对象又是存放在ExternalSessionManager的staic Map中（名称为sessionMap），如下图所示。 我们发现m.WHsessionAttrVO中保存了EJBSessionId信息(登录用户的唯一标志，由用户id+登录时间戳组成，每天都不同)和一个HashMap，这个HashMap中的内容有： ArrayList: 内有MenuTreeNodes（菜单树节点） HashMap: 内有操作人员代码信息 CurrentVersion:当前版本号 CurrentTime:当前系统时间WHsessionAttrVO这个对象的最终存放在ExternalSessionManager的static Map sessionMap中，由于ExternalSessionManager是一个全局的单实例，不会释放，所以它的成员变量sessionMap中的数据也不会释放，而Map中的Key值为EJBSessionId，每天登录的用户EJBSessionId都不同，就造成了每天的登录信息（包括菜单信息）都保存在sessionMap中不会被释放，最终造成了内存的泄漏。四、使用心得1、JProfiler监控是要消耗系统资源的，所以一般情况下不要用于性能测试时候的监控。 2、如果要用于相对大压力情况下，可以有选择的打开监控项，不用所有都打开。主要有两个，一个是内存监控，打开的情况下可以查找内存分配热点。一个是CPU监控，打开的情况下可以查看CPU使用热点。 如图所示，红笔标注部分。如果两个都关闭的话，还是可以跑一定压力的，同时还可以监控对象数量。3、个人认为最好用的（也是用的最多的）是查询当前的对象的数量。数量监控很重要，如果你使用了单例，那么你只会看到有一个对象存在，如果多