关于Java内存泄漏

skykiker

   Java中由于有垃圾收集器(GC)自动回收资源，所以一般情况下不需要担心内存泄漏的问题。
这也是Java相对C/C++而言开发简单高效的重要原因之一。想必调试过C/C++内存泄漏
障害的人都深有体会。但是如果认为Java中不存在内存泄漏也是不对的。因为GC不是万能的，
也有听它失灵的时候。那它什么情况下会失灵呢？先简单了解一下GC的工作方式吧。
   垃圾收集器每过一段时间就会将不再使用的资源回收。GC判断一个对象是否是不再使用的方法
非常重要。它以每个活的线程对象为根检查有没有能够到达目标对象的引用链为判断标准。
如果不可达则说明该对象对程序(或者线程)的执行是不可见的，因为没有任何手段可以
引用该对象，自然这个对象肯定是不再被使用了。于是将其回收。
   简单思考一下，上面的判断逻辑只是“什么是不使用对象”的充分条件，而不是必要条件。
至于必要条件是什么，答案只有开发者自己知道，因为只有开发者自己才能准确知道哪些对象
已经确实不再需要了，GC又怎么能揣测到开发者的意图呢？
   理解了这一点我们就知道了Java内存泄漏的第一种模式：GC不能正确识别出不再使用的对象。
既：存在一条以活的线程对象(通常是主线程)为起点的引用链，指向了已经不再使用的对象。
并且这些对象在程序运行中是在不断增长的(否则也不能称之为内存泄漏)。这样的内存泄漏通
常发生在一个集合对象上，尤其是作为高速缓存使用的集合对象。
   本来我以为刚才提到的模式是Java内存泄漏唯一的一种模式，但是一次实际经历使我看到了
第二种Java内存泄漏的模式：GC不能正常释放它想释放的对象。这是由于用户重载了某个Java对象
的finalize()方法，GC在释放这个对象时就要调用这个被修改了的finalize()方法，而这个
finalize()方法又由于某个原因离奇地无法结束(比如等待一个同步对象或者发生了死循环)，
也就导致这个对象没法被正常释放，于是内存泄漏自然就发生了。当然这种情况比起前面提到的
第一种模式要少见的多。
               
               
               
               
               

本文来自ChinaUnix博客，如果查看原文请点：http://blog.chinaunix.net/u2/72988/showart_1357862.html