泄露了，泄露了，我的项目也内存泄露了

我的项目也出现了内存泄露的问题。这个问题测试那边早就给我提出来了，但是到现在也没有解决。我这泄露真是泄的很神秘。范围太大，没有任何规律，找了那么长时间也没有找到。前段时间由于一直赶计划，没有时间处理这个问题。现在公司的领导一轮接着一轮的来过问，包括那些不是领导的人也开始来逼我了。所有，当务之急，必须要找出泄露的根源所在了。
目前定了几个方案来加快问题的定位：

1. 加强测试，尽快找到问题的规律或者原因。这个方法一直在努力，目前收效甚微。
   
2. 通过内存监视工具如jprofiler监控虚拟机内存，分析什么类型的对象数量最多，占用的内存最多，根据分析的结果定位泄露的原因。目前正在用jprofiler，其他可用监视工具还有如visualVM,glassbox等。
3. 进行代码审查，优化程序。
   

以下将记录我的内存泄露的发现和解决之旅。

 

20008年4月

测试部门提出内存泄露的bug，经过确认，发现问题无法再现，没有规律，有时几分钟后就死掉，有时几个小时，有时几天。在A功能区操作是出现过，在B区也出现，C,D,E,F都出过。苦于无法定位问题，于是将此bug置为later状态。待以后找机会翻身吧。于是继续往下开发新功能。

 

2008年7月

又开发了一个新模块。这期间有点间隙，加上部门刚做调整，内存泄露的问题又提上日程了。开会，讨论，提方案，找工具，优化程序，该想的招数都想了，说了这么多，领导们在怎么努力，无非就是发动一下，最后问题还是要靠我们自己解决。计划还有继续往下走，其他的问题还是要继续解决。

 

2008年8月1日

今天去完成一个功能的操作，发现没点几下就死掉了，于是重启服务，再点一会儿，又down掉，又试了几次，一样的结果。于是大喜，好像是离胜利更近了一步。于是找人把这写功能重做了一下，并且把原有的程序保留，我要好好研究以下到底是谁把我害的这么苦。

同样是今天，还有另外一个喜事。我让另外一个人去做hibernate二级缓存的优化工作，成功的优化了我希望改进的一个查询。如：根据登陆用户的登录名去查询该用户的真名，部门等信息。在项目中这样的查询有无数次。假如一个用户登陆后又30个这样的查询，200个用户同时在线就有6000次这样的查询，实际上比这还要多。这么多次数的查询，要带来相当多的内存和数据库开销。加上hibernate的二级缓存后，每个用户的查询就变成只有一次了，这个问题就很好的解决了。