深入理解 Java 虚拟机 Java内存区域与内存溢出异常
Java内存区域与内存溢出异常
1.概述
对于 Java 的开发者来说，在虚拟机的自动内存管理机制的帮助下，不再需要为每一个 new 操作去写配对的 delete/ free 代码，这样不容易出现内存泄露和内存溢出的问题，只要全权交给虚拟机去处理。不过，也正是因为这样，一旦出现内存泄露和溢出方面的问题，如果不了解虚拟机是怎样使用内存的，那么排查错误将会异常艰难。
所以我们只有了解了虚拟机的各个区域、各个区域的作用、服务对象等，才能在遇到内存问题时去解决这些问题。
2.运行时数据区域
Java 虚拟机在执行 Java 程序的过程中会把它所管理的内存划分为若干个不同的数据区域。这些区域都有各自的用途，以及创建和销毁时间。根据《Java 虚拟机规范》的规定，Java 虚拟机所管理的内存将会包括以下几个运行时数据区域。
运行时数据区
2.1 - 程序计数器（Program Counter Register）
概述：该区域是一块较小的内存空间，它可以看作是当前线程所执行的字节码的 行号指示器。
作用：通过改变计数器的值来选取下一条需要执行的字节码指令。（分支、循环、跳转、异常处理、线程恢复等）基础功能都依赖与其完成。
特点：
1.线程私有：因为 Java 虚拟机的多线程是通过 线程轮流切换 并 分配处理器执行时间来实现的，在某一时刻，只会执行一条线程。因此，为了线程切换后能恢复到正确的执行位置，每条线程都需要有一个独立的程序计数器。
2.无内存溢出：如果线程正在执行的是一个 Java 方法，这个计数器记录的是正在执行的虚拟机字节码指令的地址；如果正在执行的是 Native 方法，这个计数器值则为空（Undefined）。此内存区域是唯一一个在 Java 虚拟机程序规范中没有规定任何 OutOfMemoryError 情况的区域。
2.2 - Java 虚拟机栈（Java Virtual Machine Stacks）
2.2.1 - Java 虚拟机栈
概述：描述 Java 方法执行的内存模型，每个方法从调用直至执行的过程，对应着一个 栈帧 在虚拟机栈中入栈到出栈的过程。
作用：存储局部变量表、操作数栈、动态链接、方法出口等信息。
特点：
1.线程私有。
2.生命周期与线程相同。
2.2.2 - 局部变量表
概述：存放了编译期间可知的各种基本数据类型（8种）、对象引用、returnAddress 类型（指向一条字节码指令的地址）。
占用空间：64位长度的 long 和 double 类型占用 2 个局部变量空间（Slot），其余数据类型只占用 1 个。
分配时机：在编译期间完成分配，当进入一个方法时，这个方法所需要在帧中分配多大的局部变量空间是完全确定的，在方法运行期间不会改变局部变量表的大小。
我们经常将 Java 内存分为堆内存（Heap）和栈内存（Stack），这种分法中所指的栈就是 Java 虚拟机栈，或者说是虚拟机栈中 局部变量表 部分。
2.2.3 - 对象引用
概述：reference 类型，它不等同于对象本身，可能是一个指向对象起始地址的引用指针，也可能是指向一个代表对象的句柄或其他与此对象相关的位置。
2.2.4 - 异常
| 异常类型 |
发生条件 |
| StackOverflowError |
线程请求的栈深度大于虚拟机所允许的深度时抛出该异常。 |
| OutOfMemoryError |
无法申请到足够的内存时抛出该异常。 |
2.3 - 本地方法栈（Native Method Stack）
概述：与虚拟机栈类似，是为虚拟机使用到的 Native 方法服务的内存区域。
区别：
o 虚拟机栈：为虚拟机执行 Java 方法（字节码）服务。
o 本地方法栈：为虚拟机使用到的 Native 方法服务。
异常：与虚拟机栈一致。
在虚拟机规范中对本地方法栈中方法使用的语言、使用方式与数据结构并没有强制规定，因此具体的虚拟机可以自由实现它。甚至有的虚拟机（e.g. Sun HotSpot VM）直接将本地方法栈与虚拟机栈合二为一。
2.4 - Java 堆（Java Heap）
概述：对于大多数应用来说，该区域是 Java 虚拟机所管理的内存中最大的一块区域。
作用：此区域唯一的目的就是存放对象实例。
特点：
1.被所有线程共享。
2.在虚拟机启动时创建。
异常
| 异常类型 |
发生条件 |
| StackOverflowError |
无 |
| OutOfMemoryError |
在堆中没有内存来完成实例分配，且堆无法再扩展时，抛出该异常。 |
内存：Java 堆可以处于物理上不连续的内存空间中，只要逻辑上是连续的即可。在实现时，既可以实现成固定大小的，也可以是可扩展的，当前主流的虚拟机都是按照可扩展来实现的（通过 -Xmx 和 -Xms 控制）。
Reminde ��
随着 JIT 编译器的发展与逃逸分析技术成熟，栈上分配、标量替换 等优化技术将会导致一些微妙的变化发生，所有的对象都分配在堆上也变得不那么绝对了。
2.5 - 方法区（Method Area）
概述：Java 虚拟机规范将方法区描述为堆的一个逻辑部分，但是它却有一个别名叫做 Non-Heap（非堆），目的是与 Java 堆区分开。
作用：存储已被虚拟机加载的（类信息、常量、静态变量、即时编译器编译后的代码）等数据。
特点：线程共享。
异常
| 异常类型 |
发生条件 |
| StackOverflowError |
无 |
| OutOfMemoryError |
当方法区无法满足内存分配需求时，抛出该异常。 |
·内存：Java 虚拟机规范对方法区的限制非常宽松，除了和 Java 堆一样不需要连续的内存空间和可以选择固定大小或者可扩展外，可以选择不实现垃圾收集。
相对而言，垃圾收集行为在这个区域是比较少出现的，这个区域的内存回收目标主要是针对 常量池的回收 和 类型的卸载。
2.6 - 运行时常量池（Runtime Constant Pool）
概述：方法区的一部分。Class 文件中除了有类的（版本、字段、方法、接口）等描述信息外，还有一项信息就是常量池。
作用：用于存放编译器生成的各种 字面量 和 符号引用。
动态性：Java 语言并不要求常量池一定只有编译期才能产生，也就是并非预置入 Class 文件中常量池的内容后才能进入方法区的运行时常量池，运行期间也可以将新的常量放入池中，这种特性用的比较广泛的便是 String 类的 intern() 方法。
异常
| 异常类型 |
发生条件 |
| StackOverflowError |
无 |
| OutOfMemoryError |
因为是方法区的一部分，所以受到方法区内存的限制，当常量池无法再申请到内存时抛出该异常。 |
Java 虚拟机对 Class 文件的每一部分（包括常量池）的格式都有严格规定，每一个字节用于存储哪种数据类型必须符合规范上的要求才会被虚拟机认可、装载和执行，但对于运行时常量池，Java 虚拟机规范没有做任何细节的要求，不同的提供商实现虚拟机可以按照自己的需求来实现这个内存区域。
一般来说，除了保存 Class 文件中描述的符号引用外，还会把翻译出来的直接引用也存储在该区域中。
2.7 - 直接内存（Direct Memory）
概述：并不是虚拟机运行时数据区的一部分，也不是 Java 虚拟机规范中定义的内存区域。但是这部分内存也被频繁地使用，而且也可能导致 OutOfMemoryError 异常出现。
作用：在 JDK1.4 中新加入了 NIO（New Input/Output）类，引入了一种基于通道（Channel）与缓冲区（Buffer）的 I/O 方式，它可以使用 Native 函数库直接分配堆外内存，然后通过一个存储在 Java 堆中的 DirectByteBuffer 对象作为这块内存的引用进行操作。这样能在一些场景中显著提高性能，因为避免了在 Java 堆和 Native 堆中来回复制数据。
异常
| 异常类型 |
发生条件 |
| StackOverflowError |
无 |
| OutOfMemoryError |
受到物理内存限制，动态扩展时无法申请到内存时抛出该异常。 |
显然，本机直接内存的分配不会受到 Java 堆大小的限制，但是，既然是内存，肯定还是会受到本机内存（包括 RAM 以及 SWAP 区或者分页大小）大小以及处理器寻址空间的限制，当各个内存区域总和大于物理内存限制（包括物理和操作系统级的限制）时会出现异常。
3.HotSpot 虚拟机对象探秘
这一部分内容将以 HotSpot 虚拟机和常用的内存区域 Java 堆为例，阐述对象分配、布局和访问的全过程。
3.1 - 对象的创建
概述：Java 是一门面向对象的编程语言，在 Java 程序运行过程中无时无刻都有对象被创建出来。在语言层面上，创建对象通常仅仅是一个 new 关键字而已，而在虚拟机中对象的创建则分为以下几个步骤。
3.1.1 - 类加载
概述：虚拟机遇到一条 new 指令时，首先将去检查指令参数是否能在常量池中定位到一个类的符号引用，并且检查这个符号引用代表的类是否已被加载、解析和初始化过。如果没有，那必须先执行相应的类加载过程。
3.1.2 - 分配内存
概述：在类加载检查通过后，接下来虚拟机将为新生对象分配内存。对象所需内存的大小在类加载完成后便可以完全确定，为对象分配空间的任务等同于把一块确定大小的内存从 Java 堆中划分出来。
分配方式：
1.指针碰撞（Bump the Pointer）：假设 Java 堆中内存是绝对规整的，所有用过的内存都放在一边，空闲的内存放在另一边，中间放着一个指针作为分界点的指示器，那所分配内存就仅仅是把哪个指针向空闲那边挪动一段与对象大小相等的距离。
2.空闲列表（Free List）：如果 Java 堆中的内存不是规整的，已使用的内存和空闲的内存相互交错，那就没有办法简单地进行指针碰撞了，虚拟机就必须维护一个列表，记录上哪些内存块是可用的，在分配的时候从列表中找到一块足够大的空间划分给对象实例，并更新列表上的记录。
选择哪种分配方式由 Java 堆是否规整决定，而 Java 堆是否规整又由所采用的垃圾收集器是否带有压缩整理功能决定。因此，在使用 Serial、ParNew 等带 Compact 过程的收集器时，系统采用的分配算法是指针碰撞，而使用 CMS 这种基于 Mark-Sweep 算法的收集器时，通常采用空闲列表。
3.1.3 - 同步控制
概述：对象创建在虚拟机中是非常频繁的行为，即使是仅仅修改一个指针所指向的位置，在并发情况下也并不是线程安全的，可能出现正在给对象 A 分配地址，指针还没来得及修改，对象 B 又同时使用了原来的指针来分配内存的情况。解决这个问题有两种方案。
方案一：对分配内存空间的动作进行同步处理，虚拟机采用 CAS 配上失败重试 的方式保证更新操作的原子性。
方案二：将内存分配的动作按照线程划分在不同的空间中进行，每个线程在 Java 堆中预先分配一小块内存，称为 本地线程分配缓冲（Thread Local Allocation Buffer, TLAB） 。哪个线程需要分配内存，就在哪个线程的 TLAB 上分配，只有 TLAB 用完并分配新的 TLAB 时，才需要同步锁定。通过 -XX:+/-UseTLAB 参数设定是否使用 TLAB。
3.1.4 - 初始化
概述：内存分配完成后，虚拟机需要将分配到的内存空间都初始化为零值（不包括对象头），如果使用 TLAB，这一过程就可以提前至 TLAB 分配时进行。
作用：保证对象的实例字段在 Java 代码中可以不赋初值就直接使用，程序能访问到这些字段的数据类型对应的零值。
3.1.5 - 对象头（Object Header）
概述：接下来，虚拟机要为对象头数据进行设置。（e.g. 对象的实例类、类的元数据信息的地址、对象的哈希码、对象的 GC 分代年龄）
3.1.6 - init
概述：在上面步骤完成后，从虚拟机的角度来看，一个新的对象已经产生了，但从 Java 程序的角度来看，对象的创建才刚刚开始，
3.2 - 对象的内存布局
在 HotSpot 虚拟机中，对象在内存中存储的布局可以分为以下 3 块区域。
3.2.1 - 对象头（Header）
HotSpot 虚拟机的对象头包括两部分信息，存储自身的运行时数据的（Mark Word） 和 类型指针。
第一部分：Mark Word
概述：用于存储对象自身的运行时数据，如（HashCode、GC 分代年龄、锁状态标志、线程持有锁、偏向线程ID、偏向时间戳），这部分数据的长度在 32 位和 64 位的虚拟机中（未开启压缩指针）分别为 32bit 和 64bit。
内存：对象需要存储的运行时数据很多，其实已经超出了 32位、64位 Bitmap 结构所能记录的限度，但是对象头信息是与对象自身定义的数据无关的额外存储成本，考虑到虚拟机的空间效率，Mark Word 被设计成一个 非固定的数据结构 以便在极小的空间内存储尽量多的信息，它会根据对象的状态复用自己的存储空间。
HotSpot 虚拟机对象头 Mark Word 表如下��
| 存储内容 |
标志位 |
状态 |
| 对象哈希码、对象分代年龄 |
01 |
未锁定 |
| 指向锁记录的指针 |
00 |
轻量级锁定 |
| 指向重量级锁的指针 |
10 |
膨胀（重量级锁定） |
| 空（不需要记录信息） |
11 |
GC 标记 |
| 偏向线程 ID、偏向时间戳、对象分代年龄 |
01 |
可偏向 |
第二部分：类型指针
概述：即对象指向它的类元数据的指针，虚拟机通过这个指针来确定这个对象是哪个类的实例。
Reminder ��
并不是所有的虚拟机实现都必须在对象数据上保留类型指针，换句话说，查找对象的元数据并不一定要经过对象本身。
数组对象：如果对象是一个 Java 数组，那在对象头中还必须有一块用于记录数组长度的数据，因为虚拟机可以通过普通 Java 对象的元数据信息确定 Java 对象的大小，但是从数组的元数据中却无法确定数组的大小。
3.2.2 - 实例数据（Instance Data）
概述：这部分是对象真正存储的有效信息，也是在程序代码中所定义的各种类型字段内容。无论是从父类继承下来的，还是在子类中定义的，都需要记录起来。
存储顺序：这部分的存储顺序会受到虚拟机 分配策略参数（FieldsAllocationStyle） 和字段在 Java 源码中定义顺序的影响。
HotSpot 虚拟机默认的分配策略为 longs/doubles => ints =>shorts/chars => bytes/booleans => oops（Ordinary Object Pointers），从分配策略中可以看出，相同宽度的字段总是被分配到一起。在满足这个前提条件的情况下，在父类中定义的变量会出现在子类之前。
如果 CompactFields 参数值为 true（默认为 true），那么子类之中较窄的变量也可能会插入到父类变量的空隙之中。
3.2.3 - 对齐填充（Padding）
概述：不是必然存在的，也没有特别的含义，它仅仅起着占位符的作用。
原理：由于 HotSpot VM 的自动内存管理系统要求 对象起始地址必须是 8 字节的整倍数，换句话说，就是对象的大小必须是 8 字节的整倍数。而对象头部分正好是 8 字节的整倍数（ 1 倍或 2 倍），因此，当对象实例数据部分没有对齐时，就需要通过对齐填充来补全。
3.3 - 对象的访问定位
概述：建立对象是为了使用对象，我们的 Java 程序需要通过栈上的 reference 数据来操作堆上的具体对象。由于 reference 类型在 Java 虚拟机规范中只规定了一个指向对象的引用，并没有定义这个引用应该通过何种方式去定位、访问堆中的对象的具体位置，所以 对象访问方式也是取决于虚拟机实现而定的。目前主流的访问方式有两种。
句柄访问：Java 堆中将会划分出一块内存来作为句柄池，reference 中存储的就是对象的句柄地址，而句柄中包含了对象实例数据与类型数据各自的具体地址信息，如下图所示��。
通过句柄访问对象
直接指针：Java 堆对象的布局中必须考虑如何放置访问类型数据的相关信息，而 reference 中存储的直接就是对象地址，如下图所示��。
通过直接指针访问对象
比较：
o 句柄访问：使用句柄访问的最大好处就是 reference 中存储的是 稳定的 句柄地址，在对象被移动（垃圾收集时移动对象是非常普遍的行为）时只会改变句柄中的实例数据指针，而 reference 本身不需要修改。
o 指针访问：使用直接访问最大的好处就是 速度快，它节省了一次指针定位的时间开销，由于对象的访问在 Java 中非常频繁，因此这类开销积少成多后也是一项非常可观的执行成本。
Sun HotSpot 使用的是第二种方式进行对象访问的，但从整个软件开发的范围来看，各种语言和框架使用句柄来访问的情况也十分常见。
4.实战：OutOfMemoryError 异常
在 Java 虚拟机规范的描述中，除了程序计数器外，虚拟机内存的其他几个运行时区域都有发生 OutOfMemory（OOM）异常的可能。
目的：
1.通过代码验证 Java 虚拟机规范中描述的各个运行时区域的存储内容。
2.遇到实际的内存溢出异常时，能根据异常的信息快速判断哪个区域的内存溢出。
3.了解什么样的代码可能会导致这些区域内存溢出，并了解如何处理。
VM Args 设置
Eclipse IDE：Debug Configurations => JavaApplication => YoungGenGC => Arguments 中的 VM arguments 中进行书写（书写参数以 - 开头，以空格分隔）。
控制台：直接跟在 Java 命令之后书写。
本人运行在 Mac 系统下，使用 IDEA 进行配置，步骤如下所示��。
虚拟机启动参数.gif
1.打开 Run Configurations（⌃ + ⌥ + R 选择 0 ）或者（⌘ + ⇧ + A 输入 run 选择 run…）。
2.点击并打开 VM options。
3.写入虚拟机启动参数。
4.Apply 并 Run。
4.1 - Java 堆溢出
· 概述：Java 堆用于存储对象实例，只要不断地创建对象，并且保证 GC Roots 到对象之间有可达路径 来避免垃圾回收机制清除这些对象，那么在对象数量到达最大堆的容量限制后就会产生内存溢出异常。
测试环境：
测试代码：
运行结果：
分析：Java 堆内存的 OOM 异常是时机应用中常见的内存溢出异常情况。当出现 Java 堆内存溢出时，异常堆栈信息 java.lang.OutOfMemoryError 会跟着进一步提示 Javaheap space。
解决方式
1.堆转储快照：要解决这个区域的异常，一般的手段是先通过内存映像分析工具对 Dump 出来的堆转储快找进行分析，重点是确认内存中的对象是否是必要的，也就是要分清楚到底是出现了内存泄露（Memory Leak）还是内存溢出（Memory Overflow）。
2.内存泄露：进一步通过工具查看泄露对象到 CG Roots 的引用链，于是就能找到内存泄露对象是通过怎样的路径与 GC Roots 相关联并导致垃圾收集器无法自动回收它们的。掌握了泄露对象的类型信息以及 GC Roots 引用链的信息，就可以比较准确地定位出泄露代码的位置。
3.内存溢出：如果不存在泄露，换句话说，就是内存中的对象确实都必须还活着，那就应当检查虚拟机的堆参数（-Xmx 与 -Xms），与机器物理内存对象看是否还可以调大，从代码上检查是否存在某些对象生命周期过长、持有状态过长的情况，尝试减少程序运行期的内存消耗。
4.2 - 虚拟机栈和本地方法栈溢出
概述：由于在 HotSpot 虚拟机中并不区分虚拟机栈和本地方法栈，因此，对于 HotSpot 来说，虽然 -Xoos 参数（设置本地方法栈大小）存在，但实际上是无效的，栈容量只由 -Xss 参数设定。关于虚拟机栈和本地方法栈，在 Java 虚拟机规范中描述了两种异常。
| 异常类型 |
发生条件 |
| StackOverflowError |
线程请求的栈深度大于虚拟机所允许的深度时抛出该异常。 |
| OutOfMemoryError |
无法申请到足够的内存时抛出该异常。 |
这里把异常分为两种情况，看似更加严谨，但却存在一些相互重叠的地方：方栈空间无法继续分配时，到底是内存太小，还是已使用的栈空间太大，其本质上只是对同一件事的两种描述而已。
4.2.1 - StackOverflowError
测试环境：在此测试中，将测试范围限制于单线程中操作。
1.使用 -Xss 参数减少栈内存容量，结果抛出 SOF 异常，异常出现时输出的堆栈深度相应缩小。
2.定义了大量的本地变量，增大此方法栈中本地变量表长度。结果抛出 SOF 异常时输出的堆栈深度相应缩小。
测试代码
运行结果
分析：在单个线程下，无论是由于栈帧太大还是虚拟机栈容量太小，当内存无法分配的时候，虚拟机抛出的都是 StackOverflowError 异常。
但是这样产生的内存溢出异常与栈空间是否足够大并不存在任何联系，或者确切地说，在这种情况下，为每个线程的栈分配的内存越大，反而越容易产生内存溢出异常。
理解：操作系统分配给每个进程的内存是有限的，虚拟机提供了参数来控制 Java 堆和方法区的这两部分内存的最大值。剩余的内存 -Xms（最大堆容量） -MaxPermSize（最大方法区容量），程序计数器消耗内存很小，可以忽略不计。
如果虚拟机进程本身耗费的内存不计算在内，剩下的内存就由虚拟机栈和本地方法栈瓜分了。每个线程分配到的栈容量越大，可以建立的线程数量自然越少，建立线程时就越容易把剩下的内存耗尽。
探索：出现 SOF 异常时有错误堆栈可以阅读，相对来说，比较容易找到问题的所在。而且，如果使用虚拟机默认参数，栈深度在大多数情况下（因为每个方法压入栈的帧大小并不是一样的）达到 1000 - 2000 完全没有问题，对于正常的方法调用（包括递归），这个深度应该完全够用了。
但是，如果建立过多线程导致内存溢出，在不能减少线程数或者更换 64 位虚拟机的情况下，就只能通过 减少最大堆 和 减少栈容量 来换更多的线程。
4.2.2 - OutOfMemoryError
测试环境
测试代码：创建线程导致内存溢出异常
运行结果
4.3 - 方法区和运行时常量池溢出
概述：由于运行时常量池是方法区的一部分，因此这两个区域的溢出测试就放在一起进行。
脑补：String.intern() 是一个 Native 方法，它的作用是：如果字符串常量池中已经包含一个等于此 String 对象的字符串，则返回代表池中这个字符串的 String 对象；否则，将此 String 对象包含的字符串添加到常量池中，并且返回此 String 对象的引用。
在 JDK1.6 以及之前的版本中，由于常量池分配在永久代内，我们可以通过 -XX:PermSize 和 -XX:MaxPermSize 限制方法区的大小名，从而间接限制其中常量池的容量。
4.3.1 - OutOfMemoryError
测试环境
测试代码
运行结果
分析：从运行结果中可以看到，运行时常量池溢出，在 OutOfMemoryError 后面跟随的提示信息是 PermGenspace，说明运行时常量池属于方法区（HotSpot 虚拟机中的永久代）的一部分。
4.3.2 - String 常量池测试
使用 JDK1.7 运行这段程序就不会得到相同的结果，while 循环将一直进行下去。关于这个字符串常量池的实现问题，还可以引申出一个更有意思的影响。
测试代码
分析：
o JDK1.6：会得到两个 false，而在 JDK1.7 中运行，会得到一个 true 和一个 false。
产生差异的原因是：是 JDK1.6 中 intern() 方法会把首次遇到的字符串实例复制到永久代中，返回的也是永久代中这个字符串实例的引用，而由 StringBuilder 创建的字符串实例在 Java 堆上，所以必然不是同一个引用，将返回 false
o JDK1.7：intern() 实现不会再复制实例，只是在常量池中记录首次出现的实例引用，因此 intern() 返回的引用和由 StringBuilder 创建的那个字符串实例是同一个。
对 str2 比较返回 false 是因为 java 这个字符串在执行 StringBuilder.toString() 之前已经出现过，字符串常量池中已经有它的引用了，不符合首次出现的原则，而 计算机软件 这个字符串是首次出现的，因此返回 true。
4.3.3 - 测试设计思路
方法区用于存放 Class 的相关信息，如类名、访问修饰符、常量池、字段描述、方法描述等。对于这些区域的测试，基本思路就是运行时产生大量的类去填满方法区，直到溢出。另外的，直接使用 Java SE API 也可以动态产生类（如反射时的 GeneratedConstorAccessor 和动态代理等）。
4.3.4 - 总结
方法区溢出是一种常见的内存溢出异常，一个类要被垃圾收集器回收掉，判定条件是比较苛刻的。
在经常动态生成大量的 Class 的应用中，需要特别注意类的回收情况。这类场景除了上面提到的程序使用了 CGLib 字节码增强和动态语言之外，常见的还有：大量 JSP 或动态产生 JSP 文件的应用（JSP 第一次运行时需要编译为 Java 类）、基于 OSGi 应用（即使是同一个类文件，被不同的加载器加载也会视为不同的类）等。
4.4 - 本机直接内存溢出
概述：DirectMemory 容量可以通过 -XX:MaxDirectMemorySize 指定，如果不指定，则默认与 Java 堆最大值（-Xmx指定）一样，下面的测试代码越过了 DirectByteBuffer 类，直接通过反射获取 Unsafe 实例进行内存分配（Unsafe 类的 getUnsafe() 方法限制了只有引导类加载器才会返回实例，也就是设计者希望只有 rt.jar 中的类才能使用 Unsafe 的功能）。
因为，虽然使用 DirectByteBuffer 分配内存也会抛出内存溢出异常，但它抛出异常时并没有真正向操作系统申请分配内存，而是通过计算得知内存无法分配，于是手动抛出异常，真正申请分配内存的方法是 unfase.allocateMemory()。
测试代码
运行结果
分析：由 DirectMemory 导致的内存溢出，一个明显的特征是在 Heap Dump 文件中不会看到明显的异常，如果发现 OOM 之后 Dump 文件很小，而程序中又直接或间接使用了 NIO，那就可以考虑检查一下是不是这方面的原因。
Java内存区域与内存溢出异常
1.概述
对于 Java 的开发者来说，在虚拟机的自动内存管理机制的帮助下，不再需要为每一个 new 操作去写配对的 delete/ free 代码，这样不容易出现内存泄露和内存溢出的问题，只要全权交给虚拟机去处理。不过，也正是因为这样，一旦出现内存泄露和溢出方面的问题，如果不了解虚拟机是怎样使用内存的，那么排查错误将会异常艰难。
所以我们只有了解了虚拟机的各个区域、各个区域的作用、服务对象等，才能在遇到内存问题时去解决这些问题。
2.运行时数据区域
Java 虚拟机在执行 Java 程序的过程中会把它所管理的内存划分为若干个不同的数据区域。这些区域都有各自的用途，以及创建和销毁时间。根据《Java 虚拟机规范》的规定，Java 虚拟机所管理的内存将会包括以下几个运行时数据区域。
运行时数据区
2.1 - 程序计数器（Program Counter Register）
概述：该区域是一块较小的内存空间，它可以看作是当前线程所执行的字节码的 行号指示器。
作用：通过改变计数器的值来选取下一条需要执行的字节码指令。（分支、循环、跳转、异常处理、线程恢复等）基础功能都依赖与其完成。
特点：
1.线程私有：因为 Java 虚拟机的多线程是通过 线程轮流切换 并 分配处理器执行时间来实现的，在某一时刻，只会执行一条线程。因此，为了线程切换后能恢复到正确的执行位置，每条线程都需要有一个独立的程序计数器。
2.无内存溢出：如果线程正在执行的是一个 Java 方法，这个计数器记录的是正在执行的虚拟机字节码指令的地址；如果正在执行的是 Native 方法，这个计数器值则为空（Undefined）。此内存区域是唯一一个在 Java 虚拟机程序规范中没有规定任何 OutOfMemoryError 情况的区域。
2.2 - Java 虚拟机栈（Java Virtual Machine Stacks）
2.2.1 - Java 虚拟机栈
概述：描述 Java 方法执行的内存模型，每个方法从调用直至执行的过程，对应着一个 栈帧 在虚拟机栈中入栈到出栈的过程。
作用：存储局部变量表、操作数栈、动态链接、方法出口等信息。
特点：
1.线程私有。
2.生命周期与线程相同。
2.2.2 - 局部变量表
概述：存放了编译期间可知的各种基本数据类型（8种）、对象引用、returnAddress 类型（指向一条字节码指令的地址）。
占用空间：64位长度的 long 和 double 类型占用 2 个局部变量空间（Slot），其余数据类型只占用 1 个。
分配时机：在编译期间完成分配，当进入一个方法时，这个方法所需要在帧中分配多大的局部变量空间是完全确定的，在方法运行期间不会改变局部变量表的大小。
我们经常将 Java 内存分为堆内存（Heap）和栈内存（Stack），这种分法中所指的栈就是 Java 虚拟机栈，或者说是虚拟机栈中 局部变量表 部分。
2.2.3 - 对象引用
概述：reference 类型，它不等同于对象本身，可能是一个指向对象起始地址的引用指针，也可能是指向一个代表对象的句柄或其他与此对象相关的位置。
2.2.4 - 异常
| 异常类型 |
发生条件 |
| StackOverflowError |
线程请求的栈深度大于虚拟机所允许的深度时抛出该异常。 |
| OutOfMemoryError |
无法申请到足够的内存时抛出该异常。 |
2.3 - 本地方法栈（Native Method Stack）
概述：与虚拟机栈类似，是为虚拟机使用到的 Native 方法服务的内存区域。
区别：
o 虚拟机栈：为虚拟机执行 Java 方法（字节码）服务。
o 本地方法栈：为虚拟机使用到的 Native 方法服务。
异常：与虚拟机栈一致。
在虚拟机规范中对本地方法栈中方法使用的语言、使用方式与数据结构并没有强制规定，因此具体的虚拟机可以自由实现它。甚至有的虚拟机（e.g. Sun HotSpot VM）直接将本地方法栈与虚拟机栈合二为一。
2.4 - Java 堆（Java Heap）
概述：对于大多数应用来说，该区域是 Java 虚拟机所管理的内存中最大的一块区域。
作用：此区域唯一的目的就是存放对象实例。
特点：
1.被所有线程共享。
2.在虚拟机启动时创建。
异常
| 异常类型 |
发生条件 |
| StackOverflowError |
无 |
| OutOfMemoryError |
在堆中没有内存来完成实例分配，且堆无法再扩展时，抛出该异常。 |
内存：Java 堆可以处于物理上不连续的内存空间中，只要逻辑上是连续的即可。在实现时，既可以实现成固定大小的，也可以是可扩展的，当前主流的虚拟机都是按照可扩展来实现的（通过 -Xmx 和 -Xms 控制）。
Reminde ��
随着 JIT 编译器的发展与逃逸分析技术成熟，栈上分配、标量替换 等优化技术将会导致一些微妙的变化发生，所有的对象都分配在堆上也变得不那么绝对了。
2.5 - 方法区（Method Area）
概述：Java 虚拟机规范将方法区描述为堆的一个逻辑部分，但是它却有一个别名叫做 Non-Heap（非堆），目的是与 Java 堆区分开。
作用：存储已被虚拟机加载的（类信息、常量、静态变量、即时编译器编译后的代码）等数据。
特点：线程共享。
异常
| 异常类型 |
发生条件 |
| StackOverflowError |
无 |
| OutOfMemoryError |
当方法区无法满足内存分配需求时，抛出该异常。 |
·内存：Java 虚拟机规范对方法区的限制非常宽松，除了和 Java 堆一样不需要连续的内存空间和可以选择固定大小或者可扩展外，可以选择不实现垃圾收集。
相对而言，垃圾收集行为在这个区域是比较少出现的，这个区域的内存回收目标主要是针对 常量池的回收 和 类型的卸载。
2.6 - 运行时常量池（Runtime Constant Pool）
概述：方法区的一部分。Class 文件中除了有类的（版本、字段、方法、接口）等描述信息外，还有一项信息就是常量池。
作用：用于存放编译器生成的各种 字面量 和 符号引用。
动态性：Java 语言并不要求常量池一定只有编译期才能产生，也就是并非预置入 Class 文件中常量池的内容后才能进入方法区的运行时常量池，运行期间也可以将新的常量放入池中，这种特性用的比较广泛的便是 String 类的 intern() 方法。
异常
| 异常类型 |
发生条件 |
| StackOverflowError |
无 |
| OutOfMemoryError |
因为是方法区的一部分，所以受到方法区内存的限制，当常量池无法再申请到内存时抛出该异常。 |
Java 虚拟机对 Class 文件的每一部分（包括常量池）的格式都有严格规定，每一个字节用于存储哪种数据类型必须符合规范上的要求才会被虚拟机认可、装载和执行，但对于运行时常量池，Java 虚拟机规范没有做任何细节的要求，不同的提供商实现虚拟机可以按照自己的需求来实现这个内存区域。
一般来说，除了保存 Class 文件中描述的符号引用外，还会把翻译出来的直接引用也存储在该区域中。
2.7 - 直接内存（Direct Memory）
概述：并不是虚拟机运行时数据区的一部分，也不是 Java 虚拟机规范中定义的内存区域。但是这部分内存也被频繁地使用，而且也可能导致 OutOfMemoryError 异常出现。
作用：在 JDK1.4 中新加入了 NIO（New Input/Output）类，引入了一种基于通道（Channel）与缓冲区（Buffer）的 I/O 方式，它可以使用 Native 函数库直接分配堆外内存，然后通过一个存储在 Java 堆中的 DirectByteBuffer 对象作为这块内存的引用进行操作。这样能在一些场景中显著提高性能，因为避免了在 Java 堆和 Native 堆中来回复制数据。
异常
| 异常类型 |
发生条件 |
| StackOverflowError |
无 |
| OutOfMemoryError |
受到物理内存限制，动态扩展时无法申请到内存时抛出该异常。 |
显然，本机直接内存的分配不会受到 Java 堆大小的限制，但是，既然是内存，肯定还是会受到本机内存（包括 RAM 以及 SWAP 区或者分页大小）大小以及处理器寻址空间的限制，当各个内存区域总和大于物理内存限制（包括物理和操作系统级的限制）时会出现异常。
3.HotSpot 虚拟机对象探秘
这一部分内容将以 HotSpot 虚拟机和常用的内存区域 Java 堆为例，阐述对象分配、布局和访问的全过程。
3.1 - 对象的创建
概述：Java 是一门面向对象的编程语言，在 Java 程序运行过程中无时无刻都有对象被创建出来。在语言层面上，创建对象通常仅仅是一个 new 关键字而已，而在虚拟机中对象的创建则分为以下几个步骤。
3.1.1 - 类加载
概述：虚拟机遇到一条 new 指令时，首先将去检查指令参数是否能在常量池中定位到一个类的符号引用，并且检查这个符号引用代表的类是否已被加载、解析和初始化过。如果没有，那必须先执行相应的类加载过程。
3.1.2 - 分配内存
概述：在类加载检查通过后，接下来虚拟机将为新生对象分配内存。对象所需内存的大小在类加载完成后便可以完全确定，为对象分配空间的任务等同于把一块确定大小的内存从 Java 堆中划分出来。
分配方式：
1.指针碰撞（Bump the Pointer）：假设 Java 堆中内存是绝对规整的，所有用过的内存都放在一边，空闲的内存放在另一边，中间放着一个指针作为分界点的指示器，那所分配内存就仅仅是把哪个指针向空闲那边挪动一段与对象大小相等的距离。
2.空闲列表（Free List）：如果 Java 堆中的内存不是规整的，已使用的内存和空闲的内存相互交错，那就没有办法简单地进行指针碰撞了，虚拟机就必须维护一个列表，记录上哪些内存块是可用的，在分配的时候从列表中找到一块足够大的空间划分给对象实例，并更新列表上的记录。
选择哪种分配方式由 Java 堆是否规整决定，而 Java 堆是否规整又由所采用的垃圾收集器是否带有压缩整理功能决定。因此，在使用 Serial、ParNew 等带 Compact 过程的收集器时，系统采用的分配算法是指针碰撞，而使用 CMS 这种基于 Mark-Sweep 算法的收集器时，通常采用空闲列表。
3.1.3 - 同步控制
概述：对象创建在虚拟机中是非常频繁的行为，即使是仅仅修改一个指针所指向的位置，在并发情况下也并不是线程安全的，可能出现正在给对象 A 分配地址，指针还没来得及修改，对象 B 又同时使用了原来的指针来分配内存的情况。解决这个问题有两种方案。
方案一：对分配内存空间的动作进行同步处理，虚拟机采用 CAS 配上失败重试 的方式保证更新操作的原子性。
方案二：将内存分配的动作按照线程划分在不同的空间中进行，每个线程在 Java 堆中预先分配一小块内存，称为 本地线程分配缓冲（Thread Local Allocation Buffer, TLAB） 。哪个线程需要分配内存，就在哪个线程的 TLAB 上分配，只有 TLAB 用完并分配新的 TLAB 时，才需要同步锁定。通过 -XX:+/-UseTLAB 参数设定是否使用 TLAB。
3.1.4 - 初始化
概述：内存分配完成后，虚拟机需要将分配到的内存空间都初始化为零值（不包括对象头），如果使用 TLAB，这一过程就可以提前至 TLAB 分配时进行。
作用：保证对象的实例字段在 Java 代码中可以不赋初值就直接使用，程序能访问到这些字段的数据类型对应的零值。
3.1.5 - 对象头（Object Header）
概述：接下来，虚拟机要为对象头数据进行设置。（e.g. 对象的实例类、类的元数据信息的地址、对象的哈希码、对象的 GC 分代年龄）
3.1.6 - init
概述：在上面步骤完成后，从虚拟机的角度来看，一个新的对象已经产生了，但从 Java 程序的角度来看，对象的创建才刚刚开始，
3.2 - 对象的内存布局
在 HotSpot 虚拟机中，对象在内存中存储的布局可以分为以下 3 块区域。
3.2.1 - 对象头（Header）
HotSpot 虚拟机的对象头包括两部分信息，存储自身的运行时数据的（Mark Word） 和 类型指针。
第一部分：Mark Word
概述：用于存储对象自身的运行时数据，如（HashCode、GC 分代年龄、锁状态标志、线程持有锁、偏向线程ID、偏向时间戳），这部分数据的长度在 32 位和 64 位的虚拟机中（未开启压缩指针）分别为 32bit 和 64bit。
内存：对象需要存储的运行时数据很多，其实已经超出了 32位、64位 Bitmap 结构所能记录的限度，但是对象头信息是与对象自身定义的数据无关的额外存储成本，考虑到虚拟机的空间效率，Mark Word 被设计成一个 非固定的数据结构 以便在极小的空间内存储尽量多的信息，它会根据对象的状态复用自己的存储空间。
HotSpot 虚拟机对象头 Mark Word 表如下��
| 存储内容 |
标志位 |
状态 |
| 对象哈希码、对象分代年龄 |
01 |
未锁定 |
| 指向锁记录的指针 |
00 |
轻量级锁定 |
| 指向重量级锁的指针 |
10 |
膨胀（重量级锁定） |
| 空（不需要记录信息） |
11 |
GC 标记 |
| 偏向线程 ID、偏向时间戳、对象分代年龄 |
01 |
可偏向 |
第二部分：类型指针
概述：即对象指向它的类元数据的指针，虚拟机通过这个指针来确定这个对象是哪个类的实例。
Reminder ��
并不是所有的虚拟机实现都必须在对象数据上保留类型指针，换句话说，查找对象的元数据并不一定要经过对象本身。
数组对象：如果对象是一个 Java 数组，那在对象头中还必须有一块用于记录数组长度的数据，因为虚拟机可以通过普通 Java 对象的元数据信息确定 Java 对象的大小，但是从数组的元数据中却无法确定数组的大小。
3.2.2 - 实例数据（Instance Data）
概述：这部分是对象真正存储的有效信息，也是在程序代码中所定义的各种类型字段内容。无论是从父类继承下来的，还是在子类中定义的，都需要记录起来。
存储顺序：这部分的存储顺序会受到虚拟机 分配策略参数（FieldsAllocationStyle） 和字段在 Java 源码中定义顺序的影响。
HotSpot 虚拟机默认的分配策略为 longs/doubles => ints =>shorts/chars => bytes/booleans => oops（Ordinary Object Pointers），从分配策略中可以看出，相同宽度的字段总是被分配到一起。在满足这个前提条件的情况下，在父类中定义的变量会出现在子类之前。
如果 CompactFields 参数值为 true（默认为 true），那么子类之中较窄的变量也可能会插入到父类变量的空隙之中。
3.2.3 - 对齐填充（Padding）
概述：不是必然存在的，也没有特别的含义，它仅仅起着占位符的作用。
原理：由于 HotSpot VM 的自动内存管理系统要求 对象起始地址必须是 8 字节的整倍数，换句话说，就是对象的大小必须是 8 字节的整倍数。而对象头部分正好是 8 字节的整倍数（ 1 倍或 2 倍），因此，当对象实例数据部分没有对齐时，就需要通过对齐填充来补全。
3.3 - 对象的访问定位
概述：建立对象是为了使用对象，我们的 Java 程序需要通过栈上的 reference 数据来操作堆上的具体对象。由于 reference 类型在 Java 虚拟机规范中只规定了一个指向对象的引用，并没有定义这个引用应该通过何种方式去定位、访问堆中的对象的具体位置，所以 对象访问方式也是取决于虚拟机实现而定的。目前主流的访问方式有两种。
句柄访问：Java 堆中将会划分出一块内存来作为句柄池，reference 中存储的就是对象的句柄地址，而句柄中包含了对象实例数据与类型数据各自的具体地址信息，如下图所示��。
通过句柄访问对象
直接指针：Java 堆对象的布局中必须考虑如何放置访问类型数据的相关信息，而 reference 中存储的直接就是对象地址，如下图所示��。
通过直接指针访问对象
比较：
o 句柄访问：使用句柄访问的最大好处就是 reference 中存储的是 稳定的 句柄地址，在对象被移动（垃圾收集时移动对象是非常普遍的行为）时只会改变句柄中的实例数据指针，而 reference 本身不需要修改。
o 指针访问：使用直接访问最大的好处就是 速度快，它节省了一次指针定位的时间开销，由于对象的访问在 Java 中非常频繁，因此这类开销积少成多后也是一项非常可观的执行成本。
Sun HotSpot 使用的是第二种方式进行对象访问的，但从整个软件开发的范围来看，各种语言和框架使用句柄来访问的情况也十分常见。
4.实战：OutOfMemoryError 异常
在 Java 虚拟机规范的描述中，除了程序计数器外，虚拟机内存的其他几个运行时区域都有发生 OutOfMemory（OOM）异常的可能。
目的：
1.通过代码验证 Java 虚拟机规范中描述的各个运行时区域的存储内容。
2.遇到实际的内存溢出异常时，能根据异常的信息快速判断哪个区域的内存溢出。
3.了解什么样的代码可能会导致这些区域内存溢出，并了解如何处理。
VM Args 设置
Eclipse IDE：Debug Configurations => JavaApplication => YoungGenGC => Arguments 中的 VM arguments 中进行书写（书写参数以 - 开头，以空格分隔）。
控制台：直接跟在 Java 命令之后书写。
本人运行在 Mac 系统下，使用 IDEA 进行配置，步骤如下所示��。
虚拟机启动参数.gif
1.打开 Run Configurations（⌃ + ⌥ + R 选择 0 ）或者（⌘ + ⇧ + A 输入 run 选择 run…）。
2.点击并打开 VM options。
3.写入虚拟机启动参数。
4.Apply 并 Run。
4.1 - Java 堆溢出
· 概述：Java 堆用于存储对象实例，只要不断地创建对象，并且保证 GC Roots 到对象之间有可达路径 来避免垃圾回收机制清除这些对象，那么在对象数量到达最大堆的容量限制后就会产生内存溢出异常。
测试环境：
测试代码：
运行结果：
分析：Java 堆内存的 OOM 异常是时机应用中常见的内存溢出异常情况。当出现 Java 堆内存溢出时，异常堆栈信息 java.lang.OutOfMemoryError 会跟着进一步提示 Javaheap space。
解决方式
1.堆转储快照：要解决这个区域的异常，一般的手段是先通过内存映像分析工具对 Dump 出来的堆转储快找进行分析，重点是确认内存中的对象是否是必要的，也就是要分清楚到底是出现了内存泄露（Memory Leak）还是内存溢出（Memory Overflow）。
2.内存泄露：进一步通过工具查看泄露对象到 CG Roots 的引用链，于是就能找到内存泄露对象是通过怎样的路径与 GC Roots 相关联并导致垃圾收集器无法自动回收它们的。掌握了泄露对象的类型信息以及 GC Roots 引用链的信息，就可以比较准确地定位出泄露代码的位置。
3.内存溢出：如果不存在泄露，换句话说，就是内存中的对象确实都必须还活着，那就应当检查虚拟机的堆参数（-Xmx 与 -Xms），与机器物理内存对象看是否还可以调大，从代码上检查是否存在某些对象生命周期过长、持有状态过长的情况，尝试减少程序运行期的内存消耗。
4.2 - 虚拟机栈和本地方法栈溢出
概述：由于在 HotSpot 虚拟机中并不区分虚拟机栈和本地方法栈，因此，对于 HotSpot 来说，虽然 -Xoos 参数（设置本地方法栈大小）存在，但实际上是无效的，栈容量只由 -Xss 参数设定。关于虚拟机栈和本地方法栈，在 Java 虚拟机规范中描述了两种异常。
| 异常类型 |
发生条件 |
| StackOverflowError |
线程请求的栈深度大于虚拟机所允许的深度时抛出该异常。 |
| OutOfMemoryError |
无法申请到足够的内存时抛出该异常。 |
这里把异常分为两种情况，看似更加严谨，但却存在一些相互重叠的地方：方栈空间无法继续分配时，到底是内存太小，还是已使用的栈空间太大，其本质上只是对同一件事的两种描述而已。
4.2.1 - StackOverflowError
测试环境：在此测试中，将测试范围限制于单线程中操作。
1.使用 -Xss 参数减少栈内存容量，结果抛出 SOF 异常，异常出现时输出的堆栈深度相应缩小。
2.定义了大量的本地变量，增大此方法栈中本地变量表长度。结果抛出 SOF 异常时输出的堆栈深度相应缩小。
测试代码
运行结果
分析：在单个线程下，无论是由于栈帧太大还是虚拟机栈容量太小，当内存无法分配的时候，虚拟机抛出的都是 StackOverflowError 异常。
但是这样产生的内存溢出异常与栈空间是否足够大并不存在任何联系，或者确切地说，在这种情况下，为每个线程的栈分配的内存越大，反而越容易产生内存溢出异常。
理解：操作系统分配给每个进程的内存是有限的，虚拟机提供了参数来控制 Java 堆和方法区的这两部分内存的最大值。剩余的内存 -Xms（最大堆容量） -MaxPermSize（最大方法区容量），程序计数器消耗内存很小，可以忽略不计。
如果虚拟机进程本身耗费的内存不计算在内，剩下的内存就由虚拟机栈和本地方法栈瓜分了。每个线程分配到的栈容量越大，可以建立的线程数量自然越少，建立线程时就越容易把剩下的内存耗尽。
探索：出现 SOF 异常时有错误堆栈可以阅读，相对来说，比较容易找到问题的所在。而且，如果使用虚拟机默认参数，栈深度在大多数情况下（因为每个方法压入栈的帧大小并不是一样的）达到 1000 - 2000 完全没有问题，对于正常的方法调用（包括递归），这个深度应该完全够用了。
但是，如果建立过多线程导致内存溢出，在不能减少线程数或者更换 64 位虚拟机的情况下，就只能通过 减少最大堆 和 减少栈容量 来换更多的线程。
4.2.2 - OutOfMemoryError
测试环境
测试代码：创建线程导致内存溢出异常
运行结果
4.3 - 方法区和运行时常量池溢出
概述：由于运行时常量池是方法区的一部分，因此这两个区域的溢出测试就放在一起进行。
脑补：String.intern() 是一个 Native 方法，它的作用是：如果字符串常量池中已经包含一个等于此 String 对象的字符串，则返回代表池中这个字符串的 String 对象；否则，将此 String 对象包含的字符串添加到常量池中，并且返回此 String 对象的引用。
在 JDK1.6 以及之前的版本中，由于常量池分配在永久代内，我们可以通过 -XX:PermSize 和 -XX:MaxPermSize 限制方法区的大小名，从而间接限制其中常量池的容量。
4.3.1 - OutOfMemoryError
测试环境
测试代码
运行结果
分析：从运行结果中可以看到，运行时常量池溢出，在 OutOfMemoryError 后面跟随的提示信息是 PermGenspace，说明运行时常量池属于方法区（HotSpot 虚拟机中的永久代）的一部分。
4.3.2 - String 常量池测试
使用 JDK1.7 运行这段程序就不会得到相同的结果，while 循环将一直进行下去。关于这个字符串常量池的实现问题，还可以引申出一个更有意思的影响。
测试代码
分析：
o JDK1.6：会得到两个 false，而在 JDK1.7 中运行，会得到一个 true 和一个 false。
产生差异的原因是：是 JDK1.6 中 intern() 方法会把首次遇到的字符串实例复制到永久代中，返回的也是永久代中这个字符串实例的引用，而由 StringBuilder 创建的字符串实例在 Java 堆上，所以必然不是同一个引用，将返回 false
o JDK1.7：intern() 实现不会再复制实例，只是在常量池中记录首次出现的实例引用，因此 intern() 返回的引用和由 StringBuilder 创建的那个字符串实例是同一个。
对 str2 比较返回 false 是因为 java 这个字符串在执行 StringBuilder.toString() 之前已经出现过，字符串常量池中已经有它的引用了，不符合首次出现的原则，而 计算机软件 这个字符串是首次出现的，因此返回 true。
4.3.3 - 测试设计思路
方法区用于存放 Class 的相关信息，如类名、访问修饰符、常量池、字段描述、方法描述等。对于这些区域的测试，基本思路就是运行时产生大量的类去填满方法区，直到溢出。另外的，直接使用 Java SE API 也可以动态产生类（如反射时的 GeneratedConstorAccessor 和动态代理等）。
4.3.4 - 总结
方法区溢出是一种常见的内存溢出异常，一个类要被垃圾收集器回收掉，判定条件是比较苛刻的。
在经常动态生成大量的 Class 的应用中，需要特别注意类的回收情况。这类场景除了上面提到的程序使用了 CGLib 字节码增强和动态语言之外，常见的还有：大量 JSP 或动态产生 JSP 文件的应用（JSP 第一次运行时需要编译为 Java 类）、基于 OSGi 应用（即使是同一个类文件，被不同的加载器加载也会视为不同的类）等。
4.4 - 本机直接内存溢出
概述：DirectMemory 容量可以通过 -XX:MaxDirectMemorySize 指定，如果不指定，则默认与 Java 堆最大值（-Xmx指定）一样，下面的测试代码越过了 DirectByteBuffer 类，直接通过反射获取 Unsafe 实例进行内存分配（Unsafe 类的 getUnsafe() 方法限制了只有引导类加载器才会返回实例，也就是设计者希望只有 rt.jar 中的类才能使用 Unsafe 的功能）。
因为，虽然使用 DirectByteBuffer 分配内存也会抛出内存溢出异常，但它抛出异常时并没有真正向操作系统申请分配内存，而是通过计算得知内存无法分配，于是手动抛出异常，真正申请分配内存的方法是 unfase.allocateMemory()。
测试代码
运行结果
分析：由 DirectMemory 导致的内存溢出，一个明显的特征是在 Heap Dump 文件中不会看到明显的异常，如果发现 OOM 之后 Dump 文件很小，而程序中又直接或间接使用了 NIO，那就可以考虑检查一下是不是这方面的原因。