經過一個晚上的努力終于完成了一個文件替換指定字符串的程序，
但是由于我要替換的全站程序html文件太多，
所以eclipse下邊老是在一個目錄結束后報出java.lang.OutOfMemoryError: Java heap space的異常，然后就崩潰了。
我一想肯定是頻繁操作造成來不及回收，
于是在每個循環之后加上一個Thread.sleep（1000）,
發現還是到那個目錄下就死掉，于是把1000改成5000，還是到那里死掉，
我想可能不是來不及回收這么簡單，或許sun 的JVM里邊剛好對于這種情況不釋放也有可能。
接著我又把啟動的參數添上一個 -Xmx256M,這回就可以了。

想一想，還是對于垃圾回收的原理不太了解，就在網上查了一下，發現了幾篇不錯的文章。

http://java.ccidnet.com/art/3539/20060314/476073_1.html
http://www.pconline.com.cn/pcedu/empolder/gj/java/0509/701281.html


還有:Java堆的管理—垃圾回收提到一下幾點，很不錯，或許可以作為寫程序時候的準則：
（1）不要試圖去假定垃圾收集發生的時間，這一切都是未知的。
	比如，方法中的一個臨時對象在方法調用完畢后就變成了無用對象，這個時候它的內存就可以被釋放。 

（2）Java中提供了一些和垃圾收集打交道的類，
	而且提供了一種強行執行垃圾收集的方法--調用System.gc()，
	但這同樣是個不確定的方法。Java 中并不保證每次調用該方法就一定能夠啟動垃圾收集，
	它只不過會向JVM發出這樣一個申請，到底是否真正執行垃圾收集，一切都是個未知數。

（3）挑選適合自己的垃圾收集器。一般來說，如果系統沒有特殊和苛刻的性能要求，
	可以采用JVM的缺省選項。否則可以考慮使用有針對性的垃圾收集器，
	比如增量收集器就比較適合實時性要求較高的系統之中。
	系統具有較高的配置，有比較多的閑置資源，可以考慮使用并行標記/清除收集器。

（4）關鍵的也是難把握的問題是內存泄漏。
良好的編程習慣和嚴謹的編程態度永遠是最重要的，不要讓自己的一個小錯誤導致內存出現大漏洞。

（5）盡早釋放無用對象的引用。
	大多數程序員在使用臨時變量的時候，
	都是讓引用變量在退出活動域(scope)后，自動設置為null，
	暗示垃圾收集器來收集該對象，還必須注意該引用的對象是否被監聽，如果有，則要去掉監聽器，然后再賦空值。

	就是說,對于頻繁申請內存和釋放內存的操作,還是自己控制一下比較好,
	但是System.gc()的方法不一定適用，最好使用finallize強制執行或者寫自己的finallize方法。