GC基本概念和常见问题

JVM内存模型及分区，每个区放什么

堆里面的分区：Eden，survival from，survival to，老年代，各自的特点

GC的三种收集方法：标记清除、标记整理、复制算法的原理与特点，分别用在什么地方

Minor GC与Full GC分别在什么时候发生

新生代GC（MinorGC）：指发生在新生代的垃圾收集动作，因为Java对象大多都具备朝生夕灭的特性，所以Minor GC非常频繁，一般回收速度也比较快。

老年代GC（Major GC/Full GC）：指发生在老年代的GC，出现了Major GC，经常会伴随至少一次的Minor GC（但非绝对的，在Parallel Scavenge收集器的收集策略里就有直接进行MajorGC的策略选择过程）。Major GC的速度一般会比MinorGC慢10倍以上。

GC是什么

分代收集算法 Generational Collection
根据对象存活周期的不同将内存划分为几块。

新生代：大批对象死去，少量存活，使用复制算法
老年代：对象存活率高，没有额外空间进行分配担保，使用 标记清除或者标记压缩算法
次数上频繁收集Young区
较少收集Old区
基本不动Perm区

GC收集四大算法

引用计数算法

一般不使用
缺点：
每次对对象赋值时均要维护引用计数器，且计数器本身也有一定的消耗
较难处理循环引用

复制算法 Copying

新生代中使用的是Minor GC，这种GC算法采用的是复制算法
原理：
从根集合 GC Root开始，通过Tracing从Survive From中找到存货对象，拷贝到Survive To中
From、To交换身份，下次内存从To开始，重复复制的操作
优点：
没有标记和清除的过程，效率高
没有内存碎片，可以利用bump-the-pointer实现快速内存分配
缺点：需要双倍空间

如果对象的存活率很高，假设是100%存活，那么需要将所有的对象都复制一遍，并将所有的引用地址复制一遍。复制花费的时间，在对象多时，不可忽视。
所以复制算法要想使用，对象存活率要非常低，而且最重要的是，必须要克服50%内存的浪费。

实际应用中，商业JVM采用这种算法回收新生代，将内存分为一块较大的Eden区和两块较小的Survivor空间，每次使用Eden和其中一块Survivor。
当回收时，将Eden和Survivor中还存活这的对象一次性地复制到另一块Survivor空间。
HotSpot虚拟机默认Eden和Survivor的大小比例是8:1。每次只有10%内存会被“浪费”。
当Survivor空间不够用（存活对象占用空间>10%）时，需要依赖其他内存（老年代）进行分配担保 Handle Promotion。

标记清除 Mark-Sweep

原理：
标记 Mark，从跟集合开始扫描，对存活的对象进行标记
清楚 Sweep，扫描整个空间，回收未被标记的对象，使用free-list记录可以区域
优点：
不需要两倍的内存
缺点：
需要扫描两次，耗时严重，效率低
在进行GC时，需要停止应用程序，会导致用户体验差
内存不连续，会产生内存碎片，需要存入大容量对象时，不得不再次进行GC

标记压缩 Mark-Compact / 标记整理

原理：
标记 Mark，与标记清除一样
压缩 Compact，再次扫描，并往一端滑动存活对象
缺点：
效率不高，不仅要标记所有粗诺对象，还要整理所有存活对象的引用地址，效率要低于复制算法

标记清除压缩 Mark-Sweep-Compact

老年代一般使用标记清除或者标记清除与标记整理混合实现
原理：
Mark-Sweep和Mark-Compact的结合
和Mark-Sweep一致，当进行多次GC后才Compact

内存效率

复制算法>标记清除算法>标记压缩算法（此处的效率只是对比时间复杂度，不是真是情况）

内存整齐度

复制算法=标记压缩算法>标记清除算法

内存利用率

标记压缩算法=标记清除算法>复制算法

年轻代 Young Gen

区域相对老年代较小，对象存活率低
这种情况复制算法的回收整理速度是最快的
复制算法的效率只和当前存活对象的大小有关

老年代 Tenure Gen

区域较大，对象存活率高
一般用标记清除或者标记清除和标记压缩混合实现GC
标记阶段的开销与存入对象的数量成正比
这对于老年代，标记清除或者标记压缩有些不合适，但可以通过多核/线程利用，用并发、并行的形式提升标记效率

四种引用类型

强引用 Strong Reference

程序中普遍存在的，类似 Object obj = new Object()
只要强引用还存在，垃圾收齐器就永远不会回收掉被引用的对象

软引用 Soft Reference

用来描述一些还有用但非必须的对象。在系统将要发生内存溢出异常之前，会把这些对象列进回收范围中进行第二次回收。如果这次回收还没有足够的内存，才会抛出内存溢出异常。

弱引用 Weak Reference

也是用来描述非必须对象的，但是它的强度比软引用更弱一些。
被弱引用关联的对象只能生存到下一次垃圾收集发生前。
当垃圾收集器工作时，无论当前内存是否足够，都会回收掉被弱引用关联的对象。

虚引用 Phantom Reference

也成为幽灵引用或者幻影引用，它是最若的一种引用关系。
一个对象是否有虚引用的存在，完全不会影响其生存时间，也无法通过虚引用来去的一个对象的实例。
为一个对象设置虚引用的位移目的就是能在这个对象被收集器回收时收到一个系统通知。

对象内存分配的一般规则

对象优先在Eden分配

对象在新生代Eden区中分配
当Eden区没有足够空间进行分配时，虚拟机将发起一次Minor GC

几个参数设置的含义

-XX:PrintGCDetails： 收集器日志参数，告诉虚拟机在发生垃圾收集行为时打印内存回收日志，并且在进程退出时输出当前的内存各区域分配情况
Xms20m： 最小堆内存20M
Xmx20m： 最大堆内存20M（堆内存补课扩展）
Xmn10m： 新生代10M（剩下老年代10M）
-XX:SurvivorRatio=8： 新生代中Eden区与一个Survivor区的空间比例是8:1

大对象直接进入老年代

所谓的大对象是指，需要大量连续内存空间的Java对象，最典型的大对象就是那种很长的字符串以及数组（[byte]数组就是典型的大对象）。
大对象对虚拟机的内存分配来说就是一个坏消息（替Java虚拟机抱怨一句，比遇到一个大对象更加坏的消息就是遇到一群“朝生夕灭”的“短命大对象”，写程序的时候应当避免），
经常出现大对象容易导致内存还有不少空间时就提前触发垃圾收集以获取足够的连续空间来“安置”它们。

-XX:PretenureSize Threshold参数：

令大于这个设置值的对象直接在老年代分配。这样做的目的是避免在Eden区及两个Survivor区之间发生大量的内存复制（新生代采用复制算法收集内存）。

长期存活的对象将进入老年代

虚拟机给每个对象定义了一个对象年龄（Age）计数器。
如果对象在Eden出生并经过第一次Minor GC后仍然存活，并且能被Survivor容纳的话，将被移动到Survivor空间中，并且对象年龄设为1。
对象在Survivor区中每“熬过”一次Minor GC，年龄就增加1岁，当它的年龄增加到一定程度（默认为15岁），就将会被晋升到老年代中。
对象晋升老年代的年龄阀值，可以通过参数-XX:：Max Tenuring Threshold设置。

动态对象年龄判定

为了能更好地适应不同程序的内存状况，虚拟机并不是永远地要求对象的年龄必须达到了MaxTenuringThreshold才能晋升老年代
如果在Survivor空间中相同年龄所有对象大小的总和大于Survivor空间的一半，年龄大于或等于该年龄的对象就可以直接进入老年代，无须等到MaxTenuring Threshold中要求的年龄。
例如 bojA objB年龄都是2，两个对象的内存大于Eden空间的一半且不能被回收，就会直接被转移进入老年代

空间分配担保

在发生Minor GC之前，虚拟机会先检查老年代最大可用的连续空间是否大于新生代所有对象总空间，如果这个条件成立，那么Minor GC可以确保是安全的。
如果不成立，则虚拟机会查看HandlePromotionFailure设置值是否允许担保失败。如果允许，那么会继续检查老年代最大可用的连续空间是否大于历次晋升到老年代对象的平均大小，如果大于，将尝试着进行一次Minor GC，尽管这次Minor GC是有风险的；如果小于，或者HandlePromotionFailure设置不允许冒险，那这时也要改为进行一次Full GC。

冒险

下面解释一下“冒险”是冒了什么风险，前面提到过，新生代使用复制收集算法，但为了内存利用率，只使用其中一个Survivor空间来作为轮换备份，因此当出现大量对象在MinorGC后仍然存活的情况（最极端的情况就是内存回收后新生代中所有对象都存活），就需要老年代进行分配担保，把Survivor无法容纳的对象直接进入老年代。与生活中的贷款担保类似，老年代要进行这样的担保，前提是老年代本身还有容纳这些对象的剩余空间，一共有多少对象会活下来在实际完成内存回收之前是无法明确知道的，所以只好取之前每一次回收晋升到老年代对象容量的平均大小值作为经验值，与老年代的剩余空间进行比较，决定是否进行Full GC来让老年代腾出更多空间。
取平均值进行比较其实仍然是一种动态概率的手段，也就是说，如果某次Minor GC存活后的对象突增，远远高于平均值的话，依然会导致担保失败（Handle Promotion Failure）。如果出现了HandlePromotionFailure失败，那就只好在失败后重新发起一次Full GC。虽然担保失败时绕的圈子是最大的，但大部分情况下都还是会将HandlePromotionFailure开关打开，避免Full GC过于频繁，请读者在JDK6Update24之前的版本中运行测试。