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

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

3.1 概述

垃圾收集（Garbage Collection，GC），需要完成三件事情：

  1. 哪些内存需要回收？
  2. 什么时候回收？
  3. 如何回收？

 

3.1.1 哪些内存需要回收？

程序计数器、Java虚拟机栈、本地方法栈这三个区域随线程而生，随线程而灭（Java虚拟机栈中的栈帧随着方法的进入和退出而有条不紊地执行入栈和出栈操作，并且每一个栈帧中分配多少内存基本上在类结构确定下来时就已知的）。因此这几个区域的内存分配和回收都具备确定性，在这几个区域内就不需要过多考虑回收的问题，因为方法结束或者线程结束时,内存自然就跟随着回收了。

垃圾回收主要是针对 Java 堆和方法区进行，因为这些区域是动态的。比如，一个接口中的多个实现类需要的内存可能不一样；一个方法中的多个分支需要的内存也可能不一样（类信息等存储在方法区）；我们只有在程序处于运行期间才能知道会创建哪些对象（实例对象存储在Java堆），这部分内存的分配和回收都是动态的。

从JVM区域结构看，可将这些区域划分为“静态内存”和“动态内存”两类。程序计数器、虚拟机栈、本地方法3个区域是“静态”的，因为这几个区域的内存分配和回收都具备确定性，都随着线程而生，随着线程而灭。但Java堆和方法区不一样，内存分配都存在不确定性，只有在程序处于运行期间才能知道会创建哪些对象，这部分内存和回收都是动态的，垃圾收集器所关注的是这部分内存。

 

3.2 判断对象是否可回收？

3.2.1 引用计数算法

在对象中添加一个引用计数器，每当有一个地方引用它时，计数器值就加一；当引用失效时，计数器值就减一；任何时刻计数器为零的对象就是不可能再被使用的。

优点：实现简单

缺点：很难解决对象之间的相互循环引用的问题

实验：引用计数算法不能解决对象之间的相互循环引用问题，并且Java语言也没有使用该算法来管理内存

package JVM;
/*
 *     VM args: 
 *     -verbose:gc
    -Xms20m
    -Xmx20m
    -Xmn10m
    -XX:+PrintGCDetails
    -XX:SurvivorRatio=8
 */

public class test1 {    
    public Object instance = null;
    
    private static final int _1MB = 1024 * 1024;
    
    /*
     * 该成员属性的唯一意义就是占点内存
     */
    private byte[] bigSize = new byte[2* _1MB];
    
    public static void testGC() {
        test1 objA = new test1();
        test1 objB = new test1();
        
        objA.instance = objB;
        objB.instance = objA;
        
        objA = null;
        objB = null;
        
        System.gc();
    }
    
    public static void main(String[] args) {
        testGC();
    }
    
}
[GC (System.gc()) [PSYoungGen: 5079K->768K(9216K)] 5079K->776K(19456K), 0.0007377 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
[Full GC (System.gc()) [PSYoungGen: 768K->0K(9216K)] [ParOldGen: 8K->522K(10240K)] 776K->522K(19456K), [Metaspace: 2574K->2574K(1056768K)], 0.0038099 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
Heap
 PSYoungGen      total 9216K, used 82K [0x00000000ff600000, 0x0000000100000000, 0x0000000100000000)
  eden space 8192K, 1% used [0x00000000ff600000,0x00000000ff614920,0x00000000ffe00000)
  from space 1024K, 0% used [0x00000000ffe00000,0x00000000ffe00000,0x00000000fff00000)
  to   space 1024K, 0% used [0x00000000fff00000,0x00000000fff00000,0x0000000100000000)
 ParOldGen       total 10240K, used 522K [0x00000000fec00000, 0x00000000ff600000, 0x00000000ff600000)
  object space 10240K, 5% used [0x00000000fec00000,0x00000000fec82bb8,0x00000000ff600000)
 Metaspace       used 2580K, capacity 4486K, committed 4864K, reserved 1056768K
  class space    used 285K, capacity 386K, committed 512K, reserved 1048576K

testGC()方法:对象objA和objB都有字段instance，赋值令objA.instance=objB及objB.inst ance=objA，除此之外，这两个对象再无任何引用，实际上这两个对象已 经不可能再被访问，但是它们因为互相引用着对方，导致它们的引用计数都不为零，引用计数算法也就无法回收它们。但实际上我们可以清楚地看到GC日志中“PSYoungGen: 768K->0K(9216K)”。这意味着虚拟机并没有因为这两个对象互相引用就放弃回收它们，这也从侧面说明了Java虚拟机并不是通过引用计数算法来判断对象是否存活的。

 

3.2.2 可达性分析算法

当前主流的商用程序语言(Java、C#等)的内存管理子系统，都是通过可达性分析(Reachability Analysis)算法来判定对象是否存活的。这个算法的基本思路就是通过一系列称为“GC Roots”的根对象作为起始节点集，从这些节点开始，根据引用关系向下搜索，搜索过程所走过的路径称为“引用链”(Reference Chain)，如果某个对象到GC Roots间没有任何引用链相连， 或者用图论的话来说就是从GC Roots到这个对象不可达时，则证明此对象是不可能再被使用的。如图3-1所示，对象object 5、object 6、object 7虽然互有关联，但是它们到GC Roots是不可达的， 因此它们将会被判定为可回收的对象。

那GC Roots一般都包括哪些内容呢？

  1. 虚拟机栈（栈帧中的本地变量表）中引用的对象。
  2. 方法区中类静态属性引用的对象。如Java类的引用类型静态变量
  3. 方法区中常量引用的对象。如字符串常量池(String Table)里的引用。
  4. 本地方法栈中JNI（即一般说的Native方法）引用的对象。

 

3.2.3 再谈“引用”

在可达性分析算法中谈论到了“引用”。其传统定义为：如果$reference$类型的数据存储的数值代表的是另外一块内存的起始地址，就称该reference数据是代表某块内存、某个对象的引用。在JDK1.2之后，Java对“引用”的概念进行了扩充。

每种编程语言都有自己操作内存中元素的方式，例如在 C 和 C++ 里是通过指针，而在 Java 中则是通过“引用”。由于在 Java中一切都被视为了对象，所以操作的标识符实际上是对象的一个引用（reference）。

String str; //创建了一个引用str，引用可以独立存在，并不一定需要与一个对象关联
String str = new String("abc"); //通过将这个叫“引用”的标识符指向某个对象，之后便可以通过这个引用来实现操作对象了。

分为了强引用(Strongly Reference)、软引用(Soft Reference)、弱引用(Weak Reference)和虚引用(Phantom Reference)4种，这4种引用强度依次逐渐减弱。主要有两个目的：第一是可以让程序员通过代码的方式决定某些对象的生命周期；第二是有利于JVM进行垃圾回收。

  1. 强引用：指在程序代码之中普遍存在的引用赋值，如下：无论在任何情况下，只要强引用关系还存在，垃圾收集器就永远不会回收掉被引用的对象。哪怕是内存不足时，JVM也会直接抛出OutOfMemoryError而不会去回收。如果想中断强引用与对象之间的联系，可以显示的将强引用赋值为null，JVM就可以适时的回收对象了。 
    Object obj = new Object(); ////只要obj还指向Object对象，Object对象就不会被回收
    obj = null； //中断强引用与Object对象之间的联系
  2. 软引用：用来描述一些还有用，但非必须的对象。对于只被软引用关联着的对象，在内存足够的时候，软引用对象不会被回收，只有在内存不足时，系统则会回收软引用对象，如果回收了软引用对象之后仍然没有足够的内存，才会抛出内存溢出异常。在JDK 1.2版之后提供了SoftReference类来实现软引用。这个特性很适合用来实现缓存：比如网页缓存、图片缓存等。 
    Object obj = new Object();
SoftReference<Object> sf = new SoftReference<Object>(obj);

     

  3. 弱引用：用来描述那些非必须对象，但它的强度比软引用更弱一些，无论当前内存是否足够，只要 JVM 开始进行垃圾回收，那些只被弱引用关联的对象都会被回收。在JDK 1.2版之后提供了WeakReference类来实现弱引用 
    Object obj = new Object();
WeakReference<Object> wf = new WeakReference<Object>(obj);
  4. 虚引用：也称为“幽灵引用”或者“幻影引用”，它是最弱的一种引用关系。一个对象是否有虚引用的存在，完全不会对其生存时间构成影响，也无法通过虚引用来取得一个对象实例。为一个对象设置虚引用关联的唯一目的只是为了能在这个对象被收集器回收时收到一个系统通知。在JDK 1.2版之后提供 了PhantomReference类来实现虚引用。

 

3.2.4 fianlize()

即使在可达性分析算法中判定为不可达的对象，也不是“非死不可”的，这时候它们暂时还处于“缓刑”阶段，要真正宣告一个对象死亡，至少要经历两次标记过程:

  1. 如果一个对象在进行可达性分析后发现没有与GC Roots相连接的引用链，那它将会被第一次标记并且进行一次筛选，筛选的条件是此对象是否有必要执行finalize()方法。（注：finalize()是Object中的方法，当垃圾回收器将要回收对象所占内存之前被调用，即当一个对象被虚拟机宣告死亡时会先调用它finalize()方法，让此对象处理它生前的最后事情。假如对象没有覆盖finalize()方法，或者finalize()方法已经被虚拟机调用过，那么虚拟机将这两种情况都视为“没有必要执行”）。
  2. 对于没有必要执行finalize()方或者没有在finalize()中成功拯救自己（只要重新与引用链上的任何一个对象建立关联即可）。在第二次标记时不会被移出“即将回收”的集合，那他基本上就真的要被回收了。

 

如果这个对象被判定为确有必要执行finalize()方法，那么该对象将会被放置在一个名为F-Queue的队列之中，并在稍后由一条由虚拟机自动建立的、低调度优先级的Finalizer线程去执行它们的finalize()方法（对那些有finalize方法的对象，把他们放到专门用来执行Finalize方法的线程），并逐一执行之finalize方法。）。

这里所说的“执行”是指虚拟机会触发这个方法开始运行，但并不承诺一定会等待它运行结束。 这样做的原因是，如果某个对象的finalize()方法执行缓慢，或者更极端地发生了死循环，将很可能导致F-Queue队列中的其他对象永久处于等待，甚至导致整个内存回收子系统的崩溃。finalize()方法是对象逃脱死亡命运的最后一次机会(比喻得很形象)，稍后收集器将对F-Queue中的对象进行第二次小规模的标记，如果对象要在finalize()中成功拯救自己——只要重新与引用链上的任何一个对象建立关联即可，譬如把自己 (this关键字)赋值给某个类变量或者对象的成员变量，那在第二次标记时它将被移出“即将回收”的集 合;如果对象这时候还没有逃脱，那基本上它就真的要被回收了。

package JVM;

import java.lang.ref.SoftReference;

public class FinalizeEscapeGC {
    public static FinalizeEscapeGC SAVE_HOOK = null;
    
    public void isAlive() {
        System.out.println("Yes, I am still alive :)");
    }
    
    @Override
    protected void finalize() throws Throwable {    //GC前，让对象处理最后的事情，只会被系统自动调用一次
        super.finalize();
        System.out.println("finalize method executed!");
        FinalizeEscapeGC.SAVE_HOOK = this;    //this指向的是当前对象，对象把自己赋值给某一个类变量，成功救了自己
        //System.out.println("哈希码：" + this.hashCode());
    }
    
    public static void main(String[] args) throws InterruptedException {
        SAVE_HOOK = new FinalizeEscapeGC();    //SAVE_HOOK是类变量，指向的是FinalizeEscapeGC
        //System.out.println("哈希码：" + SAVE_HOOK.hashCode());
        
        /*
         * 对象第一次成功save
         */
        SAVE_HOOK = null;
        
        System.gc();//主动通知垃圾回收
        
        //因为Finalizer方法的优先级比较低，暂停0.5s，以等待它
        Thread.sleep(500);
        
        if(SAVE_HOOK != null) {    //类变量指向了对象FinalizeEscapeGC
            SAVE_HOOK.isAlive();
        }else {
            System.out.println("No, I am dead! :(");
        }
        
        /*
         * 对象第二次没能save，因为finalize只能执行一次
         */
        SAVE_HOOK = null;
        System.gc();
        Thread.sleep(500);
        
        if(SAVE_HOOK != null) {
            SAVE_HOOK.isAlive();
        }else {
            System.out.println("No, I am dead! :(");
        }
    }
    
}
finalize method executed!
Yes, I am still alive :)
No, I am dead! :(

《深入理解Java虚拟机》的作者建议大家尽量避免使用它，因为它的运行代价高昂，不确定性大，无法保证各个对象的调用顺序，如今已被官方明确声明为不推荐使用的语法。finalize()能做的所有工作，使用try -finally或者其他方式都可以做得更好、 更及时，所以作者建议大家完全可以忘掉Java语言里面的这个方法。

 

3.2.5 运行时方法区的回收

因为方法区主要存放永久代对象（但最好不要认为方法区是永久代的），而永久代对象的回收率比新生代差很多，因此在方法区上进行回收性价比不高。

在方法区主要是对常量池的回收和对类的卸载。

  • 常量池的回收和Java堆中对象回收类似，如没有任何String对象或者别的地方引用常量池中的“abc”常量，则发生内存回收，它则会被回收掉，其他的符号引用也是如此。
  • 类的卸载条件很多，需要满足以下三个条件，并且满足了也不一定会被卸载：
  1. 该类所有的实例都已经被回收，也就是 Java 堆中不存在该类的任何实例。
  2. 加载该类的ClassLoader已经被回收。
  3. 该类对应的java.lang.Class对象没有在任何地方被引用，也就无法在任何地方通过反射访问该类方法。

是否对类回收，HotSpot虚拟机提供的-Xnoclassgc参数来控制是否对类进行卸载。还可以使用-verbose:class以及-XX:+TraceClassLoading、-XX: +TraceClassUnLoading查看类加载和卸载信息。

 

3.3 垃圾收集算法

3.3.1 标记-清除算法

方法：首先标记出所有需要回收的对象，在标记完成后统一回收所有被标记的对象

优点：简单，适合老年代使用。

缺点：①、效率问题，标记和清除两个过程的效率都不高；②、空间问题，如上图所示，标记清除之后会产生大量不连续的内存碎片（空间碎片太多会导致以后在程序运行过程中需要分配较大对象时，无法找到足够大的连续内存而不得不提前触发另一次垃圾收集动作）。

 

3.3.2 复制算法

首先，它将可用内存按容量划分为大小相等的两块，每次只使用其中的一块。当这一块的内存用完了，就将还存活着的对象复制到另外一块上面，然后再把已使用过的内存空间一次清理掉。这样使得每次都是对整个半区进行内存回收，内存分配时也就不用考虑内存碎片等复杂情况，只要移动堆顶指针，按顺序分配内存即可。

优点：不会产生内存碎片。

缺点：内存使用效率不高，只是使用了一半的内存。不适用于存活对象较多的场合，如老年代。

将内存分为一块较大的Eden空间和两块较小的Survivor空间，每次使用Eden和其中一块Survivor。当回收时，将Eden和Survivor中还存活着的对象一次性地复制到另外一块Survivor空间上，最后清理掉Eden和刚才用过的Survivor空间。HotSpot虚拟机默认Eden(使用的)和Survivor（保留的）的大小比例是 8:1，也就是每次新生代中可用内存空间为整个新生代容量90%（80%+10%），只有10%的内存会被“浪费”。当然，98%的对象可回收只是一般场景下的数据，我们没有办法保证每次回收都只有不多于10%的对象存活，当Survivor空间不够用时，需要依赖其他内存（这里指老年代）进行分配担保（Handle Promotion）。（注，总结来说就是当保留区的内存不够时，就要借助其他区（老年代）的内存，类似于银行担保人那样）。

 

3.3.3 标记-整理算法

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

 

3.3.4 分代收集算法

分代收集（Generational Collection）算法只是根据对象存活周期的不同将内存划分为几块。一般是把Java堆分为新生代和老年代，这样就可以根据各个年代的特点采用最适当的收集算法。

  • 新生代（每次垃圾收集时都发现有大批对象死去，只有少量存活，所以只需要付出少量存活对象的复制成本就可以完成收集）—— 复制算法
  • 老年代（对象存活率高、没有额外空间对它进行分配担保）—— 标记-清理和标记-整理算法

 

3.3.5 Java虚拟机如何枚举根节点

一、可达性分析算法在执行时间上存在什么问题？

从可达性分析算法知道，我们要从GC Roots节点开始，判断某个对象到GC Roots之间没有任何引用链相连。然而可作为GC Roots的节点主要在全局性的引用（例如常量或类静态属性）与执行上下文（例如栈帧中的本地变量表）中，现在很多应用仅仅方法区就有数百兆，如果要逐个检查这里面的引用，那么必然会消耗很多时间。此外，也不能出现在可达性分析的过程中对象的引用关系还在不断变化的情况，否则分析结果准确性就无法得到保证。故GC进行时必须停顿所有Java执行线程（Stop the world）。即使是在号称（几乎）不会发生停顿的CMS收集器中，枚举根节点时也是必须要停顿的。通过枚举一个一个的根节点(GC Roots)，然后顺藤摸瓜一路摸下来，没摸到的那些对象就被回收了。所以枚举根节点时STW(Stop the world)不可避免，所以只能让STW尽量的短。今天先来讲述一下GC是如何快速枚举根节点。在HotSpot虚拟机中，是通过可达性分析来判断此对象是否需要回收的。那可达性分析就需要找到“源头”，也就是根节点。

 

在目前主流的Java虚拟机中，当执行系统停顿下来后，并不需要一个不漏地检查完所有执行上下文和全局的引用位置，Java虚拟机应当是有办法直接（查表）得知哪些地方存放着对象引用。在HotSpot虚拟机的实现中，是使用一组称为OopMap的数据结构（记录栈中引用数据类型的位置）来达到这个目的的，在类加载完成的时候，HotSpot就把对象内什么偏移量上是什么类型的数据计算出来，在JIT编译过程中，也会在特定的位置记录下栈和寄存器中哪些位置是引用（如果是引用类型，那么它所引用的对象这一次不能被回收）。这样，GC在扫描时就可以直接（查表）得知这些信息了。我觉得OopMap使用的是空间换时间的策略。

一个线程为一个栈，一个栈由多个栈桢组成，一个栈桢对应一个方法，一个方法有多个安全点。GC发生时，程序首先运行到最近的一个安全点停下来，然后更新自己的OopMap，记录栈上哪些位置代表着引用。枚举根节点时，递归遍历每个栈桢的OopMap ，通过栈中记录的被引用的对象内存地址，即可找到这些对象（GC Roots）。

 

在OopMap的协助下，HotSpot可以快速且准确地完成GC Roots枚举，但一个很现实的问题随之而来：如果OopMap内容变化的指令非常多，如果为每一条指令都生成对应的OopMap，那将会需要大量的额外空间，这样GC的空间成本将会变得很高。

为了解决这个问题，于是引出了安全点的概念。

什么是安全点？

  • 事实上，HotSpot没有为每条指令都生成OopMap数据结构（因为栈上的本地变量表里面只有一部分数据是引用类型的，那些非引用类型的数据对我们而言毫无用途，但我们还是不得不堆整个栈全部扫描一遍，这是对时间和资源的一种浪费。），所以我们只是在“特定的位置”记录了这些信息，这些位置称为安全点（Safepoint），即程序执行时并非在所有地方都能停顿下来开始GC，只有在到达安全点时才能暂停。
  • 从线程角度看，安全点可以理解成是在代码执行过程中的一些特殊位置，当线程执行到这些位置的时候，说明虚拟机当前的状态是安全的，如果有需要，可以在这个位置暂停，比如发生GC时，需要暂停所有活动线程，但是该线程在这个时刻还没有执行到一个安全点，所以该线程应该继续执行，到达下一个安全点的时候暂停，然后才开始GC，该线程等待GC结束。

那么安全点如何选取呢？

  • 安全点的选定既不能太少以致于让GC等待时间太长，也不能过于频繁以致于过分增大运行时的负荷。所以安全点是以程序“是否具有让程序长时间执行的特征”为标准进行选定的——“长时间执行”的最明显特征就是指令序列复用，例如方法调用、循环跳转、异常跳转等，所以具有这些功能的指令才会产生安全点。

那如何在GC发生时让所有线程（这里不包括执行JNI调用的线程）都“跑”到最近的安全点上再停顿下来。

  • 抢先式中断：抢先式中断不需要线程的执行代码主动去配合，在GC发生时，首先把所有线程全部中断，如果发现有线程中断的地方不在安全点上，就恢复线程，让它“跑”到安全点上。（现在几乎没有虚拟机采用这种方式）
  • 主动式中断：当GC需要中断线程的时候，不直接对线程操作，仅仅简单地设置一个标志，各个线程执行时主动去轮询这个标志，发现中断标志为真时就自己中断挂起。轮询标志的地方：安全点和创建对象需要分配内存的地方。

 现在大部分虚拟机都采用是”主动式中断”方式，因为它相对“抢先式中断”方式避免了一个中断——>启动——>又中断的一个过程。

 

安全点机制保证了程序执行时，在不太长的时间内就会遇到可进入GC的安全点。但是这里还有一个问题。安全点需要程序自己跑过去，但是程序“不执行”的时候呢（程序不执行就是没有分配CPU时间，比如线程处于Sleep状态或者Blocked状态，此时线程无法响应JVM的中断请求，“走”到安全的地方去中断挂起，JVM也显然不太可能等待线程重新被分配CPU时间）？这里就引出了安全区域的概念。

  • 安全区域是指在一段代码片段之中，引用关系不会发生变化，也就是不用去更新OopMap了。在这个区域中的任意地方开始GC都是安全的。我们也可以把安全区域看做是被扩展了的安全点。

在线程执行到安全区域中的代码时，首先标识自己已经进入了Safe Region。那么当在这段时间里JVM要发起GC时，就不用管标识自己为Safe Region状态的线程了。在线程要离开Safe Region时，它要检查系统是否已经完成了根节点枚举（或者是整个GC过程），如果完成了，那线程就继续执行，否则它就必须等待直到收到可以安全离开Safe Region的信号为止。

 

安全点和安全区域的一些博客

posted @ 2020-11-25 17:53  Peterxiazhen  阅读(109)  评论(0)  编辑  收藏  举报