JVM的内存管理和垃圾回收

 

copy from http://yanhua.blog.techweb.com.cn/archives/2006/2006915124242.shtml

 

最近在做新的产品，感觉和做项目确实不太一样，除了Web Service、BPEL以及SOA等这些以前没真正接触过的东西外，JAVA的一些基础知识也需要回头好好补一下了－－比如Swing、多线程、Socket以及JVM的一些知识。

昨天就碰到一个关于JVM内存管理和垃圾回收的问题。我们的旧版本的流程设计器是用Swing写的，对内存的消耗相当的大，每次打开一个对话窗口内存就是多占用约2m的空间，太恐怖了，如果画一个大的流程的话，用不了多久内存就被耗尽了。我想程序在设计上存在一些问题吧，不过现在没时间重构代码了，后来我想起来JBuilder里面有个功能是可以人工强制执行垃圾回收的，那我可不可以也加上这个功能呢？看了一下设计器的代码，每个对话窗口就是一个局部变量，每打开一次就要新建一个，关闭以后就成了垃圾，完全可以用强制执行垃圾回收来释放内存。

其实不只是JBuilder，Eclipse中也提供了这个方法，要让它显示出来，要做以下几步：1、在Eclipse根目录下建立一个文件，文件名options，文件内容org.eclipse.ui/perf/showHeapStatus=true2、用这条命令启动Eclipse：E:/eclipse3.1/eclipse.exe -debug options或者直接右键Eclipse的快捷方式，在"目标"中填入这行。3、启动Eclipse，就可以看到下面的状态栏会显示当前JVM内存使用量，另外还可以点击小垃圾桶图标强制进行垃圾回收，效果还是很明显的。

所谓的强制垃圾回收，无非就是调用System.gc()方法，《Think in Java》中有一段讲的挺清楚的，我做了个小例子，来演示一下强制垃圾回收的效果。那么如何在程序中得到JVM的内存状态呢？1、Runtime.getRuntime().maxMemory()当前虚拟机配置的可以使用的最大内存，可以通过java -Xmx128M 来指定其大小，默认大小大约为64M(不确切)。2、Runtime.getRuntime().totalMemory()当前虚拟机正在使用的内存，这个容量可以弹性增加，并不是虚拟机启动的时候就占用了虚拟机配置的可使用的最大内存而是使用一部份，当达到一定使用程度之后，弹性增加一段内存。3、Runtime.getRuntime().freeMemory()当前虚拟机正在使用的内存中的空闲内存，也就是说：虚拟机所占用的内存并没有完全使用，先占着，备用。

更多的关于JVM内存管理和垃圾回收的信息请参见JVM的垃圾回收机制详解和调优和Java堆的管理—垃圾回收以及《深入JAVA虚拟机　第２版》。其中，Java堆的管理—垃圾回收提到一以下的原则可以参考一下。

（1）不要试图去假定垃圾收集发生的时间，这一切都是未知的。比如，方法中的一个临时对象在方法调用完毕后就变成了无用对象，这个时候它的内存就可以被释放。（2）Java中提供了一些和垃圾收集打交道的类，而且提供了一种强行执行垃圾收集的方法--调用System.gc()，但这同样是个不确定的方法。Java 中并不保证每次调用该方法就一定能够启动垃圾收集，它只不过会向JVM发出这样一个申请，到底是否真正执行垃圾收集，一切都是个未知数。（3）挑选适合自己的垃圾收集器。一般来说，如果系统没有特殊和苛刻的性能要求，可以采用JVM的缺省选项。否则可以考虑使用有针对性的垃圾收集器，比如增量收集器就比较适合实时性要求较高的系统之中。系统具有较高的配置，有比较多的闲置资源，可以考虑使用并行标记/清除收集器。（4）关键的也是难把握的问题是内存泄漏。良好的编程习惯和严谨的编程态度永远是最重要的，不要让自己的一个小错误导致内存出现大漏洞。（5）尽早释放无用对象的引用。大多数程序员在使用临时变量的时候，都是让引用变量在退出活动域(scope)后，自动设置为null，暗示垃圾收集器来收集该对象，还必须注意该引用的对象是否被监听，如果有，则要去掉监听器，然后再赋空值。