《深入理解Java虚拟机》读书笔记（二）--自动内存管理机制

目录

一、运行时数据区域

1.1 程序计数器

1.2 虚拟机栈

1.2.1 局部变量表

1.3 本地方法栈

1.4 堆

1.5 方法区

1.5.1 运行时常量池

1.5.2 本地直接内存

二、HotSpot 虚拟机对象探秘

2.1 对象的创建

2.1.1 内存空间分配

2.2 对象内存布局

2.2.1 对象头

2.2.2 实例数据

2.2.3 对齐填充

2.3 对象的访问定位

2.3.1 句柄

2.3.2 直接指针

三、总结

---

一、运行时数据区域

Java虚拟机在执行Java程序的过程中，会把它所管理的内存划分为若干个不同的数据区域，这些区域各有各自的用途，以及创建和销毁时间。

Java虚拟机运行时数据区(网图)

1.1 程序计数器

一块较小的，线程私有的内存空间，可以看做是当前程序执行的字节码的行号指示器。在虚拟机的概念模型里（仅仅是概念模型，各个虚拟机可能会通过一些更高效的方式去实现），字节码解释器工作时就是通过改变这个计数器的值来选取下一条需要执行的字节码指令，分支、循环、跳转、异常处理、线程恢复等都需要依赖它完成。

注：为了线程切换后能恢复到正确的执行位置，每个线程都需要一个独立的程序计数器，所以这块内存区域线程私有。

如果线程正在执行Java方法，那这个计数器记录的是正在执行的虚拟机字节码指令的地址；如果正在执行Native方法，则这个计数器为空(Undefined)。此内存区域是唯一一个在Java虚拟机规范中没有规定任何OutOfMemoryError情况的区域。

1.2 虚拟机栈

线程私有，它的生命周期与线程相同。虚拟机栈描述的是Java方法执行的内存模型：每个方法在执行的同时都会创建一个栈帧(Stack Frame)用于存储局部变量表、操作数栈、动态链接、方法出入口等信息。每一个方法从调用到执行完成的过程，就对应一个栈帧在虚拟机栈中从入栈到出栈的过程。

在Java虚拟机规范中，对虚拟机栈规定了两种异常状况：如果线程请求的栈深度大于虚拟机所允许的深度（比如过度递归），抛出StackOverflowError异常；如果虚拟机栈扩展时无法申请到足够的内存，抛出OutOfMemoryError异常。

1.2.1 局部变量表

局部变量表存放了编译期可知的各种基本数据类型(byte、short等)、对象引用(reference类型)。其中64位长度的long和double类型会占用2个局部变量表空间（Slot）,其余的数据类型只占用一个。局部变量表所需要的内存空间在编译期完成分配，在进入方法时是完全确定的，方法运行期间也不会改变局部变量表的大小。

1.3 本地方法栈

与虚拟机栈的作用类似，区别是虚拟机栈为虚拟机执行Java方法（也就是字节码）服务，而本地方法栈为虚拟机使用到的Native方法服务。Java虚拟机规范没有对本地方法栈中使用的语言、使用方式和数据结构等做强制规定，因此虚拟机可以自由实现它。有的虚拟机直接将本地方法栈和虚拟机栈合并，比如Sun HotSpot。和虚拟机栈一样，可能抛出StackOverflowErro或OutOfMemoryError。

1.4 堆

所有线程共享，在虚拟机启动时创建。几乎所有的对象实例都在这里分配内存（由于栈上分配、标量替换等技术的发展，比如逃逸分析，并不是所有对象都在堆上分配）。

Java堆是GC的主要区域，站在GC的角度，还细分为新生代和老年代，新生代还可以分为Eden空间、From Survivor空间和To Survivor空间（可参考Hot Spot虚拟机新生代为什么是一个eden+2个survivor）。而站在内存分配的角度来看，Java堆中可能划分出多个线程私有的分配缓冲区（Thread Local Allocation Buffer，TLAB，主要为了解决分配内存时的并发问题）。

根据Java虚拟机规范的规定，Java堆可以处于物理上不连续的内存空间中，只要逻辑上连续即可。当前主流虚拟机的实现都是可扩展的(通过-Xmx和-Xms控制)。如果实例分配时，堆中没有可用空间，也无法再扩展时，将会抛出OutOfMemoryError。

1.5 方法区

所有线程共享，它用于存储已被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码等数据。Java虚拟机规范将其描述为堆的一个逻辑部分，但是它有一个别名叫做Non-Heap(非堆)，目的是与Java堆区分开。

方法区和永久代并不等价，只是HotSpot虚拟机选择把GC分代收集扩展至方法区，也就是用永久代来实现方法区，这样垃圾收集器就能像管理Java堆一样管理这部分内存，而不用再专门去为方法区编写内存管理代码。如何实现方法区属于虚拟机实现细节，不受虚拟机规范约束，而对于其它虚拟机来说是没有永久代的概念的。

这个区域的内存回收目标主要是针对常量池的回收和对类型的卸载。当方法区无法满足内存分配需求时，抛出OutOfMemoryError。

永久代有-XX:MaxPermSize的上限，以永久代来实现方法区容易出现内存溢出，少数方法（比如String.intern()）会导致在不同的虚拟机中有不同的表现，所以在JDK1.7中，原本位于方法区的字符串常量池被移到Java堆（逻辑上）中。而在JDK1.8之后，方法区已被元空间（MetaSpace，本地直接内存）取代。

注：可以认为永久代和元空间是方法区的不同实现方式，而方法区是Java虚拟机规范中的概念模型。

1.5.1 运行时常量池

运行时常量池是方法区的一部分。Class文件中除了有类的版本、字段、方法、接口等描述信息外，还有一项信息是常量池，用于存放编译期生成的各种字面量和符号引用，这部分内容将在类加载后进入方法区的运行时常量池存放。对于运行时常量池，Java虚拟机规范没有做什么细节上的要求，不同的虚拟机可以根据自己的需要来实现这个内存区域。

运行时常量池具备动态性，常量不一定只有编译期才产生，也就是并非只有预置入Class文件中的常量池的内容才能进入方法区运行时常量池，运行时也可以将新的常量放入池中，比如使用String.intern()方法。

1.5.2 本地直接内存

本地直接内存不是虚拟机运行时数据区域的一部分，也不是Java虚拟机规范中定义的内存区域，但是也可能导致OutOfMemoryError出现。NIO引入的一种基于通道(Channel)和缓冲区(Buffer)的I/O方式，可以使用Native函数库直接分配对外内存，然后通过一个存储在Java堆中的DirectByteBuffer对象作为这块内存的引用进行操作。

本地直接内存的分配不受Java堆大小的限制，但是会受到本机总内存大小（包括RAM以及SWAP分区或者分页文件）以及处理器寻址空间的限制。

二、HotSpot 虚拟机对象探秘

2.1 对象的创建

当虚拟机遇到一条new指令时，首先检查这个指令的参数是否能在常量池中定位到一个类的符号引用，并检查这个符号引用代表的类是否已经被加载、解析和初始化过，如果没有，那么执行类加载过程。（类加载检查）

在类加载检查通过后，虚拟机将会为新生对象分配内存，所需的内存大小在内加载完成后便可确定。内存分配完成之后，虚拟机需要将分配到的内存都初始化为零值（不包括对象头），这一步操作保证了对象的实例字段在Java代码中可以不赋初始值就可直接使用，程序能访问到这些字段的数据类型所对应的零值。（分配内存，初始化零值）

接下来，虚拟机对对象进行必要的设置，比如对象的哈希码、GC分代年龄、模板类等等，这些信息存放在对象的对象头之中。（设置对象头）

此时，一个新的对象已经产生，但是方法（编译自动生成的实例构造器方法）还没有执行，所有的字段都还为零值。所以一般来说（由字节码中是否跟随invokespecial指令决定），执行new指令之后会接着执行方法，把对象按照程序员的意愿进行初始化。（执行方法）

2.1.1 内存空间分配

指针碰撞：假设Java堆中的内存是绝对规整的，所有用过的内存都放在一边，空闲的内存放在另外一边，中间放着一个指针作为分界点的指示器，那分配内存就是把那个指针向空闲空间那边挪动一段与对象大小相等的距离。

空闲列表：如果Java堆中的内存不是规整的，那虚拟机就必须维护一个记录了哪些内存块可用的一个列表，在分配时从列表中找到一块足够大的空间划分给对象实例，并更新列表上的记录。

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

另外，内存分配的操作本身不具备原子性，其在并发情况下可能出现线程安全问题，可能出现正在给对象A分配内存，指针还没来得及修改，对象B又同时使用了原来的指针来分配内存的情况。解决这个问题有两个方案：

方案1. 采用CAS配上失败重试的方式保证更新操作的原子性。

方案2. 每个线程在Java堆中都预先分配一小块内存（本地线程分配缓冲，Thread Local Allocation Buffer，TLAB）,哪个线程要分配内存，就在自己的TLAB上分配，当TLAB用完并分配新的TLAB时，才需要同步锁定。虚拟机是否使用TLAB，可通过-XX+/-UseTLAB参数设定。

2.2 对象内存布局

在HotSpot虚拟机中，对象的内存布局分为3个区域：对象头、实例数据和对齐填充。

2.2.1 对象头

对象头包含两部分信息：

一部分用于存储对象自身的运行时数据，如哈希码、GC分代年龄、锁状态标识、线程持有的锁、偏向线程ID、偏向时间戳等等。这部分数据长度在32位和64位虚拟机(未开启压缩指针)中分别为32bit和64bit，官方称之为“Mark Word”。考虑到空间效率，其被设计成一个非固定的数据结构以便在极小的空间内存储尽量多的信息，它会根据对象的状态复用自己的存储空间。

另一部分是类型指针。即对象指向它的类元数据的指针，虚拟机通过这个指针来确定这个对象是哪个类的实例。但是并不是所有的虚拟机实现都必须在对象数据上保留类型指针，查找对象的元数据信息不一定非要经过对象本身（采取句柄方式访问对象，句柄分别包含对象的实例数据和类型数据各自的地址信息）。

注：如果一个对象是Java数组，那在对象头中还必须有一块用于记录数组长度的空间，因为虚拟机可以通过普通Java对象的元数据信息确定Java对象的大小，但是从数组的元数据中无法确定数组的大小。

2.2.2 实例数据

对象真正存储的有效信息，也就是程序代码中所定义的各种类型的字段内容，包括从父类继承的和子类中定义的字段，这些字段会按照顺序存储下来。而具体的存储顺序会受到虚拟机分配策略参数和字段在代码中定义顺序的影响。默认为longs/doubles、ints、shorts/chars、bytes/booleans、references，可以看到，相同宽度的字段总是被分配到一起。在满足整个前提的情况下，父类中的字段会出现在子类之前。如果开启了CompactFields，那么子类中较窄的字段可能会插入到父类字段的空隙之中。

简单来说就是，大字段在前，小字段在后，references最后，同大小看声明顺序，然后在考虑父类和CompactFields的情况。（详情可见Java对象内存布局概述）

2.2.3 对齐填充

不是必须存在的，只是起占位符的作用，比如Hot Spot虚拟机要求对象大小必须是8字节的整数倍，而对象头部分刚好是8字节的倍数，所以当对象的实例数据没有对齐时，就需要通过对齐填充来补全。

2.3 对象的访问定位

目前主流的访问方式有使用句柄和直接指针两种。

2.3.1 句柄

通过句柄访问对象(网图)

Java堆中会划分出一块内存作为句柄池，reference中存储的就是对象的句柄地址，而句柄中包含了对象实例数据和类型数据的地址信息（此时对象头中不再需要类型指针）。好处是在对象被移动时，只会改变句柄中的实例数据指针，而reference本身不需要修改。而且，GC时移动对象是非常普遍的行为。但是访问对象实例时，需要经过两次指针定位。

2.3.2 直接指针

通过直接指针访问对象(网图)

reference中存储的直接就是对象的地址，访问类型数据信息需要存储在对象头之中。好处是相对于句柄节约了一次指针定位的开销，速度更快。HotSpot使用的就是直接指针的对象访问方式。

三、总结

本章介绍了Java虚拟机运行时数据区域划分，同时以HotSpot虚拟机为例介绍了对象实例的分配和初始化过程、对象的内存布局和访问定位方式。另外还以代码实例复现了各个区域的内存溢出异常。