泄露了，泄露了，个人项目也内存泄露了

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

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的二级缓存后，每一个用户的查询就变成只有一次了，这个问题就很好的解决了。