JVM(3) 垃圾收集器与内存分配策略
一、垃圾收集的概念
在Java虚拟机运行时数据区中程序计数器、虚拟机栈和本地方法栈3个区域随线程而生，随线程而灭；栈中的栈帧随着方法的进入和退出而有条不紊地执行着出栈和入栈操作，每一个栈帧中分配多少内存基本上是在类结构确定下来时就已知的，因此这几个区域的内存分配和回收都具备确定性，因为方法结束或线程结束时，内存自然就跟随着回收了。
而Java堆和方法区则不一样，一个接口的多个实现类需要的内存可能不一样，一个方法中的多个分支需要的内存也可能不一样，只有在程序处于运行期间时才能知道会创建哪些对象，这部分内存的分配和回收都是动态的，垃圾收集器所关注的是这部分内存。
二、判断Java堆和方法区中的是否需要垃圾回收
1.如何判断对象是否“存活”，从而通知GC进行收集
（1）引用计数算法
引用计数算法就是：给对象中添加一个引用计数器，每一个地方引用它时，计数器值就加1；当引用失效时，计数器值就减1；任何时刻计数器为0的对象就是不可能再被使用的。引用计数算法的实现简单，判定效率也很高，在部分情况下是一个不错的算法，但是最大的问题就是很难解决对象间相互循环引用的问题。
例如：对象objA和对象objB都有字段instance，令objA.instance = objB，objB.instance=objA，除此之外，这两个对象再无任何引用，实际上这两个对象已经不可能再被访问，但是它们因为互相引用着对方，导致它们的引用计数器都不为0，于是引用计数器算法无法通知GC收集器回收它们。
（2）可达性分析算法
主流的商用程序语言都是通过可达性分析算法来判定对象是否存活的。可达性分析算法就是：有一系列的称为“GC Roots”的对象放在一个GC Root Set集合中，从这些节点开始向下搜索，搜索所走过的路径称为引用链，当GC Roots对象到某一个对象不可达时，则证明此对象是不可用的，所以会被判定成可回收的对象。
Java中，可作为GC Roots的对象包括下面几种：
- 虚拟机栈（栈帧中的本地变量表）中引用的对象
- 方法区中类静态属性引用的对象
- 方法区中常量引用的对象
- 本地方法栈中JNI（即Native方法）引用的对象
2.Java中引用的概念
在JDK1.2之后，Java中引用的概念分为四种，强引用、软引用、弱引用、虚引用，这4种引用强度依次逐渐减弱。
- 强引用。类似“Object obj = new Object()”，只要强引用还存在，垃圾收集器永远不会回收掉被引用的对象
- 软引用。用来描述一些还有用但并非必须的对象。对于软引用关联着的独享，在系统将要发生内存溢出异常之前，将会把这些对象列进回收范围之中进行第二次回收。如果这次回收还没有足够的内存，才会抛出内存溢出异常。
- 弱引用。也是用来描述非必需对象的，但是它的强度比软引用更弱一些，被弱引用关联的对象只能生存到下一次垃圾收集发生之前。当垃圾收集器工作时，无论当前内存是否足够，都会回收掉只被弱引用关联的对象
- 虚引用。是最弱的一种引用关系。一个对象是否有虚引用的存在，完全不会对其生存时间构成影响，也无法通过虚引用来取得一个对象的实例。为一个对象设置虚引用关联的唯一目的就是能在这个对象被收集器回收时收到一个系统通知。
3.可达性分析算法判定的“缓刑”到“死亡”--finalize()方法
可达性分析算法中不可达的对象暂时处于“缓刑”阶段，要真正宣告一个对象死亡，至少要经历两次标记过程：
（1）如果对象在进行可达性分析后发现诶呦与GC Roots相连接的引用链，那它将会被第一次标记并且进行一次筛选，筛选的条件是此对象是否有必要执行finalize()方法。当对象没有覆盖finalize()方法，或者finalize()方法已经被虚拟机调用过，虚拟机将这种情况都视为“没有必要执行”。如果这个对象被判定有必要执行finalize()方法，那么这个对象将会放置在一个叫做F-Queue的队列之中，并在稍后由一个由虚拟机自动建立的、低优先级的Finalizer线程去执行它。这里所谓的“执行”是指虚拟机会出发这个方法，但并不承若会等待它运行结束，因为如果一个对象在finalize()方法中执行缓慢，或者发生了死循环，将很可能会导致F-Queue队列中其他对象永久处于等待，甚至导致整个内存回收系统崩溃。finalize()方法时对象逃脱死亡命运的最后一次机会。一个对象的finalize()方法最多只会被系统执行一次。
（2）GC对F-Queue队列中的对象进行第二次小规模的标记，如果对象要在finalize()方法中成功拯救自己---只要重新与引用链上的任何一个对象建立关联即可，例如把自己（this）赋值给某个类变量或者对象的成员变量，那么在第二次标记时它将被移除“即将回收”集合；如果对象这时候还没有逃脱，那基本上就要被真正回收了。
4.回收方法区
方法区（永久代）的垃圾收集主要收集两部分内容：废弃常量和无用的类。
（1）判定一个常量是否为“废弃常量”
回收废弃常量与回收Java堆中的堆中的对象非常相似。以常量池中字面量的回收为例，加入一个字符串“abc”已经进入了常量池中，但是当前系统没有任何一个String对象是叫做“abc”的，换句话说，就是没有任何String对象引用常量池中的“abc”常量，也没有其他地方引用了这个字面量，如果此时发生内存回收，而且必要的话，这个“abc”常量就会被系统清理出常量池。常量池中的其他类（接口）、方法、字段的符号引用都与此类似。
（2）判定一个类是否是“无用的类”
- 该类所有的实例都已经被回收，也就是Java堆中不存在该类的任何实例
- 加载该类的ClassLoader已经被回收
- 该类对应的java.lang.Class对象没有在任何地方被引用，无法在任何地方通过反射访问该类的方法。
三、垃圾收集算法
1.标记-清除算法（Mark-Sweep）
“标记-清除”算法是最基础的垃圾收集算法。算法分为“标记”和“清除”两个阶段：首先标记处所有需要回收的对象，在标记完成后同一回收所有被标记的对象。
主要不足有两个：一个是效率问题，标记和清除两个过程的效率都不高；另一个是空间问题，标记清除之后会产生大量不连续的内存碎片，空间碎片太多可能会导致以后在程序运行过程中需要分配较大对象时，无法找到足够的连续内存而不得不提前触发一次垃圾收集动作。
2.复制算法（Copying）
“复制”算法，将可用内存按容量划分为大小相等的两块，每次只使用其中的一块。当这一块的内存用完了，就将还存活着的对象复制到另外一块上面，然后再把已使用过的内存空间一次清理掉。这样使得每次都是对整个半区进行内存回收，内存分配时也就不用考虑内存碎片等复杂情况，只要移动堆顶指针，按顺序分配内存即可，实现简单，运行高效。只是这种算法的代价是将内存缩小为原来的一般，未免太高了一点。
实际应用中，并不需要按照1:1的比例来划分内存空间，而是将内存分为一块较大的Eden空间和两块较小的Survivor空间，每次使用Eden和其中一块Survivor。当回收时，将Eden和Survivor中还存活着的对象一次性地复制到另外一块Survivor空间上，最后清理掉Eden和刚才用过的Survivor空间。HotSpot虚拟机默认Eden和Survivor的大小比例是8:1，也就是每次新生代中可用内存空间为整个新生代容量的80%+10%=90%，只有10%的内存会被“浪费”。然而，不能保证每次回收都只有不多于10%的对象存活，当Survivor空间不够用时，需要依赖其他内存（老年代）进行分配担保。即如果另外一块Survivor空间没有足够空间存放上一次新生代收集下来的存活对象时，这些对象将直接通过分配担保机制进入老年代。
3.标记-整理算法（Mark-Compact）
“复制”收集算法在对象存活率较高时就要进行较多的复制操作，效率将会变低。更关键的是，如果不想浪费50%的空间，就需要有额外的空间进行分配担保，以应对被使用的内存中所有对象都100%存活的极端情况，所以在老年代一般不能直接选用“复制”算法。
根据老年代的特点，“标记-整理”算法的标记过程仍然和“标记-清除”算法一样，但是后续步骤不是直接对可回收对象进行清理，而是让所有存活的对象都向一端移动，然后直接清理掉端边界以外的内存。
4.分代收集算法（Generational Collection）
当代商用虚拟机的垃圾收集都采用“分代收集”算法，即根据对象存活周期的不同将内存划分为几块。一般是把Java堆分为新生代和老年代，这样就可以根据各个年代的特点采用最适当的收集算法。在新生代中，每次垃圾收集时都发现有大批对象死去，只有少量存活，那就选用“复制”算法，只需要付出少量存活对象的复制成本就可以完成收集。而老年代中因为对象存活率高、没有额外空间对它进行分配担保，就必须使用“标记-清理”或者“标记-整理”算法来进行回收。
四、HotSpot算法实现
分为枚举根结点、安全点、和安全区域三部分。
五、垃圾收集器
主要有7种：Serial、ParNew、Parallel Scavenge、Serial Old、Parallel Old、CMS、G1
六、内存分配与回收策略
Java体系中所提倡的自动内存管理最终可以归结为自动化地解决了两个问题：给对象分配内存以及回收分配给对象的内存。
对象的内存分配，往大方向讲，就是在堆上分配（但也可能经过JIT编译后被拆散为标量类型并间接地在栈上分配），对象主要分配在新生代的Eden区上，如果启动了本地线程分配缓冲，将按线程优先在TLAB上分配。少数情况下也可能会直接分配在老年代中，分配的规则不是百分百确定的，其细节取决于当前使用的是哪一种垃圾收集器组合，还有虚拟机中与内存相关的参数的设置。
首先了解两个概念：
- 新生代GC（Minor GC）：指发生在新生代的垃圾收集动作，因为Java对象大多数都具备朝生夕灭的特征，所以Minor GC非常频繁，一般回收速度也比较快。
- 老年代GC（Major GC/Full GC）：指发生在老年代的GC，出现了Major GC，经常会伴随至少一次的Minor GC。Major GC的速度一般会比Minor GC慢10倍以上。
1.对象优先在Eden分配
大多数情况下，对象在新生代Eden区中分配。当Eden区没有足够空间进行分配时，虚拟机将发起一次Minor GC。
例如，在运行时通过-Xms20M、-Xmx20M，-Xmn10M这3个参数限制了Java堆大小为20M不可扩展，其中10MB分配给新生代，剩下的10MB分配给老年代。-XX:SurvivorRatio=8，决定了新生代中Eden区与一个Survivor区的空间比例是8:1。那么，新生代中的结构是：“eden space 8192K”、“from space 1024K”和“to space 1024K”，新生代总可用空间8192KB+1024KB=9216KB，即Eden区加上1个Survivor区的总容量。
假设首先需要分配内存给3个2MB大小的对象，那么Eden区就被占用了6MB。当新来一个4MB大小的对象时，这个时候由于4+6>8，因此需要发生Minor GC，而又由于Survivor区的大小为1MB，最小的2MB也无法放入，因此只能通过分配担保机制提前转移到老年代去。此时Eden区占用4MB，而老年代区占用了6MB。
2.大对象直接进入老年代
大对象是指需要大量连续内存空间的Java对象，例如很长的字符串以及数组。经常出现大对象容易导致内存还有不少空间时就提前出发垃圾收集以获取足够的连续空间来“安置”它们。
虚拟机提供了一个-XX:PretrnureSizeThreshold参数，令大于这个设置值的对象直接在老年代分配。这样做的目的是避免在Eden区及两个Survivor区之间发生大量的内存复制，因为新生代采用复制算法收集内存。
例如，如果使用“-XX:PretrnureSizeThreshold = 3145728”，那么超过3MB的对象都会直接在老年代进行分配。
3.长期存活的对象将进入老年代
虚拟机采用了分代收集的思想来管理内存，那么内存回收时就必须能识别哪些对象应该放在新生代，哪些对象应该放在老年代。为了做到这一点，虚拟机给每个对象定义了一个对象年龄（Age计数器）。如果对象在Eden出生并经过第一次Minor GC后仍然存活，并且能被Survivor容纳的话，将被移动到Survivor空间中，并且对象年龄设为1。对象在Survivor区每“熬过”一次Minor GC，年龄就增加1岁，当它的年龄增加到一定程度（默认为15岁），就将会被晋升到老年代中。对象晋升老年代的年龄阈值，可以通过参数-XX:MaxTenuringThreshold设置。
4.动态对象年龄判定
为了能更好地适应不同程序的内存状况，虚拟机并不是永远地要求对象的年龄必须达到了MaxTenuringThreshold才能晋升老年代，如果在Survivor空间中相同年龄所有对象大小的总和大于Survivor空间的一半，那么年龄大于或等于该年龄的对象就可以直接进入老年代，无须等到MaxTenuringThreshold中要求的年龄。
例如：Eden区大小8MB，两个Survivor区大小各1MB，老年代10MB，年龄阈值15岁。那么对象1大小为256KB进入Eden区，对象2大小也为256KB也进入Eden区，然后第1个4MB大小的对象3进入Eden区，接着第2个4MB大小的对象4要进入时，发生了一次Minor GC，这个时候对象1和对象2进入到Survivor区，年龄都为1岁，然而由于对象1和对象2加起来等于8MB，根据实际情况，肯定也是超过了Eden区的大小限制（还有一些其他的）因此，对象3进入老年代，接着第3个大小为4MB的对象5进入时，发生了第二次Minor GC，此时由于256×2=512KB>1MB/2所以对象1和对象2直接从Survivor区进入到老年代，同理对象4也进入老年代。
5.空间分配担保
在发生Minor GC之前，虚拟机会先检查老年代最大可用的连续空间是否大于新生代所有对象总空间，如果这个条件成立，那么Minor GC可以确保是安全的。如果不成立，则虚拟机会查看HandlePromotionFailure设置值是否允许担保失败。如果允许，那么会继续检查老年代最大可用的连续空间是否大于历次晋升到老年代对象的平均大小，如果大于，将尝试着进行一次Minor GC，尽管这次Minor GC是有风险的；如果小于，或者HandlePromotionFailure设置不允许冒险，那这时也要改为进行一次Full GC。
解释一下“风险”：新生代使用“复制”收集算法，但为了内存利用率，只使用其中一个Survivor空间来作为轮换备份，因此当出现大量对象在Minor GC后仍然存活的情况（最极端的情况就是内存回收后新生代中所有对象都存活），就需要老年代进行分配担保，把Survivor无法容纳的对象直接进入老年代。老年代要进行这样的担保，前提是老年代本身还有容纳这些对象的剩余空间，一共有多少对象会存活下来在实际完成内存回收之前是无法明确知道的，所以只好取之前每一次回收晋升到老年的对象容量的平均大小值作为经验值，与老年代的剩余空间进行比较，决定是否进行Full GC来让老年代腾出更多空间。
取平均值进行比较其实仍然是一种动态概率的手段，如果某次Minor GC后存活的对象突增，远远高于平均值的话，仍然会导致担保失败HandlePromotionFailure，如果出现了担保失败，那就只好在失败后重新发起一次Full GC。
JDK 6 Update 24之后的规则变为：只要老年代的连续空间大于新生代对象总大小或者历次晋升到老年代的对象容量的平均大小就会进行Minor GC，否则就会进行Full GC。
