深入理解Java虚拟机（一）

桃扇骨 2022-05-20 02:29 387阅读 0赞

## 引言 ##

JVM 是 Java 虚拟机，是一种规范，它遵循着冯诺依曼体系结构的设计原理。在冯诺依曼体系结构中指出，计算机处理的数据和指令都是二进制数，采用存储程序方式，不加区分的存储在同一个存储器里，并且顺序执行。

指令由操作码和地址码组成，操作码决定了操作类型和所操作数的数字类型，地址码则指出地址码和操作数。不同的操作系统指令集以及数据结构都有着差异，而 JVM 通过在操作系统上建立虚拟机，自己定义出来的一套统一的数据结构和操作指令，把同一套语言翻译给各大主流的操作系统，实现了跨平台运行，可以说 JVM 是 Java 的核心，是 Java 可以一次编译到处运行的本质所在。

## 一、JVM组成 ##

JVM 有多种实现，例如 Oracle 的JVM，HP 的 JVM 和 IBM 的 JVM 等，本文使用广泛的HotSpot JVM。

### 1. JVM在JDK中的位置 ###

众所周知，JDK 是 Java 开发的必备工具箱，JDK 其中有一部分是 JRE，JRE 是 JAVA 运行环境，JVM 则是 JRE 最核心的部分，下面是一张关于JDK Standard Edtion的组成图。  
![这里写图片描述][70]

从最底层的位置可以看出JVM有多重要，而实际项目中JAVA应用的性能优化，OOM等异常处理最终都得从JVM这儿来解决。在命令行，我们可以通过`java -version`命令可以查看关于当前机器JVM的信息，下面是在本人Win7系统上执行命令的截图。

![这里写图片描述][70 1]

### 2. JVM的组成 ###

JVM由4大部分组成：ClassLoader，Runtime Data Area，Execution Engine，Native Interface。JVM组成结构图如下：（后续会逐一学习）  
![这里写图片描述][70 2]

*  ClassLoader 是类加载器，是负责加载class文件，class文件在文件开头有特定的文件标识，并且ClassLoader只负责class文件的加载，至于它是否可以运行，则由Execution Engine决定
 *  Native Interface是负责调用本地接口。它的作用是调用不同语言的接口给JAVA用，它会在Native Method Stack中记录对应的本地方法，然后调用该方法时就通过Execution Engine加载对应的本地lib。
    
    > 现在很少使用，因为即使要和底层C或C++接口进行交互，可以用WebService进行，完全没必要用JNI
 *  Execution Engine是执行引擎，Class文件被加载后，会把指令和数据信息放入内存中，Execution Engine则负责把这些命令解释给操作系统。
 *  Runtime Data Area是运行时数据区，用于存放数据，分为五部分：Stack（栈），Heap（堆），Method Area（方法区），PC Register（寄存器），Native Method Stack。几乎所有的关于Java内存方面的问题，都是集中在这块。下图是关于运行时数据区的描述：  
    ![这里写图片描述][70 3]

## 三、Runtime Data Area ##

![这里写图片描述][70 4]

### 1. 栈（线程私有） ###

*  Stack表示Java栈内存，在Java中，每个线程都拥有自己的栈，即栈为线程私有，其生命周期与线程相同
 *  栈里面存储着的是栈帧（StackFrame），结构见下图
 *  Stack描述的是Java方法执行的内存模型：每个方法被执行的时候，都会同时创建一个栈帧用于存储局部变量表、操作数栈、动态链接、方法出口等信息。每一个方法被调用直至执行完成的过程就对应着一个栈帧在虚拟机栈中从入栈到出栈的过程
 *  局部变量表存放了编译期可知的各种基本数据类型（boolean、byte、char、short、int、float、long、double）、对象引用（reference类型）；
 *  局部变量表所需的空间在编译期间完成分配。当进入一个方法时，其需要在帧中分配多大的局部变量空间是确定的，方法运行期间不会改变局部变量表的大小。局部变量用来存储一个类的方法中所用到的局部变量。

下图是关于栈之间关系以及栈和非堆内存的关系基本描述：  
![这里写图片描述][70 5]

### 2. 堆（线程共享，GC最频繁） ###

*  Java堆是Java虚拟机管理内存中最大的一块，是所有线程共享的内存区域，随虚拟机的启动而创建。该区域唯一目的是存放对象实例，几乎所有对象的实例都在堆里面分配。Java堆是垃圾收集器管理的主要区域，被称作"GC堆"
 *  Java虚拟机规范规定，Java堆可以处于物理上不连续的内存空间中，只要逻辑上连续即可。如同磁盘空间一样，既可以实现成固定大小，也可以是扩展的，当前主流虚拟机都是按照扩展来实现的，通过 -Xms 和 -Xmx 控制
 *  Java虚拟机规范中对该区域规定了 OutOfMemoryError 异常：如果堆中没有内存完成实例分配，并且堆无法再扩展则抛出OutOfMemoryError异常
 *  堆的体系结构：Heap堆 （Java7之前）

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

*  堆内存**逻辑上**分为三部分：新生区 + 养老区 + 永久区  
    此处需要注意的是：在JDK1.7之前，永久区属于方法区的一部分
    
    ![这里写图片描述][70 6]

新生区介绍

*  新生区是类的诞生、成长、消亡的区域，一个类在这里产生、应用，最后被垃圾回收器收集，结束生命
 *  新生区又分为两部分：伊甸区（Eden space）和幸存者区（Survivor pace），所有的类都是在伊甸区被new出来的
 *  幸存区有两个：0区（Survivor 0 space）和1区（Survivor 1 space）
 *  Eden和Survivor 0、Survivor 1的比例是：8：1：1
 *  新生区的大小站堆内存的三分之一

> 解释：
> 
> 当Eden区的空间用完时，程序又需要创建对象，JVM的垃圾回收器将对Eden区进行垃圾回收(Minor GC)，将伊甸园区中不再被其他对象所引用的对象进行销毁。
> 
> 然后将伊甸园中的剩余对象移动到幸存0区（也叫From区），若幸存0区也满了，再对该区进行垃圾回收，然后移动到1区（也叫To区）。那如果1区也满了呢？
> 
> 再移动到养老区，若养老区也满了，那么这个时候将产生MajorGC（Full GC），进行养老区的内存清理， 若养老区执行了Full GC之后发现依然无法进行对象的保存，就会产生OOM异常“OutOfMemoryError”

### 3. PC寄存器（线程私有） ###

PC Register是程序计数寄存器，每个JAVA线程都有一个单独的PC Register，它表示一个指针，由Execution Engine读取下一条指令。如果该线程正在执行Java方法，则PC Register存储的是正在被执行的指令的地址，如果是本地方法，PC Register的值没有定义。PC寄存器非常小，只占用一个字宽，可以持有一个returnAdress或者特定平台的一个指针。

### 4. 方法区：（Non-heap，所谓的永久代，线程共享） ###

*  方法区是各个线程共享的内存区域，**用于存储已被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码等数据**。Java虚拟机对这个区域的限制非常宽松，处理和Java堆一样不需要连续的内存和可以选择固定大小或者可扩展外，还可以选择不实现垃圾收集。相对而言，垃圾收集在这个区域较少出现
 *  Java虚拟机规范中对该区域规定了OutOfMemoryError异常： 如果方法区的内存空间不能满足内存分配请求，那Java虚拟机将抛出一个OutOfMemoryError异常
 *  运行时常量池是方法区的一部分
 *  方法区保存装载的类信息：类型的常量池、字段、方法、方法字节码、通常和永久区（Perm）关联在一起
 *  运行时常量池

>  *  Class文件中除了有类的版本、字段、方法、接口等信息外，还有一项信息是常量池，用于存放编译期生成的各种字面常量和符号引用，这部分内容在类加载后存放到方法区的常量池中
>  *  Java虚拟机规范中对该区域规定了OutOfMemoryError异常：当常量池无法申请到内存时抛出OutOfMemoryError异常

### 5. 本地方法栈 ###

Native Method Stack是供本地方法（非java）使用的栈，每个线程持有一个Native Method Stack。

## 三、JVM运行原理 ##

### 1. 执行流程 ###

Java 程序被 javac 工具编译为 .class 字节码文件之后，我们执行 java 命令，该 class 文件便被 JVM 的 Class Loader 加载，可以看出JVM的启动是通过JAVA Path下的 java.exe 进行的。

JVM的初始化、运行到结束大概包括这么几步：

*  调用操作系统API判断系统的CPU架构，根据对应CPU类型寻找位于JRE目录下的/lib/jvm.cfg文件
 *  然后通过该配置文件找到对应的 jvm.dll 文件（如果我们参数中有-server或者-client， 则加载对应参数所指定的 jvm.dll，启动指定类型的JVM），初始化jvm.dll并且挂接到 JNIENV 结构的实例上，之后就可以通过JNIENV实例装载并且处理class文件了
 *  class文件是字节码文件，它按照JVM的规范，定义了变量，方法等的详细信息，JVM管理并且分配对应的内存来执行程序，同时管理垃圾回收，直到程序结束，一种情况是JVM的所有非守护线程停止，一种情况是程序调用 System.exit()，JVM的生命周期也结束。

### 2. 栈的管理 ###

JVM允许栈的大小是固定的或者是动态变化的。在Oracle的关于参数设置的官方文档中有关于Stack的设置，是通过 -Xss 来设置其大小。关于Stack的默认大小对于不同机器有不同的大小，并且不同厂商或者版本号的 jvm 的实现其大小也不同，如下表是HotSpot的默认大小：

<table> 
 <thead> 
  <tr> 
   <th>Tables</th> 
   <th align="center">Are</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>Windows IA32</td> 
   <td align="center">64 KB</td> 
  </tr> 
  <tr> 
   <td>Linux IA32</td> 
   <td align="center">128 KB</td> 
  </tr> 
  <tr> 
   <td>Windows x86_64</td> 
   <td align="center">128 KB</td> 
  </tr> 
  <tr> 
   <td>Linux x86_64</td> 
   <td align="center">256 KB</td> 
  </tr> 
  <tr> 
   <td>Windows IA64</td> 
   <td align="center">320 KB</td> 
  </tr> 
  <tr> 
   <td>Linux IA64</td> 
   <td align="center">1024 KB</td> 
  </tr> 
  <tr> 
   <td>Solaris Sparc</td> 
   <td align="center">512 KB</td> 
  </tr> 
 </tbody> 
</table>

一般通过减少常量，参数的个数来减少栈的增长。在程序设计时，我们把一些常量定义到一个对象中，然后来引用它们可以体现这一点，另外，少用递归调用也可以减少栈的占用。  
栈是不需要垃圾回收的（线程私有），尽管说垃圾回收是Java内存管理的一个很热的话题，栈中的对象如果用垃圾回收的观点来看，它永远是live状态，是可以reachable的，所以也不需要回收，它占有的空间随着Thread的结束而释放。

关于栈一般会发生以下两种异常：

*  当线程中的计算所需要的栈超过所允许大小时，会抛出StackOverflowError
 *  当Java栈试图扩展时，没有足够的存储器来实现扩展，JVM会报OutOfMemoryError

### 3. 堆的管理 ###

堆的管理要比栈管理复杂的多  
![这里写图片描述][70 7]

上图是 Heap 堆和 PermanentSapce 的组合图。其中 Eden 区里面存着是新生的对象，S0 和 S1 中存放着是每次垃圾回收后存活下来的对象 。所以**每次垃圾回收后，Eden区会被清空。存活下来的对象先是放到 S0，当 S0 满了之后移动到 S1。当S1 满了之后移动到 Old Space。**

Survivor 的两个区是对称的，没先后关系，所以同一个区中可能同时存在从 Eden 复制过来对象，和从前一个Survivor复制过来的对象，而复制到老年区的只有从第一个Survivor复制过来的对象。而且，Survivor区总有一个是空的。同时，根据程序需要，Survivor区是可以配置为多个的（多于两个），这样可以增加对象在年轻代中的存在时间，减少被放到老年代的可能。

Old Space 中则存放生命周期比较长的对象，而且有些比较大的新生对象也放在Old Space中。

堆的大小通过 **-Xms** 和 **-Xmx** 来指定最小值和最大值，通过 **-Xmn** 来指定Young Generation的大小（一些老版本也用-XX:NewSize指定），即上图中的 Eden 加 S0 和 S1的总大小。然后通过-XX:NewRatio来指定Eden区的大小，在 Xms 和 Xmx 相等的情况下，该参数不需要设置。通过-XX：SurvivorRatio 来设置 Eden 和 一个Survivor 区的比值。

堆异常分为两种，一种是Out of Memory(OOM)，一种是Memory Leak(ML)。Memory Leak最终将导致OOM。

实际应用中表现为：从Console看，内存监控曲线一直在顶部，程序响应慢；从线程看，大部分的线程在进行GC，占用比较多的CPU，最终程序异常终止，报OOM。OOM发生的时间不定，有短的一个小时，有长的10天一个月的。关于异常的处理，确定OOM/ML异常后，一定要注意保护现场，可以dump heap，如果没有现场则开启GCFlag收集垃圾回收日志，然后进行分析，确定问题所在。如果问题不是ML的话，一般通过增加Heap，增加物理内存来解决问题，是的话，就修改程序逻辑。

## 四、垃圾回收 ##

### 1. JVM中会在以下情况触发回收： ###

*  对象没有被引用
 *  作用域发生未捕捉异常
 *  程序正常执行完毕
 *  程序执行了System.exit()
 *  程序发生意外终止

### 2. 如何确定对象为垃圾对象？ ###

*  引用计数法：此方法无法解决两个对象之间循环引用的问题。
 *  可达性分析：图的遍历

> 简单的说，就是从一个叫GC Roots的对象开始，向下搜索，如果一个对象不能达到GC Roots对象的时候，说明它可以被回收了。

### 3. 垃圾收集算法 ###

*  引用计数法
 *  复制算法：该算法是从根集合扫描，并将存活的对象复制到新的空间，这种算法在存活对象少时比较高效。
 *  标记 - 清除算法（Mark-Sweep）：该算法是从根集合扫描整个空间，标记存活的对象，然后在扫描整个空间对没有被标记的对象进行回收。这种算法在存活对象较多时比较高效，但会产生内存碎片
 *  标记 - 压缩算法（Mark-Compress）：标记整理算法和标记清除算法一样都会扫描并标记存活对象，在回收未标记对象的同时会整理被标记的对象，解决了内存碎片的问题
 *  标记清除压缩

### 4. 分代收集 ###

JVM中，不同的内存区域作用和性质不一样，使用的垃圾回收算法也不一样，所以JVM中又定义了几种不同的垃圾回收器，图中连线代表两个回收器可以同时使用：

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3p4ZDE0MzU1MTM3NzU_size_16_color_FFFFFF_t_70]

*  Serial GC。从名字上看，串行GC意味着是一种单线程的，所以它要求收集的时候所有的线程暂停（Stop The World）。这对于高性能的应用是不合理的，所以串行GC一般用于Client模式的JVM中。（过时）
 *  ParNew GC。是在SerialGC的基础上，增加了多线程机制。但是如果机器是单CPU的，这种收集器是比SerialGC效率低的。
 *  Parrallel Scavenge GC。这种收集器又叫吞吐量优先收集器，而吞吐量 = 程序运行时间/(JVM执行回收的时间+程序运行时间)。假设程序运行了100分钟，JVM的垃圾回收占用1分钟，那么吞吐量就是99%。Parallel Scavenge GC由于可以提供比较不错的吞吐量，所以被作为了server模式JVM的默认配置。
 *  ParallelOld是老生代并行收集器的一种，使用了标记整理算法，是JDK1.6中引进的，在之前老生代只能使用串行回收收集器。
 *  Serial Old是老生代client模式下的默认收集器，单线程执行，同时也作为CMS收集器失败后的备用收集器。（过时）
 *  CMS又称响应时间优先回收器，使用标记清除算法。他的回收线程数为(CPU核心数+3)/4，所以当CPU核心数为2时比较高效些。CMS分为4个过程：初始标记、并发标记、重新标记、并发清除。
 *  GarbageFirst（G1）。比较特殊的是G1回收器既可以回收Young Generation，也可以回收Tenured Generation。它是在JDK6的某个版本中才引入的，性能比较高，同时注意了吞吐量和响应时间。

对于垃圾收集器的组合使用可以通过下表中的参数指定：

![这里写图片描述][70 8]

默认的GC种类可以通过jvm.cfg或者通过jmap dump出heap来查看，一般我们通过jstat -gcutil \[pid\] 1000可以查看每秒gc的大体情况，或者可以在启动参数中加入：\-verbose:gc -XX:+PrintGCTimeStamps -XX:+PrintGCDetails -Xloggc:./gc.log来记录GC日志。

GC中有一种情况叫做Full GC，以下几种情况会触发Full GC：

*  Tenured Space空间不足以创建大的对象或者数组，会执行Full GC，并且当Full GC之后空间如果还不够，那么会OOM:java heap space
 *  Permanet Generation的大小不足，存放了太多的类信息，在非CMS情况下会触发Full GC。如果之后空间还不够，会OOM:PermGen space
 *  CMS GC时出现promotion failed和concurrent mode failure时，也会触发Full GC。promotion failed是在进行Minor GC时，survivor space放不下、对象只能放入旧生代，而此时旧生代也放不下造成的；concurrent mode failure是在执行CMS GC的过程中同时有对象要放入旧生代，而此时旧生代空间不足造成的
 *  判断MinorGC后，要晋升到TenuredSpace的对象大小大于TenuredSpace的大小，也会触发FullGC。

可以看出，当Full GC频繁发生时，一定是内存出问题了

[70]: /images/20220520/f88325b96fb24ec1bda07a7c7a2af921.png
[70 1]: /images/20220520/e5533870f3b74907a6a829b0c06acca9.png
[70 2]: /images/20220520/8400a5977cc54d148430ce5439b8d6e2.png
[70 3]: /images/20220520/56cfe5f287064f61a6e5d87ed507edf0.png
[70 4]: /images/20220520/e7c819b6c3184664985b8f2b2b6b5aac.png
[70 5]: /images/20220520/b4f88a912a90455eaf08e628ca489b9d.png
[70 6]: /images/20220520/fd24cdb8125748b98725b98d85886129.png
[70 7]: /images/20220520/1718e68bed934354990ea9917ae966db.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3p4ZDE0MzU1MTM3NzU_size_16_color_FFFFFF_t_70]: /images/20220520/6f914413d4944f20a8d68adcbb290ae3.png
[70 8]: /images/20220520/290cd270be1e415e9bbdfc30383676b4.png