作者:江南白衣,最新版链接: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)。
大对象的分配效率更低,而且对非压缩算法的垃圾收集器,更容易造成碎片。
对象重用增加了代码的复杂度,降低了可读性。
所以有标题的呼吁,比如不要害怕为中间结果分配小对象。但编程习惯的改变也不是一朝一夕的事情。
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{}里释放。
5.WeakReference/SoftReference
这是个平时不怎么会搭理,偶然知道了又觉得有用的Java特征。大家都知道Java里所有对象除int等基本类型外,都是Pass by Reference的指针,实例只要被一个对象连着,就不会被收集。
而WeakReference就是真正意义上的C++指针,只是单纯的指向一个对象,而不会影响对象的引用计数。
而SoftReference更特别,在内存足够时,对象会因为SoftReference的存在而不被收集,但内存不足时,对象就还是会被收集,怎么看都是做简单缓存的料子。代码如下:
Java代码
Foo foo = new Foo();
SoftReference sr= new SoftReference(foo);
Foo bar = sr.get();
如果foo已被垃圾收集,sr.get()会返回Null;
另外还有一个ReferenceQueue的机制,使得对象被回收时能获得通知,比finalize()完全不知道GC何时会执行要聪明的多。
Java代码
ReferenceQueue rq = new ReferenceQueue();
ref = new WeakReference(foo, rq);
WeakReference cleaned = rq.pool();
cleaned就是刚刚被GC掉的WeakReference。
6.内存泄漏
java 不是有垃圾收集器了吗?怎么还泄漏啊,唬我啊??
嗯,此泄漏非比泄漏。C/C++的泄漏,是对象已不可到达,而内存又没有回收,真正的内存黑洞。
而Java的泄漏,则是因为各种原因,对象对应用已经无用,但一直被持有,一直可到达。
总结原因无外乎几方面:
被生命周期极长的集合类不当持有,号称是Java内存泄漏的首因。
这些集合类的生命周期通常极长,而且是一个辅助管理性质的对象,在一个业务事务运行完后,如果没有将某个业务对象主动的从中清除的话,这个集合就会吃越来越多内存,可以用WeakReference,如WeakHashMap,使得它持有的对象不增加对象的引用数。
Scope定义不对,这个很简单了,方法的局部变量定义成类的变量,类的静态变量等。
异常时没有加finally{}来释放某些资源,JDBC时代也是很普遍的事情。
另外一些我了解不深的原因,如:Swing里的Listener没有显式remove;内部类持有外部对象的隐式引用;Finalizers造成关联对象没有被及时清空等。
内存泄漏的检测
有不少工具辅助做这个事情的,如果手上一个工具也没有,可以用JDK自带的小工具:
看看谁占满了Heap?
用JDK6的jmap可以显示运行程序中对象的类型,个数与所占的大小
先用jps 找到进程号,然后jmap -histo pid 显示或 jmap -dump:file=heap_file_name pid 导出heap文件
为什么这些对象仍然可以到达?
用jhat(Java Heap Analysis Tool) 分析刚才导出的heap文件。
先jhat heap_file_name,然后打开浏览器http://localhost:7000/ 浏览。
看到JavaOne2007上有篇《Garbage-Collection-Friendly Programming》的68页PPT,心想都2007了还谈这个基本问题,一定总结得很全面了才好意思站出来讲吧。
GC的基础概念见上篇:JDK5.0垃圾收集优化之--Don't Pause
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{}里释放。
5.WeakReference/SoftReference
这是个平时不怎么会搭理,偶然知道了又觉得有用的Java特征。大家都知道Java里所有对象除int等基本类型外,都是Pass by Reference的指针,实例只要被一个对象连着,就不会被收集。
而WeakReference就是真正意义上的C++指针,只是单纯的指向一个对象,而不会影响对象的引用计数。
而SoftReference更特别,在内存足够时,对象会因为SoftReference的存在而不被收集,但内存不足时,对象就还是会被收集,怎么看都是做简单缓存的料子。代码如下:
Java代码
Foo foo = new Foo();
SoftReference sr= new SoftReference(foo);
Foo bar = sr.get();
如果foo已被垃圾收集,sr.get()会返回Null;
另外还有一个ReferenceQueue的机制,使得对象被回收时能获得通知,比finalize()完全不知道GC何时会执行要聪明的多。
Java代码
ReferenceQueue rq = new ReferenceQueue();
ref = new WeakReference(foo, rq);
WeakReference cleaned = rq.pool();
cleaned就是刚刚被GC掉的WeakReference。
6.内存泄漏
java 不是有垃圾收集器了吗?怎么还泄漏啊,唬我啊??
嗯,此泄漏非比泄漏。C/C++的泄漏,是对象已不可到达,而内存又没有回收,真正的内存黑洞。
而Java的泄漏,则是因为各种原因,对象对应用已经无用,但一直被持有,一直可到达。
总结原因无外乎几方面:
被生命周期极长的集合类不当持有,号称是Java内存泄漏的首因。
这些集合类的生命周期通常极长,而且是一个辅助管理性质的对象,在一个业务事务运行完后,如果没有将某个业务对象主动的从中清除的话,这个集合就会吃越来越多内存,可以用WeakReference,如WeakHashMap,使得它持有的对象不增加对象的引用数。
Scope定义不对,这个很简单了,方法的局部变量定义成类的变量,类的静态变量等。
异常时没有加finally{}来释放某些资源,JDBC时代也是很普遍的事情。
另外一些我了解不深的原因,如:Swing里的Listener没有显式remove;内部类持有外部对象的隐式引用;Finalizers造成关联对象没有被及时清空等。
内存泄漏的检测
有不少工具辅助做这个事情的,如果手上一个工具也没有,可以用JDK自带的小工具:
看看谁占满了Heap?
用JDK6的jmap可以显示运行程序中对象的类型,个数与所占的大小
先用jps 找到进程号,然后jmap -histo pid 显示或 jmap -dump:file=heap_file_name pid 导出heap文件
为什么这些对象仍然可以到达?
用jhat(Java Heap Analysis Tool) 分析刚才导出的heap文件。
先jhat heap_file_name,然后打开浏览器http://localhost:7000/ 浏览。