编写对GC友好，又不泄漏的代码

zyjwy02

 作者：江南白衣，最新版链接：http://blog.csdn.net/calvinxiu/archive/2007/05/22/1621051.aspx，版权所有，转载请保留原文链接。
    看到JavaOne2007上有篇《Garbage-Collection-Friendly Programming》的68页PPT，心想都2007了还谈这个基本问题，一定总结得很全面了才好意思站出来讲吧。    
GC的基础概念见上篇：JDK5.0垃圾收集优化之--Don't Pause  
1.使用更多生命周期短的、小的、不改变指向(immutable)的对象，编写清晰的代码。
    出于懒惰也好，朴素的节俭意识也好，我们都习惯对一个变量重用再重用。但是....

• Java的垃圾收集器喜欢短生命周期的对象，对象如果在新生代内，在垃圾收集发生前就死掉了，垃圾收集器就什么都不用做了。
  
• 现代JVM构建一个新对象只需要10个本地CPU指令，并不弱于C/C++。 (但垃圾收集没有压缩算法时会稍慢，更频繁的New对象也导致更频繁的GC)。
  
• 大对象的分配效率更低，而且对非压缩算法的垃圾收集器，更容易造成碎片。
  
• 对象重用增加了代码的复杂度，降低了可读性。
  

   所以有标题的呼吁，比如不要害怕为中间结果分配小对象。但编程习惯的改变也不是一朝一夕的事情。
<strong />
2.将用完的对象设为NULL其实没什么作用。
    貌似很酷的把对象主动设为Null 的"好习惯"其实没什么用，JIT Compiler会自动分析local变量的生命周期。
    只有一个例外情况，就是String[1024] foo 这种赤裸裸的数组，你需要主动的foo[100]=null释放第100号元素，所以最好还是直接用ArrayList这些标准库算了。
 
3.避免显式GC--System.gc()。
    大家都知道System.gc()不好，full-gc浪费巨大，gc的时机把握不一定对等等，甚至有-XX:+DisableExplicitGC的JVM参数来禁止它。
    哈哈，但我还不会用System.gc()呢，不怕不怕。真的不怕吗？

• 先用FindBugs 查一下所用到的全部第三方类库吧...
  
• 至少RMI 就会老实不客气的执行System.gc()来实现分布式GC算法。但我也不会用RMI啊。那EJB呢，EJB可是建在RMI上的....
  

    如果无可避免，用-Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 (单位为微妙) 增大大GC的间隔(原默认值为1分钟)，-XX:+ExplicitGCInvokesConcurrent 让System.gc() 也CMS并发执行。
 
4.继续千夫所指的finalize()
<strong />    大家也都知道finalize()不好，分配代价昂贵，释放代价更昂贵(要多走一个循环，而且他们死得慢，和他们相关联的对象也跟着死得慢了)，又不确定能否被调用(JVM开始关闭时，就不会再进行垃圾收集)，又不确定何时被调用(GC时间不定，即使system.gc()也只是提醒而不是强迫GC，又不确定以什么样的顺序调用，所以finalize不是C++的析构函数，也不像C++的析构函数。
   我们都知道啊，所以我从来都没使用。都是在显式的维护那些外部资源，比如在finally{}里释放。
 
5.WeakReference/SoftReference
   这是个平时不怎么会搭理，偶然知道了又觉得有用的Java特征。大家都知道Java里所有对象除int等基本类型外，都是Pass by Reference的指针，实例只要被一个对象连着，就不会被收集。
    而WeakReference就是真正意义上的C++指针，只是单纯的指向一个对象，而不会影响对象的引用计数。
    而SoftReference更特别，在内存足够时，对象会因为SoftReference的存在而不被收集，但内存不足时，对象就还是会被收集，怎么看都是做简单缓存的料子。代码如下：

<div style="padding-right: 5.4pt; padding-left: 5.4pt; background: #e6e6e6; padding-bottom: 4px; width: 95%; padding-top: 4px;">  Foo foo = new Foo(); 
  SoftReference sr= new SoftReference(foo); 
  Foo bar =  sr.get();