JVM垃圾回收与内存分配策略

一、垃圾回收算法

1. 概述
   JVM中，当创建的对象不再被使用的时候，此时我们认为他是无用的“垃圾”；在现代主流的商用jvm中，都是通过可达性分析来判断对象是否存活的。这个算法的基本思想是通过一系列“GCROOT”的对象来作为起始点，从这些节点开始向下搜索，搜索所做过的路径称为引用链，当一个对象没有任何引用链可达时，就判断该对象不可用。如下图，obj5，obj6，obj7虽然相连，但是没有引用链到达“GCROOT”，因此它也是不可用的。
   

那么在java中，哪些对象可以作为“GCROOT”呢？

• 虚拟机栈（栈帧中的本地变量表）中引用的对象。
• 方法区中类静态属性引用的对象。
• 方法区中常量引用的对象。
• 本地方法栈中JNI（即一般说的Native方法）引用的对象。

回收方法区(永久代的垃圾回收)
永久代的垃圾回收“性价比”远不如年轻代。永久代的垃圾收集主要包括两部分：

1. 废弃的常量
   常量池中的常量不再被引用时，认为废弃了。
2. 无用的类
   无用的类判断必须满足一下三个条件：
   1. 该类所有的实例都已经被回收，也就是Java堆中不存在该类的任何实例。
   2. 加载该类的ClassLoader已经被回收。
   3. 该类对应的java.lang.Class对象没有在任何地方被引用，无法在任何地方通过反射访问该类的方法。

二、 垃圾回收算法

1. 标记-清除算法
2. 复制算法
3. 标记-整理算法
4. 分代收集算法

• 标记-清除算法
  分为“标记”和“清除”两个阶段，首先标记出所有需要回收的对象，在标记完成后统一回收被标记的对象。
  缺点：

  1. 一是效率问题，标记和清除两个过程的效率都不高；
  2. 而是空间问题，标记清除之后会产生大量的内存碎片。太多的内存碎片会导致以后创建较大的对象时，因无法找到连续内存而提前触发GC。
     

• 复制算法
  将可用的内存按容量划分为大小相等的两块，每次只使用一块，当这一块使用完了之后，将这块还存活的对象复制到另一块上面去，然后再把已经使用的内存块一次清理掉。这样解决了内存碎片的问题。
  缺点：

  1. 将内存缩小为原来的一半，代价太高了。
     
     现代的商业虚拟机中，针对以上复制算法的缺点，将内存分为一块较大的Eden空间和两块较小的Survivor空间，每次使用Eden和其中一块Survivor。当回收时，将Eden和Survivor中还存活着的对象一次性地复制到另外一块Survivor空间上，最后清理掉Eden和刚才用过的Survivor空间。HotSpot虚拟机默认Eden和Survivor的大小比例是8:1，也就是每次新生代中可用内存空间为整个新生代容量的90%（80%+10%），只有10%的内存会被“浪费”。当Survivor空间不够用时，需要依赖其他内存（这里指老年代）进行分配担保（Handle Promotion）。

• 标记-整理算法
  标记过程仍然与“标记-清除”算法一样，但后续步骤不是直接对可回收对象进行清理，而是让所有存活的对象都向一端移动，然后直接清理掉端边界以外的内存。
  

• 分代收集算法
  这种算法并没有什么新的思想，只是根据对象存活周期的不同将内存划分为几块。一般是把Java堆分为新生代和老年代，这样就可以根据各个年代的特点采用最适当的收集算法。在新生代中，每次垃圾收集时都发现有大批对象死去，只有少量存活，那就选用复制算法，只需要付出少量存活对象的复制成本就可以完成收集。而老年代中因为对象存活率高、没有额外空间对它进行分配担保，就必须使用“标记—清理”或者“标记—整理”算法来进行回收。

安全点和安全区域(GC发生的时机) 参照深入理解jvm虚拟机 3.4.2章节

三、垃圾收集器

1. Serial收集器
2. ParNew收集器
3. Parallel Scavenge收集器
4. Serial Old收集器
5. Parallel Old收集器
6. CMS收集器（Concurrent Mark Sweep）
7. G1收集器

• CMS收集器
  CMS收集器是一种以获取最短回收停顿时间为目标的收集器。是基于“标记-清除”算法实现的。它的运行过程包括以下四个步骤：

  • 初始标记（CMS initial mark）
  • 并发标记（CMS concurrent mark）
  • 重新标记（CMS remark）
  • 并发清除（CMS concurrent sweep）

  其中，初始标记、重新标记这两个步骤仍然需要“Stop The World”。初始标记仅仅只是标记一下GC Roots能直接关联到的对象，速度很快，并发标记阶段就是进行GC RootsTracing的过程，而重新标记阶段则是为了修正并发标记期间因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间一般会比初始标记阶段稍长一些，但远比并发标记的时间短。

由于整个过程中耗时最长的并发标记和并发清除过程收集器线程都可以与用户线程一起
工作，所以，从总体上来说，CMS收集器的内存回收过程是与用户线程一起并发执行的。通过下图可以比较清楚地看到CMS收集器的运作步骤中并发和需要停顿的时间。

• G1收集器
  待完善

四、java内存分配和回收策略

Java技术体系中所提倡的自动内存管理最终可以归结为自动化地解决了两个问题：

1.  给对象分配内存
2.  回收分配给对象的内存

• 对象优先在Eden分配
  大多数情况下，对象在新生代Eden区中分配。当Eden区没有足够空间进行分配时，虚拟机将发起一次Minor GC。
  参数设置：

-XX：+PrintGCDetails   打印这个收集器日志参数
	// 这3个参数限制了Java堆大小为20MB，不可扩展，其中10MB分配给新生代，剩下的10MB分配给老年代。
-Xms20M、-Xmx20M、-Xmn10M
	// Eden区与一个Survivor区的空间比例是8:1 
-XX：SurvivorRatio=8

• 大对象直接进入老年代
  什么是大对象呢？就是需要大量分配连续空间的java对象。典型的比如长字符串以及数组。
• 长期存活的对象将进入老年代
  对象在Survivo去熬过了15岁(每次MinorGC长一岁)，那么就可以晋升到老年代。
• 动态对象年龄判定
  为了能更好地适应不同程序的内存状况，虚拟机并不是永远地要求对象的年龄必须达到了MaxTenuringThreshold才能晋升老年代，如果在Survivor空间中相同年龄所有对象大小的总和大于Survivor空间的一半，年龄大于或等于该年龄的对象就可以直接进入老年代，无须等到MaxTenuringThreshold中要求的年龄。
• 空间分配担保
  Survivor区晋升到老年代的时候需要判断老年代的最大可用的连续空间是否大于新生代所有存活对象的总和，如果成立，那么Minor GC是安全的。否则就要看看是否允许担保，如果允许，那么老年代会以历代晋升老年代的对象大小平均值来担保风险。如果不允许，那么就要进行一次Full GC。