java垃圾回收学习

经过一个晚上的努力终于完成了一个文件替换指定字符串的程序，但是由于我要替换的全站程序html文件太多，

所以eclipse下边老是在一个目录结束后报出java.lang.OutOfMemoryError: Java heap space的异常，然后就崩溃了。

我一想肯定是频繁操作造成来不及回收，

于是在每个循环之后加上一个Thread.sleep（1000）,

发现还是到那个目录下就死掉，于是把1000改成5000，还是到那里死掉，

我想可能不是来不及回收这么简单，或许sun 的JVM里边刚好对于这种情况不释放也有可能。

接着我又把启动的参数添上一个 -Xmx256M,这回就可以了。

还有:Java堆的管理—垃圾回收提到一下几点，很不错，或许可以作为写程序时候的准则：

（1）不要试图去假定垃圾收集发生的时间，这一切都是未知的。

比如，方法中的一个临时对象在方法调用完毕后就变成了无用对象，这个时候它的内存就可以被释放。

（2）Java中提供了一些和垃圾收集打交道的类，

而且提供了一种强行执行垃圾收集的方法--调用System.gc()，

但这同样是个不确定的方法。Java 中并不保证每次调用该方法就一定能够启动垃圾收集，

它只不过会向JVM发出这样一个申请，到底是否真正执行垃圾收集，一切都是个未知数。

（3）挑选适合自己的垃圾收集器。一般来说，如果系统没有特殊和苛刻的性能要求，

可以采用JVM的缺省选项。否则可以考虑使用有针对性的垃圾收集器，

比如增量收集器就比较适合实时性要求较高的系统之中。

系统具有较高的配置，有比较多的闲置资源，可以考虑使用并行标记/清除收集器。

（4）关键的也是难把握的问题是内存泄漏。

　良好的编程习惯和严谨的编程态度永远是最重要的，不要让自己的一个小错误导致内存出现大漏洞。

（5）尽早释放无用对象的引用。

大多数程序员在使用临时变量的时候，

都是让引用变量在退出活动域(scope)后，自动设置为null，

暗示垃圾收集器来收集该对象，还必须注意该引用的对象是否被监听，如果有，则要去掉监听器，然后再赋空值。

就是说,对于频繁申请内存和释放内存的操作,还是自己控制一下比较好,

但是System.gc()的方法不一定适用，最好使用finallize强制执行或者写自己的finallize方法。