Java 内存区域与对象探秘

Java 的内存管理都是由 JVM 来进行管理的，不需要程序员手动管理内存，这对于程序员来说是友好的。

但一件事有好处就有坏处。

假如内存管理出现了问题，如果我们不了解 JVM 是如何管理内存的，那么排查问题将会是一项异常艰难的工作。

1、运行时数据区域

Java 虚拟机在执行 Java 程序的过程中会把它所管理的内存划分为若干个不同的数据区域。这些区域都有各自的用途。

1.1 程序计数器

程序计数器（Program Counter Register）是一块较小的内存空间，它可以看作是当前线程所执行的字节码的行号指示器。

作用：

（1）字节码解释器工作时就是通过改变这个计数器的值来选取下一条需要执行的字节码指令，它是程序控制流的指示器。

（2）还有一个很重要的作用就是——线程恢复，在并发如此流行的时代，线程的上下文切换是常有的事。假如发生了线程上下文切换，如何能让线程恢复之前运行的状态？就需要依赖程序计数器来完成。

特点：

（1）就根据刚刚线程恢复这个作用就能推断出来，程序计数器是线程私有的，生命周期和线程一样。

（2）当执行 Java 方法时，程序计数器中保存的值就是正在执行的虚拟机字节码指令的地址；当执行本地方法时（用 native 关键字修饰的方法），程序计数器中保存的值就是为空。

（3）程序计数器是唯 一一个在《Java虚拟机规范》中没有规定任何 OutOfMemoryError 情况的区域。

1.2 Java 虚拟机栈

虚拟机栈描述的是 Java 方法执行的线程内存模型。

作用：

每个方法被执行的时候，Java 虚拟机都会同步创建一个栈帧（Stack Frame）用于存储局部变量表、操作数栈、动态连接、方法出口等信息。

每一个方法被调用直至执行完毕的过程，就对应着一个栈帧在虚拟机栈中从入栈到出栈的过程。

局部变量表存放了编译期可知的各种 Java 虚拟机基本数据类型、对象引用、returnAddress 类型。

特点：

如果线程请求的栈深度大于虚拟机所允许的深度，将抛出 StackOverflowError 异常；如果 Java 虚拟机栈容量可以动态扩展，当栈扩展时无法申请到足够的内存会抛出 OutOfMemoryError 异常。

注意：HotSpot 虚拟机的栈容量是不可以动态扩展的，以前的 Classic 虚拟机倒是可以。

Java 虚拟机栈是线程私有的，生命周期和线程一样。

1.3 本地方法栈

和 Java 虚拟机栈类似，只不过 Java 虚拟机栈面向的是 Java 方法，而本地方法栈面向的是本地方法。

注意：有的 Java 虚拟机（譬如 Hot-Spot 虚拟机）直接就把本地方法栈和虚拟机栈合二为一。

作用：

和 Java 虚拟栈一样，面向的对象不同而已。

特点：

与虚拟机栈一样，本地方法栈也会在栈深度溢出或者栈扩展失败时分别抛出 StackOverflowError 和 OutOfMemoryError 异常

本地方法栈是线程私有的，生命周期和线程一样。

1.4 Java 堆

是虚拟机所管理的内存中最大的一块。此内存区域的唯一目的就是存放对象实例，Java 世界里几乎所有的对象实例都在这里分配内存。

为什么是说几乎呢？

由于即时编译技术的进步，尤其是逃逸分析技术的日渐强大，栈上分配、标量替换优化手段已经导致一些微妙的变化悄然发生，所以说 Java 对象实例都分配在堆上也渐渐变得不是那么绝对了。

作用：

对象实例的内存分配，垃圾收集器管理的主要内存区域，会采用分代设计划分区域。

特点：

（1）Java 堆是被所有线程共享的一块内存区域，在虚拟机启动时创建。

（2）如果在 Java 堆中没有内存完成实例分配，并且堆也无法再扩展时，Java 虚拟机将会抛出 OutOfMemoryError 异常。

1.5 方法区

方法区（Method Area）与 Java 堆一样，是各个线程共享的内存区域，它用于存储已被虚拟机加载的类型信息、常量、静态变量、即时编译器编译后的代码缓存等数据。

注意：

我们平常基本用的就是 HotSpot 虚拟机。方法区就相当于是一个规范，具体如何实现由虚拟机自行定义（就相当于接口和实现类的关系）。

• 在 JDK 1.7，HotSpot 虚拟机对方法区的实现是永久代。
• 在 JDK 1.8，HotSpot 虚拟机对方法区的实现是元空间。

到 JDK 1.8 后，元空间是存储位置变成了本地内存，也就是从堆中移出了，并不是 JVM 的内存。

字符串常量池、静态变量还在堆中，运行时常量池还在元空间中。

特点：

如果方法区无法满足新的内存分配需求时，将抛出 OutOfMemoryError 异常。

1.6 运行时常量池

运行时常量池（Runtime Constant Pool）是方法区的一部分。

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

特点：

（1）具备动态性，例如调用 String 类的 intern() 方法即可将值放入运行时常量池中。

（2）当常量池无法再申请到内存时会抛出 OutOfMemoryError 异常。

1.7 直接内存

在 JDK 1.4 中新加入了 NIO（New Input/Output） 类，引入了一种基于通道（Channel）与缓冲区 （Buffer）的 I/O 方式，它可以使用 Native 函数库直接分配堆外内存，然后通过一个存储在 Java 堆里面的 DirectByteBuffer 对象作为这块内存的引用进行操作。这样能在一些场景中显著提高性能，因为避免了 在 Java 堆和 Native 堆中来回复制数据。

2、对象探秘

以最常用的虚拟机 HotSpot 和最常用的内存区域 Java 堆为例。

2.1 对象的创建

这里的创建对象仅仅限于普通 Java 对象，不包括数组和 Class 对象。

因为数组的创建是不会触发类加载的。

（1）检查阶段。

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

（2）分配内存阶段。

对象所需内存的大小在类加载完成后便可完全确定，为对象分配空间的任务实际上便等同于把一块确定大小的内存块从 Java 堆中划分出来。

划分内存有两种方式：

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

（2）空闲列表。但如果 Java 堆中的内存并不是规整的，已被使用的内存和空闲的内存相互交错在一起，那就没有办法简单地进行指针碰撞了，虚拟机就必须维护一个列表，记录上哪些内存块是可用的，在分 配的时候从列表中找到一块足够大的空间划分给对象实例，并更新列表上的记录。（这里如何找也是一个问题，可以联系其操作系统中内存块的分配，到底是首次适配呢，还是最佳适配又或者是最差适配。我并没有寻找到答案）

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

• 当使用 Serial、ParNew 等带压缩整理过程的收集器时，系统采用的分配算法是指针碰撞，既简单又高效；
• 而当使用 CMS 这种基于清除 （Sweep）算法的收集器时，理论上就只能采用较为复杂的空闲列表来分配内存。

另一个需要考虑的问题：线程安全问题。

对象创建在虚拟机中是非常频繁的行为，即使仅仅修改一个指针所指向的位置，在并发情况下也并不是线程安全的，可能出现正在给对象 A 分配内存，指针还没来得及修改，对象 B 又同时使用了原来的指针来分配内存的情况。

两种解决方案：

（1）CAS 方式。对分配内存空间的动作进行同步处理——实际上虚拟机是采用 CAS 配上失败重试的方式保证更新操作的原子性；

（2）TLAB 方式。把内存分配的动作按照线程划分在不同的空间之中进行，即每个线程在 Java 堆中预先分配一小块内存，称为本地线程分配缓冲（Thread Local Allocation Buffer，TLAB），哪个线程要分配内存，就在哪个线程的本地缓冲区中分配，只有本地缓冲区用完 了，分配新的缓存区时才需要同步锁定。

（3）初始化阶段。

虚拟机必须将分配到的内存空间（但不包括对象头）都初始化为零值，如果使用了 TLAB 的话，这一项工作也可以提前至 TLAB 分配时顺便进行。

这步操作保证了对象的实例字段在 Java 代码中可以不赋初始值就直接使用，使程序能访问到这些字段的数据类型所对应的零值。

（4）进行必要设置。

例如这个对象是哪个类的实例、如何才能找到类的元数据信息、对象的哈希码（实际上对象的哈希码会延后到真正调用Object.hashCode() 方法时才 计算）、对象的 GC 分代年龄等信息。这些信息存放在对象的对象头（Object Header）之中。

（5）执行构造方法。

对象创建才刚刚开始——构造函数，即 Class 文件中的 <init>() 方法还没有执行，所有的字段都为默认的零值，对象需要的其他资源和状态信息也还没有按照预定的意图构造好。

这样一个真正可用的对象才算完全被构造出来。

《深入理解 Java 虚拟机》上有源码来验证这一过程。

2.2 对象的内存布局

对象在堆内存中的存储布局可以划分为三个部分：对象头（Header）、实例数据（Instance Data）和对齐填充（Padding）。

对象的第一部分是对象头部分：

对象头部分包括两类信息：

（1）第一类是用于存储对象自身的运行时数据，如哈希码（HashCode）、GC分代年龄、锁状态标志、线程持有的锁、偏向线程ID、偏向时间戳等，这部分数据的长度在 32 位和 64 位的虚拟机（未开启压缩指针）中分别为 32 个比特和 64 个比特，官方称它为 Mark Word。

（2）第二类是类型指针，即对象指向它的类型元数据的指针，Java 虚拟机通过这个指针来确定该对象是哪个类的实例。并

不是所有的虚拟机实现都必须在对象数据上保留类型指针，换句话说，查找对象的元数据信息并不一定要经过对象本身。此外，如果对 象是一个 Java 数组，那在对象头中还必须有一块用于记录数组长度的数据，因为虚拟机可以通过普通 Java 对象的元数据信息确定Java 对象的大小，但是如果数组的长度是不确定的，将无法通过元数据中的信息推断出数组的大小。

对象的第二部分是实例数据部分：

实例数据部分是对象真正存储的有效信息，即我们在程序代码里面所定义的各种类型的字段内容，无论是从父类继承下来的，还是在子类中定义的字段都必须记录起来。

对象的第三部分是对齐填充：

这并不是必然存在的，也没有特别的含义，它仅仅起着占位符的作用。由于 HotSpot 虚拟机的自动内存管理系统要求对象起始地址必须是 8 字节的整数倍，换句话说就是任何对象的大小都必须是8字节的整数倍。

2.3 对象的访问定位

创建对象自然是为了后续使用该对象，我们的 Java 程序会通过栈上的 reference 数据来操作堆上的具体对象。

主流的访问方式主要有使用句柄和直接指针两种：

（1）句柄访问

Java 堆中将可能会划分出一块内存来作为句柄池，reference 中存储的就是对象的句柄地址，而句柄中包含了对象实例数据与类型数据各自具体的地址信息。

（2）直接指针访问

Java 堆中对象的内存布局就必须考虑如何放置访问类型数据的相关信息，reference 中存储的直接就是对象地址，如果只是访问对象本身的话，就不需要多一次间接访问的开销。

对比：

• 使用句柄来访问的最大好处就是 reference 中存储的是稳定句柄地址，在对象被移动（垃圾收集时移动对象是非常普遍的行为）时只会改变句柄中的实例数据指针，而 reference 本身不需要被修改。
• 使用直接指针来访问最大的好处就是速度更快，它节省了一次指针定位的时间开销，由于对象访问在 Java 中非常频繁，因此这类开销积少成多也是一项极为可观的执行成本。

HotSpot 虚拟机使用直接指针来访问对象。

参考

《深入理解 Java 虚拟机》-- 周志明