JVM入门(探究)

请你谈谈对JVM的理解？java8虚拟机和之前的变化更新？
什么是OOM(内存溢出)，什么是栈溢出StackOverFlowError？怎么分析？
JVM的常用调优参数有哪些？
内存快照如何抓取，怎么分析Dump文件？
谈谈你对JVM中类加载器的认识？

JVM的位置

JVM的体系结构

jvm调优：99%都是在方法区和堆，大部分时间调堆。 JNI(java native interface)本地方法接口

类加载器

作用：加载Class文件~ new Student();引用变量名在栈中，具体的实例在堆中

类是一个模板，是抽象的；对象是具体的

1.虚拟机自带的加载器

2.启动类(根)加载器

3.扩展类加载器

4.系统类加载器

双亲委派机制

APP-->EXC-->BOOT(最终执行)

从开发者的角度，类加载器可以细分为：

启动（Bootstrap）类加载器：负责将Java_Home/lib下面的类库加载到内存中（比如rt.jar）。由于引导类加载器涉及到虚拟机本地实现细节，开发者无法直接获取到启动类加载器的引用，所以不允许直接通过引用进行操作。
标准扩展（Extension）类加载器：是由 Sun 的 ExtClassLoader（sun.misc.Launcher$ExtClassLoader）实现的。它负责将Java_Home /lib/ext或者由系统变量 java.ext.dir指定位置中的类库加载到内存中。开发者可以直接使用标准扩展类加载器。
应用程序（Application）类加载器：是由 Sun 的 AppClassLoader（sun.misc.Launcher$AppClassLoader）实现的。它负责将系统类路径（CLASSPATH）中指定的类库加载到内存中。开发者可以直接使用系统类加载器。由于这个类加载器是ClassLoader中的getSystemClassLoader()方法的返回值，因此一般称为系统（System）加载器。

JVM中提供了三层的ClassLoader：

Bootstrap classLoader:主要负责加载核心的类库(java.lang.*等)，构造ExtClassLoader和APPClassLoader。
ExtClassLoader：主要负责加载jre/lib/ext目录下的一些扩展的jar。
AppClassLoader：主要负责加载应用程序的主函数类

双亲委派机制:

双亲委派机制

一个类在收到类加载请求后，不会自己加载这个类，而是把这个类加载请求向上委派给它的父类去完成，父类收到这个请求后又继续向上委派给自己的父类，以此类推，直到所有的请求委派到启动类加载器中。

当父类加载器在接收到类加载请求后，发现自己也无法加载这个类（这个情况通常是因为这个类的Class文件在父类的加载路径中不存在）这时父类会把这个信息反馈给子类，并向下委派子类加载器来加载这个类，直到这个请求被成功加载，但是一直到自定义加载器都没有找到，JVM就会抛出ClassNotFund异常。

从上图中我们就更容易理解了，当一个.class文件要被加载时。不考虑我们自定义类加载器，首先会在AppClassLoader中检查是否加载过，如果有那就无需再加载了。如果没有，那么会拿到父加载器，然后调用父加载器的loadClass方法。父类中同理也会先检查自己是否已经加载过，如果没有再往上。注意这个类似递归的过程，直到到达Bootstrap classLoader之前，都是在检查是否加载过，并不会选择自己去加载。直到BootstrapClassLoader，已经没有父加载器了，这时候开始考虑自己是否能加载了，如果自己无法加载，会下沉到子加载器去加载，一直到最底层，如果没有任何加载器能加载，就会抛出ClassNotFoundException。

作用：

1、防止重复加载同一个.class。通过委托去向上面问一问，加载过了，就不用再加载一遍。保证数据安全。
2、保证核心.class不能被篡改。通过委托方式，不会去篡改核心.class，即使篡改也不会去加载，即使加载也不会是同一个.class对象了。不同的加载器加载同一个.class也不是同一个Class对象。这样保证了Class执行安全。

比如：如果有人想替换系统级别的类：String.java。篡改它的实现，在这种机制下这些系统的类已经被Bootstrap classLoader加载过了（为什么？因为当一个类需要加载的时候，最先去尝试加载的就是BootstrapClassLoader），所以其他类加载器并没有机会再去加载，从一定程度上防止了危险代码的植入。
总结：

沙箱安全机制

组成沙箱的基本组件：

字节码校验器（bytecode verifier）：确保Java类文件遵循Java语言规范。这样可以帮助Java程序实现内存保护。但并不是所有的类文件都会经过字节码校验，比如核心类以java javax开头。
类装载器（class loader）：其中类装载器在3个方面对Java沙箱起作用
- 它防止恶意代码去干涉善意的代码；//双亲委派机制
- 它守护了被信任的类库边界；
- 它将代码归入保护域，确定了代码可以进行哪些操作。

虚拟机为不同的类加载器载入的类提供不同的命名空间，命名空间由一系列唯一的名称组成，每一个被装载的类将有一个名字，这个命名空间是由Java虚拟机为每一个类装载器维护的，它们互相之间甚至不可见。

类装载器采用的机制是双亲委派模式。

从最内层JVM自带类加载器开始加载，外层恶意同名类得不到加载从而无法使用；
由于严格通过包来区分了访问域，外层恶意的类通过内置代码也无法获得权限访问到内层类，破坏代码就自然无法生效。

存取控制器（access controller）：存取控制器可以控制核心API对操作系统的存取权限，而这个控制的策略设定，可以由用户指定。
安全管理器（security manager）：是核心API和操作系统之间的主要接口。实现权限控制，比存取控制器优先级高。
安全软件包（security package）：java.security下的类和扩展包下的类，允许用户为自己的应用增加新的安全特性，包括：
- 安全提供者
- 消息摘要
- 数字签名keytools
- 加密
- 鉴别

Native

凡是带了native 关键字的，说明java的作用范围达不到了，会去调用底层C语言的库！

凡是带了native 关键字的方法会进入本地方法栈，调用本地方法接口，其它的是java栈

JNI：Java Native Interface（本地方法接口）

调用本地方法接口（JNI）作用：

扩展java的使用，融合不同的编程语言为java所用
java诞生的初衷是融合C/C++程序，C、C++横行，想要立足，必须要有调用C、C++的程序~
它在内存区城中专门开辟了块标记区城: Native Method Stack

Native Method Stack（本地方法栈）：登记native 方法，在执行引擎（Execution Engine）执行的时候，通过JNI 加载本地方法库(Native Libraies)中的方法。

在企业级应用中少见，除非与硬件有关应用：java程序驱动打印机，Java系统管理生产设备等，掌握即可

异构领域间通信：Socket，WebService， http

PC寄存器

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

方法区

Method Area方法区：

方法区是被所有线程共享，所有字段和方法字节码，以及一些特殊方法，如构造函数，接口代码也在此定义,简单说，所有定义的方法的信息都保存在该区域，此区域属于共享区间;
静态变量、常量、类信息(构造方法、接口定义)、运行时的常量池存在方法区中，但是实例变量存在堆内存中，和方法区无关。
如：static，final,，Class（类模板）, 常量池

面试题：一张白纸，画出对象实例化过程的内存图。（主要是考你对JVM的理解）

栈

栈：数据结构
程序=数据结构+算法：持续学习~
程序=框架+业务逻辑：吃饭~
栈：先进后出、后进先出LIFO：桶
队列：先进先出 ( FIFO First Input First Output)：管
为什么main() 先执行，最后结束? （因为一开始main()先压入栈）
栈：也叫栈内存，主管程序的运行，栈的生命周期和线程同步;
线程结束，栈内存也就是释放，对于栈来说，不存在垃圾回收问题
一旦线程结束，栈就Over!
栈存放：8大基本类型+对象引用+实例的方法
栈运行原理：栈帧（局部变量表+操作数栈）每调用一个方法都有一个栈帧
栈满了 main()无法结束，会抛出错误：栈溢出 StackOverflowError

程序正在执行的方法，一定在栈的顶部

栈帧图：

栈+堆+方法区：交互关系

堆

Heap：一个JVM只有一个堆内存，堆内存的大小是可以调节的。

类加载器读取了类文件后，需要把类、方法、常变量放到堆内存中，保存所有引用类型的真实对象

堆内存细分3个区域：

新生区（伊甸园区） Young/new
养老区 old
永久区 Perm

GC垃圾回收，主要是在伊甸园区和养老区

假设内存满了==>OOM,堆内存不够！OutOfMemoryError：java heap space

在JDK8以后，永久存储区改了个名字(元空间)

新生区、老年区、永久区

新生区

类诞生和成长甚至死亡的地方；
伊甸园,所有对象都是在伊甸园区new出来的！
幸存者区(0,1)：轻GC定期清理伊甸园，活下来的放入幸存者区；幸存者区满了之后重GC清理伊甸园+幸存者区，活下来的放入养老区。都满了就报OOM。

真理：经过研究，99%的对象都是临时对象！直接被清理了

老年区

新生区剩下来的，轻GC杀不死了。

永久区

这个区域常驻内存，用来存放JDK自身携带的Class对象，Interface元数据；存储的是java运行时的一些环境或类信息，该区域不存在垃圾回收GC。关闭虚拟机就会释放这个内存。

jdk1.6之前：永久代，常量池在方法区
jdk1.7：永久代，但是慢慢退化了（去永久代）,常量池在堆中
jdk1.8之后：无永久代，常量池在元空间

一个启动类加载了大量的第三方jar包；Tomcat部署了太多的应用，大量动态生成的反射类===>不断的被加载，直到内存满，就会出现OOM。

方法区又称非堆(non-heap)，本质还是堆，只是为了区分概念。

元空间逻辑上存在，物理上不存在

扩展：

VM options参数设置

Run---->Edit Configurations打开Run/Dubug Configurations界面

Modify Options----->Add VM options添加VM options参数

设置相关参数

VM options：虚拟机参数，是在程序中需要的运行时环境变量，以-D或-X或-XX开头，每个参数使用空格分隔

参数说明：

-Xms1024m，设置JVM初始堆内存为1024m。此值可以设置与-Xmx相同，以避免每次垃圾回收完成后JVM重新分配内存。
-Xmx1024m，设置JVM最大堆内存为1024m。
-XX:+PrintGCDetails，打印gc详情

参考：IDEA中VM options参数设置和说明

Program arguments：程序参数，是传入main方法的字符串数组args[]，每个参数需要以空格隔开

Environment variables：环境变量参数，没有前缀，优先级低于 VM options ，即如果VM options 有一个变量和 Environment variable中的变量的key相同，则以VM options 中为准

堆内存调优

package com.lin.oom;

public class demo01 {
    public static void main(String[] args) {
        //返回虚拟机试图使用的最大内存
        long max = Runtime.getRuntime().maxMemory(); //字节 1024*1024
        //返回jvm初始化的总内存
        long total = Runtime.getRuntime().totalMemory();

        System.out.println("max="+max+"字节\t"+(max/(double)1024/1024+"MB"));
        System.out.println("total="+total+"字节\t"+(total/(double)1024/1024+"MB"));
        /* 运行后：
        max=1866465280字节   1780.0MB
        total=126877696字节  121.0MB
         */
        //默认情况下，分配的总内存占电脑内存1/4 初始内存1/64
    }
}

上面的程序设置VM options：-Xms1024m -Xmx1024m -XX:+PrintGCDetails

from和to中对象互换

新生区+养老区：305664K+699392K=1005056K = 981.5M

说明元空间物理并不存在。

堆内存分配：

	JVM初始分配的堆内存由-Xms指定，默认是物理内存的1/64;
	JVM最大分配的堆内存由-Xmx指定，默认是物理内存的1/4;
	默认空余堆内存小于40%时，JVM就会增大堆直到-Xmx的最大限制;
	空余堆内存大于70%时，JVM会减少堆直到-Xms的最小限制;
	因此服务器一般设置-Xms、-Xmx 相等以避免在每次GC后调整堆的大小。
	
说明：如果-Xmx 不指定或者指定偏小，应用可能会导致java.lang.OutOfMemory错误，此错误来自JVM，不是Throwable的，无法用try…catch捕捉。

面试题：程序报OOM怎么办？
1.尝试扩大堆内存，如果还报错，说明有死循环代码或垃圾代码
2.分析内存，看一下哪个地方出现问题（专业工具）

Jprofiler

在一个项目中，突然出现了OOM故障，该如何排除，研究为什么出错~

能够看到代码第几行出错：内存快照分析工具，MAT，Jprofiler
Debug，一行行分析代码！

MAT或Jprofiler作用：

分析Dump内存文件，快速定位内存泄漏；
获得堆中的数据
获得大的对象！（大厂面试）....

JProfiler安装

File----->Setting:Plugins搜索JProfiler---->Install

JProfiler监控软件安装

官方下载地址：https://www.ej-technologies.com/download/jprofiler/version_92

下载完成后点击运行，然后一直next就可以了

IDEA运行环境配置

Settings–Tools–JProflier选择JProfile安装可执行文件，apply

package com.lin.oom;

import java.util.ArrayList;

//Dump
public class demo02 {
    byte[] array = new byte[1*1024*1024];//1m
    public static void main(String[] args) {
        ArrayList<Object> list = new ArrayList<>();

        int count = 0;
        try {
            while(true){
                list.add(new demo02());//问题所在
                count++;
            }
        } catch (Exception e) {
            System.out.println("count:"+count);
            e.printStackTrace();
        }
    }


}

程序设置VM options：-Xms1m -Xmx8m -XX:+HeapDumpOnOutOfMemoryError

-XX:+HeapDumpOnOutOfMemoryError参数表示当JVM发生OOM时，自动生成DUMP文件

GC：垃圾回收

JVM在进行GC时，并不是对堆的区域统一回收。大部分时候回收的是新生代

两种GC：轻GC(minor gc)，重GC (full gc)

垃圾标记阶段：对象存活判断

堆里存放着几乎所有的Java对象实例，在GC执行垃圾回收之前，首先需要区分出内存中那些是存活对象，哪些是已经死亡的对象。只有被标记为已经死亡的对象，GC才会在垃圾回收过程时，释放掉其所占用的内存空间，因此我们可以称这个过程为垃圾标记阶段。
那么在JVM中是如何标记一个对象死亡的呢？简单来说，当一个对象已经不再被任何存活的对象引用时，就可以宣判为死亡。
判断对象存活一般有两种方式：引用计数算法和可达性分析算法。

1.垃圾标记阶段的算法之引用计数算法

引用计数算法（Reference Counting）比较简单，对每个对象保存一个整型的引用计数器属性。用于记录对象被引用的情况。

对于一个对象A，只要有任何一个对象引用了A，则A的引用计数器就加1；当引用失效时，引用计数器就减1。只要对象A的引用计数器的值为0，即表示对象A不可能再被使用，可进行回收。

优点：实现简单，垃圾对象便于辨识；判定效率高，回收没有延迟性。

缺点：

它需要单独的字段存储计数器，这样的做法增加了存储空间的开销。
每次赋值都需要更新计数器，伴随着加法和减法操作，这增加了时间开销。
引用计数器有一个严重的问题，即无法处理循环引用的情况。这是一条致命缺陷，导致在Java的垃圾回收器中没有使用这类算法。

小结

引用计数算法，是很多语言的资源回收选择，例如因人工智能而更加火热的Python，它更是同时支持引用计数和垃圾收集机制。

具体哪种最优是要看场景的，业界有大规模实践中仅保留引用计数机制，以提高吞吐量的尝试

Java并没有选择引用计数，是因为其存在一个基本的难题，也就是很难处理循环引用关系。

Python如何解决循环引用？

手动解除：很好理解，就是在合适的时机，解除引用关系。
使用弱引用weakref，weakref是Python提供的标准库，旨在解决循环引用。

2.垃圾标记阶段的算法之可达性分析算法

可达性分析算法（根搜索算法、追踪性垃圾收集）

相对于引用计数算法而言，可达性分析算法不仅同样具备实现简单和执行高效等特点，更重要的是该算法可以有效地解决在引用计数算法中循环引用的问题****，防止内存泄漏的发生。
相较于引用计数算法，这里的可达性分析就是Java、C#选择的。这种类型的垃圾收集通常也叫作追踪性垃圾收集（Tracing Garbage Collection）
所谓"GCRoots”根集合就是一组必须活跃的引用。

基本思路：

可达性分析算法是以根对象集合（GCRoots）为起始点，按照从上至下的方式搜索被根对象集合所连接的目标对象是否可达。
使用可达性分析算法后，内存中的存活对象都会被根对象集合直接或间接连接着，搜索所走过的路径称为引用链（Reference Chain）
如果目标对象没有任何引用链相连，则是不可达的，就意味着该对象己经死亡，可以标记为垃圾对象。
在可达性分析算法中，只有能够被根对象集合直接或者间接连接的对象才是存活对象。

在Java语言中，GC Roots包括以下几类元素：

虚拟机栈中引用的对象(比如：各个线程被调用的方法中使用到的参数、局部变量等)
本地方法栈内JNI(通常说的本地方法)引用的对象
方法区中类静态属性引用的对象(比如：Java类的引用类型静态变量)
方法区中常量引用的对象(比如：字符串常量池（String Table）里的引用)
所有被同步锁synchronized持有的对象
Java虚拟机内部的引用(基本数据类型对应的Class对象，一些常驻的异常对象(如：NullPointerException、OutOfMemoryError)，系统类加载器)
反映java虚拟机内部情况的JMXBean、JVMTI中注册的回调、本地代码缓存等

对象的finalization机制

Java语言提供了对象终止（finalization）机制来允许开发人员提供对象被销毁之前的自定义处理逻辑。

当垃圾回收器发现没有引用指向一个对象，即：垃圾回收此对象之前，总会先调用这个对象的finalize()方法。

finalize() 方法允许在子类中被重写，用于在对象被回收时进行资源释放。通常在这个方法中进行一些资源释放和清理的工作，比如关闭文件、套接字和数据库连接等。

永远不要主动调用某个对象的finalize()方法，应该交给垃圾回收机制调用。理由包括下面三点：

在finalize()时*可能会导致对象复活。
finalize()方法的执行时间是没有保障的，它完全由GC线程决定，极端情况下，若不发生GC，则finalize()方法将没有执行机会。
一个糟糕的finalize()会严重影响GC的性能

从功能上来说，finalize()方法与C++中的析构函数比较相似，但是Java采用的是基于垃圾回收器的自动内存管理机制，所以finalize()方法在本质上不同于C++中的析构函数。

由于finalize()方法的存在，虚拟机中的对象一般处于三种可能的状态。

如果从所有的根节点都无法访问到某个对象，说明对象己经不再使用了。一般来说，此对象需要被回收。但事实上，也并非是“非死不可”的，这时候它们暂时处于“缓刑”阶段。一个无法触及的对象有可能在某一个条件下“复活”自己，如果这样，那么对它的回收就是不合理的，为此，定义虚拟机中的对象可能的三种状态。如下：

可触及的：从根节点开始，可以到达这个对象。
可复活的：对象的所有引用都被释放，但是对象有可能在finalize()中复活。
不可触及的：对象的finalize()被调用，并且没有复活，那么就会进入不可触及状态。不可触及的对象不可能被复活，因为finalize()只会被调用一次。

以上3种状态中，是由于inalize()方法的存在，进行的区分。只有在对象不可触及时才可以被回收。

判定一个对象objA是否可回收，至少要经历两次标记过程：

如果对象objA到GC Roots没有引用链，则进行第一次标记。
进行筛选，判断此对象是否有必要执行finalize()方法

①如果对象objA没有重写finalize()方法，或者finalize()方法已经被虚拟机调用过，则虚拟机视为“没有必要执行”，objA被判定为不可触及的。

②如果对象objA重写了finalize()方法，且还未执行过，那么objA会被插入到F-Queue队列中，由一个虚拟机自动创建的、低优先级的Finalizer线程触发其finalize()方法执行。

③finalize()方法是对象逃脱死亡的最后机会，稍后GC会对F-Queue队列中的对象进行第二次标记。如果objA在finalize()方法中与引用链上的任何一个对象建立了联系，那么在第二次标记时，objA会被移出“即将回收”集合。之后，对象会再次出现没有引用存在的情况。在这个情况下，finalize方法不会被再次调用，对象会直接变成不可触及的状态，也就是说，一个对象的finalize方法只会被调用一次。

代码示例：

package com.lin.oom;

public class demo03 {
    public static demo03 obj;//类变量，属于 GC Root

    //此方法只能被调用一次
    @Override
    protected void finalize() throws Throwable {
        super.finalize();
        System.out.println("调用当前类重写的finalize()方法");
        obj = this;//当前待回收的对象在finalize()方法中与引用链上的一个对象obj建立了联系
    }
    
    public static void main(String[] args) {
        try {
            obj = new demo03();
            // 对象第一次成功拯救自己
            obj = null;
            System.gc();//调用垃圾回收器
            System.out.println("第1次 gc");
            // 因为Finalizer线程优先级很低，暂停2秒，以等待它
            Thread.sleep(2000);
            if (obj == null) {
                System.out.println("obj is dead");
            } else {
                System.out.println("obj is still alive");
            }
            System.out.println("第2次 gc");
            // 下面这段代码与上面的完全相同，但是这次自救却失败了
            obj = null;
            System.gc();
            // 因为Finalizer线程优先级很低，暂停2秒，以等待它
            Thread.sleep(2000);
            if (obj == null) {
                System.out.println("obj is dead");
            } else {
                System.out.println("obj is still alive");
            }
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }

}

注销掉重写的finalize（）方法，运行结果：

重写的finalize（）方法，运行结果

垃圾清除阶段

当成功区分出内存中存活对象和死亡对象后，GC接下来的任务就是执行垃圾回收，释放掉无用对象所占用的内存空间，以便有足够的可用内存空间为新对象分配内存。

目前在JVM中比较常见的三种垃圾收集算法是标记一清除算法（Mark-Sweep）、复制算法（copying）、标记-压缩算法（Mark-Compact）

1.垃圾清除阶段算法之标记-清除算法

背景

标记-清除算法（Mark-Sweep）是一种非常基础和常见的垃圾收集算法，该算法被J.McCarthy等人在1960年提出并并应用于Lisp语言。

执行过程

当堆中的有效内存空间（available memory）被耗尽的时候，就会停止整个程序（也被称为stop the world），然后进行两项工作，第一项则是标记，第二项则是清除

标记：Collector从引用根节点开始遍历，标记所有被引用的对象。一般是在对象的Header中记录为可达对象。
清除：Collector对堆内存从头到尾进行线性的遍历，如果发现某个对象在其Header中没有标记为可达对象，则将其**回收 **

缺点

标记清除算法的效率不算高
在进行GC的时候，需要停止整个应用程序，用户体验较差
这种方式清理出来的空闲内存是不连续的，产生内存碎片，需要维护一个空闲列表

注意：这里所谓的清除并不是真的置空，而是把需要清除的对象地址保存在空闲的地址列表里。下次有新对象需要加载时，判断垃圾的位置空间是否够，如果够，就存放覆盖原有的地址。

2.垃圾清除阶段算法之标记-复制算法

背景

为了解决标记-清除算法在垃圾收集效率方面的缺陷，M.L.Minsky于1963年发表了著名的论文，“使用双存储区的Lisp语言垃圾收集器CA LISP Garbage Collector Algorithm Using Serial Secondary Storage）”。M.L.Minsky在该论文中描述的算法被人们称为复制（Copying）算法，它也被M.L.Minsky本人成功地引入到了Lisp语言的一个实现版本中。

核心思想

将活着的内存空间分为两块，每次只使用其中一块，在垃圾回收时将正在使用的内存中的存活对象复制到未被使用的内存块中，之后清除正在使用的内存块中的所有对象，交换两个内存的角色，最后完成垃圾回收

优点

没有标记和清除过程，实现简单，运行高效
复制过去以后保证空间的连续性，不会出现“碎片”问题。

缺点

此算法的缺点也是很明显的，就是需要两倍的内存空间。
对于G1这种分拆成为大量region的GC，复制而不是移动，意味着GC需要维护region之间对象引用关系，不管是内存占用或者时间开销也不小

特别的，如果系统中的垃圾对象很多，复制算法的效率才会比较高。因为复制算法需要复制的存活对象数量并不会太大，或者说非常低才行

3.垃圾清除阶段算法之标记-压缩（整理）算法

背景

复制算法的高效性是建立在存活对象少、垃圾对象多的前提下的。这种情况在新生代经常发生，但是在老年代，更常见的情况是大部分对象都是存活对象。如果依然使用复制算法，由于存活对象较多，复制的成本也将很高。因此，基于老年代垃圾回收的特性，需要使用其他的算法。

标记一清除算法的确可以应用在老年代中，但是该算法不仅执行效率低下，而且在执行完内存回收后还会产生内存碎片，所以JVM的设计者需要在此基础之上进行改进。标记-压缩（Mark-Compact）算法由此诞生。

1970年前后，G.L.Steele、C.J.Chene和D.s.Wise等研究者发布标记-压缩算法。在许多现代的垃圾收集器中，人们都使用了标记-压缩算法或其改进版本。

执行过程

第一阶段和标记清除算法一样，从根节点开始标记所有被引用对象
第二阶段将所有的存活对象压缩到内存的一端，按顺序排放。
之后，清理边界外所有的空间。

标记-压缩算法的最终效果等同于标记-清除算法执行完成后，再进行一次内存碎片整理，因此，也可以把它称为标记-清除-压缩（Mark-Sweep-Compact）算法。

二者的本质差异在于标记-清除算法是一种非移动式的回收算法，标记-压缩是移动式的。是否移动回收后的存活对象是一项优缺点并存的风险决策。

可以看到，标记的存活对象将会被整理，按照内存地址依次排列，而未被标记的内存会被清理掉。如此一来，当我们需要给新对象分配内存时，JVM只需要持有一个内存的起始地址即可，这比维护一个空闲列表显然少了许多开销。

标记压缩算法后，可以使用指针碰撞分配新的地址；而标记清除算法之后，要用空闲列表来分配新地址。
如果内存空间以规整和有序的方式分布，即已用和未用的内存都各自一边，彼此之间维系着一个记录下一次分配起始点的标记指针，当为新对象分配内存时，只需要通过修改指针的偏移量将新对象分配在第一个空闲内存位置上，这种分配方式就叫做指针碰撞（Bump tHe Pointer）。

优点

消除了标记-清除算法当中，内存区域分散的缺点，我们需要给新对象分配内存时，JVM只需要持有一个内存的起始地址即可。
消除了复制算法当中，内存减半的高额代价。

缺点

从效率上来说，标记-整理算法要低于复制算法。
移动对象的同时，如果对象被其他对象引用，则还需要调整引用的地址
移动过程中，需要全程暂停用户应用程序。即：STW

总结

效率上来说，复制算法是当之无愧的老大，但是却浪费了太多内存。

而为了尽量兼顾上面提到的三个指标，标记-整理算法相对来说更平滑一些，但是效率上不尽如人意，它比复制算法多了一个标记的阶段，比标记-清除多了一个整理内存的阶段

分代收集算法

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

回答：无，没有最好的算法，只有最合适的算法。

分代收集算法

前面所有这些算法中，并没有一种算法可以完全替代其他算法，它们都具有自己独特的优势和特点。分代收集算法应运而生。

分代收集算法，是基于这样一个事实：不同的对象的生命周期是不一样的。因此，不同生命周期的对象可以采取不同的收集方式，以便提高回收效率。一般是把Java堆分为新生代和老年代，这样就可以根据各个年代的特点使用不同的回收算法，以提高垃圾回收的效率。

在Java程序运行的过程中，会产生大量的对象，其中有些对象是与业务信息相关，比如Http请求中的Session对象、线程、Socket连接，这类对象跟业务直接挂钩，因此生命周期比较长。但是还有一些对象，主要是程序运行过程中生成的临时变量，这些对象生命周期会比较短，比如：String对象，由于其不变类的特性，系统会产生大量的这些对象，有些对象甚至只用一次即可回收。

目前几乎所有的GC都采用分代收集算法执行垃圾回收的。

在HotSpot中，基于分代的概念，GC所使用的内存回收算法必须结合年轻代和老年代各自的特点。

年轻代

年轻代特点：区域相对老年代较小，对象生命周期短、存活率低，回收频繁。

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

老年代

老年代特点：区域较大，对象生命周期长、存活率高，回收不及年轻代频繁。

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

Mark阶段的开销与存活对象的数量成正比。
Sweep阶段的开销与所管理区域的大小成正相关。
Compact阶段的开销与存活对象的数据成正比。

以HotSpot中的CMS回收器为例，CMS是基于Mark-Sweep实现的，对于对象的回收效率很高。而对于碎片问题，CMS采用基于Mark-Compact算法的Serial Old回收器作为补偿措施：当内存回收不佳（碎片导致的Concurrent Mode Failure时），将采用Serial Old执行Full GC以达到对老年代内存的整理。
分代的思想被现有的虚拟机广泛使用。几乎所有的垃圾回收器都区分新生代和老年代

增量收集算法

上述现有的算法，在垃圾回收过程中，应用软件将处于一种Stop the World的状态。在Stop the World状态下，应用程序所有的线程都会挂起，暂停一切正常的工作，等待垃圾回收的完成。如果垃圾回收时间过长，应用程序会被挂起很久，将严重影响用户体验或者系统的稳定性。为了解决这个问题，即对实时垃圾收集算法的研究直接导致了增量收集（Incremental Collecting）算法的诞生

基本思想

如果一次性将所有的垃圾进行处理，需要造成系统长时间的停顿，那么就可以让垃圾收集线程和应用程序线程交替执行。每次，垃圾收集线程只收集一小片区域的内存空间，接着切换到应用程序线程。依次反复，直到垃圾收集完成。

总的来说，增量收集算法的基础仍是传统的标记-清除和复制算法。增量收集算法通过对线程间冲突的妥善处理，允许垃圾收集线程以分阶段的方式完成标记、清理或复制工作

缺点

使用这种方式，由于在垃圾回收过程中，间断性地还执行了应用程序代码，所以能减少系统的停顿时间。但是，因为线程切换和上下文转换的消耗，会使得垃圾回收的总体成本上升，造成系统吞吐量的下降。

分区算法

一般来说，在相同条件下，堆空间越大，一次GC时所需要的时间就越长，有关GC产生的停顿也越长。为了更好地控制GC产生的停顿时间，将一块大的内存区域分割成多个小块，根据目标的停顿时间，每次合理地回收若干个小区间，而不是整个堆空间，从而减少一次GC所产生的停顿

分代算法将按照对象的生命周期长短划分成两个部分，分区算法将整个堆空间划分成连续的不同小区间。

每一个小区间都独立使用，独立回收。这种算法的好处是可以控制一次回收多少个小区间

参考：

尚硅谷JVM笔记

JMM

JMM就是Java内存模型(java memory model)

什么是JMM内存

作用：缓存一致性协议，用于定义数据读写的规则。

JMM定义了线程工作内存和主内存之间的抽象关系：线程之间的私有变量存储在主内存中，每个线程都有一个私有的本地变量。

posted on 2023-03-23 18:45 ·草莓味的可爱多阅读(19) 评论(0) 收藏举报

刷新页面返回顶部

JVM入门(探究)

JVM入门(探究)

JVM的位置

JVM的体系结构

类加载器

双亲委派机制

沙箱安全机制

组成沙箱的基本组件：

Native

PC寄存器

方法区

栈

堆

新生区、老年区、永久区

新生区

老年区

永久区

VM options参数设置

堆内存调优

Jprofiler

JProfiler安装

JProfiler监控软件安装

IDEA运行环境配置

GC：垃圾回收

垃圾标记阶段：对象存活判断

1.垃圾标记阶段的算法之引用计数算法

2.垃圾标记阶段的算法之可达性分析算法

对象的finalization机制

垃圾清除阶段

1.垃圾清除阶段算法之 标记-清除算法

2.垃圾清除阶段算法之 标记-复制算法

3.垃圾清除阶段算法之标记-压缩（整理）算法

总结

分代收集算法

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

增量收集算法

分区算法

JMM

1.垃圾清除阶段算法之标记-清除算法

2.垃圾清除阶段算法之标记-复制算法