深入理解JVM-垃圾收集器与内存分配策略

Posted 2020-08-17 bad_boy_f

在上面一篇文章中，介绍了java内存运行时区域，其中程序计数器、虚拟机栈、本地方法栈3个区域随线程生灭；栈中的栈帧随着方法的进入和退出而有条不紊的执行着进栈出栈的操作，每一个栈帧中分配着多少内存基本上是在类结构确定下来就已知的，因此这几个区域的内存的分配和回收都具有确定性。在方法接受时内存就已经回收了。java堆和好方法区则不一样，一个接口的多个实现类需要的内存可能不一样，一个方法的多个分支需要的内存也可能不一样，我们只有在程序运行时才能知道需要创建哪些对象。这部分内存的分配和回收都是动态的，垃圾回收器也就是关注的这里。

判断对象是否存活：

一：引用计数器法

给对象添加一个引用计数器，每当有一个地方引用时加一，引用失效时减一，计数器为0就不肯能在次使用。但是这有个问题，循环问题没法解决。

二：可达性分析算法

这个算法的基本思路就是根据一系列的成为“GC Roots”的对象作为起始点向下搜索，搜索所走的过的路径成为引用链，当一个对象的GC Roots没有任何引用链项链时，则书名对象不可用。

java中，可作为GCRoots的对象包括：

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

引用

无论用哪种方法判断，最终都有引用有关，在JDK1.2以前，定义如果reference类型的数据中储存的数值代表的是另外一块内存的起始地址，就成这块内存代表着一个引用。JDK1.2以后，对引用进行了扩充，分为强引用，软引用、弱引用、虚引用。

• 强引用，普遍存在的，类似Object obj = new Object()这样的，这要强引用还存在，那么就不会回收被引用的对象
• 软引用，表述一些有用但非必要的对象。在系统将要发生内存溢出异常之前，将会把这些对象列进回收范围之中进行二次回收，如果这次回收还没有足够的内存，才会抛出内存溢出异常。
• 弱引用，也是描述有用但非必要的对象。但它比软引用更若一些。被弱引用引用的对象只能存活到下次垃圾回收之前，垃圾收集开始，无论内存是否够，这些对象都会被回收。
• 虚引用，一个对象是否有虚引用不会对其生存时间有印象。也无法根据虚引用获取对象，虚引用的目的在这个对象被回收之前受到一个系统通知。

 

即使经过可达性分析算法中不可达的对象，也并非是非死不可的，这时候他们暂时出入死缓，正真的一个对象的死亡，至少要经过两次标记过程：如果对象在经过可达性分析后没发现GC Roots相连的引用链，那么会被第一次标记，并且进行依次筛选，筛选的条件是有没有必要执行finalize()方法，当对象没有覆盖finalize方法或者finalize方法已经被虚拟机调用过，这两种情况都视为没有必要执行。

如果判断为有必要执行finalize方法，那么这个对象会被放进一个叫F-Queue的队列中，并在稍后有虚拟机自动建立的，低优先级的Finalizer线程去执行。这里执行只是保证虚拟机去触发，并不保证会等待它执行结束，原因是如果一个对象的finalize方法执行过慢或发生死循环，导致F-Queue队列其他对象永久处于等待。finalize()方法是对象逃脱死亡的最后依次机会。稍后F-Queue中的对象进行第二次小规模的标记，如果对象要在finalize()方法成功解决自己——只要重新在与引用链上的如何一个对象建立关联即可。如把this赋值给某个变量，那么在第二次回收时就会被移出即将回收的集合；如果没有逃脱，那么就基本会被回收了。这里注意一下，并不建议在finalize方法中手动救活对象。

回收方法区

很多人认为方法区（或者HotSpot虚拟机的永久代）是没有垃圾收集的。java虚拟机规范中也说可以要求虚拟机在方法区不实现垃圾收集，而且在方法区进行垃圾收集的性价比比较低，在堆中，尤其是新生代，常规应用进行依次垃圾收集可以回收%70-%95的空间。

永久代的垃圾收集分为两部分，废弃常亮和无用的类。废弃常量指如果一个字符串“a”已经进入常量池，但是当前系统没有任何一个String对象指向它，也没有其他任何地方引用了这个字面量，如果这是进行垃圾回收，那么这个字符串就会被清理出常量池，字段的符号引用也类似。

判断一个类是否无用，需满足3个条件：

1. 该类所有的实例已经被回收，也就是java堆中不存在该类的任何实例。
2. 加载该类的classloader已经被回收
3. 改类的java.lang.Class对象没有在任何地方被引用。无法在任何地方通过反射找到该类的方法。

这也只是“可以”，是否对类回收，HotSpot虚拟机提供了-Xnoclassgc参数控制。还可以使用-verbose:class 以及 -XX:+TraceClassCoading（product版的虚拟机）、-XX:+TraceClassUnLoading（FastDebug版虚拟机）查看类加载情况和卸载情况。

垃圾手机算法

标记-清除算法（Mark-Sweep）

基础的收集算法是“标记-清除”(Mark-Sweep)算法。如同它的名宇一样,算法分为“标记”和"清除”两个阶段:首先标记出所有需要回收的对象,在标记完成后统一回收所有被标 记的对象,之所以说它是最基础的收集算法,是因为后续的收集算法都基于这种思路并对其不足进行改进而得到的。它的主要不足有两个:一个是效率问题,标记和清除两个过程的效率都不高:另一个是空间问题,标记和淸除之后会产生大量不连续的内存碎片,空间碎片太多可能会导致以后在运行过程中需要分配较大对象时，无法找到足够的连续内存而不得不提前触发另一次垃圾收集动作

 

复制

为了解决效乎问题，一种称为“复制”(Copying〉的收集算法出现了,它将可用内存按容量划分为大小相等的两块,每次只使用其中的一块，当这一块的内存用完了,就将还存活着的对象复制到另外一块上面,然后再把已使用过的内存空间一次清理掉，这样使得每次都是对整个半区进行内存回收。内存分配时也就不用考虑内存碎片等复杂情况，只要移动堆顶指针,按顺序分配内存即可,实现简单,运行髙效，只是这种算法的代价是将内存缩小为原来的一半,未免太高了一点

 

 

标记整理

根据年老代的特点，有人提出“标记-整理”（Mark-Compact）算法，标记过程仍然与“标记-清除”一样，但后续步骤是让所有存活的对象向一端移动。然后清理掉端边意外的内存。

 

 分代收集算法

当前商业虚拟机垃圾收集算法都采用分代收集算法，根据对象的存活周期将内存分为几块，一般把java堆分为新生代，年老代。这样根据各个年代的特点采用不同的算法，新生代，每次都有大量的对象死去，只有少量存活，那就采用复制算法。年老代对象存活率高，没有额外的动检对其进行担保，就采用“标记-清理”或者“标记-整理”算法来进行回收。

 HotSpot的算法实现

枚举根节点

从可达性分析中从GC Roots节点找引用链操作为例，可作为GC Roots根节点的主要咋全局性的引用（常亮或静态类的属性）与执行上下文（例如帧栈中的本地变量表）中，现在很多应用，仅仅方法区就哟数百兆，入股逐个检索引用，那么会非常费时间。另外，可达性分析算法在时间的敏感还提现在GC停顿上，因为这项工作必须在一个确保一致性的快照中进行，一致性指在整个分析期间执行系统看起来就像在一个被冻住的某个时间点上。这点是导致GC进行时必须停止所有的java执行线程（stop the world）的一个重要原因。即使在号称几乎不会发生停顿的CMS收集器中，枚举根节点时也是必须要停顿的。

现在主流java虚拟机都是用准确式GC，所以当执行系统停顿后，并不需要逐个检查执行上下文和全局的引用位置，虚拟机应当有办法知道哪些地方存放着对象引用。在HotSpot虚拟机中，使用一组OopMap的数据来实现，在类加载完成的时候，HotSpot就把对象内存什么偏移量上是什么类型的数据计算出来，在JIT编译过程中，也会在特定的位置记录下栈和寄存器中哪些位置是引用。这样GC在扫描时就可以直接得知这些信息了。

安全点

但是，可以导致OopMap变化的指令非常多，如果每个指令都生成对应的OopMap，那么需要大量额外的空间，这样GC的空间成本将会很高。

实际上，HotSpot在特定的时间点上才会记录这些信息，这些位置成为安全点（Safepoint），只有在安全点才能暂停。Safepoint既不能选的太少以至于让GC等待时间过长，也不能频繁增加运行时的负荷。所以，安全点的选定基本上是已程序“是否具有让程序长时间执行的特征”为标准进行选定的。长时间运行的明显特征是指令序列复用，如方法调用，循环跳转，异常跳转等。还有一个要考虑的是怎么让所有的线程都同时在安全点停止下来。两种方法：抢先式中断和主动式终端。抢先式中断是在不需要执行代码主动配置，在GC发生时，把所有线程中断，如果发现有线程中断的地方不在安全点上那么就恢复线程。让它跑到安全点上。现在几乎没有抢先式中断。

主动式中断的思想是当GC需要中断的时候，不直接对线程操作。仅仅简单的设置一个标志。各个线程执行时主动轮询这个标志，为真时自动挂起。轮询点和安全点是重合的，另外在加上创建对象所需要赔内存的地方。

使用safepoint已经完美的解决了如果进入GC的问题，但是实际情况却不一定。只是保证了执行时，不执行呢如程序睡眠，这时候线程无法响应JVM的中断请求，走到安全的地方去中断挂起。JVM也不太可能等待线程重新分配CPU时间。这种情况就需要saferegion来解决。安全区域指在一段代码中应用关系不会发生变化，在任意地方开始GC都是安全的。在线程执行到saferegion中的代码时，首先标识自己已经进入了Safe Region，那样，当在这段时间了要发起GC时，就不用管标识自己为safe point状态的线程了。当要离开Safe Region时，它要检查系统是否已经完成了根节点枚举（或是整个GC过程）。如果完成了就继续执行，否则就等待，知道受到可以安全离开的信号。