Java内存区域与内存溢出异常
1. 运行时数据区域
《Java虚拟机规范（Java SE 7）》规定，Java虚拟机所管理的内存包括以下几个运行时数据区域。
JDK 1.8之前的运行时数据区域：
JDK 1.8之后的运行时数据区域：
- 方法区（Method Area）
- 堆（Heap）
- 虚拟机栈（VM Stack）
- 本地方法栈（Native Method Stack）
- 程序计数器（Program Counter Register）
- 线程共享的数据区：方法区、堆、直接内存
- 线程私有的数据区：虚拟机栈、本地方法栈、程序计数器
直接内存是非运行时数据区的一部分。
下面是上图中的新生代、老年代英文名称：
- 新生代(Young Generation)
- 老年代(Old Generation)
1.1 程序计数器
如果线程正在执行一个Java方法，程序计数器记录的是正在执行的虚拟机字节码指令的地址；如果正在执行Native方法，程序计数器的值为空（Undefined）。
程序计数器是唯一一个不会出现 OutOfMemoryError 的内存区域，是在Java虚拟机规范中没有规定任何OutOfMemoryError情况的区域。
1.2 虚拟机栈
虚拟机栈描述的是Java方法执行的内存模型。
Java每个方法在执行的同时都会创建一个栈帧（Stack Frame），用于存储：局部变量表、操作数栈、动态链接、方法出口等信息。
每一个方法从调用直到执行完成的过程，就对应一个栈帧在虚拟机栈中入栈到出栈的过程。
Java 方法有两种返回方式：不管哪种返回方式都会导致栈帧被弹出。
- return 语句。
- 抛出异常。
局部变量表存放编译期可知的各种基本数据类型（int、short等）、对象引用、returnAddress类型（指向一条字节码指令的地址）。
局部变量表所需的内存空间在编译期间完成分配，当进入一个方法时，这个方法需要在帧中分配多大的局部变量空间是完全确定的，在方法运行期间不会改变局部变量表的大小。
异常：
- 如果线程请求的栈深度大于虚拟机栈所允许的深度，抛出StackOverflowError异常。
- 大部分的JVM允许虚拟机栈动态扩展，如果扩展时无法申请到足够的内存，抛出OutOfMemoryError异常。
1.3 本地方法栈
本地方法栈为虚拟机使用到的Native方法服务。
本地方法被执行的时候，在本地方法栈也会创建一个栈帧，用于存放该本地方法的局部变量表、操作数栈、动态链接、出口信息。
HotSpot虚拟机直接将本地方法栈和虚拟机栈合二为一。
与虚拟机栈一样，本地方法栈会抛StackOverflowError、OutOfMemoryError异常。
1.4 堆
此内存区域的唯一目的就是存放对象实例。所有的对象实例和数组都要在堆上分配内存。栈上分配、标量优化技术导致所有的对象都不是那么“绝对”地分配在堆上。
从内存分配的角度来看，线程共享的Java堆中可能划分出多个线程私有的分配缓冲区（Thread Local Allocation Buffer，TLAB）。
由于现在收集器基本都采用分代垃圾收集算法，所以 Java 堆还可以细分为：新生代和老年代。再细致一点有：Eden 空间、From Survivor、To Survivor 空间等。
在堆中没有内存来进行实例分配，并且堆无法再扩展时，抛出OutOfMemoryError异常。
1.5 方法区
存储已被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码等数据。
HotSpot虚拟机为了使垃圾收集器可以像管理Java堆一样管理方法区内存，省去专门为方法区编写内存管理代码的工作，使用永久代实现方法区，所以方法区也被称为永久代（Permanent Generation）。
对于其他虚拟机，不存在永久代的概念。也就是说虚拟机规范中有方法区，没有永久代。
JDK1.7的HotSpot VM已经把原本放在永久代的字符串常量池移出，但是字符串常量池仍是方法区的一部分（虚拟机规范）。JDK1.7将JDK 6中永久代部分数据移动到其他空间包括：符号引用转移到native heap；字面量转移到Java堆；类的静态变量转移到Java堆。
HotSpot虚拟机规划，逐步放弃永久代，改用Native Memory实现方法区，在Java 8中使用元空间（Metaspace）实现方法区。
方法区的内存回收目标主要是对常量池的回收、对类型的卸载。
当方法区无法满足内存分配需求时，抛出OutOfMemoryError异常。
1.5.1 方法区与永久代的关系
方法区是 Java 虚拟机规范中的定义，是一种规范，而永久代是 HotSpot 的概念，是方法区的一种具体实现。
一个是标准一个是实现，其他的虚拟机实现并没有永久代这一说法。
另外在Java 8中，HotSpot使用元空间实现方法区。元空间使用的是直接内存。
永久代、元空间是HotSpot虚拟机对方法区的两种具体实现。
元空间虚拟机参数配置：
-XX:MetaspaceSize=N //设置 Metaspace 的初始（和最小大小）。如果未指定此标志，则 Metaspace 将根据运行时的应用程序需求动态地重新调整大小。默认值为 unlimited，这意味着它只受系统内存的限制。
-XX:MaxMetaspaceSize=N //设置 Metaspace 的最大大小。
为什么要将永久代 (PermGen) 替换为元空间 (MetaSpace) ：
-
整个永久代有一个 JVM 本身设置固定大小上限，无法进行调整，而元空间使用的是直接内存，受本机可用内存的限制，虽然元空间仍旧可能溢出，但是比原来出现的几率会更小。元空间里面存放的是类的元数据，这样加载多少类的元数据就不由
MaxPermSize（永久代控制参数） 控制了，而由系统的实际可用空间来控制，这样能加载的类就更多了。元空间溢出时会得到如下错误： java.lang.OutOfMemoryError: MetaSpace
在 JDK8，合并 HotSpot 和 JRockit 的代码时，JRockit 从来没有一个叫永久代的东西，合并之后就没有必要额外的设置这么一个永久代的地方了。
1.5.2 运行时常量池
运行时常量池（Runtime Constant Pool）是方法区的一部分。
Class文件常量池（Constant Pool Table，用于存放编译期生成的各种字面量和符号引用，是静态常量池，不是本节中说的运行时常量池），在类加载后进入方法区的运行时常量池（Runtime Constant Pool）。
Java虚拟机规范未对运行时常量池做任何细节的要求，不同的虚拟机提供商可以按照自己的需求来实现这个内存区域。
运行时常量池具备动态性，既包含Class文件常量池中的内容，也包含运行期间产生的新常量（如String的intern()）。
运行时常量池无法再申请到内存时，抛出OutOfMemoryError异常。
字符串内存分配：
- 在定义字符串变量时赋值，如果表达式右边只有字符串常量，就把变量存放在常量池里。
- new出来的字符串存放在堆里。
- 对字符串进行拼接操作，也就是做"+"运算的时候：
- 表达式右边是纯字符串常量，存放在常量池里。
- 表达式右边存在字符串引用，存放在堆里面。
- String.intern()：如果字符串常量池中已经包含一个等于此String对象的字符串，则返回代表池中这个字符串的String对象；否则，将此String对象包含的字符串添加到常量池，并且返回此String对象的引用。
在HotSpot VM JDK1.7中，字符串创建在堆中，不会再复制字符串实例到常量池中，常量池中只保存对堆中字符串实例的引用。
上面牵涉的情况很多，只要记住：JDK 1.7之后，字符串常量保存在堆中，常量池只保存对堆中字符串实例的引用，new String("abcdefg")时会创建两个字符串实例对象（见《013.Java几种常量池的区分.md》中4.示例）
String str1 = "aaa";
String str2 = "bbb";
String str3 = "aaabbb";
String str4 = str1 + str2;
String str5 = "aaa" + "bbb";
System.out.println(str1 == new String("aaa"));// false
System.out.println(str3 == str4);// false
System.out.println(str3 == str4.intern());// true
System.out.println(str3 == str5);// true
1.6 直接内存
直接内存也就是堆外内存。
-
对内内存
堆内内存 = 新生代+老年代+持久代
-
堆外内存
堆外内存就是把内存对象分配在Java虚拟机的堆以外的内存，这些内存直接受操作系统管理（而不是虚拟机）。
我们经常用java.nio.DirectByteBuffer对象进行堆外内存的管理和使用，它会在对象创建时就分配堆外内存。
不是虚拟机运行时数据区的一部分，也不是Java虚拟机规范中定义的内存区域。但是也可能抛出OutOfMemoryError异常。
NIO引入基于通道（Channel）和缓冲区（Buffer）的I/O方式，可以使用Native函数库直接分配堆外内存，然后通过在Java堆中的DirectByteBuffer对象作为这块内存的引用进行操作，在某些场景中避免了在Java堆和Native堆中来回复制数据，显著提高性能。
本机直接内存的分配不会受到Java堆大小的限制。但是，既然是内存，肯定还是会受到本机总内存大小、处理器寻址空间的限制。
在配置虚拟机内存参数时，如果忽略直接内存，可能会使各个内存区域总和大于物理内存限制（包括物理的和操作系统级的限制），从而导致动态扩展时出现OutOfMemoryError异常。
2. OutOfMemoryError异常实战
OutOfMemoryError简称OOM。
操作系统分配给每个进程的内存是有限制的，如32位Windows限制为2G。在这种情况下，Java运行时各数据区域占用的内存总和最大为2G。
- 内存溢出（Out of memory）：程序在申请内存时，没有足够的内存空间供其使用。
- 内存泄露（Memory leak）：程序在申请内存后，无法释放已申请的内存空间。一次内存泄露危害可以忽略，但内存泄露堆积后果很严重，无论多少内存，迟早会被占光。
2.1 Java堆溢出
https://github.com/iMustang/l-jdk/raw/master/src/main/java/jvm/HeapOOM.java
OutOfMemoryError：Java heap space
-Xms20m -Xmx20m -XX:+HeapDumpOnOutOfMemoryError
public class HeapOOM {
static class OOMObject {
}
public static void main(String[] args) {
List list = new ArrayList<>();
while (true) {
list.add(new OOMObject());
}
}
}
运行结果：
输出的堆转储快照为：https://gitee.com/xMustang/notes/raw/master/.attachment/java_pid2020.hprof
处理思路：
- 如果是内存泄露，查看对象到GC Roots的引用链，找到泄露对象通过怎样的路径与GC Roots相关联导致垃圾收集器无法自动回收它们，即GC Roots引用链的信息，可以比较准确定位出泄露代码的位置。
- 如果不存在内存泄露，就是内存中的对象确实还必须存活着，是否需要加大虚拟机的堆参数。从代码上检查是否存在某些对象生命周期过长、持有状态时间过长的情况，尝试减小程序运行期的内存消耗。
2.2 虚拟机栈与本地方法栈溢出
https://github.com/iMustang/l-jdk/raw/master/src/main/java/jvm/JavaVMStackSOF.java
在HotSpot VM中不区分虚拟机栈和本地方法栈。
对于HotSpot VM来说，-Xss（设置本地方法栈大小）是无效的。
-Xss128k
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;
}
}
}
运行结果：
建立过多线程导致的内存溢出，在不能减少线程数或者更换64位虚拟机的情况下，可以通过减小最大堆来换取更多的线程。
https://github.com/iMustang/l-jdk/raw/master/src/main/java/jvm/JavaVMStackOOM.java
-Xss2M
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) {
JavaVMStackOOM oom = new JavaVMStackOOM();
oom.stackLeakByThread();
}
}
Windows上，Java线程映射到操作系统的内核线程上，因此这段代码可能导致操作系统假死。
Exception in thread "main" java.lang.OutOfMemoryError：unable to
create new native thread
2.3 方法区和运行时常量池溢出
-
在JDK1.6及之前构造大量的字符串导致永久代溢出
https://github.com/iMustang/l-jdk/raw/master/src/main/java/jvm/RuntimeConstantPoolOOM.java
OutOfMemoryError：PerGen space 在jdk1.6及之前，HotSpot用永久代实现方法区。在JDK1.7逐步去永久代。 以下代码需要在JDK1.6测试 VM参数： -XX:PermSize=10M -XX:MaxPermSize=10M public class RuntimeConstantPoolOOM { public static void main(String[] args) { Listlist = new ArrayList<>(); int i = 0; while (true) { list.add(String.valueOf(i++).intern()); } } } 运行结果：
方法区和运行时常量池溢出 -
使用CGLib动态产生类使方法区溢出
-XX:PermSize=10M -XX:MaxPermSize=10M public class JavaMethodAreaOOM{ public static void main(String[] args){ while(true){ Enhancer enhancer = new Enhancer(); enhancer.setSuperclass(OOMObject.class); enhancer.setUseCache(false); enhancer.setCallback(new MethodInterceptor(){ public Object intercept(Object obj, Method method, Object[] args, MethodProxy proxy) throws Throwable{ return proxy.invokeSuper(obj,args); } }); enhancer.create(); } } static class OOMObject{ } }运行结果： Caused by: java.lang.OutOfMemoryError: PermGen space常见场景：
- 使用反射，动态代理、CGLib等动态生成类时。
- 在大量JSP或动态产生JSP文件的应用（JSP第一次运行时需要编译为Java类）
- 基于OSGi的应用（同一个类被不同的加载器加载也会视为不同的类）。
以下代码在JDK1.6、JDK1.7结果不同：
String str1 = new StringBuilder("计算机").append("软件").toString();
// JDK1.6 false
// JDK1.7 true
System.out.println(str1.intern() == str1);
String str2 = new StringBuilder("ja").append("va").toString();
// JDK1.6 false
// JDK1.7 false
System.out.println(str2.intern() == str2);
在下面分析具体原因前，先看一下StringBuilder的toString()源码
public String toString() {
// Create a copy, don't share the array
return new String(value, 0, count);
}
JDK1.6中，StringBuilder.toString()创建的字符串实例在Java堆上，intern()将首次出现的字符串实例复制到永久代中，返回也是永久代这个字符串实例的引用，所以与StringBuilder.toString()创建的字符串实例必然不是同一个引用，将返回false。
JDK1.7中，StringBuilder.toString()创建的字符串实例在Java堆上，intern()不会再将首次出现的字符串实例复制字符串常量池，只是在常量池中记录首次出现的实例的引用。因此intern()返回的引用和StringBuilder.toString()创建的字符串实例是同一个。
上面代码在JDK1.7第二个结果为false是因为java这个字符串在运行new StringBuilder("ja").append("va").toString();代码之前早就存在JVM中了，不是首次出现。
2.4 本机直接内存溢出
https://github.com/iMustang/l-jdk/raw/master/src/main/java/jvm/DirectMemoryOOM.java
OutOfMemoryError
DirectMemory容量可通过-XX:MaxDirectMemorySize指定，如果不指定，默认与Java堆最大值（-Xmx）一样。
-Xmx20M -XX:MaxDirectMemorySize=10M
public class DirectMemoryOOM {
private static final int _1MB = 1024 * 1024;
public static void main(String[] args) throws IllegalAccessException {
Field unsafeField = Unsafe.class.getDeclaredFields()[0];
unsafeField.setAccessible(true);
Unsafe unsafe = (Unsafe) unsafeField.get(null);
while (true) {
unsafe.allocateMemory(_1MB);
}
}
}
运行结果：
由DirectMemory导致的内存溢出，明显的特征是Heap Dump文件中不会看到明显的异常。
如果OOM后发现Dump文件很小，又直接或间接使用了NIO，考虑是不是本机直接内存溢出。