编写对GC友好又不泄露的代码[Java编程]

1.利用更多生命周期短的、小的、不改变指向(immutable)的对象,编写清楚的代码.

出于怠惰也好,朴实的俭仆意识也好,我们都习惯对一个变量重用再重用.但是....

Java的垃圾汇集器喜好短生命周期的对象,对象假如在新生代内,在垃圾汇集发生前就死掉了,垃圾汇集器就什么都不用做了.
现代JVM构建一个新对象只需求10个本地CPU指令,并不弱于C/C++. (但垃圾汇集没有压缩算法时会稍慢,更频繁的New对象也招致更频繁的GC).
大对象的分配效率更低,并且对非压缩算法的垃圾汇集器,更简单造成碎片.
对象重用增添了代码的复杂度,降低了可读性.
   所以有标题的号令,比方不要惊骇为中间后果分配小对象.但编程习惯的改变也不是一朝一夕的事情.

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()

大家也都知道finalize()不好,分配代价高贵,释放代价更高贵(要多走一个循环,并且他们死得慢,和他们相关联的对象也随着死得慢了),又不肯定可否被调用(JVM开始关闭时,就不会再举行垃圾汇集),又不肯定什么时刻被调用(GC时间不定,即便system.gc()也只是提醒而不是逼迫GC,又不肯定以什么样的次序调用,所以finalize不是C++的析构函数,也不像C++的析构函数.

我们都知道啊,所以我历来都没利用.都是在显式的保护那些外部资源,比方在finally{}里释放.
　　以上是“编写对GC友好又不泄露的代码[Java编程]”的内容，如果你对以上该文章内容感兴趣，你可以看看七道奇为您推荐以下文章：