今天看thinking in java，里面很详细的谈到java垃圾回收器机制，看完后让我对这神秘的区域有一定的了解，特写一些小总结记录下来。
分两点来说。
第一点：Object.finalize();方法。finalize()方法是Object类的意味着所有类都可以使用、重写该方法。当对象调用finalize方法后，相当于告诉垃圾回收器：“我是垃圾，在下次垃圾回收的时候可以把我回收”，然后垃圾回收器在下次回收垃圾的时候就把这个对象给回收了，但是在程序运行周期中，垃圾回收器不一定会执行，它一般在虚拟机内存不够的时候才会执行，为什么是这样呢？因为垃圾回收器的执行也消耗资源、性能，而且在程序结束的时候，虚拟机的内存会自动释放归还给内存。当然你也可以显示地调用System.gc();来告诉系统立刻、马上进行垃圾回收，但是不建议这么做，虚拟机总是在最优的时刻调用垃圾回收。很多经验丰富的开发者同时建议：如果不是必须，最好不要使用finalize()。
第二点：垃圾回收。垃圾回收这个动作实际上做了两件事，1、回收垃圾，释放内存；2、重新排列堆中内容，让内存的分配更高效。
在程序启动后，java虚拟机在不断地监视着内存情况，如果发现垃圾比较多，对象在堆中排布比较零散，启动第一种模式：停止-复制（stop and copy）。先把“活”的对象找出来，怎样找呢？垃圾回收器检索整个堆，因为引用可能不断关联着引用，所以将堆中的引用整理出一个“脉络图”，没有被引用的就是“死”的对象，接着，程序短时间停止，把“活”的对象从堆A复制到堆B中，一个挨一个排列整齐，现在堆A只剩下“死”的对象了，也就是垃圾，回头把堆A全部清理，这样就完成一次垃圾清理了。
假设有9个碎片化严重的对象，排布前和排布后对比：
有人可能想到，如果垃圾比较少，对象比较稳定的情况，那么要把所有“活”的对象迁移到另一个堆里，不是很耗费性能吗？就好比一座稳定的大山需要搬迁，工程浩大。对于这种情况，启动第二种模式：标记-清除（mark and clear），同样如上方法整理出“脉络图”，把“死”的对象标记起来，程序短时间暂停，然后垃圾回收器把标记的对象给回收。因为垃圾较少，不会造成内存碎片化太严重，所以这个模式不会对堆中对象重新排布。