Java虚拟机

一、Java类加载器

JVM体系结构概览

1.1 类加载器ClassLoader

负责加载class文件，class文件在文件开头有特定的文件标示，将class文件字节码内容加载到内存中，并将这些内容转换成方法区中的运行时数据结构，并且ClassLoader只负责class文件的加载，至于它是否可以运行，则由Execution Engine决定

1.2 类加载器类型

1.2.1 虚拟机自带的加载器

启动类加载器(Bootstrap) C++

扩展类加载器(Extension) Java

应用程序类加载器(AppClassLoader)，Java也叫系统类加载器，加载当前应用的classpath的所有类

1.2.1 用户自定义加载器

Java.lang.ClassLoader的子类，用户可以定制类的加载方式

1.3 双亲委派机制

当一个类收到了类加载请求，他首先不会尝试自己去加载这个类，而是把这个请求委派给父类去完成，每一个层次类加载器都是如此，因此所有的加载请求都应该传送到启动类加载器中，只有当父类加载器反馈自己无法完成这个请求的时候(在它的加载路径下没有找到所需加载的Class)，子类加载器才会尝试自己去加载。

采用双亲委派的一个好处是比如加载位于rt.jar包中的类java.lang.Object，不管是哪个加载器加载这个类，最终都是委托给顶层的启动类加载器进行加载，这样就保证了使用不同的类加载器最终得到的都是同样一个Object对象

二、本地接口

2.1 Native Interface本地接口

本地接口的作用是融合不同的编程语言为Java所用，它的初衷是融合C/C++程序，Java诞生的时候是C/C++横行的时候，要想立足，必须有调用C/C++程序，于是就在内存中专门开辟了一块区域处理标记为native的代码，它的具体做法是本地方法栈(Native Method Stack)中登记native方法，在执行引擎(Execution Engine)执行时加载本地方法库(native libraies)。

目前，该方法使用的越来越少了，除非是与硬件有关的应用，比如通过Java程序驱动打印机或者Java系统管理生产设备，在企业级应用中已经比较少见。因为现在的异构领域间的通信很发达，比如，可以使用Socket通信，也可以使用Web Service等等。

java的多线程与语言没关系，与操作系统有关系，有线程就应该有进程

只要是native的方法，代表的就是调用的是跟java无关的，底层的第三方系统库，或C语言函数库，由于方法要放到栈里面，native就相当于绿色通道，如果是native方法，就放到native栈里面，专方法专用的栈。简而言之，native标注直接调底层了，不归java管

2.2 Native Method Stack本地方法栈

它的具体做法是Native Method Stack中登记native方法，在Execution Engine执行时加载本地方法库。

三、PC寄存器

PC寄存器就是一个指针，指着这个方法运行完后，下一个要去执行的方法是谁。类似于排班值日表，标记着下一个值日的人员。

每个线程都有一个程序计数器，是线程私有的，就是一个指针，指向方法区中的方法字节码(用来存储指向下一条指令的地址，也即将要执行的指令代码)，由执行引擎读取下一条指令，是一个非常小的内存空间，几乎可以忽略不记。

这块内存区域很小，它是当前线程所执行的字节码的行号指示器，字节码解释器通过改变这个计数器的值来选取下一条需要执行的字节码指令。

如果执行的是一个Native方法(不归java管)，那这个计数器是空的。

用以完成分支、循环、跳转、异常处理、线程恢复等基础功能。不会发生内存溢出(OutOfMemory=OOM)错误。

四、方法区

供各线程共享的运行时内存区域。它存储了每一个类的结构信息，例如运行时常量池(Runtime Constant Pool)、字段和方法数据、构造函数和普通方法的字节码内容。上面讲的是规范，在不同虚拟机里头实现是不一样的，最典型的就是永久代(PermGen space)和元空间(Metaspace)。但是，实例变量存在堆内存中，和方法区无关。

天上飞的是理念，下面是一些具体落地实现，如空调有格力，奥克斯等。汉堡有，肯德基，麦当劳等，都是具体的落地实现。

空调 k1 = new 格力()

List list = new ArrayList();

方法区 f = new 永久代

方法区 f = new 元空间

五、Stack栈

栈管运行，堆管存储

栈也叫栈内存，主管Java程序的运行，是在线程创建时创建，它的生命期是跟随线程的生命期，线程结束栈内存也就释放，对于栈来说不存在垃圾回收问题，只要线程一结束该栈就Over，生命周期和线程一致，是线程私有的。8种基本类型的变量+对象的引用变量+实例方法都是在函数的栈内存中分配。

5.1 栈存储什么

java方法=栈帧，java的层面叫方法，压入栈以后就叫栈帧

栈帧中主要保存3类数据：

本地变量：输入参数和输出参数以及方法内的变量

栈操作：记录出栈、入栈的操作

栈帧数据：包括类文件、方法等待。

5.2 栈运行原理

栈中的数据都是以栈帧的格式存在，栈帧是一个内存区块，是一个数据集，是一个有关方法和运行期数据的数据集，当一个方法A被调用时，就产生了一个栈帧F1，并被压入到栈中，A方法又调用了B方法，于是产生栈帧F2也被压入栈，B方法又调用了C方法，于是产生栈帧F3也被压入栈...执行完毕后，先弹出F3栈帧，再弹出F2栈帧，再弹出F1栈帧...

遵循先进后出/后进先出原则

每个方法执行的同时都会创建一个栈帧，用于存储局部变量表、操作数栈、动态链接、方法出口等信息，每一个方法从调用直至执行完毕的过程，就对应着一个栈帧在虚拟机中入栈到出栈的过程。栈的大小和具体JVM的实现有关，通常在256-756K之间，约等于1Mb左右。

 

图示在一个栈中有两个栈帧：

栈帧2是最先被调用的方法，先入栈，

然后，方法2又调用了方法1，栈帧1处于栈顶的位置，

栈帧2处于栈底，执行完毕后，依次弹出栈帧1和栈帧2，线程结束，栈释放。

每执行一个方法都会产生一个栈帧，保存到栈(后进先出)的顶部，顶部栈就是当前的方法，该方法执行完毕后会自动将此栈帧出栈。

5.3 StackOverflowError & OutOfMemoryError

无限递归

list中不断添加大对象

5.4 栈+堆+方法区的交互关系

HotSport是使用指针的方式来访问对象：

Java堆中会存放访问类元数据(类的结构信息，模板)的地址，

refrerence存储的就是直接对象的地址。

六、Heap堆

一个JVM实例只存在一个堆内存，堆内存的大小是可以调节的。类加载器读取了类文件后，需要把类、方法、常变量放到堆内存中，保存所有引用类型的真实信息，以方便执行器执行，堆内存分为三部分：

Young Generation Space  新生代               Young/New

Tenure Generation Space  老年代             Old/Tenure

Permanent Space             永久代/元空间   Perm

6.1 Java7之前

Java8之前为永久代，Java8之后为元空间

6.2 新生区

新生区是类的诞生、成长、消亡的区域，一个类在这里产生，应用，最后被垃圾回收器收集，结束生命。新生区又分为两部分：伊甸区(Eden Space)和幸存者区(Survivor Space)，所有的类都是在伊甸区被new出来的。幸存区有两个：0区(Survivor 0 Space)和1区(Survivor 1 Space)。当伊甸园的空间用完时，程序又需要创建对象，JVM的垃圾回收器将对伊甸园区进行垃圾回收(Minor GC)，将伊甸园区中的不再被其它对象所引用的对象进行销毁。然后将伊甸园中的剩余对象移动到幸存者0区。若幸存者0区也满了，再对该区进行垃圾回收，然后移动到幸存者1区。那如果1区也满了呢？再移动到养老区。若养老区也满了，那么这个时候将产生MajorGC(FullGC)，进行养老区的内存清理。若养老区执行了Full GC之后发现依然无法进行对象的保存，就会产生OOM异常"OutOfMemoryError“。

如果出现java.lang.OutOfMemoryError:java heap space异常，说明Java虚拟机的堆内存不够，原因有二：

1. Java虚拟机的堆内存设置不够，可以通过参数-Xms、-Xmx来调整
2. 代码中创建了大量大对象，并且长时间不能被垃圾收集器收集(存在被引用)

Java堆从GC的角度还可以细分为：新生代(Eden区、From Survivor区和To Survivor区)和老年代。

1：eden、SurvivorFrom复制到SurvivorTo，年龄+1

首先，当Eden区满的时候会触发第一次GC，把还活着的对象拷贝到ServivorFrom区，当Eden区再次触发GC的时候会扫描Eden区和From区，对这两个区域进行垃圾回收，经过这次回收后还存活的对象，则直接复制到To区域(如果有对象的年龄已经达到了老年的标准，则复制到老年代区)，同时把这些对象的年龄+1.

2：清空eden、SurvivorFrom

然后，清空Eden和SurvivorFrom中的对象，也即复制之后有交换，谁空谁是To

3：Survivor和SurvivorFrom互换

最后，SurvivorTo和SurvivorFrom互换，原SurvivorTo成为下一次GC时的SurvivorFrom区。部分对象会在From和To区域中复制来复制去，如此交换15次(由JVM参数MaxTenuringThreshold决定，这个参数默认是15)，最终如果还是存活，就存入到老年代。

6.3 永久代(Java7之前有)

永久存储区是一个常驻内存区域，用于存放JDK自身所携带的Class,Interface(如rt.jar包里的Class)的元数据，也就是说它存储的是运行环境必须的类信息，被装载进此区域的数据是不会被垃圾回收器回收掉的，关闭JVM才会释放此区域所占用的内存。

不同对象的生命周期不同，98%的对象是临时对象。

实际而言，方法区(Method Area)和堆一样，是各个线程共享的内存区域，它用于存储虚拟机加载的：类信息+普通常量+静态常量+编译器编译后的代码等等，虽然JVM规范将方法区描述为堆的一个逻辑部分，但它却 还有一个别名叫做Non-Heap(非堆)，目的就是要和堆分开。

对于HotSpot虚拟机，很多开发者习惯将方法区称之为”永久代(Parmanent Gen)",但严格本质上说两者不同，或者说使用永久代来实现方法区而已，永久代是方法区(相当于是一个接口interface)的一个实现，jdk1.7的版本中，已经将原本放在永久代的字符串常量池移走。

七、堆参数调整

7.1 Java7之前

-Xms：堆空间初始化值

-Xmx：堆空间最大值

7.2 Java8之后

Java8之后，将最初的永久代取消了，由元空间取代

在Java8中，永久代已经被移除，被一个称为元空间的区域所取代。元空间的本质和永久代类似。

元空间与永久代之间最大的区别在于：

永久代使用的JVM的堆内存，但是Java8以后的元空间并不在虚拟机中而是使用本机物理内存。

因此，默认情况下，元空间的大小仅受本地内存限制。类的元数据放入native momory，字符串池和类的静态变量放入Java堆中，这样可以加载多少类的元数据就不再由MaxPermSize控制，而由系统的实际可用空间来控制。

7.3 堆内存调优

7.3.1 默认值

-Xms：设置初始分配大小，默认为物理内存的“1/64”

-Xmx：最大分配内存，默认为物理内存的“1/4”

-XX:+PrintGCDetails：输出详细的GC处理日志

public class T2 {
    public static void main(String[] args) {
        long maxMemory = Runtime.getRuntime().maxMemory();
        long totalMemory = Runtime.getRuntime().totalMemory();
        System.out.println("-Xmx:MAX_MEMORY = " + maxMemory + "(字节、)" + (maxMemory / (double) 1024 / 1024) + "MB");
        System.out.println("-Xms:TOTOL_MEMORY = " + totalMemory + "(字节、)" + (totalMemory / (double) 1024 / 1024) + "MB");
    }
}

7.3.2 调节参数

-Xms1024m -Xmx1024m -XX:+PrintGCDetails

7.3.3 OOM

public class T3 {
    public static void main(String[] args) {
        String str = "测试OOM";
        while (true) {
            str += str + new Random().nextInt(88888888) + new Random().nextInt(66666666);
        }
    }
}

八、GC四大算法

次数上频繁收集Young区

次数上较少收集Old区

基本不动元空间

8.1 GC算法总体概述

JVM在进行GC时，并非每次都对上面三个内存区域一起回收的，大部分时候回收的都是指新生代。

因此，GC按照回收的区域又分了两种类型，一种是普通GC(minor GC)，一种是全局GC(major GC or Full GC)

8.1.1 Minor GC和Full GC的区别

普通GC(minor GC)

只针对新生代区域的GC，指发生在新生代的垃圾收集动作，因为大多数Java对象存活率都不高，所以Minor GC非常频繁，一般回收速度也比较快。

全局GC(major GC or Full GC)

指发生在老年代的垃圾收集动作，出现了Major GC，经常会伴随至少一次的Minor GC(但并不是绝对的)。Major GC的速度一般要比Minor GC慢上10倍以上，老年代占堆空间的2/3，新生代1/3，范围更大

8.2 引用计数法

如果有对象引用就加1，如果没有对象引用减1，当减到0时，说明没有对象引用，就可被回收

缺点：

每次对对象赋值时，均要维护引用计数器，且计数器本身也有一定的消耗。

较难处理循环引用

JVM的实现一般不采用这种方式

public class RefCountGC  {
    //这个成员属性唯一的作用就是占用一点内存
    private byte[] bigSize = new byte[2 * 1024 * 1024];
    Object instance = null;

    public static void main(String[] args) {
        RefCountGC objectA = new RefCountGC();
        RefCountGC objectB = new RefCountGC();
        objectA.instance = objectB;
        objectB.instance = objectA;
        objectA = null;
        objectB = null;
        //注意System.gc执行完之后并不会立即GC
        System.gc();
    }
}

8.2 复制算法(Coping)

年轻代中使用的是Minor GC，这种GC算法采用的是复制算法(Coping)

HotSpot JVM把年轻代分为了三部分：1个Eden区和2个Survivor区(分别叫from和to)，默认比例为8:1:1，一般情况下，新创建的对象都会被分配到Eden区(一些大对象特殊处理)，这些对象经过第一次Minor GC后，如果仍然存活，将会被移到Survivor区。对象在Survivor区中每熬过一次Minor GC，年龄就会增加1岁，当它的年龄增加到一定程度时，就会被移动到年老代中。因为年轻代中的对象基本都是朝生夕死的(90%以上)，所以在年轻代的垃圾回收算法使用的是复制算法，复制算法的基本思想就是将内存分为两块，每次只用其中一块，当这一块内存用完，就将还活着的对象复制到另外一块上面。复制算法不会产生内存碎片。

(年轻代90%都是死光了，只需要拷贝10%，效率高，耗空间)

在GC开始的时候，对象只会存在于Eden区和名为“From"的Survivor区，Survivor区”To"是空的。紧接着进行GC，Eden区中所有存活的对象都会被复制到“To"，而在”From"区中，仍存活的对象会根据他们的年龄值来决定去向。年龄达到一定值(年龄阈值默认15，可以通过-XX:MaxTenuringThreshold来设置)的对象会被移动到年老代中，没有达到阈值的对象会被复制到"To"区域。经过这次GC后，Eden区和From区已经被清空。这个时候，“From"和"To"会交换他们的角色，也就新的"To"就是上次GC前的"From"，新的"From"就是上次GC前的"To"。不管怎样，都会保证名为To的Survivor区域是空的。Minor GC会一直重复这样的过程，直到"To"区被填满，"To"区被填满之后，会将所有对象移动到年老代中。

因为Eden区对象一般存活率较低，一般的，使用两块10%的内存作为空闲和活动区间，而另外80%的内存，则是用来给新建对象分配内存的，一旦发生GC，将10%的from活动区间与另外80%中存活的eden对象转移到10%的To空闲区间(谁空谁是To)，接下来，将之前90%的内存全部释放，以此类推。

8.2.1 复制算法缺点

复制算法它的缺点也是相当明显的。

1.它浪费了一半的内存，这太要命了。

2.如果对象的存活率很高，我们可用极端一点，假设是100%存活，那么我们需要将所有对象都复制一遍，并将所有引用地址重置一遍，复制这一工作所花费的时间，在对象存活率达到一定程度时，将会变得不可忽视。所以，从以上描述不难看出，复制算法要想使用，最起码对象的存活率要非常低才行，而且，最重要的是，我们必须要克服50%内存的浪费。

8.3 标记清除(Mark-Sweep)

复制算法用在年轻代，老年代一般是标记清除或者是标记清除与标记整理的混合实现。

标记清除算法，分成标记和清除两个阶段，先标记出要回收的对象，然后统一回收这些对象。形如：

 

用通俗的话解释一下标记清除算法，就是当程序运行期间，若可以使用的内存被耗尽的时候，GC线程就会被触发并将程序暂停，随后将要回收的对象标记一遍，最终统一回收这些对象，完成标记清除工作，接下来便让应用程序恢复运行。

8.3.1 标记清除算法缺点

1. 首先，它的缺点就是效率比较低(递归与全堆对象遍历)，而且在进行GC的时候，需要停止应用程序，这会导致用户体验非常差劲

2. 其次，主要的缺点则是这种方式清理出来的空闲内存是不连续的，这点不难理解，我们的死亡对象都是随机的出现在内存的各个角落的，现在把它们清除之后，内存的布局自然会乱七八糟。而为了应付这一点，JVM就不得不维持一个内存的空闲列表，这又是一种开销，而且在分配数组对象的时候，寻找连续的内存空间会不太好找。

8.4 标记压缩(Mark-Compact)

在整理压缩阶段，不再对标记的对象做回收，而是通过所有存活对象都向一端移动，然后直接清除边界以外的内存。可以看到，标记的存活对象将会被整理，按照内存地址依次排列，而未被标记的内存会被清理掉。如此一来，当我们需要给新对象分配内存时，JVM只需要持有一个内存的起始地址即可，这比维护一个空闲列表显然少了许多开销。

8.4.1 缺点

标记-整理算法唯一的缺点就是效率不高，不仅要标记所有存活对象，还要整理所有存活对象的引用地址。

从效率上来说，标记-整理算法要低于复制算法。

8.4.2 标记-清除-压缩(Mark-Sweep-Compact)

多次清除以后，才压缩

8.4.3 过程图

8.5 分代收集算法

没有最好的算法，根据每一代特性，使用不同的算法

新生代用复制算法

老年代用标记清除，标记整理算法，不同的代，用不同方法

8.5.1 总结

内存效率：复制算法>标记清除算法>标记整理算法(此处的效率只是简单的对比时间复杂度，实际情况不一定如此)。

内存整齐度：复制算法=标记整理算法>标记清除算法。

内存利用率：标记整理算法=标记清除算法>复制算法

可以看出，效率上来说，复制算法是当之无愧的老大，但是，却浪费了太多内存，而为了尽量兼顾上面所提到的三个指标，标记/整理算法相当来说更平滑一些，但效率上依然不尽如人意，它比复制算法多了一个标记的阶段，又比标记/清除多了一个整理内存的过程。

难道就没有一种最优算法吗？

无，没有最好的算法，只有最合适的算法

年轻代(Young Gen)

年轻代特点是区域相对老年代较少，对象存活率低。

这种情况复制算法的回收整理，速度是最快的。复制算法的效率只和当前存活对象大小有关，因而很适用于年轻代的回收。而复制算法内存利用率不高的问题，通过hotspot中的两个survivor的设计得到缓解。

老年代(Tenure Gen)

老年代的特点是区域较大，对象存活率高。

这种情况，存在大量存活率高的对象，复制算法明显变得不合适。一般是由标记清除或者标记整理的混合实现。

Mark阶段的开销与存活对象的数量成正比，这点上说来，对于老年代，标记清除或者标记整理有一些不符，但可以通过多核/线程利用，对并发、并行的形式来提高标记效率。

Sweep阶段的开销与所管理区域的大小正相关，但Sweep"就地解决"的特点，回收的过程没有对象的移动。使其相对其它有对象移动步骤的回收算法，仍然是效率最好的。但是需要解决内存碎片问题。

Compact阶段的开销与存活对象的数据成正比，如上一条所描述，对于大量对象的移动是很大开销的，作为老年代的第一选择并不合适。

基于上面的考虑，老年代一般是由标记清除或者标记清除与标记整理的混合实现。以hotspot中的CMS回收器为例，CMS是基于Mark-Sweep实现的，对于对象的回收效率很高，而对于碎片问题，CMS采用基于Mark-Compact算法的Serial Old回收器作为补偿措施：当内存回收不佳(碎片导致的Concurrent Mode Failure时)，将采用Serial Old执行Full GC以达到对老年代内存的整理。

九、JVM垃圾回收的时候如何确定垃圾？什么是GC Roots

9.1 什么是垃圾

简单的说就是内存中已经不再被使用到的空间就是垃圾

9.2 要进行垃圾回收，如何判断一个对象是否可以被回收

9.2.1 引用计数法

Java中，引用和对象是有关联的，如果要操作对象则必须用引用进行

因此，很显然一个简单的办法是通过引用计数来判断一个对象是否可以回收。简单说，给对象添加一个引用计数器，

每当有一个地方引用它，计数器值加1

每当有一个引用失效时，计数器值减1

任何时刻计数器值为零的对象，就是不可能再被使用的，那么这个对象就是可回收对象

那为什么主流的Java虚拟机里面都没有选用这种算法呢？其中最主要的原因就是它很难解决对象之间相互循环引用的问题

9.2.2 可达性分析

枚举根节点做可达性分析(根搜索路径)

为了解决引用计数法的循环引用问题，Java使用了可达性分析的方法

所谓"GC roots"或者说tracing GC的"跟集合"就是一组必须活跃的引用。

基本思路就是通过一系列名为"GC Roots"的对象作为起始点，从这个被称为GC Roots的对象开始向下搜索，如果一个对象到GC Roots没有任何引用链相连时，则说明此对象不可用。也即给定一个集合的引用作为根出发，通过引用关系遍历对象图，能被遍历到的(可到达的)对象就被判定为存活；没有被遍历到的自然被判定为死亡。

通俗理解，人，狗，毛衣，人牵着狗，狗穿着衣服。如果人没了，狗即使穿着衣服，是不是还有可能被拐跑

9.2.3 Java可以做GCRoots的对象

虚拟机栈(栈帧中的局部变量区，也叫局部变量表)中引用的对象。

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

方法区中常量引用的对象

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

十、引用

10.1 整体架构

10.2 强引用

当内存不足，JVM开始垃圾回收，对于强引用的对象，就算是出现了OOM也不会对该对象进行回收，死都不收。

强引用是我们最常见的普通对象引用，只要还有强引用指向一个对象，就能表面对象还"活着"，垃圾收集器不会碰这种对象。在Java中最常见的就是强引用，把一个对象赋给一个引用变量，这个引用变量就是一个强引用。当一个对象被强引用变量引用时，它处于可达状态，它是不可能被垃圾回收机制回收的，即使该对象以后永远都不会被用到JVM也不会回收。因此，强引用是造成Java内存泄漏的主要原因之一。

对于一个普通的对象，如果没有其他的引用关系，只要超过了引用的作用域或者显示地将相应的(强)引用赋值为null，一般认为就是可以被垃圾收集了(当然具体回收时机还是要看垃圾收集策略)。

10.3 软引用

软引用是一种相对强引用弱化了一些的引用，需要用java.lang.ref.SoftReference类来实现，可以让对象豁免一些垃圾收集。

对于只有软引用的对象来说，

当系统内存充足时，它不会被回收，

当系统内存不足时，它会被回收。

软引用通常用在对内存敏感的程序中，比如高速缓存就有用到软引用，内存够用的时候就保留，不够用就回收！

10.3.1 内存够用

10.3.2 内存不够用

10.4 弱引用

10.4.1 case

弱引用需要用java.lang.ref.WeakReference类来实现，它比软引用的生存期更短，对于只有弱引用的对象来说，只要垃圾回收机制一运行，不管JVM的内存空间是否足够，都会回收该对象占用的内存。

10.4.2 软引用和弱引用的使用场景

假如有一个应用需要读取大量的本地图片：

如果每次读取图片都从硬盘读取则会严重影响性能

如果一次性全部加载到内存中又可能造成内存溢出

此时使用软引用可以解决这个问题。

设计思路是：用一个HashMap来保存图片的路径和相应图片对象关联的软引用之间的映射关系，在内存不足时，JVM会自动回收这些缓存图片对象所占用的空间，从而有效地避免了OOM的问题。

Map<String, SoftReference<BitMap>> imageCache = new HashMap<String, SoftReference<BitMap>>();

10.4.3 WeakHashMap

你知道弱引用的话，能谈谈WeakHashMap吗 

10.5 虚引用

虚引用需要java.lang.ref.PhantomReferene类来实现。

顾名思义，就是形同虚设，与其他几种引用都不同，虚引用并不会决定对象的生命周期。

如果一个对象仅持有虚引用，那么它就和没有任何引用一样，在任何时候都可能被垃圾回收器回收，它不能单独使用，也不能通过它访问对象，虚引用必须和引用队列(RefrenceQueue)联合使用。

虚引用的主要作用是跟踪对象被垃圾回收的状态。仅仅是提供了一种确保对象被finalize以后，做某些事情的机制。PhantomReference的get方法总是返回null，因此无法访问对应的引用对象。其意义在于说明一个对象已经进入finalization阶段，可以被gc回收，用来实现比finalization机制更灵活的回收操作。

换句话说，设置虚引用关联的唯一目的，就是在这个对象被收集器回收的时候收到一个系统通知或者后续添加进一步的处理。java技术允许使用finalize()方法，在垃圾收集器将对象从内存中清除出去之前做必要的清理工作。

10.5.1 引用队列

被回收之前，需要被引用队列保存下。

弱引用

虚引用

10.6 GCRoots和四大引用的总结

强引用，即便OOM也不回收

软引用，内存紧张的时候我们就回收，内存不紧张的时候不回收

弱引用只要有GC就会被回收

虚引用的get方法GC前后都是null，形同虚设，主要与引用队列配合使用，GC之后会被放到引用队列里面，临死前，做点其他事情，一种通知机制。

十一、OOM

11.1 StackOverFlowError

栈溢出错误

为什么会有StackOverFlowError这种错误？

递归调用之后，方法特别多，把栈空间给撑爆了。

11.2 OutOfMemoryError之Java heap space

为什么会有Java heap space这种错误？

堆干爆了

11.3 OutOfMemoryError之overhead limit exceeded

GC回收时间过长时会抛出OutOfMemoryError。过长的定义是，超过98%的时间用来做GC，并且回收了不到2%的堆内存
连续多次GC都只回收了不到2%的极端情况下才会抛出。假如不抛出GC overhead limit错误会发生什么情况呢？
那就是GC清理的这么点内存很快会再次填满，迫使GC再次执行，这样就形成恶性循环，
CPU使用率一直是100%，而GC却没有任何成果。

11.4 OutOfMemoryError之Direct buffer memory

元空间并不在虚拟机中，而是使用本地内存。因此，默认情况下，元空间的大小仅受本地内存限制。

写NIO程序经常使用ByteBuffer来读取或者写入数据，这是一种基于通道(Channel)与缓冲区(Buffer)的I/O方式,

它可以使用Native函数库直接分配堆外内存，然后通过一个存储在Java堆里面的DirectByteBuffer对象作为这块内存的引用进行操作。

这样能在一些场景中显著提高性能，因为避免了在Java堆和Native堆中来回复制数据。

ByteBuffer.allocate(capability) 第一种方式是分配JVM堆内存，属于GC管辖范围，由于需要拷贝，所以速度相对较慢

ByteBuffer.aalocateDirect(capability) 第二种方式是分配操作系统本地内存，不属于GC管辖范围，由于不需要内存拷贝，所以速度相对较快。

但如果不断分配本地内存，堆内存很少使用，那么JVM就不需要执行GC，DirectByteBuffer对象们就不会被回收，

这时候堆内存充足，但本地内存可能已经使用光了，再次尝试分配本地内存就会出现OutOfMemoryError，那么程序就直接崩溃了。

直接内存是堆外内存

-Xms10m -Xmx10m -XX:+PrintGCDetails -XX:MaxDirectMemorySize=5m

11.5 OutOfMemoryError之unable to create new native thread

高并发请求服务器时，经常出现如下异常：java.lang.OutOfMemoryError: unable to create new native thread准确的讲，该native thread异常与对应的平台有关。

导致原因：

1. 你的应用创建了太多线程了，一个应用进程创建多个线程，超过系统承载极限。

2. 你的服务器并不允许你的应用程序创建这么多线程，linux系统默认允许单个进程可以创建的线程数是1024个，

     你的应用创建超过这个数量，就会报java.lang.OutOfMemorError: unable to create new native thread

解决办法：

1. 想办法降低你应用程序创建线程的数量，分析应用是否真的需要创建这么多线程，如果不是，改代码将线程数降到最低。

2. 对于有的应用，确实需要创建很多线程，远超过linux系统的默认1024个线程的限制，可以通过修改linux服务器配置，扩大linux默认限制。

11.5.1 服务器级别调参调优

非root用户登录linux系统测试，root用户默认没有上限

11.6 OutOfMemoryError之Metaspace

-XX:MetaspaceSize=8m -XX:MaxMetaspaceSize=8m

Java 8及之后的版本使用Metaspace来替代永久代。

Metaspace是方法区在HotSpot中的实现，它与持久代最大的区别在于：Metaspace并不在虚拟机内存中，而是使用本地内存也即java8中，class metadata(the virtual machines internal presentation of Java class)，被存储在叫做Metaspace的native memory

永久代(java8后被元空间Metaspace取代了)存放了以下信息：

• 虚拟机加载的类信息
• 常量池
• 静态变量
• 即使编译后的代码

模拟Metaspace空间溢出，我们不断生成类往元空间灌，类占据的空间总是会超过Metaspace指定的空间大小的 

十二、GC垃圾回收算法和垃圾收集器的关系

天上飞的理念，地下是落地实现。

GC算法(引用计数/复制/标清/标整)是内存回收的方法论，垃圾收集器就是算法的落地实现。

到目前为止，还没有完美的收集器出现，更加没有万能的收集器，只是针对具体情况，应用最合适的收集器，进行分代收集

12.1 四种主要垃圾收集器

12.1.1 串行垃圾回收器(Serial)

串行垃圾回收器(Serial)：它为单线程环境设计，且只使用一个线程进行垃圾回收，会暂停所有的用户线程。所以不适合服务器环境。

我们运行的工作线程，运行到一定程度，会停下我们的程序，启动GC线程，来进行垃圾收集。(程序->GC->程序)

通俗理解：你现在正在餐厅吃饭，突然有人告诉你，这位顾客麻烦你离开一下，我们要打扫一下餐厅，等打扫干净了，你再过来。(用餐->打扫卫生->用餐)

12.1.2 并行垃圾回收器(Parallel)

并行垃圾回收器(Parallel)：多个垃圾收集线程并行工作，此时用户线程是暂停的，适用于科学计算/大数据处理等弱交互场景

串行是启动一个线程进行垃圾回收，并行是启动多个GC线程回收。

通俗理解：餐厅吃饭，打扫卫生，一个人效率比较慢，这时多来几个人打扫，停顿的时间就会比较短。

12.1.3 并发垃圾回收器(CMS)

并发垃圾回收器(CMS)：用户线程和垃圾收集线程同时执行(不一定是并行，可能交替执行)，不需要停顿用户线程，互联网公司多用它，适用对响应时间有要求的场景。

一边执行用户的应用程序，一边进行垃圾回收，

通俗理解：餐厅吃饭，餐厅工作人员要打扫卫生了，先把1号桌打扫干净，然后，告诉你先去1号桌吃饭，等把这边打扫完后，再换回来

12.1.4 G1垃圾回收器

G1垃圾回收器：G1垃圾回收器将堆内存分割成不同的区域，然后并发的对其进行垃圾回收。

 

十三、垃圾收集器

思想：四大垃圾回收算法思想

引用计数、复制拷贝、标记清除、标记整理

落地实现：

串行回收、并行回收、并发回收、G1

13.1 查看默认的垃圾收集器

java -XX:+PrintCommandLineFlags -version

13.2 默认的垃圾收集器

java的GC回收的类型主要有几种：

UseSerialGC，UseParallelGC，UseConcMarkSweepGC，UseParNewGC，UseParallelOldGC，UseG1GC

13.2.1 垃圾收集器

13.2.2 部分参数预先说明

1. DefNew：Default New Generation
2. Tenured：Old
3. ParNew：Parallel New Generation
4. PSYoungGen：Parallel Scavenge
5. ParOldGen：Parallel Old Generation

13.2.3 Server/Client模式

1. 使用范围：只需要掌握Server模式即可，Client模式基本不会用

2. 操作系统：

2.1 32位Window操作系统，不论硬件如何都默认使用Client的JVM模式

2.2 32位其他操作系统，2G内存同时有2个CPU以上用Server模式，低于该配置还是Client模式

2.3 64位only Server模式

13.2.4 新生代

1.串行GC(Serial)/(Serial Copying)

1:1

串行收集器: Serial收集器

一句话：一个单线程的收集器，在进行垃圾收集时候，必须暂停其他所有的工作线程，直到它收集结束。

串行收集器是最古老，最稳定以及效率高的收集器，只使用一个线程去回收，但其在进行垃圾收集过程中可能会产生较长的停顿(Stop-The-World状态)。虽然，在收集垃圾过程中需要暂停所有其他的工作线程，但是它简单高效，对于限定单个CPU环境来说，没有线程交互的开销，可以获得最高的单线程垃圾收集效率，因此Serial垃圾收集器依然是java虚拟机运行在Client模式下默认的新生代垃圾收集器。

对应JVM参数是：

-XX:+UseSerialGC

开启后会使用：Serial(Young区用) + Serial Old(Old区用)的收集器组合

表示：新生代、老年代都会使用串行垃圾收集器，新生代使用复制算法，老年代使用标记-整理算法

-Xms10m -Xmx10m -XX:+PrintGCDetails -XX:+PrintCommandLineFlags -XX:+UseSerialGC(DefNew + Tenured)

 

2. ParNew(并行)收集器

N:1

一句话：使用多线程进行垃圾回收，在垃圾收集时，会Stop-the-World暂停其他所有的工作线程直到它收集结束。

ParNew收集器其实就是Serial收集器新生代的并行多线程版本，最常见的应用场景是配合老年代的CMS GC工作，其余的行为和Serial收集器完全一样，ParNew垃圾收集器在垃圾收集过程中同样也要暂停所有其他的工作线程。它是很多java虚拟机运行在Server模式下新生代的默认垃圾收集器。

常用对应JVM参数：-XX:UseParNewGC启用ParNew收集器，只影响新生代的收集，不影响老年代

开启上述参数后，会使用ParNew(Young区用)+Serial Old的收集器组合，新生代使用复制算法，老年代采用标记-整理算法

但是，ParNew+Tenured这样的搭配，java8已经不再被推荐

Java HotSpot(TM) 64-Bit Server VM warning:

Using the ParNew young collector with the Serial old collector is deprecated and will likely be removed in a future release

备注

-Xms10m -Xmx10m -XX:+PrintGCDetails -XX:+PrintCommandLineFlags -XX:+UseParNewGC
-XXParallelGCThreads 限制线程数量，默认开启和CPU数目相同的线程数

3. 并行回收GC(Parallel)/(Parallel Scavenge)

Parallel Scavenge收集器类似ParNew也是一个新生代垃圾收集器，使用复制算法，也是一个并行的多线程垃圾收集器，俗称吞吐量优先收集器。

一句话：串行收集器在新生代和老年代的并行化

它重点关注的是：

可控制的吞吐量(Thoughput=运行用户代码时间/(运行用户代码时间+垃圾收集时间)，也即比如程序运行100分钟，垃圾收集时间1分钟，吞吐量就是99%）。高吞吐量意味着高效率利用CPU的时间，它多用于在后台运算而不需要太多交互的任务。

自适应调节策略也是ParallelScavenge收集器与ParNew收集器的一个重要区别。（自适应调节策略：虚拟机会根据当前系统的运行情况，收集性能监控信息，动态调整这些参数以提供最合适的停顿时间(-XX:MaxGCPauseMillis)或最大的吞吐量。

常用JVM参数：-XX:+UseParallelGC或-XX:+UseParallelOldGC（可互相激活）使用Parallel Scanvenge收集器

开启该参数后：新生代使用复制算法，老年代使用标记-整理算法

-XX:ParallelGCThreads=数字N 表示启动多少个GC线程
cpu>8 N = 5/8
cpu<8 N = 实际个数
-Xms10 -Xmx10m -XX:+PrintGCDetails -XX:+PrintCommandLineFlags -XX:+UseParallelGC
-Xms10m -Xmx10m -XX:+PrintGCDetails -XX:+PrintCommandLineFlags -XX:+UseParallelOldGC

什么参数都不加默认就是+UseParallelGC

13.2.5 老年代

1.串行GC(Serial Old)/(Serial MSC)

Serial Old是Serial垃圾收集器老年代版本，它同样是个单线程的收集器，使用标记-整理算法，这个收集器也主要是运行在Client默认的java虚拟机默认的老年代垃圾收集器。

在Server模式下，主要有两个用途

1.在JDK1.5之前版本中与新生代Parallel Scavenge收集器搭配使用。(Parallel Scavenge + Serial Old)

2.作为老年代版中使用CMS收集器的后备垃圾收集方案。

-Xms10m -Xmx10m -XX:+PrintGCDetails -XX:+PrintCommandLineFlags -XX:+UseSerialOldGC

2. 并行GC(Parallel Old)/(Parallel MSC)

Parallel Old收集器是Parallel Scavenge的老年代版本，使用多线程的标记-整理算法，Parallel Old收集器在JDK1.6才开始提供。

在JDK1.6之前，新生代使用ParallelScavenge收集器只能搭配老年代的Serial Old收集器，只能保证新生代的吞吐量优先，无法保证整体的吞吐量。在JDK1.6之前(Parallel Scavenge + Serial Old)

Parallel Old正是为了在年老代同样提供吞吐量优先的垃圾收集器，如果系统对吞吐量要求比较高，JDK1.8后可以优先考虑新生代Parallel Scavenge和年老代Parallel Old收集器的搭配策略。在JDK1.8及后(Parallel Scavenge + Parallel Old)

JVM常用参数：

-XX:+UseParallelOldGC 使用Parallel Old收集器，设置该参数后，新生代Parallel + 老年代Parallel Old

3. 并发标记清除GC(CMS)

CMS收集器(Concurrent Mark Sweep：并发标记清除）是一种以获取最短回收停顿时间为目标的收集器。

适合应用在互联网站或者B/S系统的服务器上，这类应用尤其重视服务器的响应速度，希望系统停顿时间最短。

CMS非常适合堆内存大、CPU核数多的服务器端应用，也是G1出现之前，大型应用的首选收集器。

Concurrent Mark Sweep并发标记清除，并发收集低停顿，并发指的是与用户线程一起执行

开启该收集器的JVM参数：-XX:+UseConcMarkSweepGC 开启该参数后会自动将-XX:+UseParNewGC打开

开启该参数后，使用ParNew(Young区用)+CMS(Old区用)+Serial Old的收集器组合，Serial Old将作为CMS出错的后备收集器

-Xms10m -Xmx10m -XX:+PrintGCDetails -XX:+PrintCommandLineFlags -XX:+UseConcMarkSweepGC

(1) 四步过程

初始标记(CMS initial mark)：只是标记一下GC Roots能直接关联的对象，速度很快，仍然需要暂停所有的工作线程。

并发标记(CMS concurrent mark)和用户线程一起：进行GC Roots跟踪的过程，和用户线程一起工作，不需要暂停工作线程。主要标记过程，标记全部对象。

重新标记(CMS remark)：为了修正在并发标记期间，因用户程序继续运行而导致标记产生变动的那一部分对象的标记记录，仍然需要暂停所有的工作线程。由于并发标记时，用户线程依然运行，因此在正式清理前，再做修正。

并发清除(CMS concurrent sweep)和用户线程一起：清除GC Roots不可达对象，和用户线程一起工作，不需要暂停工作线程。基于标记结果，直接清理对象。由于耗时最长的并发标记和并发清除过程中，垃圾收集线程可以和用户现在一起并发工作，所以总体上来看CMS收集器的内存回收和用户线程是一起并发地执行。

(2) 四步概述

(3) 优点：

并发收集低停顿

(4) 缺点：

并发执行，对CPU资源压力大

由于并发进行，CMS在收集与应用线程会同时，会增加对堆内存的占用，也就是说，CMS必须要在老年代堆内存用尽之前完成垃圾回收，否则CMS回收失败时，将触发担保机制，串行老年代收集器将会以STW的方式进行一次GC，从而造成较大停顿时间。

采用的标记清除算法会导致大量碎片

标记清除算法无法整理空间碎片，老年代空间会随着应用时长被逐步耗尽，最后将不得不通过担保机制对堆内存进行压缩，CMS也提供了参数-XX:CMSFullGCsBeForeCompaction(默认0，即每次都进行内存整理)来指定多少次CMS收集之后，进行一次压缩的Full GC。

13.2.6 G1

-Xms10m -Xmx10m -XX:PrintGCDetails -XX:+PrintCommandLineFlags -XX:+UseG1GC

1.以前收集器的特点

• 年轻代和老年代是各自独立且连续的内存块；
• 年轻代收集使用eden+S0+S1进行复制算法；
• 老年代收集必须扫描整个老年代区域；
• 都是以尽可能少而快速地执行GC为设计原则。 

2.G1是什么

G1(Gargage-First)收集器，是一款面向服务端应用的收集器

从官网的描述中，我们知道G1是一种服务器端的垃圾收集器，应用在多处理器和大容量内存环境中，在实现高吞吐量的同时，尽可能的满足垃圾收集暂停时间的要求。另外，它还具有以下特性：

1. 像CMS收集器一样，能与应用程序线程并发执行。
2. 整理空闲空间更快。
3. 需要更多的时间来预测GC停顿时间。
4. 不希望牺牲大量的吞吐性能。
5. 不需要更大的Java Heap

G1收集器的设计目标是取代CMS收集器，它同CMS相比，在以下方面表现的更出色：

G1是一个有整理内存过程的垃圾收集器，不会产生很多内存碎片。

G1的Stop The World(STW)更可控，G1在停顿时间上添加了预测机制，用户可以指定期望停顿时间。

CMS垃圾收集器，虽然减少了暂停应用程序的运行时间，但是，它还是存在着内存碎片问题。于是，为了去除内存碎片问题，同时又保留CMS垃圾收集器低暂停时间的优点，Java7发布了一个新的垃圾收集器-G1垃圾收集器。

G1是在2012年才在jdk1.7u4中可用。oracle官方计划在jdk9中将G1变成默认的垃圾收集器以替代CMS。它是一款面向服务端应用的收集器，主要应用在多CPU和大内存服务器环境下，极大的减少垃圾收集的停顿时间，全面提升服务器的性能，逐步替换java8以前的CMS收集器。

主要改变是Eden，Survivor和Tenured等内存区域不再是连续的了，而是变成了一个个大小一样的region，每个region从1M到32M不等。一个region有可能属于Eden，Survivor或者Tenured内存区域。

3.G1特点

1. G1能充分利用多CPU、多核环境硬件优势，尽量缩短STW。
2. G1整体上采用标记-整理算法、局部是通过复制算法，不会产生内存碎片。
3. 宏观上看，G1之中不再区分年轻代和年老代。把内存划分成多个独立的子区域(Region)，可以近似理解为一个围棋的棋盘。
4. G1收集器里面，将整个的内存区都混合在一起了，但其本身依然在小范围内要进行年轻代和年老代的区分，保留了新生代和年老代，但它们不再是物理隔离的，而是一部分Region的集合且不需要Region是连续的，也就是说依然会采用不同的GC方式来处理不同的区域。
5. G1虽然也是分代收集器，但整个内存分区不存在物理上的年轻代与年老代的区别，也不需要完全独立的survivor(to space)堆做复制准备。G1只有逻辑上的分代概念，或者说每个分区都可能随G1的运行在不同代之间前后切换。

4.G1底层原理

(1) Region区域化垃圾收集器

最大好处是化整为零，避免全内存扫描，只需要按照区域来进行扫描即可。

区域化内存划片Region，整体变为了一系列不连续的内存区域，避免了全内存区的GC操作。

核心思想是将整个堆内存区域分成大小相同的子区域(Region)，在JVM启动时会自动设置这些子区域的大小。

在堆的使用上，G1并不要求对象的存储一定是物理上连续的只要逻辑上连续即可，每个分区也不会固定地为某个代服务，可以按需在年轻代和年老代之间切换。启动时可以通过参数-XX:G1HeapRegionSize=n指定分区大小(1MB-32MB，且必须是2的幂)，默认将整堆划分为2048个分区。

大小范围在1MB-32MB，最多能设置2048个区域，也即能够支持的最大内存为：32MB*2048=65536MB=64G内存

G1算法将堆划分为若干个区域(Region)，它仍然属于分代收集器，这些Region的一部分包含新生代，新生代的垃圾收集依然采用暂停所有应用线程的方式，将存活对象拷贝到老年代或者Survivor空间。

这些Region的一部分包含老年代，G1收集器通过将对象从一个区域复制到另外一个区域，完成了清理工作。这就意味着，在正常的处理过程中，G1完成了堆的压缩(至少是部分堆的压缩)，这样也就不会有CMS内存碎片问题的存在了。

在G1中，还有一种特殊的区域，叫Humongous(巨大的)区域，如果一个对象占用的空间超过了分区容量50%以上，G1收集器就认为这些是一个巨型对象。这些巨型对象默认直接会被分配在年老代，但是如果它是一个短期存在的巨型对象，就会对垃圾收集器造成负面影响。为了解决这个问题，G1划分了一个Humongous区，它用来专门存放巨型对象。如果一个H区装不下一个巨型对象，那么G1会寻找连续的H分区来存储。为了能找到连续的H区，有时候不得不启动Full GC。

5.回收步骤

针对Eden区进行收集，Eden区耗尽后会被触发，主要是小区域收集+形成连续的内存块，避免内存碎片

Eden区的数据移动到Survivor区，假如出现Survivor区空间不够，Eden区数据会晋升到Old区

Survivor区的数据移动到新的Survivor区，数据晋升到Old区

最后Eden区收拾干净了，GC结束，用户的应用程序继续执行。

6.四步过程

初始标记：只标记GC Roots能直接关联到的对象

并发标记：进行GC Roots Tracing的过程

最终标记：修正并发标记期间，因程序运行导致标记发生变化的那一部分对象

筛选回收：根据时间来进行价值最大化的回收。

7. 常用配置参数

-XX:+UseG1GC
-XX:G1HeapRegionSize=n：设置G1区域的大小，值是2的幂，范围是1M到32M。目标是根据最小的Java堆大小划分出约2048个区域
-XX:MaxGCPauseMillis=n: 最大停顿时间，这是个软目标，JVM将尽可能(但不保证)停顿时间小于这个时间
-XX:InitiatingHeapOccupancyPercent=n：堆占用了多少的时候就触发GC，默认是45
-XX:ConcGCThreads=n：并发GC使用的线程数
-XX:G1ReservePercent=n：设置作为空闲空间的预留内存百分比，以降低目标空间溢出的风险，默认值是10%

8. 和CMS相比的优势

 比起CMS有两个优势：

1）G1不会产生内存碎片。

2）是可以精确控制停顿。该收集器是把整个堆(新生代、老年代)划分成多个固定大小区域，每次根据允许停顿的时间去收集垃圾最多的区域。

13.2.6 如何选择垃圾收集器

13.2.7 JVM GC + SpringBoot微服务的生产部署和调参优化

1. IDEA开发完微服务工程

2. Maven进行clean package

3. 要求微服务启动的时候，同时配置我们的JVM/GC的调优参数

4. java -server jvm的各种参数 -jar 第一步上面的jar/war包名字

视频教程、面试视频、源码