Java内存泄漏有关问题

   (1) 引起内存泄漏的地方

    wap page中分享和收藏相册功能中使用了如下代码：

        rose =  new RoseAppContext();

    调用分享/收藏相册时都执行一遍该语句，导致每次都会新增一个容器，将所有bean重新实例化一次，耗去大量内存。

    该语句借鉴了ShareFacade里的代码，拿来主义，没理解它都做了什么工作，从而造成了此次事故。

    (2) 以下是马帅同学定位该问题的方法

    //start
    a、根据志强邮件中的附件1048.txt，像是有对象泄漏。
       查本地的缓存：找到GlobalMemocache中有ThreahLocal的本地缓存实现，怀疑是它的问题。
       后经多次更新，实践证实，跟GlobalMemocache无关。

    b、dump出来内存镜像。发现一百多个百万级的对象数组。
       用MAT分析出这个一百多个百万级的对象数组都来自BlogPhotoAuditBiz。看源码。有单例实现。
       自己模拟这种代码实现测试，发现spring可以通过私有的无参构造方法完成构造。出现两个实例。
       然后就让志强邮件代码的开发者，希望发现同类问题。结果：无同类问题。
       开发者把数组量由百万降到十万级，问题依旧。

    c、查数据库连接：发现有800多个数据库连接。怀疑有问题。
       让志强看了下主站的，也有700百。基本排除数据库的问题。

    d、查线程锁，有大量对象锁发现。
       结果绝大多数为ICE的连接。放弃。

    e、看dump出来的数据
       看很多Map的Enty，看字符串，看调用关系，ect...浪费了很多时间，无收获。

    f、回到线上，观察内存中的实例数变化(只观察com.xiaonei.blog.biz)
       发现Service的实例数是整体的增加。像是Rose的容器中的对象都成倍增加。
       最后才想到是Rose的容器被手工new了。

    总结一下：
    第1步的时候我就犯了个错误，如果是本地缓存问题，如果最多的应该是Doing对象。
    第2步的时候已经发现BlogPhotoAuditBiz的实例不止两个，顺着这个应该会更快找到原因。
    真正的错误是MPage抄了ShareFacade中的错误用法。导致了错误的结果。

    附一下用到的几个工具和命令
    mat下载地址：www.eclipse.org/mat/downloads.php
    其它工具全是jdk自带的
    jps
      查所有java进程的VM编号，Linux下一般跟进程号pid一致。因此编号存储于/tmp下，较长时间运行的vm编号可能会被自动清理，需要自己建。
     jmap -histo:live 15604 > 15604.log
     把vm编号为15604的对象分布以列表的形式输出到一个日志文件，以便分析。我同时还用下面这条命令来确定有多少个对象的实例：
     grep com.xiaonei.blog.biz 15604.log 

     jstack 15604
     看vm中各线程的状态。包括对象锁的情况。

     jmap -heap 15604
     看内存使用情况。之前张剑曾经发现Perm区的问题，然后改了Resin的启动参数。这次是Old区的问题，Perm区还没来得及出问题。

     kill -3 15604
     不是杀进程，是在jvm.log中输出jstack和jmap -heap的内容。比较懒的用法。

     jstat -printcompilation 15604
     第1步判断的时候，以为这个命令是显示当前vm中执行的指令。看到了ThreadLocal的指令执行。可能是我理解错了，意思不详。

    我也犯了另一个错误，看到<bean>配置的时候，在init-method里指定getInstance，就误以为是指定构造。实际上这个是构造完成且属性设置完后后，顺便做的一个调用，只是可以用来做一些初始化操作。
//end