JVM基础及JVM内存结构

布满荆棘的人生 2023-10-04 15:07 3阅读 0赞

# JVM基础 #

## JVM定义 ##

> JVM（Java Virtual Machine）即Java虚拟机
> 
> Java源码经过Javac命令编译后得到Java字节码，Java字节码需要在JVM上运行

## JVM作用 ##

> 1.  一次编写，处处运行
> 2.  自动内存管理，垃圾回收机制
> 3.  数组下标越界检查
> 4.  多态实现

## JVM,JRE,JDK关系 ##

> JRE = JVM + Java基础类库
> 
> JDK = JRE + Java编译工具(如javac,java,javap等)
> 
> ![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FmY18xMjgyMjA_size_16_color_FFFFFF_t_70][]

## JVM组成 ##

> 1.  类加载子系统
> 2.  JVM内存
> 3.  执行引擎
> 
> ![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FmY18xMjgyMjA_size_16_color_FFFFFF_t_70 1][]

# JVM内存结构 #

## 程序计数器 ##

> **作用**：记录下一次要执行的JVM指令的内存地址
> 
> **运作**：当一个线程启动时，JVM就会为该线程创建一个私有的程序计数器内存，线程运行中执行Java代码，在JVM底层来看都是执行其对应的Java字节码中的JVM指令，而每个JVM指令都有一个行号（即该指令在内存中的地址），线程将要执行的下一条指令内存地址存入其私有的程序计数器中，当线程抢夺到CPU时间片时，JVM执行引擎中的解释器就会去该线程的程序计数器中获取要解释的指令，并解释为操作系统级别的机器码，交给CPU执行。当线程失去CPU时间片时，线程会继续将下一个要执行的指令的地址存入其私有的程序计数器，等到再次获取CPU时间片后，可以接着执行。
> 
> **特点**：
> 
> 1.  线程私有（随着线程的启动而创建，随着线程的死亡而销毁）
> 2.  不存在内存溢出（只存储下一条执行指令的地址值）
> 3.  内存小，速度快，物理实现是寄存器
> 
> **注意**：对于非本地方法，即Java方法，程序计数器记录的是下一条将要执行的JVM指令的地址，对于本地方法，即Native方法，程序计数器记录的是空。

## 虚拟机栈 ##

> 虚拟机栈的组成单位是：栈帧。
> 
> 栈帧的组成是：局部变量表，操作数栈，方法返回地址，动态链接。
> 
> **虚拟机栈**：JVM会每个线程创建一个虚拟机栈内存。即虚拟机栈是线程运行过程中需要的内存。虚拟机栈是线程私有的。
> 
> **栈帧**：线程中每次方法调用对应虚拟机栈有一个栈帧入栈，每次方法调用结束都对应虚拟机栈一个栈帧出栈。即栈帧是方法运行过程中需要的内存。
> 
> 注意：线程只能有一个活动栈帧，就是当前正在执行的方法，即虚拟机栈顶的栈帧。
> 
> **局部变量表**：方法运行中方法参数，局部变量所需要的内存，存储单位称为槽位。
> 
> **操作数栈**：方法运行中方法参数，局部变量运算所需要的内存。
> 
> **返回地址**：方法出口。
> 
> **动态链接**：是找到正确的方法入口，然后才有后来的进栈出栈的执行。
> 
> ![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FmY18xMjgyMjA_size_16_color_FFFFFF_t_70 2][]
> 
> **问题0：虚拟机栈是否会出现内存溢出？**
> 
> 会，虚拟机栈是一种栈结构，它有着入栈出栈两种行为。当入栈的栈帧数目大于虚拟机栈的深度时，就会导致java.lang.StackOverFlowError。现实例子比如方法的递归调用，但是递归方向是未知的。还有一种情况是单个栈帧内存过大，直接超出了虚拟机栈剩余内存大小，比如一个方法中定义了过多的变量，此时会报错java.lang.StackOverFlowError。
> 
> 还有一种情况，就是创建过多的线程，导致没有足够的内存给新线程创建虚拟机栈，此时会报错java.lang.OutOfMemoryError。
> 
> **问题1：虚拟机栈内存是否越大越好？**
> 
> JVM可以通过-Xss参数来设置单个线程的虚拟机栈的内存大小，如果单个线程的栈内存设置的越大，则总线程数越少。另外当创建的线程过多时，可能出现OOM。
> 
> **问题2：虚拟机栈内存是否需要被垃圾回收？**
> 
> 不需要，因为虚拟机栈的生命周期就是线程的生命周期。当线程结束时，虚拟机栈内存被JVM自动回收。相较于堆中对象，虚拟机栈中的数据生命周期更短且更容易判断是否存活。
> 
> **问题3：方法内的局部变量是否线程安全？**
> 
> 线程安全场景出现的前提是：1.多线程环境 2.多线程共享操作同一个数据
> 
> 一个方法被多线程执行，
> 
> 如果方法内的局部变量来自于外部传入（即方法参数），则可能该局部变量线程不安全，
> 
> 如果方法内的局部变量会作为方法返回值返回，则可能局部变量线程不安全，
> 
> 如果方法内的局部变量，既不从外部传入，也不传出给外部，则局部变量线程安全。
> 
> 当然前面三个判断是以局部变量是引用类型为前提的，如果方法内局部变量是基本类型，则一定线程安全。

## 本地方法栈 ##

> 和虚拟机栈没有本质区别。
> 
> 只是虚拟机栈是给Java方法用的，本地方法栈是给Native方法用的。
> 
> 本地方法栈也会出现StackOverFlowError和OOM。

## 堆 ##

> **定义**：所有的对象实例和数组实例都存在堆中。
> 
> **特点**：
> 
> 1.  线程共享，堆中对象都需要考虑线程安全的问题
> 2.  堆内存是GC管理的内存区域，可以实现垃圾对象内存回收。
> 3.  堆内存是实现分代的，如经典分代将堆分为两块：新生代，老年代
> 4.  堆内存可以划分出线程私有的TLAB，即本地线程分配缓冲区，提高内存分配效率，减少内存分配冲突。
> 5.  堆内存在物理上可以是不连续的内存组成，但是逻辑上是连续的。
> 6.  堆内存既可以是固定大小的，也可以可扩展大小的。可以通过虚拟机参数控制：
> 
>  *  \-Xms 堆初始内存大小
>  *  \-Xmx 堆最大内存大小
> 
> **注意**：当堆内存不足以分配时，就会发生堆内存溢出，即报错java.lang.OutOfMemoryError:Java heap space

## 方法区 ##

> **定义**：是线程共享的内存区域。方法区是堆的逻辑部分，但是也叫非堆。
> 
> **作用**：存储加载的类型信息，常量，静态变量，即时编译器编译代码的缓存
> 
> **实现**：方法区只是一种概念，对于Hotspot虚拟机，它的具体实现分为两阶段
> 
> 1.  JDK8：元空间，元空间处于本地内存中
> 2.  JDK8以前：永久代，永久代处于JVM内存中
> 
> ![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FmY18xMjgyMjA_size_16_color_FFFFFF_t_70 3][]
> 
> ![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FmY18xMjgyMjA_size_16_color_FFFFFF_t_70 4][]
> 
> **设置方法区内存大小的虚拟机参数变化**：
> 
> JDK8：-XX:MaxMetaspaceSize=
> 
> JDK8以前：-XX:MaxPermSize=
> 
> **方法区内存溢出报错变化**：
> 
> JDK8：java.lang.OutOfMemoryError：Metaspace
> 
> JDK8以前：java.lang.OutOfMemoryError：PermGen space
> 
> **问题：是否会存在方法区溢出的场景？**
> 
> 会，大量加载类到方法区，当前流行的Spring,Mybatis框架都使用了cjLib，即底层使用ClassWriter原理自动生成二进制类。

## 运行时常量池 ##

> **常量池和运行时常量池的关系：**
> 
> 常量池是class文件，即二进制字节码文件中的Constant Pool信息，当字节码被类加载器加载到方法区后，它的Constant Pool信息就会放入运行时常量池，并把里面的符号地址变为真实地址。
> 
> **串池和运行时常量池的关系：**
> 
> 运行时常量池中的字符串仅仅是符号，而不是对象。只有对应字符串符号第一次被使用时，才会变成字符串对象，并存入串池。
> 
> **串池特点：**
> 
> 1.  字符串对象的延迟加载特性：运行时常量池中的字符串仅仅是符号，只有运行时常量池中的字符串符号第一次被使用时才会变成字符串对象。
> 2.  字符串对象的去重特性：当需要使用字符串时，会先使用字符串符号去串池中查找是否由对应的字符串对象，如果有，则直接引用串池中的字符串对象。
> 3.  可以使用String::intern方法，主动将串池中还没有的字符串对象放入串池
> 4.  字节串+号拼接优化：
> 
> 对于字符串变量+拼接：底层new StringBuilder().append("x").append("y").toString();
> 
> 对于字符串常量+拼接：编译期优化，则直接替换为拼接结果字符串对象。
> 
> **串池位置：**
> 
> JDK6：永久代
> 
> JDK7：堆
> 
> 问题：如何验证串池位置
> 
> 我们可以利用String::intern()方法往串池中加入大量字符串对象，撑爆内存，使之抛出OOM，对于永久代内存溢出报错：java.lang.OutOfMemoryError:PermGen space,对于堆内存溢出报错：java.lang.OutOfMemoryError:Java heap space,所以可以通过内存溢出报错来辨别串池位置。
> 
> 问题：为什么要将串池位置从永久代换到堆中？
> 
> 因为Java程序运行中会产生大量的字符串对象，如果不及时回收字符串对象内存，很有可能造成内存溢出，而永久代只有在Full GC时才会进行回收，而堆内存新生代会经常触发Minor GC,代价更小，频率更高。
> 
> 问题：串池位置的变化对String::intern()方法返回结果的影响?
> 
> JDK6时，串池在永久代中，堆中字符串对象调用intern方法后，会尝试去串池中查找是否已存在对应字符串对象，若不存在，则复制堆中字符串对象到串池中，此时串池中复制对象和堆中原对象不是同一个对象。
> 
> JDK7时，串池在堆中，堆中字符串对象调用intern方法后，会尝试去串池中查找是否已存在对应字符串对象，若不存在，则串池直接引用堆中字符串对象，此时串池和堆中字符串对象是同一个。
> 
> **JDK7串池垃圾回收**
> 
> JDK7时，串池已经放在了堆中，所以串池可以被垃圾回收。
> 
> **字符串引发的内存问题**
> 
> 字符串对象可以存在堆中（非串池内存），存储在堆中有一个坏处就是允许重复的字符串对象，所以用堆来存储字符串对象，会产生大量相同的字符串对象，从而导致浪费内存。
> 
> 解决方案：将字符串对象存入串池，串池的数据结构是哈希表，哈希表可以保证不存入重复的字符串，对于重复的字符串对象，对外提供唯一的字符串对象引用。
> 
> **串池调优**
> 
> 由于串池的数据结构是哈希表，所以字符串对象存入哈希表之前，需要计算其在表中的桶位置，如果对应桶已经有对象了，则比较二者是否相同，如果不相同，则继续和桶下链表节点对象比较。
> 
> 可以发现在哈希冲突严重的串池中，存入字符串对象的效率很低。所以串池的调优就是针对降低其底层哈希表的哈希冲突。
> 
> 我们知道当哈希表长度越长时，哈希冲突越少。所以可以增加串池底层哈希表的长度，即增加哈希表桶数目。
> 
> \-XX:StringTableSize=

## 直接内存 ##

> **直接内存的意义**
> 
> 电脑内存条的内存受操作系统直接管理，所以也叫系统内存。
> 
> 当我们启动Java程序时，操作系统会从系统内存中划分出一部分作为JVM内存。
> 
> Java程序只能访问操作JVM内存，不能访问操作系统内存。这就造成了一些繁琐的内存操作。
> 
> 如阻塞IO，我们需要从磁盘中读取文件到Java程序中，则需要：
> 
> ![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FmY18xMjgyMjA_size_16_color_FFFFFF_t_70 5][]
> 
> 读取磁盘文件需要操作系统来做，所以切换到内核态，由操作系统在系统内存中开辟一块缓冲区，然后从磁盘中读取文件到系统缓冲区中，当系统缓冲区写满，则操作系统继续从该系统缓冲区中读取数据，并写入到JVM堆内存的缓冲区中，当JVM堆内存缓冲区写满，操作系统重新从磁盘中读取，周而复始，直到磁盘文件全部读取写入到JVM堆内存中。
> 
> 可以发现磁盘文件数据需要读取写入两次，一次是磁盘文件到系统内存缓冲区，一次是系统内存缓冲区到JVM堆内存缓冲区。只是因为JVM无法直接访问系统内存。
> 
> 后面NIO使用了直接内存
> 
> ![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FmY18xMjgyMjA_size_16_color_FFFFFF_t_70 6][]
> 
> 即操作系统将磁盘文件读取写入到直接内存中，JVM直接访问直接内存就可以读取文件数据。这里文件数据只写入了一次，且是直接内存。
> 
> 可以看出：直接内存是可以被操作系统和JVM直接访问操作的内存，这极大方便了磁盘文件的读写操作。
> 
> **JVM与直接内存**
> 
> 虽然直接内存不属于JVM内存结构，但是JVM可以操作直接内存，所以当直接内存不够分配时，也会在Java层面抛出内存溢出错误。java.lang.OutOfMemoryError: Direct buffer memory。
> 
> 由于JVM的垃圾回收器只管理堆内存，所以直接内存不会被JVM自动管理，即需要我们手写程序进行管理。
> 
> **直接内存的分配与回收原理**
> 
> 本质使用了Unsafe对象调用allocateMemory和setMemory完成直接内存的分配，另外回收需要主动调用freeMemory方法。
> 
> ![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FmY18xMjgyMjA_size_16_color_FFFFFF_t_70 7][]
> 
> 而我们使用ByteBuffer类对象使用完直接内存后，可以直接将对象赋值为null来间接完成直接内存回收。
> 
> 那是因为ByteBuffer的实现类内部，使用了Cleaner（虚引用）来监测ByteBuffer对象，一旦ByteBuffer对象被垃圾回收，那么就会由ReferenceHandler线程（守护线程）通过Cleaner的clean方法调用freeMemory来释放直接内存。
> 
> ![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FmY18xMjgyMjA_size_16_color_FFFFFF_t_70 8][]
> 
> **禁用显示回收对直接内存的影响**
> 
> 只有ByteBuffer对象被回收后，其分配的直接内存才会被回收。我们一般将ByteBuffer变量指向null，然后System.gc()来回收ByteBuffer对象。但是项目一般会禁用System.gc()这种显示回收的方式。因为System.gc()是一种FullGC回收。
> 
> 当使用-XX:+DisableExplicitGC禁用显示回收，即使System.gc()失效后，ByteBuffer对象使用的直接内存就无法即时被回收了。
> 
> 此时推荐使用Unsafe对象手动调用freeMemory()方法来释放直接内存

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FmY18xMjgyMjA_size_16_color_FFFFFF_t_70]: https://img-blog.csdnimg.cn/20210625140523913.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FmY18xMjgyMjA=,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FmY18xMjgyMjA_size_16_color_FFFFFF_t_70 1]: https://img-blog.csdnimg.cn/20210625140703625.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FmY18xMjgyMjA=,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FmY18xMjgyMjA_size_16_color_FFFFFF_t_70 2]: https://img-blog.csdnimg.cn/20210625143130475.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FmY18xMjgyMjA=,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FmY18xMjgyMjA_size_16_color_FFFFFF_t_70 3]: https://img-blog.csdnimg.cn/20210625152418771.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FmY18xMjgyMjA=,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FmY18xMjgyMjA_size_16_color_FFFFFF_t_70 4]: https://img-blog.csdnimg.cn/20210625152434938.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FmY18xMjgyMjA=,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FmY18xMjgyMjA_size_16_color_FFFFFF_t_70 5]: https://img-blog.csdnimg.cn/2021062517580029.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FmY18xMjgyMjA=,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FmY18xMjgyMjA_size_16_color_FFFFFF_t_70 6]: https://img-blog.csdnimg.cn/20210625180332875.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FmY18xMjgyMjA=,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FmY18xMjgyMjA_size_16_color_FFFFFF_t_70 7]: https://img-blog.csdnimg.cn/20210625181301285.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FmY18xMjgyMjA=,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FmY18xMjgyMjA_size_16_color_FFFFFF_t_70 8]: https://img-blog.csdnimg.cn/2021062518154910.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FmY18xMjgyMjA=,size_16,color_FFFFFF,t_70