Java');" target="_self">Java语言相比C++的一个很大优势就是Java可以自动管理内存的回收，这大大减少了程序员的负担。然而，Java并不是杜绝了所有的内存问题，还是会有内存泄漏的问题，只不过原因和C++是不一样的，所以出现得比较少。Java的内存垃圾回收机制是从程序的主要运行对象开始检查引用链，当遍历一遍后发现没有被引用的孤立对象就作为垃圾回收。详细说明可以看ibm developerworks上的文章（http://www-900.ibm.com/developerworks/cn/java/j-leaks/index_eng.shtml）。在现在代码检查工具越来越先进的情况下，C++的内存漏洞检查已经变得容易很多，但Java的内存漏洞由于机制不一样，反而无法通过工具直接检查出来，只要靠辅助工具检测，发现疑点，然后再手动解决。

下面是我调试一个大型软件系统内存泄漏问题的过程，把其中失败的做法也写出来了，因为都是有参考价值的：

现象：程序启动后一直运行正常，但启动某个模块后，每分钟多消耗1M的内存，持续增长到出现java.lang.OutOfMemoryError为止，而CPU占用率也是逐步上升至100%。

判断：由于CPU和内存都出现问题，无法判断哪个是主因，也可能是多个原因造成的，估计最可能是多线程或者内存泄漏的问题。

辅助工具：由于不是我自己写的程序，所以没法直接估计是代码的哪一部分的问题，所以需要使用辅助工具，我比较常用的是Eclipse的插件ru.nlmk.eclipse.plugins.profiler（免费）和Borland公司的Borland Optimizeit Suite（收费）。因为我是用Eclipse来开发程序，所以使用前者比较方便，个人感觉使用时占用的系统资源少一点，而且在CPU检查方面是略强一点，但是后者在内存检查方面强大很多。

分析过程：当时由于CPU和内存都出现问题，无法判断哪个是主因，需要检测两方面的数据。内存泄漏需要等程序运行一段时间后才能看出来，所以检查很消耗时间。为了减少干扰，我把系统中所有不是必要的各线程逐个关闭来试验，然后把确认对内存问题没有影响的线程都关闭。

首先考虑解决内存问题。因为Java的内存泄漏问题往往跟HashMap相关，所以HashMap可能是一个突破口，而这么大量的内存泄漏，很可能会是某些HashMap存放过多已经没用的对象造成的（如果是这个原因，那改为用WeakHashMap就可以解决问题了）。我从HashMap和LinkedHashMap派生了子类，其中加入了数据量检查的信息，把系统中所有构造HashMap和LinkedHashMap的地方都改为使用这些子类。但是运行后发现系统中构造的HashMap只有十几个，而且每个指向的对象也不多，只有少数几个是接近1千的，而仔细检查代码后，发现这几个指向对象较多的HashMap也不会造成太大的内存泄漏问题。

这样我的思路就中断了，只好求助于工具来寻找疑点。因为发现CPU占用到100％一段时间后，程序就呈死机状态没法运行下去了，内存问题也就无从检测，所以就决定先检查CPU，用Eclipse的profiler插件来查。如图：

图1 Eclipse的profiler插件的Threads View

因为问题出在某个模块启动之后，所以这时先把统计功能关闭可以使结果更有意义（如果全部采样，初始化阶段的资源消耗对结果影响很大），也可以加快程序启动。等问题模块启动后，开始启动统计功能，此时点击Threads View中某个线程，在Thread method View中就会显示该线程中各调用的方法所运行的时间。

图2 点击Threads View中的某个Thread，Thread methods View中就会显示相关的内容

按Total time排序查看就可以找到哪些方法是占用CPU最多的。

图3 按Total time排序查看Thread methods的数据

但是当时我犯了非常严重的错误，以前在filter中把系统类(例如java.*、sun.*等等)过滤了，忘了取消，结果查出来的结果非常莫名其妙，最占用CPU的函数（达30％多）居然只有一个long型的赋值语句！这是在profiler的属性中设置的，如图：

图4 Eclipse的profiler插件的运行属性设置

后来想起有这个问题，把fliter重新设好，检测结果就正常了，不过没有什么有价值的线索，占用CPU较多的都是java系统包的方法（后来查出问题后回想才发现这里其实是有线索的）。于是就怀疑是内存快用光时JVM的内存管理模块会大量占用CPU，所以导致java程序的CPU占有率偏高（现在还不知道是否确实如此），另一方面，这些检测工具本身就大量消耗系统资源，也是导致CPU占用为100%的主要原因。于是，又改为用Borland Optimizeit Suite检查内存问题了。

先启动Optimizeit Suite中的profiler模块：

图5 启动Profiler模块

图6 在Profiler主界面中添加新Setting

注意使用Borland Optimizeit Suite时，jar中要把main class设好，classpath中要把所有用到的外部jar包全部输入，否则无法启动和正常运行。这个工具不太友好，无法启动时输出信息很不明确，所以最好自己先检查清楚了。

图7 在Profiler的Setting中设置main class和classpath

一般测试时都有运行多次，当发现某些包跟问题无关时，可以把它们过滤掉，这样最后得到的结果更容易阅读。

图8 设置filter

用Profiler启动程序。运行到问题模块后，点击工具栏最右边的按钮，标记当时各对象占用内存的情况。

图9 标记当前内存情况（图中红柱上的黑线）

点击工具栏上像感叹号的按钮，选择显示的内容。对这个问题，我觉得show size是最重要的。

图10 设置显示的内容

再运行一段时间后，按Size diff排序。发现占用内存比较多的了后，双击该行，打开该对象的详细信息（目前bug已经改好，我只是随便点一个类作为示范）。这时展开整棵树，就可以看到该类所有实例分别是在什么方法中生成的（如果跟踪CPU信息，也有这种资源分配树显示）。

图11 某个类的所有对象的构造位置分布

因为占用内存最多的往往是系统基本数据类型，例如char，int[]等等，所以需要人工去判断哪些类是真正的疑点。我发现占用新申请内存排名第20－30之间有几个类的对象数是完全相同的，而且持续同步增长，估计是某些线程中重复构造对象造成的，比其他以不规则速度增长的类更加可疑，于是就仔细检查了这几个的类的详细信息，发现果然是来自同一个函数。再仔细看代码，就找到内存泄漏的原因，原来是某行代码写错了，不断构造新的button。而保存这些button是用Vector！说明我最早使用的检查HashMap的思路是对的。可惜只是从自己的编程习惯出发，没有考虑到Vector，否则问题就更容易发现了。

不过当时还曾经检测到一个突变过程，至今没有想明白原因。在没有任何人对该计算机进行操作的情况下，CPU和内存占有率在某个时刻同时暴增。如图：

图12 CPU占用率突变

图13 内存占用突变

欢迎知道原因的朋友回复，:)