运行时数据区域
Java 虚拟机在执行 Java 程序的过程中会把它所管理的内存划分为若干个不同的数据区域。这些区域都有各自的用途，以及创建和销毁的时间，有的区域随着虚拟机进程的启动而存在（下图中绿色的数据区），有些区域则依赖用户线程的启动和结束而建立、销毁（下图中橙色的数据区）。
程序计数器
程序计数器是一块较小的内存空间，可以看作是当前线程所执行的字节码的行号指示器，在虚拟机的概念模型里，字节码解释器工作时就是通过改变这个计数器的值来选取下一条需要执行的字节码指令。
多线程是通过不断地切换线程实现的，因此任意一个确定的时刻，都只会执行一条指令，为了线程切换后能恢复到正确的执行位置，每条线程都需要有一个独立的程序计数器。
如果执行的是 Java 方法，这个计数器记录的是正在执行的虚拟机字节码指令的地址；如果执行的是 Native 方法，则这个计数器值为空。
此内存区域是 Java 虚拟机规范中唯一一个没有规定任何 OOM 情况的区域。
Java 虚拟机栈
Java 虚拟机栈也是线程私有的，它的生命周期与线程相同。
虚拟机栈描述的是 Java 方法执行的内存模型，每个方法在执行的同时都会创建一个栈帧，用于存储局部变量表、操作数栈、动态连接、方法出口等信息。每一个方法从调用直至执行完成的过程，就对应一个栈帧从虚拟机栈入栈到出栈的过程。
局部变量表存放的是编译期可知的基本数据类型、对象引用类型、returnAddress 类型（指向一条字节码指令的地址）。
经常有人把 Java 内存区分为堆内存、栈内存，这个分法比较粗糙，其中的栈指的就是虚拟机栈，或虚拟机栈中的局部变量表部分。
在 Java 虚拟机栈中，这个区域规定了两种异常情况：
1) StackOverflow：线程请求的栈深度大于虚拟机所允许的深度
2) OOM：虚拟机栈无法申请到足够的内存，且无法扩展
本地方法栈
本地方法栈和 Java 虚拟机栈类似，不过它是为 Native 方法服务的，同样会抛出 StackOverflow、OOM 两种异常。
有的虚拟机会把 Java 虚拟机栈和本地方法栈合二为一，比如 Sun HotSpot 虚拟机。
Java 堆
对于大多数应用而言，Java 堆是 Java 虚拟机所管理的内存中最大的一块，被所有线程共享，在虚拟机启动时创建。
此区域的唯一目的就是存放对象实例，几乎所有的对象实例（和数组）都在这里分配内存。
Java 堆是垃圾收集器管理的主要区域，因此很多时候也被称为 GC 堆(Garbage Collected Heap)。从内存回收的角度看，由于现在垃圾回收器基本都采用分代回收算法，因此可以分为新生代、年老代，或细致一点，有 Eden、From Survivor、To Survivor 空间等。从内存分配的角度看，线程共享的 Java 堆可能划分出多个线程私有的分配缓冲区（Thread Local Allocation Buffer，TLAB）。
根据 Java 虚拟机规范，Java 堆可以处于不连续的内存空间中，只要逻辑上连续即可。在实现时，可以是固定大小的，也可以是可扩展的，目前主流的虚拟机实现都是可扩展的，通过 -Xmx、Xms 控制。如果堆中没有更多的内存用以分配对象，并且无法扩展时，将抛出 OOM 异常。
方法区
方法区也是各个线程共享的内存区域，用于存储已被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码等数据。
HotSpot 的虚拟机设计团队使用永久代来实现方法区，因此很多人愿意把方法区成为“永久代”，但对于其它虚拟机，二者是不等价的，而且在 Java 8 中，HotSpot 已经移除了永久代(PermGen)，改用 Metaspace(元空间)。移除的原因是永久代大小受到 -XX:PermSize 和 -XX:MaxPermSize 两个参数的限制，而这两个参数又受到 JVM 的内存大小限制，这就导致在使用中可能会出现永久代内存溢出的问题。
Java 虚拟机规范对方法区的限制非常宽松，不需要连续的内存，可以选择固定大小或可扩展，还可以不实现垃圾收集。垃圾收集行为在这个区域是比较少出现的，这个区域的内存回收目标主要是针对常量池的回收和对类型的卸载。但回收成绩往往难以让人满意，尤其是类型的卸载，条件相当苛刻。
当方法区无法满足内存分配需求时，将抛出 OOM 异常。
运行时常量池
运行时常量池（Runtime Constant Pool）是方法区的一部分，同样会在无法申请到内存时抛出 OOM 异常。
Class 文件除了有类的版本、字段、方法、接口等描述信息外，还有一项信息是常量池（Constant Pool Table），用于存放编译期生成的各种字面量和符号引用。
Java 虚拟机规范对 Class 文件的格式有严格规定，但对于运行时常量池，没有做任何细节的要求，不同的虚拟机提供商的实现细节不同，一般除了保存 Class 文件的符号引用外，还会把翻译出来的直接引用也存储在运行时常量池中。
Java 语言并不要求常量一定要在编译期产生，可以在运行期间把新的常量放入常量池中，这种特性被开发人员利用得比较多的是 String 的 intern 方法。
String.intern() 是一个 Native 方法，它的作用是：如果字符串常量池中已经包含一个等于此 String 对象的字符串，则返回池中的该对象，否则，将此 String 对象包含的字符串添加到常量池中，并且返回此 String 对象的引用。
public class RuntimeConstantPoolOOM {
public static void main(String[] args) {
String str1 = new StringBuilder("深入理解").append("虚拟机").toString();
System.out.println(str1.intern() == str1);
String str2 = new StringBuilder("ja").append("va").toString();
System.out.println(str2.intern() == str2);
}
}这段代码在 JDK 1.6 中运行，会返回两个 false，在 JDK 1.7 中，会返回一个 true，一个 false。在 JDK 1.6 中，intern() 方法会把首次遇到的字符串实例复制到永久代中，而 StringBuilder 创建的字符串实例在 Java 堆上，所以必然不是同一个引用。而在 JDK 1.7 中，intern() 不再复制实例，只是在常量池中记录首次出现的实例引用，因此 intern() 返回的引用和 StringBuilder 创建的那个字符串实例是同一个，对 str2，字符串 “java” 在 StringBuilder.toString 之前已经存在于常量池中，因此不是同一个，返回 false。这个特性还经常出现在实际应用中，比如 Spring、Hibernate 等。
直接内存
直接内存并不是虚拟机运行时数据区的一部分，但这部分内存也被频繁地使用，而且可能导致 OOM 异常。
JDK 1.4 中新加入了 NIO 类，引入了一种基于通道与缓冲区的 I/O 方式，它可以使用 Native 函数直接分配堆外内存，然后通过一个存储在 Java 堆中的 DirectByteBuffer 对象操作这块内存，这样能显著提高性能。
直接内存不受 Java 堆大小的限制，但会受到本机总内存大小的限制，服务器管理员在配置 -Xmx 等参数信息时经常忽略直接内存，使得各个内存区域总和大于物理内存限制，从而导致动态扩展时出现 OOM 异常。
HotSpot 虚拟机对象探秘
对象的创建
虚拟机遇到一条 new 指令时，首先将去检查这个指令的参数是否能在常量池中定位到一个类的符号引用，并且检查这个符号引用代表的类是否已经被加载、解析和初始化过。如果没有，那必须先执行相应的类加载过程。
在类加载检查通过后，接下来虚拟机将为新生对象分配内存。对象所需的内存大小在类加载完成后并可完全确定，为对象分配空间的任务等同于把一块确定大小的内存从 Java 堆中划分出来。
假设 Java 堆中内存是绝对规整的，所有用过的内存放在一边，空闲的内存放在另一边，中间放着一个指针作为分界点的指示器，那分配内存就仅仅是把那个指针向空闲空间挪动一段与对象大小相等的距离，这种分配方法成为指针碰撞（Bump the Pointer）。
如果 Java 堆中的内存是不规整的，那么虚拟机必须维护一个列表，记录哪些内存可用，在分配的时候从列表中找到一块足够大的空间分配给对象实例，并更新列表上的记录，这种分配方式成为空闲列表（Free List）。
在使用 Serial、ParNew 等带 Compact 过程的收集器时，系统使用的分配算法是指针碰撞，而使用 CMS 这种基于 Mark-Sweep 算法的收集器时，通常采用空闲列表。
除此之外，创建对象时还需要考虑线程安全的问题，解决方法有两种：
1) 对分配内存空间的动作进行同步处理
2) 把内存分配的动作按照线程划分在不同的空间之中进行，即每个线程在 Java 堆中的预先分配一小块内存，成为本地线程分配缓冲（TLAB）
内存分配完成后，虚拟机需要将分配到的内存空间都初始化为零值。接着虚拟机要对对象进行必要的设置，例如这个对象是哪个类的实例、如何才能找到类的元数据信息、对象的哈希码、对象的 GC 分代年龄等信息，这些信息都存放在对象头中。
从虚拟机的角度来看，此时一个新的对象已经产生了，但从 Java 程序的角度看，对象创建才刚刚开始——还要接着执行 < init >方法。
对象的内存布局
在 HotSpot 虚拟机中，对象在内存中存储的布局可以分为 3 个区域：对象头、实例数据、对齐填充（Padding）。
HotSpot 虚拟机的对象头分为两部分信息，第一部分用于存储对象自身的运行时数据，如哈希码、GC 分代年龄等，这部分数据的长度在 32bit 和 64bit 的虚拟机中分别为 32bit、64bit，官方称它为 “Mark Word”。对象头的另一部分是类型指针，即对象指向它的类元数据的指针，虚拟机通过这个指针来确定这个对象是哪个类的实例。如果对象是一个数组，那在对象头中还必须有一块用于记录数组长度的数据。
实例数据是对象真正存储的有效信息，也是在程序代码中所定义的各种类型的字段内容，无论是从父类继承下来的，还是在子类中定义的，都需要记录。存储顺序受虚拟机分配策略参数和字段在 Java 代码中的定义顺序的影响，相同宽度的字段总是分配到一起，在这个前提下，父类中定义的变量会出现在子类之前。如果 CompactFields 的参数值为 true（默认为 true），那么子类中较窄的变量也可能会插入到父类的空隙之中。
第三部分并不是必然存在的，HotSpot VM 要求对象其实地址必须是 8 字节的整数倍，对象头正好的 8 的倍数，因此，当实例数据没有对齐时，就需要通过对齐填充来补全。
对象的访问定位
Java 程序需要通过栈上的 reference 数据来操作堆上的具体对象，目前主流的访问方式有两种：句柄、直接指针。
如果使用句柄的话，Java 堆将会划分除一块块内存作为句柄池，reference 中存储的就是对象的句柄地址，而句柄中包含了对象实例数据与类型数据各自的具体地址信息：
如果使用直接指针访问，那么 Java 堆对象的布局中就必须考虑如何放置类型数据的相关信息，而 reference 中存储的就是对象地址：
句柄的优点是稳定，当对象被移动时只会改变句柄中的实例数据指针，reference 本身不需要修改。
直接指针的优点是速度更快，HotSpot 使用的就是这种方式。
OutOfMemory 异常
在 Java 虚拟机规范的描述中，除了程序计数器外，虚拟机内存的其它几个运行时区域都有发生 OutOfMemory 异常的可能。
Java 堆溢出
调整虚拟机参数，并编写如下代码：
/**
* VM Args：-Xms20m -Xmx20m -XX:+HeapDumpOnOutOfMemoryError
* @author zzm
*/
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要解决这个区域的异常，一般的手工是先通过内存映像分析工作（如 Eclipse Memory Analyzer）对 Dump 出来的堆转储快照进行分析，重点是确认内存中的对象是否是必要的，并区分清楚是内存泄漏，还是内存溢出。如果是内存泄漏，可进一步通过工具查看对象到 GC Roots 的引用链，即可确认是怎样的路径导致对象无法被回收。如果不存在泄露，那么可以检查代码上某些对象生命周期是否过长，尝试减少程序运行期的内存消耗。
Java 虚拟机栈和本地方法栈溢出
/**
* VM Args：-Xss128k
* @author zzm
*/
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;
}
}
}这段代码会抛出 StackOverflow 异常，StackOverflow 有错误堆栈可以阅读，相对容易找到问题所在：
Exception in thread "main" java.land.StackOverflow
at ...下面这段代码能抛出 OOM 异常：
/**
* VM Args：-Xss2M （这时候不妨设大些）
* @author zzm
*/
public class JavaVMStackOOM {
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) throws Throwable {
JavaVMStackOOM oom = new JavaVMStackOOM();
oom.stackLeakByThread();
}
}运行结果：
Exception in thread "main" java.land.OutOfMemoryError: unable to create new native thread需要注意的是，此时虚拟机空间越大，反而越容易产生 OOM 异常，因为每个线程能分配的栈容量越大，可以建立的线程数量自然就少，就越容易把剩下的内存耗尽。
方法区和运行时常量池溢出
测试代码：
/**
* VM Args：-XX:MetaspaceSize=1M -XX:MaxMetaspaceSize=1M
* @author zzm
*/
public class RuntimeConstantPoolOOM {
public static void main(String[] args) {
// 使用List保持着常量池引用，避免Full GC回收常量池行为
List<String> list = new ArrayList<String>();
int i = 0;
while (true) {
list.add(String.valueOf(i++).intern());
}
}
}运行结果：
Error occurred during initialization of VM
OutOfMemoryError: MetaspaceMetaspace 说明运行时常量池属于方法区的一部分。
本地直接内存溢出
测试代码：
/**
* VM Args：-Xmx20M -XX:MaxDirectMemorySize=10M
* @author zzm
*/
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);
}
}
}运行结果：
Exception in thread "main" java.lang.OutOfMemoryError
at sun.misc.Unsafe.allocateMemory(Native Method)
at main.InternTest.main(DirectMemoryOOM.java:18)由 DirectMemory 导致的内存溢出，一个明显的特征是在 Heap Dump 文件中不会看见明显的异常，如果发现 OOM 之后 Dump 文件很小，而程序中又直接或简介使用了 NIO，那就可以考虑检查一下是不是这方面的原因。
总结
上面就是《深入理解 Java 虚拟机》第 2 章的内容了，我用 思维导图 作了一个总结，需要的可以查看链接或下面的图片：
