【JVM系列】你了解Java的自动内存管理吗？

🎈初学时，你是否曾分不清堆与栈？🎈实战时，你是否时常被 OutOfMemoryError (OOM) 气得抓耳挠腮？🎈排查问题时，你是否会考虑Java内存管理的方式？这里，小火种想和大家聊聊 Java虚拟机(JVM)的自动内存管理 ，以下内容来自对周志明先生 《深入理解JVM》 的个人解读，欢迎指正！

---

说起来，Java作为比C/C++更为上层的语言，它留给开发者可操控的空间并不多，而对于我们不可视的部分，理解其原理仍然必要。C/C++开发者们肩负着对一个对象全生命周期的维护责任，而Java开发者们的责任则被Java虚拟机(JVM)分摊，JVM得到了对Java内存的控制权。但这并不意味着Java开发者们从此可以在内存管理上高枕无忧，我们学习JVM的内存管理，更多地是想要了解虚拟机对内存的使用方式，以便排查程序执行时所报告的内存泄漏、内存溢出等问题。这些异常问题我们下次再聊，本次聊聊虚拟机对内存的使用，在此之前，小火种希望你清楚Java的各内存区域。

Java内存区域 包括以下几部分，此外，书中分享了更多的内存使用细节：

---

💦程序计数器

💞线程私有💞

程序计数器 （Program Count Register, PC）是当前线程所执行的字节码的 行号指示器（也可以说是程序控制流指示器）。

PC所占的内存区域其实很小，但由于它的重要性，所以优先提及。要理解重要性，我们需要先明确Java虚拟机的多线程实现方式： 线程轮流切换 、 分配处理器执行时间 。也就是说，任一确定时刻一个处理器只能执行一条线程中的指令。既然存在频繁的线程切换，那么势必就要考虑线程恢复问题，PC的作用可以理解为“保存现场”，用于帮助被切换的线程快速恢复现场，这很重要。

💦Java 虚拟机栈

💞线程私有💞

Java 虚拟机栈 （Java Virtual Machine Stack）随 Java方法/字节码 执行，同步创建 栈帧（Stack Frame）。

可以这样理解栈帧。每一个 Java方法 的生命周期（从被调用直至执行完毕的过程），就对应着一个 栈帧 的使用周期（从入栈到出栈的过程）。

我们常说的 “栈” 常指 “Java虚拟机栈” ，甚至仅指其中的 “局部变量表” 部分。简单介绍下局部变量表：

局部变量表-存储
Java虚拟机基本数据类型 (boolean, int, double等)	对象引用 (reference类型：对象引用指针、句柄、其他相关位置等)	returnAddress 类型 (指向一条字节码指令的地址)

局部变量表所需的内存空间 在编译期间 即可完成分配，因此，异常状况也一般出现在此刻。一般来说，Java虚拟机栈有两类异常：1）StackOverflowError ：线程请求的栈深> 虚拟机所允许的深度；2）OutOfMemoryError (OOM)：栈容量动态扩展至 无法申请到足够的内存（注：Hotspot虚拟机的栈容量不可动态扩展）

💦本地方法栈

本地方法栈 （Native Method Stacks）类似Java虚拟机栈，主要 服务本地（Native）方法 。

同样，异常状况也与Java虚拟机栈类似。

💦Java堆

💞线程共享💞

Java堆 （Java Heap）于虚拟机启动时创建，用于存放 对象实例。

Java堆是虚拟机管理的最大内存，是垃圾收集器的内存区域（Garbage Collected Heap，GC堆），仅用于存放对象实例，且存储可在物理上不连续，但需逻辑连续。Java堆存储的针对性有利于JVM对内存的回收、分配，而它线程共享的特性表现在其划分了多个线程私有的分配缓冲区（Thread Local Allocation Buffer，TLAB），用以提升对象分配效率。

由于Java堆是支持扩展的，因此在内存分配过程中可能会发生Java堆内存不够需申请扩展，而当内存不够无法实现扩展时，实例将无法分配，由此导致 OutOfMemoryError (OOM) 异常状况。

💦方法区

💞线程共享💞

方法区（Method Area） 用于存储 已被虚拟机加载的数据（如类型信息、常量、静态变量、即时编译器编译后的代码缓存等），由于逻辑类似于Java堆，通常为了便于区分，方法区又别称为“非堆”（Non-Heap）。

方法区同样支持存储不连续，且可扩展，与Java堆不同的是，方法区可以选择不实现GC（它的内存回收仅针对常量池/类型卸载，且效果不好）。

同样，在内存分配过程中方法区无法满足新内存分配需求时，将导致 OutOfMemoryError (OOM) 异常状况。

💦运行时常量池

运行时常量池 （Runtime Constant Pool） 方法区的一部分，存放类加载后的常量池表（Constant Pool Table），涵盖编译期生成的各种字面量以及符号引用。

相比于Class文件常量池，运行时常量池具备动态性，支持在运行期间存放新的常量（常见的如String类型的intern()方法）。

运行时常量池会受到方法区内存的限制，因此，也会遇到 OutOfMemoryError (OOM) 异常状况。

---

—更多细节—

这里还要提及一下 直接内存 （Direct Memory） ，它并不属于运行时数据区域，但因频繁使用，且该部分内存不受限制，可能会意外导致动态扩展，出现 OutOfMemoryError (OOM) 异常状况。

在清楚JVM内存模型概况后，你或许想进一步了解 更多细节 ，书中以最常用的虚拟机 HotSpot 和最常用的内存区域 Java堆 为例：

💠创建对象

通常，Java开发人员创建对象似乎只需要写 new 关键字，就可以一劳永逸了。不过，你是否考虑过这对于虚拟机来说意味着什么？

①类加载检查

Java虚拟机在遇到字节码 new 指令时，第一反应就是根据指令参数去常量池 定位类的符号引用 ，更进一步，检查该符号引用所代表的类是否被加载、解析以及初始化过。倘若检查不通过，那么必须要先执行类加载过程（详情我们以后再做赘述，这里仅了解就好了）。

②内存分配

在类加载检查通过后，新生对象就相当于获得身份认证，接下来它便可以向虚拟机要地皮啦！🤓一般地，不同设置的虚拟机其内存分配方式也不同。为新生对象分配内存的方式取决于Java堆是否规整，而Java堆是否规整取决于其所采用的垃圾收集器是否带有空间压缩整理过程（Compact），具体来说：

是否带有空间压缩整理过程（Compact）	垃圾收集器举例	Java堆是否规整	选择内存分配方式	特点
是	Serial、ParNew等	是	指针碰撞（Bump The Pointer）	简单高效
否	基于清除算法的CMS	否	空闲列表（Frer List）	复杂

③初始化零值

内存分配完成之后，虚拟机必须将分配到的内存空间（不包括对象头）都初始化零值，以保障对象实例字段可以在Java代码中未赋初始值的情况下直接使用。

④对象头设置

虚拟机须对对象头 (Object Header)进行必要设置，包括对象所属的类实例、类元数据信息的定位、对象的哈希码、对象的GC分代年龄等信息，它将根据虚拟机当前运行状态的不同（如是否启用偏向锁等），设置不同的对象头信息。（详情我们以后再做赘述，这里仅了解就好了）。

⑤按程序员意愿的对象初始化

此时虚拟机已经完成使命了，但对Java程序而言，创建对象才刚刚开始，最关键的 构造函数 即将执行（Class文件中的<init>()方法，紧跟着 new 指令之后进行的 invokespecial 指令）。只有在按照程序员意愿初始化对象后，一个真正可用的对象才算被完全构造出来！

💠存储布局

这里要讲的布局不是Java内存布局，而是一个对象在Java堆内存中存储布局，包括三部分： 对象头 、 实例数据 以及 对齐填充 。

对象头	实例数据	对齐填充
对象自身运行时数据（如哈希码、锁状态标志等），官方称为"Mark Word"，属于动态定义的数据结构	对象真正存储的有效信息（被定义的字段内容）	占位符（不是必然存在的）
类型指针，即对象指向它的类型元数据指针，用于确定对象所属的类实例

💠访问对象

创建就是为了使用。一般来说，Java程序会通过栈上的reference类型数据（指向对象的引用）来操作Java堆上的具体对象。

目前，主流的对象访问方式包括： 句柄 以及 直接指针 。

句柄：Java堆会划分句柄池，reference存储句柄地址 ---- 优点：稳定句柄地址（移动对象仅改变句柄中实例数据指针，不改变reference本身）
直接指针：reference直接存储对象地址 ---- 优点：速度更快（对象访问节省一次指针定位的间接时间开销）

---

总结一下

本文分享了Java内存区域概述以及虚拟机对内存的使用方式。在介绍Java内存区域时，我们会发现书中反复提到关于OOM等异常问题的露面场景，这也是我们开篇提到的，学习JVM内存管理对于排查内存泄漏、内存溢出等问题是十分有必要。在了解内存使用的过程中，我们也可以学习到，所有的管理设计都与架构的配置和属性紧密耦合，一切策略都以提供优质服务、优化系统性能为目的。在精妙的设计里，我们似乎看得到那个更加有序和美好的未来🎈。
（完）

下期预告：小火种将深入分析OOM~