深入理解Java虚拟机-Java内存区域与内存溢出异常

缺乏、安全感 2021-09-21 01:38 455阅读 0赞

> 本博客主要参考周志明老师的《深入理解Java虚拟机》第二版

读书是一种跟大神的交流。阅读《深入理解Java虚拟机》受益匪浅，对Java虚拟机有初步的认识。这里写博客主要出于以下三个目的：一方面是记录，方便日后阅读；一方面是加深对内容的理解；一方面是分享给大家，希望对大家有帮助。

《深入理解Java虚拟机》全书总结如下：

<table> 
 <thead> 
  <tr> 
   <th>序号</th> 
   <th>内容</th> 
   <th>链接地址</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>1</td> 
   <td>深入理解Java虚拟机-走近Java</td> 
   <td><a href="https://blog.csdn.net/ThinkWon/article/details/103804387" rel="nofollow">https://blog.csdn.net/ThinkWon/article/details/103804387</a></td> 
  </tr> 
  <tr> 
   <td>2</td> 
   <td>深入理解Java虚拟机-Java内存区域与内存溢出异常</td> 
   <td><a href="https://blog.csdn.net/ThinkWon/article/details/103827387" rel="nofollow">https://blog.csdn.net/ThinkWon/article/details/103827387</a></td> 
  </tr> 
  <tr> 
   <td>3</td> 
   <td>深入理解Java虚拟机-垃圾回收器与内存分配策略</td> 
   <td><a href="https://blog.csdn.net/ThinkWon/article/details/103831676" rel="nofollow">https://blog.csdn.net/ThinkWon/article/details/103831676</a></td> 
  </tr> 
  <tr> 
   <td>4</td> 
   <td>深入理解Java虚拟机-虚拟机执行子系统</td> 
   <td><a href="https://blog.csdn.net/ThinkWon/article/details/103835168" rel="nofollow">https://blog.csdn.net/ThinkWon/article/details/103835168</a></td> 
  </tr> 
  <tr> 
   <td>5</td> 
   <td>深入理解Java虚拟机-程序编译与代码优化</td> 
   <td><a href="https://blog.csdn.net/ThinkWon/article/details/103835883" rel="nofollow">https://blog.csdn.net/ThinkWon/article/details/103835883</a></td> 
  </tr> 
  <tr> 
   <td>6</td> 
   <td>深入理解Java虚拟机-高效并发</td> 
   <td><a href="https://blog.csdn.net/ThinkWon/article/details/103836167" rel="nofollow">https://blog.csdn.net/ThinkWon/article/details/103836167</a></td> 
  </tr> 
 </tbody> 
</table>

### 文章目录 ###

*   *   *  概述
         *  运行时数据区域
         *   *  程序计数器（线程私有）
             *  Java虚拟机栈（线程私有）
             *   *  局部变量表
                 *  操作数栈
                 *  动态链接
                 *  方法返回地址
                 *  小结
             *  本地方法栈（线程私有）
             *  Java堆（全局共享）
             *  方法区（全局共享）
             *   *  运行时常量池
             *  直接内存
         *  HotSpot虚拟机对象探秘
         *   *  对象的创建
             *   *  1.判断对象对应的类是否加载、链接、初始化
                 *  2.为对象分配内存
                 *  3.处理并发安全问题
                 *  4.初始化分配到的内存空间
                 *  5.设置对象的对象头
                 *  6.执行init方法进行初始化
             *  对象的内存布局
             *   *  对象头
                 *  实例数据
                 *  对齐填充
             *  对象的访问定位
             *   *  句柄访问
                 *  直接指针
         *  实战：OutOfMemoryError异常
         *   *  Java堆溢出
             *  虚拟机栈和本地方法栈溢出
             *  方法区和运行时常量池溢出
             *  本机直接内存溢出
         *  本章小结

Java与C++之间有一堵由内存动态分配和垃圾收集技术所围成的"高墙"，墙外面的人想进去，墙里面的人却想出来。

### 概述 ###

对于从事C、C++程序开发的开发人员来说，在内存管理领域，他们既是拥有最高权力的“皇帝”又是从事最基础工作的“劳动人民”——既拥有每一个对象的“所有权”，又担负着每一个对象生命开始到终结的维护责任。  
对于Java程序员来说，在虚拟机自动内存管理机制的帮助下，不再需要为每一个new操作去写配对的delete/free代码，不容易出现内存泄漏和内存溢出问题，由虚拟机管理内存这一切看起来都很美好。不过，也正是因为Java程序员把内存控制的权力交给了Java虚拟机，一旦出现内存泄漏和溢出方面的问题，如果不了解虚拟机是怎样使用内存的，那么排查错误将会成为一项异常艰难的工作。

### 运行时数据区域 ###

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

JVM包含两个子系统和两个组件，两个子系统为Class loader(类装载)、Execution engine(执行引擎)；两个组件为Runtime data area(运行时数据区)、Native Interface(本地接口)。

Class loader(类装载)：根据给定的全限定名类名(如：java.lang.Object)来装载class文件到Runtime data area中的method area。

Execution engine（执行引擎）：执行classes中的指令。

Native Interface(本地接口)：与native libraries交互，是其它编程语言交互的接口。

Runtime data area(运行时数据区域)：这就是我们常说的JVM的内存。

**Java 虚拟机在执行 Java 程序的过程中会把它所管理的内存区域划分为若干个不同的数据区域**。这些区域都有各自的用途，以及创建和销毁的时间，有些区域随着虚拟机进程的启动而存在，有些区域则是依赖线程的启动和结束而建立和销毁。Java 虚拟机所管理的内存被划分为如下几个区域：

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

#### 程序计数器（线程私有） ####

程序计数器是一块**较小**的内存区域，可以看做是**当前线程**所执行的**字节码的行号指示器**。在虚拟机的概念模型里，字节码解释器工作时就是通过改变这个计数器的值来选取下一条需要执行的字节码指令，分支、循环、跳转、异常处理、线程恢复等基础功能都需要依赖这个计数器来完成。「属于线程私有的内存区域」

> 附加：
> 
> 1.  当前线程所执行的字节码**行号指示器**。
> 2.  每个线程都有一个自己的`PC`计数器。
> 3.  线程**私有的**，生命周期与线程相同，随`JVM`启动而生，`JVM`关闭而死。
> 4.  线程执行`Java`方法时，记录其正在执行的虚拟机**字节码指令地址**。
> 5.  线程执行`Native`方法时，计数器记录为**空**(`Undefined`)。
> 6.  唯一在`Java`虚拟机规范中没有规定任何`OutOfMemoryError`情况区域。

#### Java虚拟机栈（线程私有） ####

线程**私有**内存空间，它的生命周期和线程相同。线程执行期间，每个方法被执行时，都会创建一个栈帧（Stack Frame）用于存储**局部变量表、操作栈、动态链接、方法出口**等信息。**每个方法从被调用到执行完成的过程，就对应着一个栈帧在虚拟机栈中从入栈到出栈的过程。**「属于线程私有的内存区域」

> 注意：下面的内容为附加内容，对Java虚拟机栈进行详细说明，感兴趣的小伙伴可以有针对性的阅读

下面依次解释**栈帧**里的四种组成元素的具体结构和功能：

##### 局部变量表 #####

**局部变量表**局部变量表是 Java 虚拟机栈的一部分，是一组**变量值**的存储空间，用于存储**方法参数**和**局部变量**。 在 `Class` 文件的方法表的 `Code` 属性的 `max_locals` 指定了该方法所需局部变量表的**最大容量**。

**局部变量表**在编译期间分配内存空间，可以存放**编译期**的各种变量类型：

1.  **基本数据类型** ：`boolean`, `byte`, `char`, `short`, `int`, `float`, `long`, `double`等`8`种；
2.  **对象引用类型** ：`reference`，指向对象**起始地址**的**引用指针**；不等同于对象本身，根据不同的虚拟机实现，它可能是一个指向对象起始地址的引用指针，也可能是指向一个代表对象的句柄或者其他与此对象相关的位置
3.  **返回地址类型** ：`returnAddress`，返回地址的类型。指向了一条字节码指令的地址

变量槽(`Variable Slot`)：

> **变量槽**是**局部变量表**的**最小单位**，规定大小为`32`位。对于`64`位的`long`和`double`变量而言，虚拟机会为其分配**两个连续**的`Slot`空间。

##### 操作数栈 #####

**操作数栈**（`Operand Stack`）也常称为操作栈，是一个后入先出栈。在 `Class` 文件的 `Code` 属性的 `max_stacks` 指定了执行过程中最大的栈深度。`Java`虚拟机的**解释执行引擎**被称为**基于栈的执行引擎** ，其中所指的**栈**就是指－**操作数栈**。

1.  和**局部变量表**一样，**操作数栈**也是一个以`32`**字长**为单位的数组。
2.  虚拟机在操作数栈中可存储的**数据类型**：`int`、`long`、`float`、`double`、`reference`和`returnType`等类型 (对于`byte`、`short`以及`char`类型的值在压入到操作数栈之前，也会被转换为`int`)。
3.  和**局部变量表**不同的是，它不是通过**索引**来访问，而是通过标准的**栈操作** — **压栈**和**出栈**来访问。比如，如果某个指令把一个值压入到操作数栈中，稍后另一个指令就可以弹出这个值来使用。

**虚拟机把操作数栈作为它的工作区——大多数指令都要从这里弹出数据，执行运算，然后把结果压回操作数栈**。

begin
    iload_0    // push the int in local variable 0 onto the stack
    iload_1    // push the int in local variable 1 onto the stack
    iadd       // pop two ints, add them, push result
    istore_2   // pop int, store into local variable 2
    end

> 在这个**字节码序列**里，前两个指令 `iload_0` 和 `iload_1` 将存储在**局部变量表**中索引为`0`和`1`的整数压入操作数栈中，其后`iadd`指令从操作数栈中弹出那两个整数相加，再将结果压入**操作数栈**。第四条指令`istore_2`则从**操作数栈**中弹出结果，并把它存储到**局部变量表**索引为`2`的位置。

下图详细表述了这个过程中**局部变量表**和**操作数栈**的状态变化(图中没有使用的**局部变量表**和**操作数栈**区域以空白表示)。

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

##### 动态链接 #####

每个**栈帧**都包含一个指向运行时**常量池**中所属的**方法引用**，持有这个引用是为了支持方法调用过程中的**动态链接**。

`Class`文件的**常量池**中存在有大量的**符号引用**，字节码中的**方法调用指令**就以常量池中指向方法的**符号引用**为参数。这些符号引用：

1.  静态解析：一部分会在**类加载阶段**或第一次使用的时候转化为**直接引用**（如`final`、`static`域等），称为**静态解析**，
2.  动态解析：另一部分将在每一次的**运行期间**转化为**直接引用**，称为**动态链接**。

##### 方法返回地址 #####

当一个方法开始执行以后，只有两种方法可以退出当前方法：

1.  **正常返回**：当执行遇到返回指令，会将返回值传递给上层的方法调用者，这种退出的方式称为**正常完成出口**(`Normal Method Invocation Completion`)，一般来说，调用者的`PC`**计数器**可以作为返回地址。
2.  **异常返回**：当执行遇到异常，并且当前方法体内没有得到处理，就会导致方法退出，此时是没有返回值的，称为**异常完成出口**(`Abrupt Method Invocation Completion`)，返回地址要通过**异常处理器**表来确定。

当一个方法返回时，可能依次进行以下`3`个操作：

1.  恢复**上层方法**的**局部变量表**和**操作数栈**。
2.  把**返回值**压入**调用者栈帧**的**操作数栈**。
3.  将`PC`**计数器**的值指向**下一条**方法指令位置。

##### 小结 #####

> **注意**：在Java虚拟机规范中，对这个区域规定了两种异常。
> 
> **其一**：如果当前线程请求的栈深度大于虚拟机栈所允许的深度，将会抛出 `StackOverflowError` 异常（在虚拟机栈不允许动态扩展的情况下）；
> 
> **其二**：如果扩展时无法申请到足够的内存空间，就会抛出 `OutOfMemoryError` 异常。

#### 本地方法栈（线程私有） ####

**本地方法栈**和`Java`**虚拟机栈**发挥的作用非常相似，主要区别是`Java`**虚拟机栈**执行的是`Java`**方法服务**，而**本地方法栈**执行`Native`**方法服务**(通常用C编写)。

> 有些虚拟机发行版本(譬如`Sun HotSpot`虚拟机)直接将**本地方法栈**和`Java`**虚拟机**栈合二为一。与虚拟机栈一样，本地方法栈也会抛出`StackOverflowError`和`OutOfMemoryError`异常。

#### Java堆（全局共享） ####

对大多数应用而言，Java 堆是虚拟机所管理的内存中最大的一块，是被所有线程共享的一块内存区域，在虚拟机启动时创建。此内存区域的唯一作用就是存放对象实例，**几乎所有的对象实例都是在这里分配的（不绝对，在虚拟机的优化策略下，也会存在栈上分配、标量替换的情况，后面的章节会详细介绍**）。

Java 堆是 GC 回收的主要区域，因此很多时候也被称为 GC 堆。

从内存回收的角度看，由于现在收集器基本都采用分代收集算法，所以在Java堆被划分成两个不同的区域：**新生代** (`Young Generation`) 、**老年代** (`Old Generation`) 。**新生代** (`Young`) 又被划分为三个区域：**一个**`Eden`区和**两个**`Survivor`区 - `From Survivor`区和`To Survivor`区。不过无论如何划分，都与存放内容无关，无论哪个区域，存储的都仍然时对象实例，记你一步划分的目的是为了使`JVM`能够更好的管理堆内存中的对象，包括内存的分配以及回收。

> 简要归纳：新的对象分配是首先放在年轻代 (`Young Generation`) 的`Eden`区，`Survivor`区作为`Eden`区和`Old`区的缓冲，在`Survivor`区的对象经历若干次收集仍然存活的，就会被转移到老年代`Old`中。

从内存回收的角度看，线程共享的 Java 堆可能划分出多个线程私有的分配缓冲区（Thread Local Allocation Buffer，TLAB）。「属于线程共享的内存区域」

#### 方法区（全局共享） ####

方法区和`Java`堆一样，为多个线程共享，它用于存储**类信息**、**常量**、**静态常量**和**即时编译后的代码**等数据。Non-Heap（非堆）「属于线程共享的内存区域」

##### 运行时常量池 #####

运行时常量池是方法区的一部分。Class文件中除了有类的版本、字段、方法、接口等描述信息外，还有一项信息就是常量池（Constant Pool Table），用于存放编译期生成的各种字面常量和符号引用，这部分内容会在类加载后进入方法区的运行时常量池。

> 下面信息为附加信息

*  HotSpot虚拟机中，将方法区称为“永久代”，本质上两者并不等价，仅仅是因为HotSpot虚拟机把GC分代收集扩展至方法区。
 *  JDK 7的HotSpot中，已经将原本存放于永久代中的字符串常量池移出。
 *  根据虚拟机规范的规定，当方法区无法满足内存分配需求时，将会抛出OutOfMemoryError异常。当常量池无法再申请到内存时也会抛出OutOfMemoryError异常。
 *  JDK 8的HotSpot中，已经将永久代废除，用元数据实现了方法区。元空间与永久代之间最大的区别在于：元空间并不在虚拟机中，而是使用本地内存。理论上取决于32位/64位系统可虚拟的内存大小。可见也不是无限制的，需要配置参数。

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

#### 直接内存 ####

**直接内存（Direct Memory）并不是虚拟机运行时数据区的一部分**，也不是 Java 虚拟机规范中定义的内存区域。Java 中的 NIO 可以使用 Native 函数直接分配堆外内存，**通常直接内存的速度会优于Java堆内存**，然后通过一个存储在 Java 堆中的 DiectByteBuffer 对象作为这块内存的引用进行操作。这样能在一些场景显著提高性能，**对于读写频繁、性能要求高的场景，可以考虑使用直接内存**，因为避免了在 Java 堆和 Native 堆中来回复制数据。直接内存不受 Java 堆大小的限制。

### HotSpot虚拟机对象探秘 ###

#### 对象的创建 ####

说到对象的创建，首先让我们看看 `Java` 中提供的几种对象创建方式：

<table> 
 <thead> 
  <tr> 
   <th align="left">Header</th> 
   <th align="left">解释</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td align="left">使用new关键字</td> 
   <td align="left">调用了构造函数</td> 
  </tr> 
  <tr> 
   <td align="left">使用Class的newInstance方法</td> 
   <td align="left">调用了构造函数</td> 
  </tr> 
  <tr> 
   <td align="left">使用Constructor类的newInstance方法</td> 
   <td align="left">调用了构造函数</td> 
  </tr> 
  <tr> 
   <td align="left">使用clone方法</td> 
   <td align="left">没有调用构造函数</td> 
  </tr> 
  <tr> 
   <td align="left">使用反序列化</td> 
   <td align="left">没有调用构造函数</td> 
  </tr> 
 </tbody> 
</table>

下面是对象创建的主要流程:

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

虚拟机遇到一条new指令时，先检查常量池是否已经加载相应的类，如果没有，必须先执行相应的类加载。类加载通过后，接下来分配内存。若Java堆中内存是绝对规整的，使用“指针碰撞“方式分配内存；如果不是规整的，就从空闲列表中分配，叫做”空闲列表“方式。划分内存时还需要考虑一个问题-并发，也有两种方式: CAS同步处理，或者本地线程分配缓冲(Thread Local Allocation Buffer, TLAB)。然后内存空间初始化操作，接着是做一些必要的对象设置(元信息、哈希码…)，最后执行`<init>`方法。

> 下面内容是对象创建的详细过程

对象的创建通常是通过new关键字创建一个对象的，当虚拟机接收到一个new指令时，它会做如下的操作。

##### 1.判断对象对应的类是否加载、链接、初始化 #####

虚拟机接收到一条new指令时，首先会去检查这个指定的参数是否能在常量池中定位到一个类的符号引用，并且检查这个符号引用代表的类是否已被类加载器加载、链接和初始化过。如果没有则先执行相应的类加载过程。

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

##### 2.为对象分配内存 #####

类加载完成后，接着会在Java堆中划分一块内存分配给对象。内存分配根据Java堆是否规整，有两种方式：

*  指针碰撞：如果Java堆的内存是规整，即所有用过的内存放在一边，而空闲的的放在另一边。分配内存时将位于中间的指针指示器向空闲的内存移动一段与对象大小相等的距离，这样便完成分配内存工作。
 *  空闲列表：如果Java堆的内存不是规整的，则需要由虚拟机维护一个列表来记录那些内存是可用的，这样在分配的时候可以从列表中查询到足够大的内存分配给对象，并在分配后更新列表记录。

选择哪种分配方式是由 Java 堆是否规整来决定的，而 Java 堆是否规整又由所采用的垃圾收集器是否带有压缩整理功能决定。

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

##### 3.处理并发安全问题 #####

对象的创建在虚拟机中是一个非常频繁的行为，哪怕只是修改一个指针所指向的位置，在并发情况下也是不安全的，可能出现正在给对象 A 分配内存，指针还没来得及修改，对象 B 又同时使用了原来的指针来分配内存的情况。解决这个问题有两种方案：

*  对分配内存空间的动作进行同步处理（采用 CAS + 失败重试来保障更新操作的原子性）；
 *  把内存分配的动作按照线程划分在不同的空间之中进行，即每个线程在 Java 堆中预先分配一小块内存，称为本地线程分配缓冲（Thread Local Allocation Buffer, TLAB）。哪个线程要分配内存，就在哪个线程的 TLAB 上分配。只有 TLAB 用完并分配新的 TLAB 时，才需要同步锁。通过-XX:+/-UserTLAB参数来设定虚拟机是否使用TLAB。

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

##### 4.初始化分配到的内存空间 #####

内存分配完后，虚拟机要将分配到的内存空间初始化为零值（不包括对象头）。如果使用了 TLAB，这一步会提前到 TLAB 分配时进行。这一步保证了对象的实例字段在 Java 代码中可以不赋初始值就直接使用。

##### 5.设置对象的对象头 #####

接下来设置对象头（Object Header）信息，包括对象的所属类、对象的HashCode和对象的GC分代年龄等数据存储在对象的对象头中。

##### 6.执行init方法进行初始化 #####

执行init方法，初始化对象的成员变量、调用类的构造方法，这样一个对象就被创建了出来。

#### 对象的内存布局 ####

`HotSpot`虚拟机中，对象在内存中存储的布局可以分为三块区域：**对象头**（`Header`）、**实例数据**（`Instance Data`）和**对齐填充**（`Padding`）。

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

##### 对象头 #####

在`HotSpot`虚拟机中，对象头有两部分信息组成：**运行时数据** 和 **类型指针**，如果是数组对象，还有一个保存数组长度的空间。

*  Mark Word（运行时数据）：用于存储对象自身运行时的数据，如**哈希码**（hashCode）、**GC分带年龄**、**线程持有的锁**、**偏向线程ID** 等信息。在32位系统占4字节，在64位系统中占8字节；
    
    HotSpot虚拟机对象头Mark Word在其他状态（轻量级锁定、重量级锁定、GC标记、可偏向）下对象的存储内容如下表所示：

<table> 
 <thead> 
  <tr> 
   <th>存储内容</th> 
   <th align="left">标志位</th> 
   <th align="left">状态</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>对象哈希码、对象分代年龄</td> 
   <td align="left">01</td> 
   <td align="left">未锁定</td> 
  </tr> 
  <tr> 
   <td>指向锁记录的指针</td> 
   <td align="left">00</td> 
   <td align="left">轻量级锁定</td> 
  </tr> 
  <tr> 
   <td>指向重量级锁的指针</td> 
   <td align="left">10</td> 
   <td align="left">膨胀（重量级锁定）</td> 
  </tr> 
  <tr> 
   <td>空，不需要记录信息</td> 
   <td align="left">11</td> 
   <td align="left">GC标记</td> 
  </tr> 
  <tr> 
   <td>偏向线程ID、偏向时间戳、对象分代年龄</td> 
   <td align="left">01</td> 
   <td align="left">可偏向</td> 
  </tr> 
 </tbody> 
</table>

*  Class Pointer（类型指针）：用来指向对象对应的Class对象（其对应的元数据对象）的内存地址。在32位系统占4字节，在64位系统中占8字节；
 *  Length：如果是数组对象，还有一个保存数组长度的空间，占4个字节；

##### 实例数据 #####

**实例数据** 是对象真正存储的**有效信息**，无论是从**父类继承**下来的还是该类**自身的**，都需要记录下来，而这部分的**存储顺序**受虚拟机的**分配策略**和**定义的顺序**的影响。

默认分配策略：

> long/double -> int/float -> short/char -> byte/boolean -> reference

如果设置了`-XX:FieldsAllocationStyle=0`（默认是`1`），那么**引用类型**数据就会优先分配存储空间：

> reference -> long/double -> int/float -> short/char -> byte/boolean

**结论：**

> 分配策略总是按照字节大小由大到小的顺序排列，相同字节大小的放在一起。

##### 对齐填充 #####

无特殊含义，不是必须存在的，仅作为占位符。

`HotSpot`虚拟机要求每个对象的**起始地址**必须是`8`字节的整数倍，也就是对象的大小必须是`8`字节的**整数倍**。而**对象头部分**正好是`8`字节的倍数（`32`位为`1`倍，`64`位为`2`倍），因此，当对象实例数据部分没有对齐的时候，就需要通过**对齐填充**来补全。

#### 对象的访问定位 ####

`Java`程序需要通过 `JVM` 栈上的引用访问堆中的具体对象。对象的访问方式取决于 `JVM` 虚拟机的实现。目前主流的访问方式有 **句柄** 和 **直接指针** 两种方式。

> **指针：** 指向对象，代表一个对象在内存中的起始地址。
> 
> **句柄：** 可以理解为指向指针的指针，维护着对象的指针。句柄不直接指向对象，而是指向对象的指针（句柄不发生变化，指向固定内存地址），再由对象的指针指向对象的真实内存地址。

##### 句柄访问 #####

`Java`堆中划分出一块内存来作为**句柄池**，引用中存储对象的**句柄地址**，而句柄中包含了**对象实例数据**与**对象类型数据**各自的**具体地址**信息，具体构造如下图所示：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly90aGlua3dvbi5ibG9nLmNzZG4ubmV0_size_16_color_FFFFFF_t_70 9]  
**优势**：引用中存储的是**稳定**的句柄地址，在对象被移动（垃圾收集时移动对象是非常普遍的行为）时只会改变**句柄中**的**实例数据指针**，而**引用**本身不需要修改。

##### 直接指针 #####

如果使用**直接指针**访问，**引用** 中存储的直接就是**对象地址**，那么`Java`堆对象内部的布局中就必须考虑如何放置访问**类型数据**的相关信息。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly90aGlua3dvbi5ibG9nLmNzZG4ubmV0_size_16_color_FFFFFF_t_70 10]  
**优势**：速度更**快**，节省了**一次指针定位**的时间开销。由于对象的访问在`Java`中非常频繁，因此这类开销积少成多后也是非常可观的执行成本。HotSpot 中采用的就是这种方式。

### 实战：OutOfMemoryError异常 ###

内存异常是我们工作当中经常会遇到问题，但如果仅仅会通过加大内存参数来解决问题显然是不够的，应该通过一定的手段定位问题，到底是因为参数问题，还是程序问题(无限创建，内存泄露)。定位问题后才能采取合适的解决方案，而不是一内存溢出就查找相关参数加大。

> 概念
> 
> **内存泄露**：代码中的某个对象本应该被虚拟机回收，但因为拥有GCRoot引用而没有被回收。
> 
> **内存溢出**：虚拟机由于堆中拥有太多不可回收对象没有回收，导致无法继续创建新对象。

在分析问题之前先给大家讲一讲排查内存溢出问题的方法，内存溢出时JVM虚拟机会退出，那么我们怎么知道JVM运行时的各种信息呢，**Dump**机制会帮助我们，可以通过加上VM参数-XX:+HeapDumpOnOutOfMemoryError让虚拟机在出现内存溢出异常时生成dump文件，然后通过外部工具(VisualVM)来具体分析异常的原因。

除了程序计数器外，`Java`虚拟机的其他运行时区域都有可能发生`OutOfMemoryError`的异常，下面分别给出验证：

#### Java堆溢出 ####

Java堆用来存储对象，因此只要不断创建对象，并保证 GC Roots 到对象之间有可达路径来避免垃圾回收机制清楚这些对象，那么当对象数量达到最大堆容量时就会产生 OOM。

/** * java堆内存溢出测试 * VM Args: -Xms20m -Xmx20m -XX:+HeapDumpOnOutOfMemoryError */
    public class HeapOOM { 
    
        static class OOMObject{ }
    
        public static void main(String[] args) { 
            List<OOMObject> list = new ArrayList<OOMObject>();
            while (true) { 
                list.add(new OOMObject());
            }
        }
    }

运行结果：

java.lang.OutOfMemoryError: Java heap space 
    Dumping heap to java_pid7164.hprof … 
    Heap dump file created [27880921 bytes in 0.193 secs] 
    Exception in thread “main” java.lang.OutOfMemoryError: Java heap space 
    at java.util.Arrays.copyOf(Arrays.java:2245) 
    at java.util.Arrays.copyOf(Arrays.java:2219) 
    at java.util.ArrayList.grow(ArrayList.java:242) 
    at java.util.ArrayList.ensureExplicitCapacity(ArrayList.java:216) 
    at java.util.ArrayList.ensureCapacityInternal(ArrayList.java:208) 
    at java.util.ArrayList.add(ArrayList.java:440) 
    at com.jvm.oom.HeapOOM.main(HeapOOM.java:17)

堆内存 OOM 是经常会出现的问题，异常信息会进一步提示 Java heap space

#### 虚拟机栈和本地方法栈溢出 ####

在 HotSpot 虚拟机中不区分虚拟机栈和本地方法栈，栈容量只由 -Xss 参数设定。关于虚拟机栈和本地方法栈，在 Java 虚拟机规范中描述了两种异常：

*  如果线程请求的栈深度大于虚拟机所允许的最大深度，将抛出 StackOverflowError 异常。
 *  如果虚拟机在扩展栈时无法申请到足够的内存空间，则抛出 OutOfMemoryError 异常。

/** * 虚拟机栈和本地方法栈内存溢出测试，抛出stackoverflow exception * VM ARGS: -Xss128k 减少栈内存容量 */
    public class JavaVMStackSOF { 
    
        private int stackLength = 1;
    
        public void stackLeak () { 
            stackLength++;
            stackLeak();
        }
    
        public static void main(String[] args) throws Throwable { 
            JavaVMStackSOF oom = new JavaVMStackSOF();
            try { 
                oom.stackLeak();
            } catch (Throwable e) { 
                System.out.println("stack length = " + oom.stackLength);
                throw e;
            }
    
        }
    
    }

运行结果:

stack length = 11420 
    Exception in thread “main” java.lang.StackOverflowError 
    at com.jvm.oom.JavaVMStackSOF.stackLeak(JavaVMStackSOF.java:12) 
    at com.jvm.oom.JavaVMStackSOF.stackLeak(JavaVMStackSOF.java:13) 
    at com.jvm.oom.JavaVMStackSOF.stackLeak(JavaVMStackSOF.java:13)

以上代码在单线程环境下，无论是由于栈帧太大还是虚拟机栈容量太小，当内存无法分配时，抛出的都是 StackOverflowError 异常。

如果测试环境是多线程环境，通过不断建立线程的方式可以产生内存溢出异常，代码如下所示。但是这样产生的 OOM 与栈空间是否足够大不存在任何联系，在这种情况下，为每个线程的栈分配的内存足够大，反而越容易产生OOM 异常。这点不难理解，每个线程分配到的栈容量越大，可以建立的线程数就变少，建立多线程时就越容易把剩下的内存耗尽。**这点在开发多线程的应用时要特别注意。如果建立过多线程导致内存溢出，在不能减少线程数或更换64位虚拟机的情况下，只能通过减少最大堆和减少栈容量来换取更多的线程。**

/** * JVM 虚拟机栈内存溢出测试, 注意在windows平台运行时可能会导致操作系统假死 * VM Args: -Xss2M -XX:+HeapDumpOnOutOfMemoryError */
    
    public class JVMStackOOM { 
    
        private void dontStop() { 
            while (true) { }
        }
    
        public void stackLeakByThread() { 
            while (true) { 
                Thread thread = new Thread(new Runnable() { 
    
                    @Override
                    public void run() { 
                        dontStop();
                    }
                });
                thread.start();
            }
        }
    
        public static void main(String[] args) { 
            JVMStackOOM oom = new JVMStackOOM();
            oom.stackLeakByThread();
        }
    }

#### 方法区和运行时常量池溢出 ####

方法区用于存放Class的相关信息，对这个区域的测试，基本思路是运行时产生大量的类去填满方法区，直到溢出。使用CGLib实现。

方法区溢出也是一种常见的内存溢出异常，在经常生成大量Class的应用中，需要特别注意类的回收情况，这类场景除了使用了CGLib字节码增强和动态语言外，常见的还有JSP文件的应用(JSP第一次运行时要编译为Java类)、基于OSGI的应用等。

/** * 测试JVM方法区内存溢出 * VM Args: -XX:PermSize=10M -XX:MaxPermSize=10M */
    public class MethodAreaOOM { 
    
        public static void main(String[] args) { 
            while (true) { 
                Enhancer enhancer = new Enhancer();
                enhancer.setSuperclass(OOMObject.class);
                enhancer.setUseCache(false);
                enhancer.setCallback(new MethodInterceptor() { 
                    @Override
                    public Object intercept(Object obj, Method method, Object[] args,
                            MethodProxy proxy) throws Throwable { 
                        return proxy.invokeSuper(obj, args);
                    }
                });
                enhancer.create();
            }
        }
    
        static class OOMObject{ }
    }

#### 本机直接内存溢出 ####

DirectMemory 容量可通过 -XX:MaxDirectMemorySize 指定，如不指定，则默认与Java堆最大值一样。测试代码使用了 Unsafe 实例进行内存分配。

由 DirectMemory 导致的内存溢出，一个明显的特征是在Heap Dump 文件中不会看见明显的异常，如果发现 OOM 之后 Dump 文件很小，而程序直接或间接使用了NIO，那就可以考虑检查一下是不是这方面的原因。

/** * 测试本地直接内存溢出 * VM Args: -Xmx20M -XX:MaxDirectMemorySize=10M */
    public class DirectMemoryOOM { 
    
        private static final int _1MB = 1024 * 1024;
    
        public static void main(String[] args) throws Exception { 
            Field unsafeField = Unsafe.class.getDeclaredFields()[0];
            unsafeField.setAccessible(true);
            Unsafe unsafe = (Unsafe) unsafeField.get(null);
            while (true) { 
                unsafe.allocateMemory(_1MB);
            }
        }
    }

### 本章小结 ###

通过本章的学习，我们明白了虚拟机中的内存是如何划分的，哪部分区域、什么样的代码和操作可能导致内存溢出异常。虽然Java有垃圾收集机制，但内存溢出异常离我们仍然并不遥远，本章只是讲解了各个区域出现内存溢出异常的原因。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly90aGlua3dvbi5ibG9nLmNzZG4ubmV0_size_16_color_FFFFFF_t_70]: /images/20210920/d5c0cf997d684e35b2dda39ce52a7fee.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly90aGlua3dvbi5ibG9nLmNzZG4ubmV0_size_16_color_FFFFFF_t_70 1]: /images/20210920/63a44cb4916a47c99819e89c79ef4b06.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly90aGlua3dvbi5ibG9nLmNzZG4ubmV0_size_16_color_FFFFFF_t_70 2]: /images/20210920/e78c6e7a718c47f2bd8c7354109cd2ad.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly90aGlua3dvbi5ibG9nLmNzZG4ubmV0_size_16_color_FFFFFF_t_70 3]: /images/20210920/7e224707b4804ee6ba34a78548b2e420.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly90aGlua3dvbi5ibG9nLmNzZG4ubmV0_size_16_color_FFFFFF_t_70 4]: /images/20210920/26f5aaaa0f884366b34f317170ac03ad.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly90aGlua3dvbi5ibG9nLmNzZG4ubmV0_size_16_color_FFFFFF_t_70 5]: /images/20210920/6cb58d8a5d8940468f884445349bf0c1.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly90aGlua3dvbi5ibG9nLmNzZG4ubmV0_size_16_color_FFFFFF_t_70 6]: /images/20210920/7f944d1c5f49435cbe2331e0ce5d1197.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly90aGlua3dvbi5ibG9nLmNzZG4ubmV0_size_16_color_FFFFFF_t_70 7]: /images/20210920/c281969bee7540e08b11659d81f6407c.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly90aGlua3dvbi5ibG9nLmNzZG4ubmV0_size_16_color_FFFFFF_t_70 8]: /images/20210920/55d378c5a5bd438b86873c76df1aa285.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly90aGlua3dvbi5ibG9nLmNzZG4ubmV0_size_16_color_FFFFFF_t_70 9]: /images/20210920/b74a579267034fd596b665ed06ad37f0.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly90aGlua3dvbi5ibG9nLmNzZG4ubmV0_size_16_color_FFFFFF_t_70 10]: /images/20210920/34244493a243449a941b48141ae5dad2.png