通过JProbe提高项目开发质量

 通过JProbe提高项目开发质量 之内存泄漏 收藏 http://blog.csdn.net/wst302/archive/2005/07/23/432799.aspx q

一.当前，J2EE的开发质量的问题已经越来越突出，“内存泄露”是目前Java应用中最为常见的问题之一，这里以Quest JProbe Suite 工具为例，说明在实际开发中应如何提高开发质量,解决“内存泄露”问题。
 
1.启动JProbe J2EE Integration。
2.从左上角下拉列表中选择你要集成的服务器版本，以tomcat为例子 。然后编辑右侧内容。
 
3.编辑下面区域或使用默认值 ，然后点击“save”按纽

 
3.编辑下面区域或使用默认值 ，然后点击“save”按纽
 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虚拟机的执行文件路径

3.编辑下面区域或使用默认值 ，然后点击“save”按纽

 
3.编辑下面区域或使用默认值 ，然后点击“save”按纽
 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虚拟机的执行文件路径

 
4.启动JProbe Memory Debugger的研究会话
a.选择session-New J2EE Settings
b.点击“Manage Configutions”,然后点击“Edit“，在“Application Deploy Directory”下选择项目的根目录。
 
5.在JProbe LaunchPad窗口中选择“Filter”
a.点击“Please enter a package，or method to display data for”。
     b.输入你要调查的包，然后在“Display”栏的下拉菜单里选择“Display”               c.选中"Monitor Garbage Collections from Program Start"复选框
 
5.在JProbe LaunchPad窗口中选择“Filter”
a.点击“Please enter a package，or method to display data for”。
b.输入你要调查的包，然后在“Display”栏的下拉菜单里选择“Display”              
c.选中"Monitor Garbage Collections from Program Start"复选框
 
7.当tomcat初始化时，Runtime Heap Graph将增高，这反映了对象创建和垃圾回收活动。一旦tomcat 已经被充分初始化后，就可以开始着手分析了。
a.首先点击“Start Use Case”,然后我们登陆系统。
b. Filter Classes域中填入要监控的类。
c.进行一些需要监控的操作，观察“Count Change”，即堆中各个类找一系列操作中的对象改变数。
d.点击“Finish Use Case”。
 
8.我们注意到BsFormField类的Count Change列显示为+65，这表示从开始运行用例到结束用例运行这段时间内，堆中增加了65个BsFormField对象，很可能就是内存泄漏的对象。
9.这部分我们将找到究竟是哪些存活对象还持有BsFormField游离实例的引用。打开Class View窗口查看snapshot中的数据，通过Instance Detail View可以更深入地看到BsFormField的细节信息，最后打开Source窗口我们将看到原来是BsFormDate仍然持有游离对象BsFormField 。
 
  a. 选中要分析的snapshot，点击”Class View”。打开的窗口显示了堆中的类。
     b. 选中BsFormFiled类并点击”Merged Allocation Points View” 。这样可以查看到该类在是由谁实例化的及个数。
 
c.右击BsFormDate.putForce(String,String)，选择”Allocate At Source”,弹出的窗口显示选中的putForce( )方法并定位到了分配BsFormFiled实例的代码行。至此，你看到了BsFormFiled是在什么地方被实例的。
 
c.找到代码行后，即说明在此方法中实例化的BsFormField对象在使用后未被置null，释放对象。
d.找到原因之后，我们在每次使用BsFormField后，手动置null,确保对象被释放。

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/wst302/archive/2005/07/23/432799.aspx