JVM读书笔记（二）：垃圾收集器与内存分配策略

垃圾收集器与内存分配策略

-XX:+PrintGCDetails

一、概述

垃圾收集器关注的内存：方法区、java堆（因为这部分内存的分配和回收都是动态的）

二、对象已死吗（判断对象是否存活）

计数算法：

给对象中添加一个引用计数器，每当有一个地方引用它时，加一，引用失效时，减一

主流的java虚拟机不采用这种方法，原因：

难以解决对象之间的循环引用问题

可达性分析算法

通过一系列成为“GC ROOTS”的对象作为起始点，从这些节点开始向下搜索，搜索所走过的路径称为引用链，

当一个对象到GC ROOTS没有任何引用链相连时，则证明此对象是不可用的

可作为GC ROOTS的对象：

虚拟机栈（栈帧中的本地变量表）中引用的对象

方法区中类静态属性引用的对象

方法区中常量引用的对象

本地方法栈中JNI引用的对象

关于引用

强———————————————–》弱

强引用—》软引用—》弱引用—》虚引用

强引用：只要强引用存在，GC永远不会回收掉被引用的对象

软引用：（SoftReference）描述还有用但并非必须的对象，在系统将要发生内存溢出异常之前，会把这些对象列进回收范围中
进行第二次回收，如果还是没有足够的内存，才报OOM

弱引用：（WeakReference）描述非必须对象，被弱引用关联的对象只能生存到下一次垃圾收集发生之前

虚引用：（PhantomReference）一个对象是否有虚引用完全不会影响其生存时间，也无法通过虚引用来取得对象实例。

为一个对象设置虚引用关联的唯一目的：能在这个对象被收集器回收时收到一个系统通知

生死存亡（两次标记）

如果对象在进行可达性分析后发现没有雨GC ROOTS的引用链：

进行第一次标记并筛选，删选条件：此对象是否有必要执行finalize方法。
若对象没有覆盖finalize方法或该方法已经被虚拟机调用过，则认为没有必要执行

若认为有必要执行，对象被放置到F-Queue中，由Finalizer线程去触发其finalize方法，此时是对象拯救自身的最后机会，可以通过finalize方法将自己移出回收
队列，稍后GC进行第二次标记。两次标记结束后，还在回收队列的被回收。

可怜的finalize方法，不要去用它。

回收方法区

无用类：

java堆中不存在该类的任何实例
加载该类的ClassLoader已经被回收
该类的Class对象没有在任何地方被引用，无法在任何地方通过反射访问该类的方法

-verbose:class

-XX:+TraceClassLoading -XX:+TraceClassUnLoading

在大量使用反射、动态代理、CGLib、JSP、OSGI等频繁自定义ClassLoader的场景都需要虚拟机具备类卸载的功能，以保证
方法区不会溢出

三、GC算法

1、标记-清除算法

标记出所有需要回收的对象，标记完成后统一回收所有被标记的对象。

不足：

1、效率：标记和清除两个过程的效率都不高
2、空间：标记清除后会产生大量不连续的内存碎片

2、复制算法(主要用来回收新生代)

解决效率问题：将可用内存按容量划分为大小相等的两块，每次只使用其中的一块。当这一块的内存用完了，就将还存活的对象复制到另外一块上面，然后把已使用

的内存一次清理掉。

代价：将内存缩小为了原来的一半

实际的实现方式：由于新生代能存活下来的很少，按8:1:1来划分一个Eden空间和两个Survivor空间，每次使用一个Eden和一个Survivor来轮流倒

问题：为什么要用两个survivor：结合复制算法，防止单个survivor在GC时碎片化

由于没有办法保证每次回收都只有不到10%的对象存活，当空的哪个Survivor不够用时，需要依赖其他内存（老年代）进行分配担保。

3、标记-整理算法（针对老年代）

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

四、HotSpot的算法实现

1、枚举根节点

准确式GC：存放的内容是值还是地址可以区分

GC时必须停顿所有执行线程（Stop the world），确保一致性

HotSpot中使用OopMap来进行GC ROOTS的枚举

2、安全点

只有在安全点处生成OopMap，程序执行时并非在所有地方都能停顿下来开始GC，只有在到达安全点时才能暂停

安全点通常在一些“长时间执行”的指令上（指令序列复用），如方法调用、循环跳转、异常跳转等

问题：如何在GC时让所有线程跑到安全点上停下：

主动式中断：在安全点上放置一个轮询标志，各个线程执行时主动去轮询这个标志，发现中断标志为真时就自己中断挂起

3、安全区域

扩展的安全点，处理程序Sleep或Block时的情况

五、垃圾收集器

1、Serial收集器（新生代）

进行垃圾收集时，必须暂停其他所有工作线程，直到收集结束

到现在为止，依然是虚拟机运行在Client模式下的默认新生代收集器（简单高效）

2、ParNew收集器（新生代）

Serial收集器的多线程版本

运行在Server模式下的虚拟机的首选的新生代收集器（除Serial外唯一能和CMS配合的）

并行（Parallel）：多条垃圾收集线程并行工作，但用户线程仍处于等待状态
并发（Concurrent）：用户线程与垃圾收集线程同时执行

3、Parallel Scavenge收集器（新生代）

关注点不同，其他收集器关注停顿时间，Parallel Scavenge关注吞吐量

停顿时间越短越适合需要与用户交互的程序，良好的响应速度可以提升用户体验
高吞吐量可以尽快完成程序的运算任务，适合在后台运行不需要太多交互的任务

4、Serial Old收集器（老年代）

Serial收集器的老年代版本，使用标记-整理算法

主要给Client模式下的虚拟机使用

5、Parallel Old收集器（老年代）

主要用于配合Parallel Scavenge收集器

6、CMS收集器（老年代）

目标：获取最短回收停顿时间

网站、B/S系统的服务端

使用标记-清除算法

运作过程;

初始标记（Stop the world）：标记GC ROOTS直接关联的对象，速度很快
并发标记：进行GC ROOTS TRACING
重新标记（Stop the world）：修正并发标记期间因用户程序继续运作而导致标记产生变动的一部分对象的标记记录
并发清除

缺点：

占CPU
无法处理浮动垃圾
产生内存碎片

7、G1收集器

面向服务端应用

并行、并发
分代收集，也可以独立管理整个GC
空间整合：整体基于标记-整理算法，局部基于复制算法，不会产生内存空间碎片
可预测的停顿：

六、内存分配与回收策略

1、对象优先在Eden分配

Eden区没有足够空间进行分配时，虚拟机将发起一次Minor GC

2、大对象直接进入老年代

-XX:+PretenureSizeThreshold=…

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

每个对象有一个年龄计数器，对象在Eden出生经过第一次Minor GC如果还在，进入Survivor并将年龄变为1，此后每经历一次Minor GC，年龄就增加1，
默认15岁时晋升到老年代

4、动态对象年龄判定

如果在Survivor空间中相同年龄的对象大小总和大于Survivor空间的一半，年龄大于或等于该年龄的对象就会直接进入老年代

5、空间分配担保

在发生Minor GC之前，虚拟机会先检查老年代最大的连续空间是否大于新生代所有对象总空间，如果这个条件成立，那么Minor可以确保是安全的。

如果不够空间，full GC