GC 垃圾收集器 内存分配 读笔

GC

GC需要完成的3件事情：

• 哪些内存需要回收
• 什么时候进行回收
• 怎么进行回收

在之前介绍中，程序计数器，虚拟机栈，本地方法栈的生命周期和线程保持一致，生则生，死则死；因此这几个区域的内存分配和回收都具有确定性，在方法或者线程结束时，内存自然回收。而Java堆与方法区内存的分配和回收都是动态的，垃圾收集器主要关注的就是这个部分的内存。

对象存活性的判断：
在垃圾收集器对堆回收之前，需要判断哪些对象还是存活的，哪一些死亡，判定算法：

• 引用计数法（Reference Counting）：
  实现：通过给对象添加一个引用计数器，被引用则数值加1；引用失效，数值减1；当数值为0，则不可能再被使用。
  优点：实现方式简单，判断效率高。
  缺点：1.对象每次被引用或者失效，都必须对引用计数进行修改，程序整体的性能会受到影响。
  2.难以解决对象之间循环引用的问题，如下。

class A{
  public B b;

}
class B{
  public A a;
}
public class Main{
    public static void main(String[] args){
    A a = new A();
    B b = new B();
    a.b=b;
    b.a=a;
    }
}

如上相互引用的情况下，a，b都不可能再被访问，但是由于相互引用则对方，引用计数都不为0，则无法被回收。

• 可达性分析法（Reachability Analysis）：
  实现：通过一些称为“GC Roots”的对象作为起始点，从这些节点开始向下搜索，搜索走过的路径称为引用链（Reference Chain），当一个对象与GC Roots之间没有任何引用链相连（即对象与GC Roots之间不可达），则不可用。
  
  GC Roots的对象：
• 虚拟机栈（栈帧中的本地变量表）中引用的对象。
• 方法区中类静态属性引用的对象。
• 方法区中常量引用的对象。
• Native方法引用的对象。

引用：
JDK1.2之前，引用指reference类型数据中存储的数值代表的另一块内存的起始地址。JDK1.2后，扩充了引用的概念，将是否回收随内存空间状况而变化。

• 强引用（Strong Reference）：代码中最普遍必须的引用，主要强引用还存在，垃圾收集器永远不会回收被引用的对象。
• 软引用（Soft Reference）：描述一些还有用但非必须的对象。在发生内存溢出异常之前，将会把这类对象列进第二次回收。
• 弱引用（Weak Reference）：描述非必须对象，强度比软引用软。该类对象只能生存到下一次垃圾收集器发生之前，无论当前内存是否足够，都会被回收。
• 虚引用（Phantom Reference）：最弱的引用关系。虚引用不会对生存时间造成影响，也无法通过其获取对象实例。唯一目前是当这个对象被回收时会受到一个系统通知。

回收过程：
在可达性分析算法中不可达的对象，处于“缓刑”阶段。
对象的要经历两个标记阶段才会真正的死亡。
finalize（）方法：子类覆盖该方法以实现资源的清理工作。不推荐使用该方法，因为其运行代价高昂，不确定性大，无法保证各个对象的调用顺序。

• 第一次标记：
  对象没有引用，那么对象会被第一次标记并进行一次筛选，筛选的条件是是否有必要执行finalize方法，如果该对象没有覆盖finalize方法或者finalize方法已经被虚拟机执行过那么没必要执行。
• 第二次标记：
  如果有必要执行finalize 方法，那么对象会被放到一个F-queue的队列中，并在稍后由一个虚拟机建立的低优先级的Finalizer线程去执行，但不保证等待执行结束，如果一个对象finalize方法执行缓慢或者发生了死循环，就会导致队列中其他对象处于等待状态。

finalize（）方法是对象逃脱的最后一次机会：

• 对象在被GC时可以自救，在finalize（）方法中，重新与引用链上任何一个对象建立链接，在第二次标记过程中将被移除出即将回收合集。
• 这种机会只有一次，一个对象的finalize（）方法最多只会被自动调用一次。

回收方法区：
方法区的垃圾收集效率低，但是还是必要的。
回收内容：

• 废弃常量：当一个常量不存在被引用，即为废弃常量，可被回收。
• 无用的类：需同时满足以下3个条件：
  
  • 该类所有的实例都已经被回收，Java堆中不存在任何该类的实例。
  • 加载该类的ClassLoader已经被回收。
  • 该类对应的Java.lang.Class对象没有再任何地方被引用，无法再任何地方通过反射访问该类的方法。

垃圾回收算法：

• 标记-清除算法（Mark-Sweep）：
  实现：此算法执行分两阶段。第一阶段从引用根节点开始标记所有被引用的对象，第二阶段遍历整个堆，把未标记的对象清除。
  缺点：1.效率问题，标记和清除两个过程效率都不高。 2.会产生大量不连续的内存碎片，可能会导致在分配较大对象时，无法找到足够连续空间，提前触发GC。
  
• 复制算法（Copying）：
  实现：此算法把内存空间划为两个相等的区域，每次只使用其中一个区域。垃圾回收时，遍历当前使用区域，把正在使用中的对象复制到另外一个区域中。每次算法每次只处理正在使用中的对象，因此复制成本比较小，同时复制过去以后还能进行相应的内存整理，不过出现”碎片”问题。
  缺点：将内存缩小了一半。 在对象存活率较高情况下，需较多复制操作，效率低。
  优化：实际中，可将内存划分为一块较大的Eden空间与两块较小的Survivor空间（比例为8：1），每次使用Eden与一块Survivor，将还存活对象复制到另一个Survivor中。利用率得到了较大改善，现在商业虚拟机都采用该算法。
  
• 标记-整理算法（Mark-Compact）：
  实现：两阶段，第一阶段从根节点开始标记所有被引用对象，第二阶段遍历整个堆，把清除未标记对象并且把存活对象”压缩”到堆的其中一块，按顺序排放。
  优点：避免了标记-清除算法的内存碎片问题。避免了复制算法的空间问题。
  
• 分代收集算法（Generational Collection）：
  实现：基于对对象生命周期分析后，把对象分为年青代、年老代，对不同生命周期的对象使用不同的算法（上述一种，不同年代使用不太算法）进行回收。
  
  • 新生代：每次垃圾收集，都有大批对象死去，采用复制算法。
  • 老年代：对象存活率高，没有额外空间对其分配担保，则采用“标记-整理”算法。

实际实现优化：
枚举根节点：
在查找GC Roots过程中，为了避免逐个检查引用，则通过“准确式GC”，即虚拟机有办法知道哪些地方存着对象引用（HotSpot中，通过一组OopMap数据结构实现）。

安全点：由于需要将程序所有地方都停顿下来开始GC，则处于效率考虑，只能在一些“特点位置（安全点）”暂停。
安全点因为不能太少而使GC时间过长，不能太多而使频繁GC，则以“是否让程序长时间执行的特征”为标准选定，由于指令执行时间都很短，则特征等同为“指令序列复用”。
怎么使GC发生时所有线程到最近的“安全点”再停顿：

• 抢先式中断：当GC发生，先中断所有线程，再使不在安全点的线程再运行到“安全点”上。
• 主动式中断：设置一个Flag，FLag检验位于“安全点”重合，通过这个Flag告知线程是否需要中断，需要则各自中断。

垃圾收集器

收集算法是内存回收的理论，垃圾收集器是内存回收的具体实现。
JVM规范对于垃圾收集器的实现没有任何规定，则不同厂商，版本的虚拟机提供的垃圾收集器可能不同，一般会提供参数供用户以自身特点和要求组合各个年代使用的收集器，下以HotSpot虚拟机为例。

如图，有7种作用于不同分代的收集器，两个收集器自己存在连线，则表示可以搭配使用；所属区域表示是新生代还是老年代的收集器。

• Serial收集器：
  新生代收集器，复制算法，单线程收集器：只会使用一个收集线程去完成垃圾收集；在其进行垃圾收集时，必须暂停其他所有工作线程（包括用户正常使用的线程），直到其收集结束。
  优点：简单高效。在限定单个CPU环境下，由于没有线程交互的开销，具有最高的单线程收集效率。
  
• ParNew收集器：
  新生代收集器，复制算法，多线程收集器：使用多个收集线程去完成垃圾收集；其余行为（包括Serial收集器可用的所有控制参数、收集算法、Stop The World、对象分配规则、回收策略）与Serial收集器完全一样。
  优点：除Serial收集器，只有其可以和CMS收集配合工作。由于线程交互的开销，在CPU数非常多的情况下，才会有较好的效果。
  

• Parallel Scavenge收集器：
  新生代收集器，复制算法，多线程收集器，“吞吐量优先”收集器。
  特点：关注点与其他收集器不同。CMS等收集器以尽可能缩短收集时用户线程的停顿时间；其目标是达到一个可控制的吞吐量（CPU用于运行用户代码时间/运行用户代码时间+垃圾收集时间）。
  关注点不同，使用情况不同：

  • 停顿时间短：使用需要和用户交互的程序，良好的响应速度能提升用户体验。
  • 高吞吐量：高效率的利用CPU时间。

• Serial Old收集器：
  老年代收集器，“标记-整理”算法，单线程收集器。
  用途：1.在JDK1.5之前版本，与Parallel Scavenge收集器搭配使用。2.作为CMS收集器的后备方案。
  

• Parallel Old收集器：
  老年代收集器，“标记-整理”算法，多线程算法，“吞吐量优先”算法。
  在注重吞吐量预计CPU资源敏感的场合，都可以优先采用Parallel Scavenge加Parallel Old收集器搭配使用。
  

• CMS收集器（Concurrent Mark Sweep）：
  老年代收集器，“标记-清除”算法，并发收集器（垃圾收集线程与用户线程（基本上）同时工作），重视服务的响应速度，以获取最短回收停顿时间为目标的收集器。
  运作过程：
  

  • 初始标记（CMS initial mark）：需要“Stop The World”，标记GC Roots能直接关联到的对象，速度快。
  • 并发标记（CMS concurrent mark）：进行GC Roots Tracing（以GC Roots为根的深搜）。
  • 重新标记（CMS remark）：需要“Stop The World”，修正并发标记期间因为用户程序继续运作而导致标记产生变动的那一部分对象的标记记录。 该阶段停顿时间稍大于初始标记，远小于并发标记，所以值得。
  • 并发清除（CMS concurrent sweep）：并发清除标记对象。
    整体过程中耗时最长的并发标记和并发清除过程收集器线程都可以与用户进程一起工作，则总体上，CMS收集器的内存回收过程是和用户线程并发执行的。
    缺点：1.CMS收集器对CPU资源非常敏感。2.CMS收集器无法处理浮动垃圾（即在并发清理阶段用户线程产生的垃圾）。 3.由于基于“标记-清除”算法，可能会有大量空间碎片产生，提前引发Full GC。

• G1收集器（Garbage-First）：
  最先进的收集器，面向服务端应用。
  特点：

  • 并行与并发 ：能充分利用多CPU，多核环境来缩短“Stop The World”停顿时间，以并发方式让Java程序继续运行。
  • 分代收集：能够独立管理整个GC堆，能采用不同方式处理不同年代的对象以获取更好的收集效果。
  • 空间整合：由于整体上基于“标记-整理”算法，运行期间不会产生内存空间碎片，有利于长时间运行。
  • 可预测的停顿：降低停顿时间，能建立可预测的停顿时间模型。通过有计划地避免整个GC堆的全区域垃圾回收，以优先列表维护回收队列，优先升级回收价值大的Region。

  运行过程：类似于CMS收集器的回收过程
  

  • 初始标记（Initital Marking）:需要“Stop The World”，标记GC Roots能直接关联到的对象，并且修改TAMS（Next Top at Mark Start）的值，速度快。
  • 并发标记（Concurrent Marking）：进行GC Roots Tracing（以GC Roots为根的深搜）。
  • 最终标记（Final Making）：需要“Stop The World”，修正并发标记期间因为用户程序继续运作而导致标记产生变动的那一部分对象的标记记录。
  • 筛选标记（Live Data Counting and Evacuation）：先对各个Region的回收价值和成本进行排序，根据用户期望的GC停顿制定回收计划。（可并发执行，但是停顿用户线程将大幅提高收集效率）

内存分配

对象优先在Eden分配:
大多数情况下，对象在新生代Eden区中分配。当Eden区没有足够空间进行分配，则将发起一次Minor GC（新生代GC）。

大对象直接进入老年区：
大对象：需要大量连续内存空间的Java对象。（如极长的字符串以及数组）
通过数组-XX：PrerenureSizeThreshold参数，大于该设置值的对象直接在老年代分配，避免在Eden区以及两个Survivor区之间发生大量的内存复制。

长期存活的对象将进入老年区：
每个对象被定义了一个对象年龄（Age）计数器。
当对象在Eden出生并经过第一场Minor GC后仍然存在，并且能被Survivor容纳的话，将被移动到Survivor空间，并且年龄设置为1。对象在Survivor区每经过一个Minor GC,年龄增加1，当年龄大于一定值（默认15，可通过-XX:MaxTenuringThreshold设置），将进入老年区。

动态对象年龄判定：
当Survivor空间内相同年龄所有对象大小的总和大于Survivor空间的一半，则年龄大于等于该年龄的对象就可以直接进入老年区。

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

JDK 6 Update 24之后的规则变为:不再考虑是否允许担保失败,只要老年代的连续空间大于新生代对象总大小或者历次晋升的平均大小就会进行Minor GC，否则将进行Full GC。