JAVA内存泄漏问题

Java的一个重要优点就是通过垃圾收集器(Garbage Collection，GC)自动管理内存的回收，程序员不需要通过调用函数来释放内存。因此，很多程序员认为Java不存在内存泄漏问题，或者认为即使有内存泄漏也不是程序的责任，而是GC或 JVM的问题。其实，这种想法是不正确的，因为Java也存在内存泄露，但它的表现与C++不同。

　　Java的一个重要优点就是通过垃圾收集器(Garbage Collection，GC)自动管理内存的回收，程序员不需要通过调用函数来释放内存。因此，很多程序员认为Java不存在内存泄漏问题，或者认为即使有内存泄漏也不是程序的责任，而是GC或 JVM的问题。其实，这种想法是不正确的，因为Java也存在内存泄露，但它的表现与C++不同。

　　在Java中，内存泄漏就是存在一些被分配的对象，这些对象有下面两个特点，首先，这些对象是可达的，即在有向图中，存在通路可以与其相连; 其次，这些对象是无用的，即程序以后不会再使用这些对象。如果对象满足这两个条件，这些对象就可以判定为Java中的内存泄漏，这些对象不会被GC所回收，然而它却占用内存。

　　在C++中，内存泄漏的范围更大一些。有些对象被分配了内存空间，然后却不可达，由于C++中没有GC，这些内存将永远收不回来。在Java中，这些不可达的对象都由GC负责回收，因此不需要考虑这部分的内存泄露。

　　注意事项：

　　1.最基本的建议是尽早释放无用对象的引用。如：

　　...

　　A a = new A();

　　//应用a对象

　　a = null; //当使用对象a之后主动将其设置为空

　　….

　　注：如果a 是方法的返回值，不要做这样的处理，否则你从该方法中得到的返回值永远为空，而且这种错误不易被发现、排除

　　2.尽量少用finalize函数。它会加大GC的工作量。

　　3.如果需要使用经常用到的图片，可以使用soft应用类型。它尽可能把图片保存在内存中

　　4.注意集合数据类型，包括数组、树、图、链表等数据结构，这些数据结构对GC来说，回收更为复杂。

　　5.尽量避免在类的默认构造器中创建、初始化大量的对象，防止在调用其自类的构造器时造成不必要的内存资源浪费

　　6.尽量避免强制系统做垃圾内存的回收，增长系统做垃圾回收的最终时间

　　7.尽量避免显式申请数组空间

　　8.尽量做远程方法调用类应用开发时使用瞬间值变量，除非远程调用端需要获取该瞬间值变量的值。

　　9.尽量在合适的场景下使用对象池技术以提高系统性能。

这两天看了一本老书《bitter java》，第一次系统地了解了所谓“反模式”。就书的内容来说已经过于陈旧，书中提到的magic servlet、复合jsp等等反模式已经是早就熟知的编程禁忌，而如web页面不能有太多元素这样的反模式也因为ajax的出现（异步加载）变的不是那么“反模式”了，其中又讲述了很多ejb的反模式，这些在轻量级框架流行的今天也早已经过时。不过书中有一个章节倒是挺有价值，讲述的是java的内存泄露问题，我认为是我目前读的关于这方面问题比较有价值的介绍。
网上关于java内存泄露的资料都过于玄乎，其实java导致内存泄露的原因很明确：长生命周期的对象持有短生命周期对象的引用就很可能发生内存泄露，尽管短生命周期对象已经不再需要，但是因为长生命周期对象持有它的引用而导致不能被回收，这就是java中内存泄露的发生场景。作者在书中提到了3个场景：
1。流失监听器问题，在awt、swing编程中，给组件添加了事件监听器，这些组件的生命周期如果很长的话，监听器对象将不能被正确回收。关于GUI编程我不是很熟悉，这一点存有疑问，因为显然你触发一个按钮的事件，当然是一直期待同样的行为发生，如果删除了监听器或者使用弱引用让JVM回收不符合业务逻辑和用户体验。

2。集合类，集合类仅仅有添加元素的方法，而没有相应的删除机制，导致内存被占用。这一点其实也不明确，这个集合类如果仅仅是局部变量，根本不会造成内存泄露，在方法栈退出后就没有引用了会被jvm正常回收。而如果这个集合类是全局性的变量（比如类中的静态属性，全局性的map等），那么没有相应的删除机制，很可能导致集合所占用的内存只增不减，因此提供这样的删除机制或者定期清除策略非常必要。

3。单例模式。不正确使用单例模式是引起内存泄露的一个常见问题，单例对象在被初始化后将在JVM的整个生命周期中存在（以静态变量的方式），如果单例对象持有外部对象的引用，那么这个外部对象将不能被jvm正常回收，导致内存泄露，考虑下面的例子：
class A{
public A(){
B.getInstance().setA(this);
}
....
}
//B类采用单例模式
class B{
private A a;
private static B instance=new B();
public B(){}
public static B getInstance(){
return instance;
}
public void setA(A a){
this.a=a;
}
//getter...
}

显然B采用singleton模式，他持有一个A对象的引用，而这个A类的对象将不能被回收。想象下如果A是个比较大的对象或者集合类型会发生什么情况。

上面所讲的这些也启发我们如何去查找内存泄露问题，第一选择当然是利用工具，比如jprofiler，第二就是在代码复审的时候关注长生命周期对象：全局性的集合、单例模式的使用、类的static变量等等。