了解JVM内存结构的目的
在Java的开发过程中，因为有JVM自动内存管理机制，不再需要像在C、C++开发那样手动释放对象的内存空间，不容易出现内存泄漏和内存溢出的问题。但是，正是由于把内存管理的权利交给了JVM，一旦出现内存泄漏和内存溢出方面的问题，如果不了解JVM是如何使用内存的，不了解JVM的内存结构是什么样子的，就很难找到问题的根源，就更难以解决问题。
JVM内存结构简介
在JVM所管理的内存中，大致分为以下几个运行时数据区域：
程序计数器：当前线程所执行的字节码的行号指示器。
虚拟机栈：Java方法执行的内存模型，用于存储局部变量表、操作数栈、动态链接、方法出口等信息。
本地方法栈：本地方法执行的内存模型，和虚拟机栈非常相似，其区别是本地方法栈为JVM使用到的Native方法服务。
堆：用于存储对象实例，是垃圾收集器管理的主要区域。
方法区：用于存储已被JVM加载的类信息、常量、静态变量、即时编译器编译后的代码等数据。
其中，黄色区域的程序计数器、虚拟机栈和本地方法栈是线程私有的，红色区域的堆和方法区是线程共享的。下面我们逐一详细分析各个区域。
程序计数器
程序计数器（Program Counter Register）是一块较小的内存空间，它记录了当前线程所执行的字节码的行号。在JVM的概念模型里，字节码解释器工作时就是通过改变它的值来选取下一条需要执行的字节码指令，分支、循环、跳转、异常处理、线程恢复等基础功能都是依赖它来完成的。
通过线程轮流切换并分配处理器执行时间，实现了JVM的多线程操作。在任何一个确定的时刻，一个处理器（对于多核处理器来说是一个内核）只会执行一条线程中的指令。因此，为了线程切换后能恢复到正确的执行位置，每条线程都需要有一个独立的程序计数器，各条线程之间的计数器互不影响，独立存储，称这类内存区域为“线程私有”的内存。
如果线程正在执行的是一个Java方法，那么它记录的是正在执行的虚拟机字节码指令的地址；如果正在执行的是Natvie方法，它的值就为空（Undefined）。此内存区域是唯一一个在Java虚拟机规范中没有规定任何OutOfMemoryError情况的区域。
虚拟机栈
与程序计数器一样，Java虚拟机栈（Java Virtual Machine Stacks）也是线程私有的，如上图每一个线程都有自己的虚拟机栈，它的生命周期与线程相同，当线程被创建时，虚拟机栈也同时被创建；当线程被销毁时，虚拟机栈也同时被销毁。
在线程内部，每个方法被执行的时候都会同时创建一个栈帧（Stack Frame），用于存储局部变量表、操作数栈、动态链接、方法出口等信息，如上图。每一个方法被调用直至执行完成的过程，就对应着一个栈帧在虚拟机栈中从入栈到出栈的过程。
其中栈帧中的局部变量表存放了编译期可知的各种基本数据类型（boolean、byte、char、short、int、float、long、double）、对象引用（reference类型）和returnAddress类型（指向了一条字节码指令的地址）。
其中64位长度的long和double类型的数据会占用2个局部变量空间（Slot），其余的数据类型只占用1个。局部变量表所需的内存空间在编译期间完成分配，当进入一个方法时，这个方法需要在帧中分配多大的局部变量空间是完全确定的，在方法运行期间不会改变局部变量表的大小。
在Java虚拟机规范中，对这个区域规定了两种异常状况：
如果线程请求的栈深度大于虚拟机所允许的深度，将抛出StackOverflowError异常，让我们写一段代码，使其抛出该异常：
/**
* VM Args: -Xss128k
*/
public class JVMStackSOF {
private int stackLength = 1;
public void stackLeak() {
stackLength++;
stackLeak();
}
public static void main(String[] args) {
JVMStackSOF sof = new JVMStackSOF();
try {
sof.stackLeak();
} catch (Throwable e) {
System.out.println("Stack length:" + sof.stackLength);
throw e;
}
}
}
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
在运行之前，设置JVM的参数为-Xss128k，运行结果如下：
Stack length:1002
Exception in thread "main" java.lang.StackOverflowError
at OneMoreStudy.JVMStackSOF.stackLeak(JVMStackSOF.java:10)
at OneMoreStudy.JVMStackSOF.stackLeak(JVMStackSOF.java:11)
at OneMoreStudy.JVMStackSOF.stackLeak(JVMStackSOF.java:11)
......
1.
2.
3.
4.
5.
6.
栈的深度达到1002时，抛出了StackOverflowError异常。
如果虚拟机栈可以动态扩展，当扩展时无法申请到足够的内存时会抛出OutOfMemoryError异常，还是让我们写一段代码，使其抛出该异常：
/**
* VM Args: -Xss2M
*/
public class JVMStackOOM {
private void dontStop() {
while (true) {
}
}
public void stackLeakByThread() {
while (true) {
Thread t = new Thread(new Runnable() {
public void run() {
dontStop();
}
});
t.start();
}
}
public static void main(String[] args) {
JVMStackOOM oom = new JVMStackOOM();
oom.stackLeakByThread();
}
}
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
这段代码会创建出无限多的线程，因为Java的线程会映射系统的内核线程上，所以会造成CPU占用率100%，系统假死等现象，请谨慎运行。在运行之前，设置JVM的参数为-Xss2M，运行很长一段时间后结果如下：
Exception in thread "main" java.lang.OutMemoryError: unable to create new native thread
at java.lang.Thread.start0(Native Method)
at java.lang.Thread.start(Unknown Source)
at OneMoreStudy.JVMStackOOM.stackLeakByThread(JVMStackOOM.java:18)
at OneMoreStudy.JVMStackOOM.main(JVMStackOOM.java:24)
1.
2.
3.
4.
5.
本地方法栈
本地方法栈（Native Method Stacks）与虚拟机栈所发挥的作用是非常相似的，其区别不过是虚拟机栈为虚拟机执行Java方法（也就是字节码）服务，而本地方法栈则是为虚拟机使用到的Native方法服务。
虚拟机规范中对本地方法栈中的方法使用的语言、使用方式与数据结构并没有强制规定，所以具体的虚拟机可以自由实现它。甚至有的虚拟机（比如Sun HotSpot虚拟机）直接就把本地方法栈和虚拟机栈合二为一。与虚拟机栈一样，本地方法栈区域也会抛出StackOverflowError和OutOfMemoryError异常。
堆
Java堆（Java Heap）是Java虚拟机所管理的内存中最大的一块。它是被所有线程共享的一块内存区域，在虚拟机启动时创建。它就是用来存放对象实例的，几乎所有的对象实例都在这里分配内存。
堆是垃圾收集器管理的主要区域，如果从内存回收的角度看，由于现在收集器基本都是采用的分代收集算法，所以Java堆中还可以细分为：新生代和老年代；再细致一点的有Eden空间、From Survivor空间、To Survivor空间等。从内存分配的角度看，线程共享的堆中又可能划分出多个线程私有的分配缓存区（Thread Local Allocation Buffer，TLAB）。
根据Java虚拟机规范的规定，Java堆可以处于物理上不连续的内存空间中，只要逻辑上是连续的即可，就像我们的磁盘空间一样。在实现时，既可以实现成固定大小的，也可以是可扩展的，不过当前主流的虚拟机都是按照可扩展来实现的（通过-Xmx和-Xms控制）。
如果在堆中没有内存完成实例分配，并且堆也无法再扩展时，将会抛出OutOfMemoryError异常，再让我们写一段代码，使其抛出该异常：
/*
* VM Args: -Xms20M -Xmx20M
*/
public class HeapOOM {
static class OOMObject{
}
public static void main(String[] args){
List<OOMObject> list = new ArrayList<OOMObject>();
while(true){
//把对象实例放入列表中，
//使其一直被引用，不会被垃圾回收
list.add(new OOMObject());
}
}
}
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
在运行之前，设置JVM的参数为-Xms20M -Xmx20M，运行结果如下：
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
at java.util.Arrays.copyOf(Unknown Source)
at java.util.Arrays.copyOf(Unknown Source)
at java.util.ArrayList.grow(Unknown Source)
at java.util.ArrayList.ensureExplicitCapacity(Unknown Source)
at java.util.ArrayList.ensureCapacityInternal(Unknown Source)
at java.util.ArrayList.add(Unknown Source)
at OneMoreStudy.HeapOOM.main(HeapOOM.java:18)
1.
2.
3.
4.
5.
6.
7.
8.
9.
方法区
方法区（Method Area）与Java堆一样，是各个线程共享的内存区域，它用于存储已被JVM加载的类信息、常量、静态变量、即时编译器编译后的代码等数据。
对于习惯在HotSpot虚拟机上开发和部署程序的开发者来说，很多人愿意把方法区称为“永久代”（Permanent Generation），本质上两者并不等价，仅仅是因为HotSpot虚拟机的设计团队选择把GC分代收集扩展至方法区，或者说使用永久代来实现方法区而已。在JDK7的HotSpot中，已经把原本在永久代的字符串常量池移出，在JDK8的HotSpot中，已经没有永久代的存在了，而是采用了新的内存空间：元空间（Metaspace）。
JVM规范对这个区域的限制非常宽松，除了和Java堆一样不需要连续的内存和可以选择固定大小或者可扩展外，还可以选择不实现垃圾收集。相对而言，垃圾收集行为在这个区域是比较少出现的，但并不是数据进入了方法区就被一直存放。这个区域的内存回收目标主要是针对常量池的回收和对类型的卸载，一般来说这个区域的回收“成绩”比较难以令人满意，尤其是类型的卸载，条件相当苛刻，但是这部分区域的回收确实是有必要的。
根据Java虚拟机规范的规定，当方法区无法满足内存分配需求时，将抛出OutOfMemoryError异常。再让我们写一段代码，尝试使其抛出该异常：
/*
* VM Args: -XX:PermSize=2M -XX:MaxPermSize=2M
*/
public class RuntimeConstantPoolOOM {
public static void main(String[] args) {
List<String> list = new ArrayList<String>();
for (int i = 0; i < 100000; i++) {
System.out.println(i);
//将i转化为字符串，
//并且调用intern()，把字符串放在运行时常量池
list.add(String.valueOf(i).intern());
}
}
}
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
在运行之前，设置JVM的参数为-XX:PermSize=2M -XX:MaxPermSize=2M。
在JDK6中运行抛出了老年代的OutOfMemoryError异常，结果如下：
......
35813
35814
Exception in thread "main" java.lang.OutOfMemoryError: PermGen space
at java.lang.String.intern(Native Method)
at OneMoreStudy.RuntimeConstantPoolOOM.main(RuntimeConstantPoolOOM.java:12)
1.
2.
3.
4.
5.
6.
在JDK7中运行，循环全部完毕后，也没有抛出任何异常，结果如下：
......
99996
99997
99998
99999
1.
2.
3.
4.
5.
同一段代码，在不同版本JDK中的运行结果为什么是不同的呢？这是因为：在JDK6中，字符串常量池还在永久代中，而在JDK7中，已经把原本在永久代的字符串常量池移出了。
再再让我们写一段代码，尝试使其抛出该异常：
/*
* VM Args: -XX:PermSize=2M -XX:MaxPermSize=2M
*/
public class MethodAreaOOM {
static class OOMObject {
}
public static void main(String[] args) {
for (int i = 0; i < 300; i++) {
System.out.println(i);
createNewClass();
}
}
private static void createNewClass() {
//这里使用了CGLIB，动态创建类，载入方法区
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();
}
}
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
在运行之前，设置JVM的参数为-XX:PermSize=2M -XX:MaxPermSize=2M。
在JDK6中运行抛出了老年代的OutOfMemoryError异常，，结果如下：
......
Caused by: java.lang.OutOfMemoryError: PermGen space
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClassCond(Unknown Source)
at java.lang.ClassLoader.defineClass(Unknown Source)
... 12 more
1.
2.
3.
4.
5.
6.
在JDK7中运行也抛出了OutOfMemoryError异常，结果如下：
Exception in thread "main"
Exception: java.lang.OutOfMemoryError thrown from the UncaughtExceptionHandler in thread "main"
1.
2.
在JDK8中运行，循环全部完毕后，也没有抛出任何异常，结果如下：
......
298
299
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option PermSize=2M; support was removed in 8.0
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=2M; support was removed in 8.0
1.
2.
3.
4.
5.
同一段代码，在不同版本JDK中的运行结果为什么是不同的呢？这是因为：在JDK6和JDK7中，永久代仍然存在，而在JDK8中，已经没有永久代的存在了，而是采用了新的内存空间：元空间，并且JVM参数PermSize和MaxPermSize也被移出了。
总结
在JVM所管理的内存中，大致分为：程序计数器、虚拟机栈、本地方法栈、堆和方法区。程序计数器是当前线程所执行的字节码的行号指示器。虚拟机栈是Java方法执行的内存模型，用于存储局部变量表、操作数栈、动态链接、方法出口等信息。本地方法栈是本地方法执行的内存模型，和虚拟机栈非常相似，其区别是本地方法栈为JVM使用到的Native方法服务。堆是用于存储对象实例的，是垃圾收集器管理的主要区域。方法区用于存储已被JVM加载的类信息、常量、静态变量、即时编译器编译后的代码等数据。
-----------------------------------
©著作权归作者所有：来自51CTO博客作者万猫学社的原创作品，请联系作者获取转载授权，否则将追究法律责任
Java虚拟机内存结构及编码实战
https://blog.51cto.com/u_6740480/5138577
