主要看《深入理解Java虚拟机》
第三张 P84 开始是垃圾收集相关。
1. 1960年诞生于MIT的Lisp是第一门采用垃圾回收的语言。
2. 程序计数器、虚拟机栈、本地方法栈3个区域随线程而生而亡。
3. 垃圾回收主要关注的是堆里面的对象。
1. 检查
1.1 引用计数。基本不用。因为很难解决相互循环引用的问题。当然Python、COM等应用里面用到了。热热
1.2 可达性分析。Reachability Analysis. 通过一系列作为GC roots的对象作为起始。
GC roots的对象包括：
虚拟机栈（栈帧中的本地变量表）中引用的对象。
方法区中类静态属性引用的对象。
方法区中常量引用的对象。
本地方法栈中JNI（Native方法）引用的对象。
1.3 判定都与引用有关。
传统判定：reference类型的数据中存储的数值代表的是另外一块内存，就称这块内存代表着一个引用。
但问题是非1即0.
JDK1.2之后，引用概念进行了扩充，分为：
强引用、软引用、弱引用、虚引用4中。
1.4 两次标记过程：
1. 如果可达性分析发现没有与 GC roots相连，经历第一次筛选，条件是此对象是否有必要执行finalize()。如果没有，或者已经被调用过，则不需要再调用。
2. 如果判定需要调用，放在F-Queue里面，由虚拟机自动建立的，低优先级的Finalizer线程去执行它。
之后GC会对F-Queue中的对象进行第二次标记，如果之前的finalize方法导致对象又与GC roots发生了关联，那么这个对象就不再需要被回收了。
书中的 P90 有示例代码。
但是Java的finalize()方法强烈不建议使用，有很多不确定性。建议忘了它。try{}finally{}能够代替所有场景。
1.5 方法区（虚拟机的永久代）垃圾回收
回收：废弃常量、无用的类。
废弃常量：没有地方引用它。
无用的类：所有实例已经回收；加载该类的ClassLoader已经回收；对应的Class对象没有任何地方被引用，无法在任何地方通过反射访问该类的方法。
在大量使用反射、动态代理、OSGi的场景需要虚拟机具备卸载的能力。
3. 垃圾手机算法
3.1 标记-清除算法：1.效率问题，两个步骤效率都不高；2.空间问题，容易产生大量碎片。
3.2 复制算法：基本都采用这种算法回收新生代。一块较大的Eden空间和两块较小的Survivor空间，大小8：1。
3.3 标记-整理算法：老年代的特点，而使用。让所有存活对象都向一端移动。
3.4 分代收集：根据对象存活周期的不同而把内存分为几块，新生代（复制）、老年代（标记-清除、标记-整理）。
4. HotSpot实现
4.1 枚举根节点
可达性分析：
1. GC roots主要在全局性引用（常量或类静态属性）与执行上下文（栈桢中的本地变量表），时间消耗大。
2. 必须在确保一致性的快照中进行。
OopMap
有一组称为OopMap的数据结构来达到这个目的，在类加载完成的时候，Hotspot就把对象内什么偏移量上是什么类型的数据计算出来，在JIT编译过程中，也会特点位置记录栈和寄存器中哪些位置是引用，这样GC在扫描时就直接得知这些信息。
4.2 安全点
在OopMap协助下，Hotspot可以快速准确地完成GC roots枚举。但是只在特定位置记录这些信息，这些位置成为安全点(Safepoint)，只有到达安全点，才会GC。
Safepoint的选择标准：是否具有让程序长时间执行，而这不是根据指令流太长，而是根据方法调用、循环跳转、异常跳转等。
怎么让程序跑到安全点停下来：抢先式中断(Preemptive Suspension)和主动式中断（Voluntary Suspension）。
抢先式中断：主动让所有线程都暂停，如果有线程不在点上，就恢复执行，让所有线程到点。现在几乎没有虚拟机是这样实现。
主动式中断：简单设一个标志，各个线程主动去轮询。标识为真就自己挂起。比如设置一个 test value addr地址，然后设置addr不可读，就会发生一个自陷异常中断，在预先注册的异常处理器中暂停线程。
4.3 安全区域
有的线程在sleep, blocked，那么无法响应，也可能不在安全点。所以要设置安全区域，引用不发生变化的区域。
线程执行到Safe Region中，标识自己已进入，即使sleep，JVM要GC时，不用管标记进入Safe Region的线程，而这个线程如果恢复，要离开Safe Region时，要检查系统是否已经收集完成 GC roots。
5. 垃圾收集器。
有点多，如图：
7种收集器，作用于不同分代。如果两个收集器存在连线，那么表示可以搭配使用。
后面十几页都是各种收集器介绍。略过。
GC日志：
其中，开始数字，表示GC发生时间，然后Full GC表示经过了(Stop the World)。有时候对新生代的回收，也会Stop the World，因为担保失败。
接下来是发生GC的区域，可能有新生代、老年代、永久代，根据GC收集器不同，而命名不同。
关于用户态消耗的CPU时间、内核态消耗的CPU时间、墙钟时间(Wall Clock Time)。说得很不错。
再后面讲对象内存分配：
1. 大方向，就是在堆上分配（可能JIT编译后拆散为标量类型而间接在栈上分配）。
有几条最普遍的内存分配准则：
1. 对象有现在新生代Eden区中分配。当没有足够空间，虚拟机发起一次Minor GC.
Minor GC与Full GC的区别：
2. 大对象直接进入老年代
典型对象就是那种很长的byte[]或者字符串。直接放入老年代的目的是避免新生代在Eden和两个Survivor之间频繁复制。
3. 长期存活的对象进入老年代
虚拟机给每个对象定义一个对象年龄计数器，每次Minor GC，复制到Survivor，年龄+1。当到达默认为15岁，就会晋升到老年代（这个晋升年龄有参数可以调，MaxTenuringThreshold）。
4. 动态判定年龄及晋升
当Survivor中相同年龄对象总和大于Survivor容积的一半，年龄大于等于该年龄的对象直接进入老年代。
注意说的是容积，不是对象个数。
5. 空间分配担保
Survivor不够用，把无法容纳的对象放入老年代。需要担保。并且根据经验值，判断是否Full GC。
还有就是取平均值比较的动态概率手段，如果Minor GC后存活的对象远高于正常，汇报之担保失败，并发起Full GC。
第三章基本看完，后面几章还有实际调试的例子。
一些总结
（http://www.360doc.com/content/12/1219/15/495229_255087879.shtml）：
关于引用：
标记-清除算法：
复制算法：
标记-整理算法：
分代：
还有另一篇文章，讲得也挺好 （http://blog.csdn.net/zsuguangh/article/details/6429592）：
垃圾收集的算法分析
2.1. 引用计数法(Reference Counting Collector)
运行较快，不会长时间中断程序执行，适宜地必须实时运行的程序。
增加了程序执行的开销。无法处理循环引用。
2.2. tracing算法(Tracing Collector)
使用了根集的概念。基于tracing算法的垃圾收集器从根集开始扫描，识别出哪些对象可达，并用某种方式标记可达对象，例如设置一个或多个位。基于tracing算法的垃圾收集也称为标记和清除(mark-and-sweep)垃圾收集器。
2.3. compacting算法(Compacting Collector)
为了解决堆碎片问题。在清除的过程中，算法将所有的对象移到堆的一端，堆的另一端就变成了一个相邻的空闲内存区。收集器会对它移动的所有对象的所有引用进行更新，在基于Compacting算法的收集器的实现中，一般增加句柄和句柄表。
2.4. copying算法(Coping Collector)
开始时把堆分成一个对象区和多个空闲区，一种典型的基于coping算法的垃圾回收是stop-and-copy算法，在对象区与空闲区域的切换过程中，程序暂停执行。
2.5. generation算法(Generational Collector)
如果收集器必须复制所有的活动对象，这增加了程序等待时间。generation算法将堆分成两个或多个，每个子堆作为对象的一代 (generation)。
在分代式的垃圾收集器运行后，上次运行存活下来的对象移到下一最高代的子堆中，由于老一代的子堆不会经常被回收，因而节省了时间。
2.6. adaptive算法(Adaptive Collector)
在特定的情况下，一些垃圾收集算法会优于其它算法。基于Adaptive算法的垃圾收集器就是监控当前堆的使用情况，并将选择适当算法的垃圾收集器。
System.gc()方法
使用System.gc()可以不管JVM使用的是哪一种垃圾回收的算法，都可以请求Java的垃圾回收。
需要注意的是，调用System.gc()也仅仅是一个请求(建议)。JVM接受这个消息后，并不是立即做垃圾回收，而只是对几个垃圾回收算法做了加权，使垃圾回收操作容易发生，或提早发生，或回收较多而已。
finalize()方法：protected void finalize() throws Throwable
在finalize()方法返回之后，对象消失，垃圾收集开始执行。原型中的throws Throwable表示它可以抛出任何类型的异常。
之所以要使用finalize()，是存在着垃圾回收器不能处理的特殊情况。
假定你的对象（并非使用new方法）获得了一块“特殊”的内存区域，由于垃圾回收器只知道那些显示地经由new分配的内存空间，
所以它不知道该如何释放这块“特殊”的内存区域，那么这个时候java允许在类中定义一个由finalize()方法。 特殊的区域例如：
）由于在分配内存的时候可能采用了类似 C语言的做法，而非JAVA的通常new做法。这种情况主要发生在native method中，
比如native method调用了C/C++方法malloc()函数系列来分配存储空间，但是除非调用free()函数，否则这些内存空间将不会得到释放，
那么这个时候就可能造成内存泄漏。但是由于free()方法是在C/C++中的函数，所以finalize()中可以用本地方法来调用它。以释放这些“特殊”的内存空间。 ）又或者打开的文件资源，这些资源不属于垃圾回收器的回收范围。 例如，假设某一个对象在创建过程中会将自己绘制到屏幕上，如果不是明确地从屏幕上将其擦出，它可能永远都不会被清理。
如果在finalize()加入某一种擦除功能，当GC工作时，finalize()得到了调用，图像就会被擦除。
一旦垃圾回收器准备好释放对象占用的存储空间，首先会去调用finalize()方法进行一些必要的清理工作。只有到下一次再进行垃圾回收动作的时候，才会真正释放这个对象所占用的内存空间。
垃圾收集器的存在并不能完全消除对析构函数的需要，或者说不能消除对析构函数代表的那种机制的需要。（另外finalize()函数是在垃圾回收器准备释放对象占用的存储空间的时候被调用的，绝对不能直接调用finalize()，所以应尽量避免用它）
在C++中所有的对象运用delete()一定会被销毁，而JAVA里的对象并非总会被垃圾回收器回收。
记住下面三句话：
1 对象可能不被垃圾回收，2 垃圾回收并不等于“析构”，3 垃圾回收只与内存有关。
问：如果一个对象不再被使用，是不是要在finalize()中释放这个对象中含有的其它对象呢？
不是的。因为无论对象是如何创建的，垃圾回收器都会负责释放那些对象占有的内存。
触发主GC（Garbage Collector）的条件
JVM进行次GC的频率很高,但因为这种GC占用时间极短,所以对系统产生的影响不大。
更值得关注的是主GC的触发条件,因为它对系统影响很明显。
1)当应用程序空闲时,即没有应用线程在运行时,GC会被调用。因为GC在优先级最低的线程中进行,所以当应用忙时,GC线程就不会被调用,但以下条件除外。
2)Java堆内存不足时,GC会被调用。当应用线程在运行,并在运行过程中创建新对象,若这时内存空间不足,JVM就会强制地调用GC线程,以便回收内存用于新的分配。若GC一次之后仍不能满足内存分配的要求,JVM会再进行两次GC作进一步的尝试,若仍无法满足要求,则 JVM将报“out of memory”的错误,Java应用将停止。
由于是否进行主GC由JVM根据系统环境决定,而系统环境在不断的变化当中,所以主GC的运行具有不确定性,无法预计它何时必然出现,但可以确定的是对一个长期运行的应用来说,其主GC是反复进行的。
6. 减少GC开销的措施
根据上述GC的机制,程序的运行会直接影响系统环境的变化,从而影响GC的触发。若不针对GC的特点进行设计和编码,就会出现内存驻留等一系列负面影响。为了避免这些影响,基本的原则就是尽可能地减少垃圾和减少GC过程中的开销。
具体措施包括以下几个方面:
(1)不要显式调用System.gc()
此函数建议JVM进行主GC,虽然只是建议而非一定,但很多情况下它会触发主GC,从而增加主GC的频率,也即增加了间歇性停顿的次数。
(2)尽量减少临时对象的使用
临时对象在跳出函数调用后,会成为垃圾,少用临时变量就相当于减少了垃圾的产生,从而延长了出现上述第二个触发条件出现的时间,减少了主GC的机会。
(3)对象不用时最好显式置为Null
一般而言,为Null的对象都会被作为垃圾处理,所以将不用的对象显式地设为Null,有利于GC收集器判定垃圾,从而提高了GC的效率。
(4)尽量使用StringBuffer,而不用String来累加字符串
由于String是固定长的字符串对象,累加String对象时,并非在一个String对象中扩增,而是重新创建新的String对象,如Str5=Str1+Str2+Str3+Str4,这条语句执行过程中会产生多个垃圾对象,因为对次作“+”操作时都必须创建新的String对象,但这些过渡对象对系统来说是没有实际意义的,只会增加更多的垃圾。避免这种情况可以改用StringBuffer来累加字符串,因StringBuffer是可变长的,它在原有基础上进行扩增,不会产生中间对象。
(5)能用基本类型如Int,Long,就不用Integer,Long对象
基本类型变量占用的内存资源比相应对象占用的少得多,如果没有必要,最好使用基本变量。
(6)尽量少用静态对象变量
静态变量属于全局变量,不会被GC回收,它们会一直占用内存。
(7)分散对象创建或删除的时间
集中在短时间内大量创建新对象,特别是大对象,会导致突然需要大量内存,JVM在面临这种情况时,只能进行主GC,以回收内存或整合内存碎片,从而增加主GC的频率。集中删除对象,道理也是一样的。它使得突然出现了大量的垃圾对象,空闲空间必然减少,从而大大增加了下一次创建新对象时强制主GC的机会。
7. 关于垃圾回收的几点补充
可以发现垃圾回收有以下的几个特点：
（1）垃圾收集发生的不可预知性：由于实现了不同的垃圾回收算法和采用了不同的收集机制，所以它有可能是定时发生，有可能是当出现系统空闲CPU资源时发生，也有可能是和原始的垃圾收集一样，等到内存消耗出现极限时发生，这与垃圾收集器的选择和具体的设置都有关系。
（2）垃圾收集的精确性：主要包括2 个方面：（a）垃圾收集器能够精确标记活着的对象；（b）垃圾收集器能够精确地定位对象之间的引用关系。前者是完全地回收所有废弃对象的前提，否则就可能造成内存泄漏。而后者则是实现归并和复制等算法的必要条件。所有不可达对象都能够可靠地得到回收，所有对象都能够重新分配，允许对象的复制和对象内存的缩并，这样就有效地防止内存的支离破碎。
（3）现在有许多种不同的垃圾收集器，每种有其算法且其表现各异，既有当垃圾收集开始时就停止应用程序的运行，又有当垃圾收集开始时也允许应用程序的线程运行，还有在同一时间垃圾收集多线程运行。
（4）垃圾收集的实现和具体的JVM 以及JVM的内存模型有非常紧密的关系。不同的JVM 可能采用不同的垃圾收集，而JVM 的内存模型决定着该JVM可以采用哪些类型垃圾收集。现在，HotSpot 系列JVM中的内存系统都采用先进的面向对象的框架设计，这使得该系列JVM都可以采用最先进的垃圾收集。
（5）随着技术的发展，现代垃圾收集技术提供许多可选的垃圾收集器，而且在配置每种收集器的时候又可以设置不同的参数，这就使得根据不同的应用环境获得最优的应用性能成为可能。
针对以上特点，我们在使用的时候要注意：
（1）不要试图去假定垃圾收集发生的时间，这一切都是未知的。比如，方法中的一个临时对象在方法调用完毕后就变成了无用对象，这个时候它的内存就可以被释放。
（2）Java中提供了一些和垃圾收集打交道的类，而且提供了一种强行执行垃圾收集的方法--调用System.gc()，但这同样是个不确定的方法。Java 中并不保证每次调用该方法就一定能够启动垃圾收集，它只不过会向JVM发出这样一个申请，到底是否真正执行垃圾收集，一切都是个未知数。
（3）挑选适合自己的垃圾收集器。一般来说，如果系统没有特殊和苛刻的性能要求，可以采用JVM的缺省选项。否则可以考虑使用有针对性的垃圾收集器，比如增量收集器就比较适合实时性要求较高的系统之中。系统具有较高的配置，有比较多的闲置资源，可以考虑使用并行标记/清除收集器。
（4）关键的也是难把握的问题是内存泄漏。良好的编程习惯和严谨的编程态度永远是最重要的，不要让自己的一个小错误导致内存出现大漏洞。
（5）尽早释放无用对象的引用。大多数程序员在使用临时变量的时候，都是让引用变量在退出活动域(scope)后，自动设置为null，暗示垃圾收集器来收集该对象，还必须注意该引用的对象是否被监听，如果有，则要去掉监听器，然后再赋空值。