Java内存区域与内存溢出异常（jdk 6,7,8）
运行时数据区域
Java虚拟机在执行Java程序的过程中会把它关联的内存划分为若干个不同的数据区域。这些区域都有各自的用途，以及创建和销毁的时间，有的区域随着虚拟机进程的启动而存在，有些区域则依赖用户线程的启动和结束而建立和销毁。根据《Java虚拟机规范（Java SE 7版）》的规定，Java虚拟机所管理的内存将会包括以下几个运行时的数据区域。如图所示：
1.1程序计数器
程序计数器是一块较小的内存空间，它可以看成是当前线程所执行的字节码的行号指示器。程序计数器记录线程当前要执行的下一条字节码指令的地址。由于Java是多线程的，所以为了多线程之间的切换与恢复，每一个线程都需要单独的程序计数器，各线程之间互不影响。这类内存区域被称为“线程私有”的内存区域。 由于程序计数器只存储一个字节码指令地址，故此内存区域没有规定任何OutOfMemoryError情况。
1.2虚拟机栈
Java虚拟机栈也是
线程私有
的，它的生命周期与线程相同。虚拟机栈描述的是Java方法执行的内存模型：每个方法在执行时都会创建一个栈帧（Stack Frame）用于存储信息如下：
- 局部变量表
- 返回值
- 操作数栈
- 当前方法所在的类的运行时常量池引用
每一个方法从调用直至执行完成的过程，就对应着一个栈帧在虚拟机中入栈到出栈的过程。我们平时所说的“局部变量存储在栈中”就是指方法中的局部变量存储在代表该方法的栈帧的局部变量表中。而方法的执行正是从局部变量表中获取数据，放至操作数栈上，然后在操作数栈上进行运算，再将运算结果放入局部变量表中，最后将操作数栈顶的数据返回给方法的调用者的过程。
虚拟机栈可能出现两种异常：
由线程请求的栈深度过大超出虚拟机所允许的深度而引起的StackOverflowError异常；
以及由虚拟机栈无法提供足够的内存而引起的OutOfMemoryError异常。
局部变量存放数据如下：
- boolean
- byte
- char
- long
- short
- int
- float
- double
- reference（对象引用）
- returnAddress（指向了一条字节码指令的地址）
在局部变量表里，除了long和double，所有类型都是占了一个槽位，它们占了2个连续槽位，因为他们是64位宽度。
1.3本地方法栈
本地方法栈与虚拟机栈类似，他们的区别在于：本地方法栈用于执行本地方法（Native方法）；虚拟机栈用于执行普通的Java方法。在HotSpot虚拟机中，就将本地方法栈与虚拟机栈做在了一起。 本地方法栈可能抛出的异常同虚拟机栈一样。
1.4Java堆
Java堆是被所有
线程共享
的一块内存区域，此内存区域的唯一目的就是存放对象实例。
为了支持垃圾收集，堆被分为三个部分：
- 年轻代
- 常常又被划分为Eden区和Survivor（From Survivor To Survivor）区
- 老年代
- 永久代 （jdk 8已移除永久代，后续会详细讲解）
1.5方法区
方法区与Java堆一样，是各个
线程共享的内存区域，它用于存储已被虚拟机加载的类信息、常量、静态变量、及时编译器编译后的代码等数据。这也是开发者常说的永久代。具体存放信息如下：
- 类加载器引用
- 运行时常量池
- 所有常量
- 字段引用
- 方法引用
- 属性
- 字段数据
- 每个方法
- 名字
- 类型
- 修饰符
- 属性
-
- 方法数据
- 每个方法
- 名字
- 返回类型
- 参数类型(按顺序)
- 修饰符
- 属性
-
- 方法代码
- 每个方法
- 字节码
- 操作数栈大小
- 局部变量大小
- 局部变量表
- 异常表
- 每个异常处理
- 开始位置
- 结束位置
- 代码处理在程序计数器中的偏移地址
- 被捕获的异常类的常量池索引
1.6直接内存
JDK1.4中引用了NIO，并引用了Channel与Buffer，可以使用Native函数库直接分配堆外内存，并通过一个存储在Java堆里面的DirectByteBuffer对象作为这块内存的引用进行操作。
Java8以及之后的版本中方法区已经从原来的JVM运行时数据区中被开辟到了一个称作元空间的直接内存区域。
JDK 6,7,8 方法区的区别
在Java7之前，HotSpot虚拟机中将GC分代收集扩展到了方法区，使用永久代来实现了方法区。这个区域的内存回收目标主要是针对常量池的回收和对类型的卸载，但是在之后的HotSpot虚拟机实现中，逐渐开始将方法区从永久代移除。Java7中已经将运行时常量池从永久代移除，在Java堆（Heap）中开辟了一块区域存放运行时常量池。而在Java8中，已经彻底没有了永久代，将方法区直接放在一个与堆不相连的本地内存区域，这个区域叫元空间。
实战OutOfMemoryError异常
2.1Java堆溢出
Java堆用来存储对象实例，只要不断的创建对象，并且保证GC Roots到对象之间有可达路径来避免垃圾回收机制清除这些对象，那么在对象到达最大堆的容量限制后就会产生内存溢出异常。
java.lang.OutOfMemoryError:Java heap space 示例：
设置
-Xms20m -Xmx20m
package com.tlk.jvm;
import java.util.ArrayList;
import java.util.List;
/**
* 一直创建对象，堆内存溢出
* VM Args: -Xms20m -Xmx20m
* Created by tanlk on 2017/8/30 21:16.
*/
public class HeapOOM {
static class OOMObject{
}
public static void main(String[] args){
List
2.2虚拟机栈和本地方法栈溢出
HotSpot 虚拟机中并不区分虚拟机栈和本地方法栈。栈容量只由-Xss参数设定。
如果线程请求的栈深度大于虚拟机所允许的最大深度，将抛出StackOverflowError异常。
如果虚拟机在扩展栈时，无法申请到足够的内存空间，则将抛出OutOfMemoryError异常。
（本地测试了一个OOM，但没有出现）
package com.tlk.jvm;
/**
* 栈溢出
* VM Args:-Xss128k
*/
public class StackErrorMock {
private static int index = 1;
public void call(){
index++;
call();
}
public static void main(String[] args) {
StackErrorMock mock = new StackErrorMock();
try {
mock.call();
}catch (Throwable e){
System.out.println("Stack deep : "+index);
e.printStackTrace();
}
}
}
当栈调用深度大于JVM所允许的范围，会抛出StackOverflowError的错误，不过这个深度范围不是一个恒定的值
2.3方法区和运行时常量池溢出
package com.tlk.jvm;
import net.sf.cglib.proxy.Enhancer;
import net.sf.cglib.proxy.MethodInterceptor;
import net.sf.cglib.proxy.MethodProxy;
import java.lang.reflect.Method;
/**
* jdk 1.6
* VM Args: -XX:PermSize=10M -XX:MaxPermSize=10M
* Created by tanlk on 2017/9/1 15:48.
*/
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() {
@Override
public Object intercept(Object obj, Method method, Object[] args, MethodProxy proxy) throws Throwable {
return proxy.invokeSuper(obj, args);
}
});
enhancer.create();
}
}
static class OOMObject{}
}
其实，移除永久代的工作从JDK1.7就开始了。JDK1.7中，存储在永久代的部分数据就已经转移到了Java Heap或者是 Native Heap。但永久代仍存在于JDK1.7中，并没完全移除，譬如符号引用(Symbols)转移到了native heap；字面量(interned strings)转移到了java heap；类的静态变量(class statics)转移到了java heap。我们可以通过一段程序来比较 JDK 1.6 与 JDK 1.7及 JDK 1.8 的区别，以字符串常量为例：
这段程序以2的指数级不断的生成新的字符串，这样可以比较快速的消耗内存。我们通过 JDK 1.6、JDK 1.7 和 JDK 1.8 分别运行：
package com.tlk.jvm;
import java.util.ArrayList;
import java.util.List;
/**
*
* VM Args: -Xmx200M -XX:PermSize=10M -XX:MaxPermSize=10M
* Created by tanlk on 2017/9/1 21:48.
*/
public class StringOomMock {
static String base = "string";
public static void main(String[] args) {
List list = new ArrayList();
for (int i=0;i< Integer.MAX_VALUE;i++){
String str = base + base;
base = str;
list.add(str.intern());
}
}
}
JDK1.6运行结果：
JDK1.7运行结果：
JDK1.8运行结果：
从上述结果可以看出，JDK 1.6下，会出现“PermGen Space”的内存溢出，而在 JDK 1.7和 JDK 1.8 中，会出现堆内存溢出，并且 JDK 1.8中 PermSize 和 MaxPermGen 已经无效。
另外JDK8 设置了-XX:MaxMetaspaceSize=10m，结果也是报Java heap space
并且笔者用jconsole监控发现堆内存使用非常大。
因此，可以大致验证 JDK 1.7 和 1.8 将字符串常量由
永久代转移到堆中
，并且 JDK 1.8 中已经不存在永久代的结论。
上诉测试代码简单解释：
运行时常量池在
JDK1.6及之前版本的JVM中是方法区的一部分
，而在HotSpot虚拟机中方法区放在了”永久代(Permanent Generation)”。所以运行时常量池也是在永久代的。
但是
JDK1.7及之后版本的JVM已经将运行时常量池从方法区中移了出来，在Java 堆（Heap）中开辟了一块区域存放运行时常量池
。
String.intern()是一个Native方法，它的作用是：如果运行时常量池中已经包含一个等于此String对象内容的字符串，则返回常量池中该字符串的引用；如果没有，则在常量池中创建与此String内容相同的字符串，并返回常量池中创建的字符串的引用。
JDK1.7改变
当常量池中没有该字符串时，JDK7的intern（）方法的实现不再是在常量池中创建与此String内容相同的字符串，而改为
在常量池中记录
java
Heap中首次出现的该字符串的引用，并返回该引用
。
Metaspace（元空间）
3.1元空间是什么？
元空间的本质和永久代类似，都是对JVM规范中方法区的实现。不过元空间与永久代之间最大的区别在于：元空间并不在虚拟机中，而是
使用本地内存
。因此，默认情况下，元空间的大小仅受本地内存限制，但可以通过以下参数来指定元空间的大小：
-XX:MetaspaceSize，初始空间大小，达到该值就会触发垃圾收集进行类型卸载，同时GC会对该值进行调整：如果释放了大量的空间，就适当降低该值；如果释放了很少的空间，那么在不超过MaxMetaspaceSize时，适当提高该值。
-XX:MaxMetaspaceSize，最大空间，默认是没有限制的。
除了上面两个指定大小的选项以外，还有两个与 GC 相关的属性：
-XX:MinMetaspaceFreeRatio，在GC之后，最小的Metaspace剩余空间容量的百分比，减少为分配空间所导致的垃圾收集
-XX:MaxMetaspaceFreeRatio，在GC之后，最大的Metaspace剩余空间容量的百分比，减少为释放空间所导致的垃圾收集
3.2元空间内存溢出的例子
package com.tlk.jvm;
import net.sf.cglib.proxy.Enhancer;
import net.sf.cglib.proxy.MethodInterceptor;
import net.sf.cglib.proxy.MethodProxy;
import java.lang.reflect.Method;
/**
* -XX:MaxMetaspaceSize=10m
* jdk1.8没有永久代了，取而代之的是Metaspace
* Created by tanlk on 2017/9/4 20:48.
*/
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() {
@Override
public Object intercept(Object obj, Method method, Object[] args, MethodProxy proxy) throws Throwable {
return proxy.invokeSuper(obj, args);
}
});
enhancer.create();
}
}
static class OOMObject{}
}
java.lang.OutOfMemoryError: Metaspace
3.3元空间总结：
通过上面分析，大家应该大致了解了 JVM 的内存划分，也清楚了 JDK 8 中永久代向元空间的转换。不过大家应该都有一个疑问，就是为什么要做这个转换？所以，最后给大家总结以下几点原因：
1、字符串存在永久代中，容易出现性能问题和内存溢出。
2、类及方法的信息等比较难确定其大小，因此对于永久代的大小指定比较困难，太小容易出现永久代溢出，太大则容易导致老年代溢出。
3、永久代会为 GC 带来不必要的复杂度，并且回收效率偏低。
4、Oracle 可能会将HotSpot 与 JRockit 合二为一。
相关文章：
Java永久代去哪了：
http://www.infoq.com/cn/articles/Java-PERMGEN-Removed?utm_campaign=infoq_content&
JVM内部原理：
http://ifeve.com/jvm-internals/
了解String intern()：
http://blog.csdn.net/seu_calvin/article/details/52291082