尚硅谷JVM与GC

• JVM体系结构
  • 类加载器ClassLoader
  • 双亲委派
  • 本地接口
  • PC寄存器
  • 方法区
  • 栈
  • 垃圾回收
  • 强，软，弱，虚引用
• 堆结构
  • java7
• 堆参数
  • 内存调优
• GC算法
  • 引用计数法
  • 复制算法
  • 标记清除法
  • 标记压缩算法
  • 总结
• GC垃圾收集器
  • 串行垃圾收集器
  • 并行垃圾收集器
  • 并发垃圾收集器CMS
  • G1垃圾收集器
• OOM

JVM体系结构

• JVM是运行在操作系统之上的，它与硬件没有直接的交互

类加载器ClassLoader

• 负责加载class文件，class文件在文件开头有特定的文件标示，将class文件字节码内容加载到内存中，并将这些内容转换成方法区中的运行时数据结构，并且ClassLoader只负责class文件的加载，至于它是否可以运行，则由Execution Engine决定。
• Execution Engine执行引擎负责解释命令，提交操作系统执行

双亲委派

• 当一个类收到了类加载请求，他首先不会尝试自己去加载这个类，而是把这个请求委派给父类去完成，每一个层次类加载器都是如此，因此所有的加载请求都应该传送到启动类加载器（Bootstrap）中，只有当父类加载器反馈自己无法完成这个请求的时候（在它的加载路径下没有找到所需加载的Class），子类加载器才会尝试自己去加载。
• 采用双亲委派的一个好处是比如加载位于 rt.jar包中的类 java.lang.Object，不管是哪个加载器加载这个类，最终都是委托给顶层的启动类加载器进行加载，这样就保证了使用不同的类加载器最终得到的都是同样一个Object对象

本地接口

• 本地接口的作用是融合不同的编程语言为 Java 所用，它的初衷是融合C/C++程序，Java 诞生的时候是 C/C++横行的时候，要想立足，必须有调用C/C++程序，于是就在内存中专门开辟了一块区域处理标记为native的代码，它的具体做法是Native Method Stack中登记 native方法，在Execution Engine 执行时加载native libraies。
• 目前该方法使用的越来越少了，除非是与硬件有关的应用，比如通过Java程序驱动打印机或者Java系统管理生产设备，在企业级应用中已经比较少见。因为现在的异构领域间的通信很发达，比如可以使用Socket通信，也可以使用Web Service等等
• native method stack：它的具体做法是native method stack中登记native方法，在execution engine执行时加载本地方法库

PC寄存器

• 每个线程都有一个程序计数器，是线程私有的,就是一个指针，指向方法区中的方法字节码（用来存储指向下一条指令的地址,也即将要执行的指令代码），由执行引擎读取下一条指令，是一个非常小的内存空间，几乎可以忽略不记
• 这块内存区域很小，它是当前线程所执行的字节码的行号指示器，字节码解释器通过改变这个计数器的值来选取下一条需要执行的字节码指令。
• 如果执行的是一个Native方法，那这个计数器是空的。
• 用以完成分支、循环、跳转、异常处理、线程恢复等基础功能。不会发生内存溢出(OutOfMemory=OOM)错误

方法区

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

栈

• 栈也叫栈内存，主管Java程序的运行，是在线程创建时创建，它的生命期是跟随线程的生命期，线程结束栈内存也就释放。

• 对于栈来说不存在垃圾回收问题，只要线程一结束该栈就Over，生命周期和线程一致，是线程私有的。

• 8种基本类型的变量+对象的引用变量+实例方法都是在函数的栈内存中分配。

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

  • 本地变量（local variables）：输入参数和输出参数以及方法内的变量。
  • 栈操作（operand stack）：记录出栈，入栈的操作。
  • 栈帧数据（frame data）：包括类文件，方法等等。

• 栈中的数据都是以栈帧（Stack Frame）的格式存在，栈帧是一个内存区块，是一个数据集，是一个有关方法(Method)和运行期数据的数据集。

• 当一个方法A被调用时就产生了一个栈帧F1，并被压入到栈中，

  A方法又调用了B方法，于是产生栈帧F2 也被压入栈，

  B方法又调用了C方法，于是产生栈帧F3 也被压入栈，

  ……

  执行完毕后，先弹出F3栈帧，再弹出F2栈帧，再弹出F1栈帧……

  遵循“先进后出”/“后进先出”原则。

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

• 栈，堆和方法区的交互关系

垃圾回收

• 什么是垃圾？简单的说，内存中已经不再被使用到的空间就是垃圾
• 如何判断一个对象可以被回收？
  • 引用计数法：java中，引用和对象是有关联的。如果要操作对象必须用引用进行。因此，很显然一个简单的办法就是通过引用计数来判断一个对象是否可以回收。简单说，给对象添加一个引用计数器，每当有一个地方引用它，计数器值就加1，每当有一个引用失效时，计数器值就减1。任何时刻计数器值为0的对象就是不可能再被使用的，那么这个对象就是可回收对象。该算法存在但目前无人使用了，解决不掉循环引用的问题。
  • 枚举根节点做可达性分析
  • 
  • 
  • java中可作为GC Roots的对象：
    • 虚拟机栈（栈帧中的局部变量表）中引用的对象
    • 方法区中的静态属性引用的对象
    • 方法区中常量引用的对象
    • 本地方法栈JNI（Native方法）引用的对象

强，软，弱，虚引用

• 整体架构

• 强引用

• 软引用

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

• WeakHashMap案例

public class WeakHashMapDemo {

    public static void main(String[] args) {
        myHashMap();
        System.out.println("--------------------");
        myWeakHashMap();
    }

    public static void myHashMap() {
        HashMap<Integer, String> hashMap = new HashMap<>();
        Integer key = new Integer(1);
        String value = "HashMap";

        hashMap.put(key, value);
        System.out.println(hashMap);

        key = null;
        System.out.println(hashMap);

        System.gc();
        System.out.println(hashMap + "\t" + hashMap.size());
    }

    public static void myWeakHashMap() {
        WeakHashMap<Integer, String> weakHashMap = new WeakHashMap<>();
        Integer key = new Integer(2);
        String value = "WeakHashMap";

        weakHashMap.put(key, value);
        System.out.println(weakHashMap);

        key = null;
        System.out.println(weakHashMap);

        System.gc();
        System.out.println(weakHashMap + "\t" + weakHashMap.size());
    }
}
 
/*
{1=HashMap}
{1=HashMap}
{1=HashMap}    1
--------------------
{2=WeakHashMap}
{2=WeakHashMap}
{}  0
*/

• 虚引用

• 引用队列案例

public class ReferenceQueueDemo {

    public static void main(String[] args) throws InterruptedException {
        Object o1 = new Object();
        ReferenceQueue<Object> referenceQueue = new ReferenceQueue<>();
        WeakReference<Object> weakReference = new WeakReference<>(o1, referenceQueue);

        System.out.println(o1);
        System.out.println(weakReference.get());
        System.out.println(referenceQueue.poll());

        System.out.println("--------------------------");
        o1 = null;
        System.gc();
        Thread.sleep(500);

        System.out.println(o1);
        System.out.println(weakReference.get());
        System.out.println(referenceQueue.poll());
    }
}
 
/*
软(内存不够时)、弱、虚引用，gc后放到引用队列中
 
java.lang.Object@1540e19d
java.lang.Object@1540e19d
null
--------------------------
null
null
java.lang.ref.WeakReference@677327b6
*/

• 总结

堆结构

• 一个JVM实例只存在一个堆内存，堆内存的大小是可以调节的。

• 类加载器读取了类文件后，需要把类、方法、常变量放到堆内存中，保存所有引用类型的真实信息，以方便执行器执行。

• 堆内存分为三部分：

  young generation space：新生区（young/new）

  tenure generation space：养老区（old/tenure）

  permanent space：永久区（perm）

java7

• 新生区是类的诞生、成长、消亡的区域，一个类在这里产生，应用，最后被垃圾回收器收集，结束生命

• 新生区又分为两部分： 伊甸区（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: Javaheap space异常，说明Java虚拟机的堆内存不够。原因有二：

  （1）Java虚拟机的堆内存设置不够，可以通过参数-Xms、-Xmx来调整。

  （2）代码中创建了大量大对象，并且长时间不能被垃圾收集器收集（存在被引用）

• 为什么要进行分代管理：经研究，不同对象的生命周期不同，98%的对象是临时对象。
• 方法区（Method Area）和堆一样，是各个线程共享的内存区域，它用于存储虚拟机加载的：类信息+普通常量+静态常量+编译器编译后的代码等等
• 虽然JVM规范将方法区描述为堆的一个逻辑部分，但它却还有一个别名叫做Non-Heap(非堆)，目的就是要和堆分开。
• 永久区：永久存储区是一个常驻内存区域，用于存放JDK自身所携带的Class,Interface 的元数据，也就是说它存储的是运行环境必须的类信息，被装载进此区域的数据是不会被垃圾回收器回收掉的，关闭JVM 才会释放此区域所占用的内存。

堆参数

• java7

• java8

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

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

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

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

内存调优

GC算法

• GC的作用区域：方法区，堆
• GC是什么（分代收集算法）
  • 次数上频繁收集young区
  • 次数上较少收集old区
  • 基本不动元空间

• JVM在进行GC时，并非每次都对上面三个内存区域一起回收的，大部分时候回收的都是指新生代。
• GC按照回收的区域又分了两种类型，一种是普通GC（minor GC），一种是全局GC（major GC or Full GC）
• 普通GC（minor GC）：只针对新生代区域的GC,指发生在新生代的垃圾收集动作，因为大多数Java对象存活率都不高，所以Minor GC非常频繁，一般回收速度也比较快。
• 全局GC（major GC or Full GC）：指发生在老年代的垃圾收集动作，出现了Major GC，经常会伴随至少一次的Minor GC（但并不是绝对的）。Major GC的速度一般要比Minor GC慢上10倍以上

引用计数法

• 引用计数器的实现很简单，对于一个对象A，只要有任何一个对象引用了A，则A的引用计数器就加1，当引用失效时，引用计数器就减一。只要对象A的引用计数器的值为0，则对象A就不可能再被使用。

复制算法

• 年轻代中使用的是Minor GC，这种GC算法采用的是复制算法
• JVM把年轻代分为了三部分：1个Eden区和2个Survivor区（分别叫from和to）。默认比例为8:1:1
• Minor GC会把Eden中的所有活的对象都移到Survivor区域中，如果Survivor区中放不下，那么剩下的活的对象就被移到Old generation中，也即一旦收集后，Eden是就变成空的了。
• 当对象在 Eden ( 包括一个 Survivor 区域，这里假设是 from 区域 ) 出生后，在经过一次 Minor GC 后，如果对象还存活，并且能够被另外一块 Survivor 区域所容纳( 这里应为 to 区域，即 to 区域有足够的内存空间来存储 Eden 和 from 区域中存活的对象 )，则使用复制算法将这些仍然还存活的对象复制到另外一块 Survivor 区域 ( 即 to 区域 ) 中，然后清理所使用过的 Eden 以及 Survivor 区域 ( 即 from 区域 )，并且将这些对象的年龄设置为1，以后对象在 Survivor 区每熬过一次 Minor GC，就将对象的年龄 + 1，当对象的年龄达到某个值时 ( 默认是 15 岁，通过-XX:MaxTenuringThreshold 来设定参数)，这些对象就会成为老年代。
• -XX:MaxTenuringThreshold — 设置对象在新生代中存活的次数
• 因为年轻代中的对象基本都是朝生夕死的(90%以上)，所以在年轻代的垃圾回收算法使用的是复制算法，复制算法的基本思想就是将内存分为两块，每次只用其中一块，当这一块内存用完，就将还活着的对象复制到另外一块上面。复制算法不会产生内存碎片。
• 因为Eden区对象一般存活率较低，一般的，使用两块10%的内存作为空闲和活动区间，而另外80%的内存，则是用来给新建对象分配内存的。一旦发生GC，将10%的from活动区间与另外80%中存活的eden对象转移到10%的to空闲区间，接下来，将之前90%的内存全部释放，以此类推。
• Minor GC会一直重复这样的过程，直到“To”区被填满，“To”区被填满之后，会将所有对象移动到年老代中。

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

标记清除法

• 老年代一般是由标记清除或者是标记清除与标记压缩的混合实现

• 当程序运行期间，若可以使用的内存被耗尽的时候，GC线程就会被触发并将程序暂停，随后将要回收的对象标记一遍，最终统一回收这些对象，完成标记清理工作接下来便让应用程序恢复运行。
• 主要进行两项工作，第一项是标记，第二项是清除
• 标记：从引用根节点开始标记遍历所有的GC Roots，先标记出要回收的对象
• 清除：遍历整个堆，把标记的对象清除。
• 优点：不需要额外空间
• 缺点：效率比较低（递归与全堆对象遍历）两次扫描，在进行GC的时候，需要停止应用程序，这会导致用户体验非常差劲，耗时严重；会产生内存碎片

标记压缩算法

• 老年代一般是由标记清除或者是标记清除和标记压缩的混合实现

• 在整理压缩阶段，不再对标记的对像做回收，而是通过所有存活对像都向一端移动，然后直接清除边界以外的内存。
• 标记的存活对象将会被整理，按照内存地址依次排列，而未被标记的内存会被清理掉。如此一来，当我们需要给新对象分配内存时，JVM只需要持有一个内存的起始地址即可，这比维护一个空闲列表显然少了许多开销。
• 标记/整理算法不仅可以弥补标记/清除算法当中，内存区域分散的缺点，也消除了复制算法当中，内存减半的高额代价
• 标记/整理算法唯一的缺点就是效率也不高，不仅要标记所有存活对象，还要整理所有存活对象的引用地址。从效率上来说，标记/整理算法要低于复制算法。

总结

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

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

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

• 没有最好的算法，只有最合适的算法。==========>分代收集算法。

• 年轻代(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以达到对老年代内存的整理。

GC垃圾收集器

• 目前为止还没有完美的收集器出现，更没有万能的收集器，只有针对具体应用最适合的收集器，进行分代收集。
• java的gc回收的类型主要有几种：UseSerialGC，UseParallelGC，UseConcMarkSweepGC，UseParNewGC，UseParallelOldGC，UseG1GC

串行垃圾收集器

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

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

• 老年代收集器

并行垃圾收集器

• 多个垃圾收集线程并行工作，此时用户线程是暂停的，适用于科学计算或大数据处理后台处理等弱交互场景。

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

• 并行回收GC

• 老年代

并发垃圾收集器CMS

• concurrent Mark sweep
• 用户线程和垃圾收集线程同时执行（不一定并行，可能交替执行）不需要停顿用户线程。互联网公司多用，适用于对响应时间有要求的场景。

• 四个步骤
  • 初始标记：只是标记一下GC Roots能直接关联的对象，速度很快，仍然需要暂停所有的工作线程。
  • 并发标记，和用户线程一起：进行GC Roots跟踪的过程，和用户线程一起工作，不需要暂停工作线程。主要标记过程，标记全部对象。
  • 重新标记：为了修正在并发标记期间，因用户程序继续运行而导致标记产生变动的那一部分对象的标记记录，仍然需要暂停所有的工作线程。由于并发标记时，用户线程依然运行，因此在正式清理前，再做修正。
  • 并发清除，和用户线程一起：清除GC Roots不可达对象，和用户线程一起工作，不需要暂停工作线程。基于标记结果，直接清理对象。由于耗时最长的并发标记和并发清除过程中，垃圾收集线程可以和用户线程一起并发工作，所以总体上看来CMS收集器的内存回收和用户线程是一起并发的执行。

• 优缺点
  • 优点是并发收集停顿低
  • 缺点是并发执行，对CPU压力较大，采用的标记清除算法会产生大量碎片。
• 如何选择垃圾收集器

G1垃圾收集器

• G1收集器，是一款面向服务端应用的收集器

• G1垃圾收集器将堆内存分割成不同的区域然后并发地对其进行垃圾回收。
• CMS 使用标记清除算法，节约空间但产生内存碎片
• 以前收集器存在的问题
  • 年轻代和老年代是各自独立且连续的内存块
  • 年轻代收集，使用单eden+s0+s1进行复制算法
  • 老年代收集必须扫描整个老年代区域
  • 都是以尽可能快速地执行GC为设计原则

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

• 回收步骤：G1收集器下的young GC
• 针对Eden区进行收集，Eden区耗尽后会被触发，主要是小区域收集+形成连续的内存块，避免内存碎片。
  • Eden区的数据移动到survivor区，假如出现survivor区空间不够，Eden区数据会晋升到old区
  • survivor区的数据移动到新的survivor区，部分数据晋升到old区
  • 最后Eden区收拾干净了，GC结束，用户的应用程序继续执行

• G1对比CMS
  • G1不会产生内存碎片
  • G1可以精确控制停顿。该收集器把整个堆（新生代，老年代）划分为多个固定大小的区域，每次根据允许停顿的时间去收集垃圾最多的区域。

OOM

• java.lang.StackOverflowError
• java.lang.OutOfMemoryError:java heap space
• java.lang.OutOfMemoryError:GC overhead limit exceeded
• java.lang.OutOfMemoryError:Direct buffer memory
• java.lang.OutOfMemoryError:unable to create new native thread
• java.lang.OutOfMemoryError:Metaspace