通过JProbe提高项目开发质量 之内存泄漏

一.当前，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/Ja va.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/Ja va.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, 确保对象被释 放。