二、按应用程序导致内存泄漏诊断，JProfiler检测

    如果遇到OOM问题，我想大家都会想到内存检测工具，现在最可靠的还是下面三种分析工具：Borland 的Optimizeit Suite，Quest的JProbe，ej-technologies的JProfiler。但面临三个问题：
1、三个都是商业产品，公司暂时没有买，必须自己下载，而且要找序列号。
2、工具必须支持AIX5.3＋JDK1.42＋WAS6.0，不是Windows平台。
3、工具必须在客户真实环境下部署，对客户的业务不能有冲击，也就是说部署测试工具前，必须做个大量测试，对工具非常熟练，遇到意外可以立即恢复现场。
Note:项目上线后，而不是测试或试运行阶段遇到此类问题，非常考验人；另外一个，就是性能和可伸缩性问题，很可能把整个项目给毁了。

    当我决定要这么做后，就立即动手查阅这些工具的官方文档，用emule下载，最终都下载到了。试用后，最终选择了JProfiler4.03，比起其它工具，它界面美观、清晰、功能强大、集成度高(Heap,Memory,CPU,Thread都统一了)。另外，JProbe没有AIX版本，这也是放弃它的一个原因。

    JVM的Profiler原理，都是通过JVM内置的的标准C语言Profiler 接口收集数据，然后通过Profiler工具的客户端展现。也就是说各厂商的Profiler工具，都有两个部分，一个部分是Profiler Agent，和JVM绑定，负责收集JVM内部数据，譬如方法调用次数、耗费时间等；另外一个部分就是Profiler front-end。通过Profiler工具的自定义local或remote协议传输到front-end，其实，我们最常用的JavaIDE的debug功能就是在此基础上的（JPDA）。（JProfiler的截图http://www.ej-technologies.com/products/jprofiler/screenshots.html ）。
下面是Sun官方文档：
JDK1.42及以前是JVM PI：http://java.sun.com/j2se/1.4.2/docs/guide/jvmpi/jvmpi.html
JDK1.5是JVM TI：http://java.sun.com/j2se/1.5.0/docs/guide/jvmti/jvmti.html
具体到JProfiler的配置上，专门针对JDK1.4和1.5的JVM配置差别很大。

我用的JProfiler是4.31版本，透露给大家一个功能较多序列号吧(这东西不太好找)，对各版本应该都支持。深入了解Java，这类工具是不可少的：
Name: License for You
Lincese Code: A-G667#42616F-10kg1r134fq9m#2217

为了保证真实环境的检测成功，我做了大量的试验，譬如：
1、Windows系列的本地、远程测试。
2、AIX的远程测试。
3、Tomcat5.0、WebLogic8.14、WebSphere6.02，以及上述两种方式的组合测试，排列组合，场景不下10个。
当时也参阅了大量JVM文档，JProfiler官方几百页英文文档，辅助的JProbe对照。而且也制造过内存泄漏造成的OOM场景。
当然，要是在几个月前，在客户那边部署的测试环境时，就进行测试该多好啊。

    在公司内部，我用JProfiler测试了我们当时部署的几个应用，没有发现内存泄漏，所以，我们最怀疑的是就是CMS系统。因为出问题的那个WAS上它占去了90％的负荷（我们有多台AIX、WAS服务器）。该CMS超级庞大，感觉著名的赛迪网就用它，当时该CMS厂商给我们部署都花了快一个月。所以再重新部署一套测试环境也挺困难。另外，CMS提供商不给lisence。现在测试，客户早就对我们恼火了，当然不怎么配合，这对我们工作的开展就有很大的挑战。

    在大致可以确定万无一失的情况下，我们最终决定在客户的真实环境下测试。也就是让JProfiler的agent端直接在WAS的JVM里面启动（北京IDC），然后远程（大连）监控。
本来该模式在另外几个应用的测试都通过了（因为北京IDC那边好几台AIX服务器）。但一部署上，客户的一些编辑用CMS时就感觉超级慢，尽管我们用了JProfiler的最小负载模式。半个小时后，客户实在无法忍受，打电话过来，又把我们部长和经理训了一顿，还要写书面报告。我们被迫马山中止测试，恢复现场。

    虽然JProfiler也支持客户那边的环境，但还是有bug，至少负载一高就有严重的性能问题，几乎导致系统挂起，这是我当时没有料到的。JProfiler一启动，WAS的启动时间就由原来的3分钟降到10分钟，而且系统响应明显变慢，我们具体的环境如下（排列组合恐怕不下20种）：
1、AIX5.3，Power PC64位（不是32位）
2、WebSphere6.0
3、IBM JVM1.42
4、Remote 模式

    我后来仔细读了一下JProfiler的changeLog，发现对上面的环境支持不够也很正常，因为官方在最近的4.3.x版本下陆续有对IBM JVM和Websphere6.0的features和bug fix：http://www.ej-technologies.com/download/jprofiler/changelog.html

    进行到这一步，我忽然觉得无计可施了 ，此时已经过了三周。
上面的策略，我认为是很正统的处理方法。谁怪我们当初项目上线时没有进行充分的测试呢？其实，这类测试没做也正常，OOM这类问题谁都无法预测。

到这个时候，我想肯定有人会问我？你知道导致JVM的OOM有几种情况吗？在当时，我想到了以下五种：
1、JVM的heap最小、最大值没有设，或不合理。
2、JVM的maxPermSize没有设置（这个IBM的JVM没有，一设置JVM就起不来）。
对于Sun和BEA的JVM，以上两种参数设置，可以排除90％以上的非程序内存溢出导致的OOM。
3、程序内存泄漏
4、有的JVM，当在80%的CPU时间内，不能GC出2%的heap时，也发生OOM（IBM的JVM就是，但我没有验证）
5、JVM本身内存泄漏（JVM有bug不是不可能）

    现在的难题是，如果是那个可怕的CMS程序本身有内存溢出，在产品环境下，我们怎么去验证？我们自己开发的10来个web应用，测试并不是很难，在公司测试都可以。但是，我现在最想解决的，就是CMS测试的问题。而且，在我们那种环境下，该CMS产品供应商并没有透露成功案例。

其实，最后发现，并不是内存泄漏造成的，因为我们的heap走势都很平稳。纳闷的是，有1000M的heap，每次在heap只被占用400来M时就发生OOM，没有任何预兆。大家猜猜，会是什么原因 ？这个问题我到后面相关章节再说吧。

既然我们所有的矛头都指向那个可怕的CMS系统，现在就是考虑隔离的问题。如果我们验证这个问题是CMS造成的， 那么大部分责任就应该由CMS厂商承担 。
既然CMS我们不敢移（费劲，而且客户在正式用），那我就移我们开发的10来个web系统吧。

三、移出除CMS系统以外的所有应用
说起来容易啊，做呢？ 隔离（移动）工作由我负责，具体涉及到10来个相关负责人。
转移工作，必须处理好很多问题，就说几个印象最深的吧：
1、某些应用，如Blog和BBS，都涉及到文件、图片上传目录和产品本身的环境，如 JDBC连接池、Cache位置。
2、目标服务器本身的环境，WAS安装环境、网络等。
3、移植时的先后顺序、调度，各应用内部本身的约束关系。
4、移植后的测试。
当然，还有一个最严峻的问题，客户允许我们这么做吗？对它们目前运行的系统有多大影响？风险如何评估？

    这个工作持续了一天，已经完成了80％的工作，到第二天，客户又恼火了：WAS又宕机了。
为什么？这确实是WAS的一个bug：WAS的后台随便一操作，heap就会突然上升几百M，导致JVM内存不够。不过WAS撑住的话，过半小时后就会降下来，我估计是WAS后台对用户操作状态、文件都缓存到Session里面。你们可以检查类似这样的一个文件夹：d:\IBM\WebSphere\AppServer\profiles\AppSrv01\wstemp，我不知道为什么WAS不主动去清除它，它偷偷的就上升到几个G，系统硬盘可能不久就后就会空间不足，WAS莫名迟缓、最后死掉。听过WAS6.0以前这个目录更夸张。大家见我附件的截图WAS_Console.png那个尖峰。

咋办？经理也已经不敢让我们继续铤而走险了。这个方案最终又以失败告终 。

    不过，最后我们还是发现问题出在CMS上。我们以前把这个问题向CMS技术支持反映，有大量依据和现象，并且把相关日志都给它们。过了两天，他们最后竟然只回了一句话“从给我的两个日志来看，没有找到任何与XXX有关的东西....”。TMD！我真的很生气 ，它们的产品都折磨我们半年之久了。不过，看他们对IBM的WAS和JVM也不懂，我也就不想再说什么了。下面是我的邮件，公司机密部分都隐去了：

    文中说到了IBM的两个分析工具，这也是我们后来的救星：我们就是需要这种离线分析工具，因为实时检测已经证明不现实。但我始终对该分析出来的结果抱怀疑态度，直到我去深入IBM的JVM以及和IBM的技术支持交流......

柳暗花明啊 ，至少看到了一点希望，不过最后我们还是失望而返。