JVM知识体系

Always_Best_Sign_X

已于 2024-09-23 18:32:17 修改

阅读量22

点赞数 1

分类专栏： JAVA基础文章标签： java

于 2024-08-29 16:46:27 首次发布

原文链接：https://pdai.tech/md/java/jvm/java-jvm-classload.html

版权

JAVA基础专栏收录该内容

3 篇文章 0 订阅

订阅专栏

JVM知识体系

1、JVM内存区域

在这里插入图片描述
根据上图可以发现，java程序执行需要经过四个阶段：
1、java文件编译成Class文件；
2、Class文件加载（类加载机制）；
3、运行时数据区域；
4、JIT编译（将字节码逐条解释为机器码的过程）；

1.1、程序计数器（线程私有）

字节码解释器工作时就是通过改变这个计数器的值来选取下一条需要执行的字节码指令，存在以下特点：
1、内存空间小；
2、如果线程执行的为java方法，则存储的为正在执行虚拟机字节码指令的地址；
3、如果为Native方法，则为undefined；
4、分支、循环、调整，异常处理、线程恢复等处理都依赖于程序计数器；
5、它是唯一一个在 JVM 规范中没有规定任何 OutOfMemoryError 情况的区域

1.2、虚拟机栈（线程私有）

Java 虚拟机栈(Java Virtual Machine Stacks)，早期也叫 Java 栈。每个线程在创建的时候都会创建一个虚拟机栈，其内部保存一个个的栈帧(Stack Frame），对应着一次次 Java 方法调用，是线程私有的，生命周期和线程一致。
Java虚拟机栈的作用：保存方法的局部变量、部分结果，并参与方法的调用和返回。每个方法执行，伴随着入栈（进栈/压栈），方法执行结束出栈。

如果虚拟机栈设置成固定不变：超过最大容量会抛出StackOverflowError异常；
如果是动态扩展：申请不到更多内存会出现OutOfMemoryError异常；
可通过参数 -Xss 设置大小；

在这里插入图片描述

1.3、本地方法栈（线程私有）

本地方法栈：就是一个 Java 调用非 Java 代码的接口；

1.4、堆（线程共享）

Java 堆是 Java 虚拟机管理的内存中最大的一块，被所有线程共享。此内存区域的唯一目的就是存放对象实例，几乎所有的对象实例以及数据都在这里分配内存。

为了进行高效的垃圾回收，虚拟机把堆内存逻辑上划分成三块区域（分代的唯一理由就是优化 GC 性能）：

新生带（年轻代）：新对象和没达到一定年龄的对象都在新生代;
老年代（养老区）：被长时间使用的对象，老年代的内存空间应该要比年轻代更大;
元空间（JDK1.8 之前叫永久代）：像一些方法中的操作临时对象等，JDK1.8 之前是占用 JVM 内存，JDK1.8 之后直接使用物理内存;

在这里插入图片描述
其中需要注意的是：堆的大小在 JVM 启动的时候就确定了，我们可以通过 -Xmx 和 -Xms 来设定：

-Xms 用来表示堆的起始内存，等价于 -XX:InitialHeapSize
-Xmx 用来表示堆的最大内存，等价于 -XX:MaxHeapSize

对象的创建过程：

在这里插入图片描述

1.5、方法区（元空间，线程共享）

1、方法区（Method Area）与 Java 堆一样，是所有线程共享的内存区域。
2、虽然 Java 虚拟机规范把方法区描述为堆的一个逻辑部分，但是它却有一个别名叫 Non-Heap（非堆），目的应该是与 Java 堆区分开。
3、运行时常量池（Runtime Constant Pool）是方法区的一部分。Class 文件中除了有类的版本/字段/方法/接口等描述信息外，还有一项信息是常量池（Constant Pool Table），用于存放编译期生成的各种字面量和符号引用，这部分内容将类在加载后进入方法区的运行时常量池中存放。运行期间也可能将新的常量放入池中，这种特性被开发人员利用得比较多的是 String.intern()方法。
4、受方法区内存的限制，当常量池无法再申请到内存时会抛出 OutOfMemoryError 异常。
5、方法区的大小和堆空间一样，可以选择固定大小也可选择可扩展，方法区的大小决定了系统可以放多少个类，如果系统类太多，导致方法区溢出，虚拟机同样会抛出内存溢出错误；
6、JVM 关闭后方法区即被释放；
7、方法区是JVM规范中定义的一种概念，用于存储类信息、常量池、静态变量、JIT编译后的代码缓存等数据；
8、Java7 中我们通过-XX:PermSize 和 -xx:MaxPermSize 来设置永久代参数，Java8 之后，随着永久代的取消，这些参数也就随之失效了，改为通过-XX:MetaspaceSize 和 -XX:MaxMetaspaceSize 用来设置元空间参数；

注意：
1、取消永久代使用元空间的原因：
（1）永久代设置空间大小很难确定，受JVM堆内存大小限制，当某个web工程，功能点很多，需要不断的动态加载很多类，就会经常出现OOM。而元空间不一样，不在虚拟机中，直接使用的是本地内存。
（2）对永久代进行调优比较困难。
2、方法区的垃圾收集主要回收两部分内容：常量池中废弃的常量和不再使用的类型。

1.6、堆外内存（直接内存）

在这里插入图片描述

（1）堆外内存的优点

1、减少垃圾回收的次数： 垃圾回收机制不会回收堆外内存，所以使用堆外内存可以减少垃圾回收次数，提升运行效率；因为垃圾回收工作时会暂停工作线程；
2、加快复制的速度： 因为堆内在flush到远程时，会先复制到堆内内存，在复制到堆外内存，然后在发送；操作系统是不可直接访问堆内内存的，而堆外内存省去了堆内到堆外的复制工作；比如netty框架就是用了直接内存才会如此之快；而且堆外内存使用的都是ByteBuffer，因此需要将Flush的数据进行序列化，然后堆外到堆内进行反序列化。

在这里插入图片描述

（2）堆外内存的缺点

1、因为不受jvm管控，所以垃圾回收机制不会回收直接内存的空间，需要用户自己释放内存空间；
2、堆外内存一旦发生泄漏，很难排查，所以，一定要对堆外内存足够了解再去使用堆外内存；
3、不适合存储很复杂的对象。一般简单的对象或者扁平化的比较适合；

（3）堆外内存的使用

作为JAVA开发者我们经常用java.nio.DirectByteBuffer对象进行堆外内存的管理和使用，它会在对象创建的时候就分配堆外内存。
DirectByteBuffer类是在Java Heap外分配内存，通过阅读DirectByteBuffer源码可以知道，对堆外内存的申请主要是通过成员变量unsafe来操作，下面介绍构造方法。

DirectByteBuffer(int cap) {                   // package-private
    // 初始化Buffer的四个核心属性
    super(-1, 0, cap, cap);
    // 判断是否需要页面对齐，通过参数-XX:+PageAlignDirectMemory控制，默认为false
    boolean pa = VM.isDirectMemoryPageAligned();
    int ps = Bits.pageSize();
    // 确保有足够内存
    long size = Math.max(1L, (long)cap + (pa ? ps : 0));
    Bits.reserveMemory(size, cap);
 
    long base = 0;
    try {
        // 调用unsafe方法分配内存
        base = unsafe.allocateMemory(size);
    } catch (OutOfMemoryError x) {
        // 分配失败，释放内存
        Bits.unreserveMemory(size, cap);
        throw x;
    }
    // 初始化内存空间为0
    unsafe.setMemory(base, size, (byte) 0);
    // 设置内存起始地址
    if (pa && (base % ps != 0)) {
        address = base + ps - (base & (ps - 1));
    } else {
        address = base;
    }
    // 使用Cleaner机制注册内存回收处理函数
    cleaner = Cleaner.create(this, new Deallocator(base, size, cap));
    att = null;
}

在DirectByteBuffer构造方法的最后注册了一个Cleaner对象，这个对象内部通过一个列表Bits，维护DirectByteBuffer和回收堆外内存的线程对象(Runnable) 之间的引用（就是一个直接释放内存的线程），下述是代码实现：

//就是一个释放直接内存的线程
private static class Deallocator  implements Runnable
{
        private static Unsafe unsafe = Unsafe.getUnsafe();
        private long address;
        private long size;
        private int capacity;
        private Deallocator(long address, long size, int capacity) {
            assert (address != 0);
            this.address = address;
            this.size = size;
            this.capacity = capacity;
        }
        public void run() {
            if (address == 0) {
                // Paranoia
                return;
            }
            unsafe.freeMemory(address); //释放地址
            address = 0;
            Bits.unreserveMemory(size, capacity); //修改统计
        }
}

2、垃圾回收

2.1、垃圾回收简介

在这里插入图片描述
JVM中堆内存分为三个区域：Eden/S0、S1（from:to）/老年代，其中Eden:from:to==8:1:1。当JVM中新创建一个对象之后：

1、新产生的对象优先分配在Eden区（除非配置了-XX:PretenureSizeThreshold，大于该值的对象会直接进入年老代）；
2、当Eden区满了或放不下了，这时候其中存活的对象会复制到from区。
注意：  这里，需要注意的是，如果存活下来的对象from区都放不下，则这些存活下来的对象全部进入年老代。之后Eden区的内存全部回收掉。
3、之后产生的对象继续分配在Eden区，当Eden区又满了或放不下了，这时候将会把Eden区和from区存活下来的对象复制到to区（同理，如果存活下来的对象to区都放不下，则这些存活下来的对象全部进入年老代），之后回收掉Eden区和from区的所有内存。
4、如上这样，会有很多对象会被复制很多次（每复制一次，对象的年龄就+1），默认情况下，当对象被复制了15次，就会进入年老代了。
5、当年老代满了或者存放不下，且将要进入年老代的存活对象的时候，就会发生一次Full GC（这个是我们最需要减少的，因为耗时很严重）。

新生代收集（Minor GC/Young GC）：只是新生代的垃圾收集；
老年代收集（Major GC/Old GC）：只是老年代的垃圾收集目前，只有 CMS GC 会有单独收集老年代的行为；
整堆收集（Full GC）：收集整个 Java 堆和方法区的垃圾；

2.2、引用类型、以及可达性判断（寻找垃圾的算法）

2.3、垃圾回收算法

（1）年轻代：复制算法

所有新生成的对象首先都是放在年轻代的。年轻代的目标就是尽可能快速的收集掉那些生命周期短的对象。
新生代内存按照8:1:1的比例分为一个eden区和两个survivor(survivor0,survivor1)区。一个Eden区，两个 Survivor区(一般而言)。大部分对象在Eden区中生成。回收时先将eden区存活对象复制到一个survivor0区，然后清空eden区，当这个survivor0区也存放满了时，则将eden区和survivor0区存活对象复制到另一个survivor1区，然后清空eden和这个survivor0区，此时survivor0区是空的，然后将survivor0区和survivor1区交换，即保持survivor1区为空，如此往复。
当survivor1区不足以存放 eden和survivor0的存活对象时，就将存活对象直接存放到老年代。若是老年代也满了就会触发一次Full GC(Major GC)，也就是新生代、老年代都进行回收。
新生代发生的GC也叫做Minor GC，MinorGC发生频率比较高(不一定等Eden区满了才触发)。

（2）老年代：标记-清楚或标记整理

在年轻代中经历了15次垃圾回收后仍然存活的对象，就会被放到年老代中。因此，可以认为年老代中存放的都是一些生命周期较长的对象。
内存比新生代也大很多(大概比例是1:2)，当老年代内存满时触发Major GC即Full GC，Full GC发生频率比较低，老年代对象存活时间比较长，存活率标记高。

以上这种年轻代与年老代分别采用不同回收算法的方式称为”分代收集算法”，这也是当下企业使用的一种方式

3）每一种算法都会有很多不同的垃圾回收器去实现，在实际使用中，根据自己的业务特点做出选择就好。

2.4、垃圾收集器

2.5、FullGC的触发条件

1、调用 System.gc()；
2、老年代空间不足；
3、空间分配担保失败：使用复制算法的 Minor GC 需要老年代的内存空间作担保，如果担保失败会执行一次 Full GC；
4、（1.7之前）永久代空间不足；
5、 Concurrent Mode Failure：执行 CMS GC 的过程中同时有对象要放入老年代，而此时老年代空间不足(可能是 GC 过程中浮动垃圾过多导致暂时性的空间不足)，便会报 Concurrent Mode Failure 错误，并触发 Full GC。

3、JVM调优和排错

3.1、JVM参数和垃圾回收参数

（1）JVM参数

（2）垃圾回收参数

3.2、常见内存溢出问题

（1）Java栈内存溢出

（2）Java堆内存溢出

创建的报错信息：

1、OutOfMemoryError: Java heap space 
2、OutOfMemoryError: GC overhead limit exceeded# OutOfMemoryError: Java heap space

第一个是堆内存溢出（当无法进行堆内存扩展时）；
第二个是old区占用过多，导致频繁的Full GC，最终导致GC overhead limit exceed;

-XX:+HeapDumpOutofMemoryErorr 当发生 OOM 时会自动 dump 堆栈到文件中。

（3）MetaSpace（元数据）内存溢出

常见的报错信息为：

java.lang.OutOfMemoryError: Metaspace

元空间里面保存的是：加载的类信息，常量池信息等信息，且元空间直接占用的机器内存信息，当不断地创建新类，本地内存空间又无法对元空间进行扩展的时候，就会出现这个报错信息。

-XX:MaxMetaspaceSize=10M 来限制最大元数据；

（4）堆内存Dump获取方式

1、添加JVM参数，当出现OOM的时候，会自动生存Dump文件: -XX:+HeapDumpOnOutOfMemoryError
2、jmap获取：在cmd里面执行：jmap -dump:format=b file=<文件名XX.hprof>
3、JConsole可视化工具直接导出。

3.3、JVM内存分析之堆外内存

可以通过 -XX:MaxDirectMemorySize 来指定最大的堆外内存大小，当使用达到了阈值的时候将调用 System.gc() 来做一次 full gc，以此来回收掉没有被使用的堆外内存。

3.4、JVM内存比例设置

3.5、OOM的分析方法

1、设置JVM参数-XX:+HeapDumpOnOutOfMemoryError，设定当发生OOM时自动dump出堆信息；（后面使用jhat对Dump文件进行分析）
2、JConsole 是一种 Java 监控和管理控制台工具，可以用于监视 Java 虚拟机（JVM）的性能和资源利用情况；
3、内存映像分析工具Jprofiler分析产生的堆储存快照（jmap ：生成对转储快照）。

4、类加载机制

4.1、类的生命周期

其中类加载的过程包括了加载、验证、准备、解析、初始化五个阶段。在这五个阶段中，加载、验证、准备和初始化这四个阶段发生的顺序是确定的，而解析阶段则不一定，它在某些情况下可以在初始化阶段之后开始，这是为了支持Java语言的运行时绑定(也成为动态绑定或晚期绑定)。
另外注意这里的几个阶段是按顺序开始，而不是按顺序进行或完成，因为这些阶段通常都是互相交叉地混合进行的，通常在一个阶段执行的过程中调用或激活另一个阶段。

在这里插入图片描述

4.2、类的加载

在加载阶段，虚拟机需要完成以下三件事情:
1、通过一个类的全限定名来获取其定义的二进制字节流。
2、将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构。
3、在Java堆中生成一个代表这个类的java.lang.Class对象，作为对方法区中这些数据的访问入口。

加载.Class文件的格式

1、从本地系统中直接加载
2、通过网络下载.class文件
3、从zip，jar等归档文件中加载.class文件
4、从专有数据库中提取.class文件
5、将Java源文件动态编译为.class文件
（外部文件进入到JVM内部，都是以二进制字节流的形式进行传输）

4.3、类的连接

（1）验证：确保被加载的类的正确性

（2）准备：为类的静态变量分配内存，并将其初始化

（3）解析：将类中的符号引用转换成直接引用

4.4、初始化

只有当对类的主动使用的时候才会导致类的初始化，类的主动使用包括以下4种:
1、常见类的实例；
2、对静态变量复制、或者调用类的静态方法；
3、反射
4、初始化子类，那么父类也会被初始化；

4.5、使用

4.6、卸载

4.7、JVM类加载机制

在这里插入图片描述

4.7.1、类加载器

（1）启动类加载器：Bootstrap ClassLoader，负责加载存放在JDK\jre\lib(JDK代表JDK的安装目录，下同)下，或被-Xbootclasspath参数指定的路径中的，并且能被虚拟机识别的类库(如rt.jar，所有的java.*开头的类均被Bootstrap ClassLoader加载)。启动类加载器是无法被Java程序直接引用的。
（2）扩展类加载器：该加载器由sun.misc.Launcher$ExtClassLoader实现，它负责加载 JDK\jre\lib\ext 目录中，或者由java.ext.dirs系统变量指定的路径中的所有类库(如javax.*开头的类)，开发者可以直接使用扩展类加载器。
（3）应用类加载器：Application ClassLoader，该类加载器由sun.misc.Launcher$AppClassLoader来实现，它负责 加载用户类路径(ClassPath)所指定的类，开发者可以直接使用该类加载器，如果应用程序中没有自定义过自己的类加载器，一般情况下这个就是程序中默认的类加载器。

4.7.2、JVM类加载机制

全盘负责：当一个类加载器负责加载某个Class时，该Class所依赖的和引用的其他Class也将由该类加载器负责载入，除非显示使用另外一个类加载器来载入；
父类委托：先让父类加载器试图加载该类，只有在父类加载器无法加载该类时才尝试从自己的类路径中加载该类；
缓存机制：缓存机制将会保证所有加载过的Class都会被缓存，当程序中需要使用某个Class时，类加载器先从缓存区寻找该Class，只有缓存区不存在，系统才会读取该类对应的二进制数据，并将其转换成Class对象，存入缓存区。这就是为什么修改了Class后，必须重启JVM，程序的修改才会生效；
双亲委派机制：如果一个类加载器收到了类加载的请求，它首先不会自己去尝试加载这个类，而是把请求委托给父加载器去完成，依次向上，因此，所有的类加载请求最终都应该被传递到顶层的启动类加载器中，只有当父加载器在它的搜索范围中没有找到所需的类时，即无法完成该加载，子加载器才会尝试自己去加载该类。

双亲委派机制的流程：

1、当AppClassLoader加载一个class时，它首先不会自己去尝试加载这个类，而是把类加载请求委派给父类加载器ExtClassLoader去完成。
2、当ExtClassLoader加载一个class时，它首先也不会自己去尝试加载这个类，而是把类加载请求委派给BootStrapClassLoader去完成。
3、如果BootStrapClassLoader加载失败(例如在$JAVA_HOME/jre/lib里未查找到该class)，会使用ExtClassLoader来尝试加载；
4、若ExtClassLoader也加载失败，则会使用AppClassLoader来加载；
5、如果AppClassLoader也加载失败，则会报出异常ClassNotFoundException。

双亲委派机制的好处：

1、系统类防止内存中出现多份同样的字节码
2、保证Java程序安全稳定运行

4.7.3、自定义类加载机制器

通常情况下，我们都是直接使用系统类加载器。但是，有的时候，我们也需要自定义类加载器。比如应用是通过网络来传输 Java 类的字节码，为保证安全性，这些字节码经过了加密处理，这时系统类加载器就无法对其进行加载，这样则需要自定义类加载器来实现。自定义类加载器一般都是继承自 ClassLoader 类，从上面对 loadClass 方法来分析来看，我们 只需要重写 findClass 方法 即可。