一、前言
java是一门跨硬件平台的面向对象高级编程语言，java程序运行在java虚拟机上（JVM），由JVM管理内存，这点是和C++最大区别；虽然内存有JVM管理，但是我们也必须要理解JVM是如何管理内存的；JVM不是只有一种，当前存在的虚拟机可能达几十款，但是一个符合规范的虚拟机设计是必须遵循《java 虚拟机规范》的，本文是基于HotSpot虚拟机描述，对于和其它虚拟机有区别会提到；本文主要描述JVM中内存是如何分布、java程序的对象是如何存储访问、各个内存区域可能出现的异常。
二、JVM中内存分布(区域)
JVM在执行java程序的时会把内存分为多个不同的数据区域进行管理，这些区域有着不一样的作用、创建和销毁时间，有的区域是在JVM进程启动时分配，有的区域则与用户线程（程序本身的线程）的生命周期相关；按照JVM规范，JVM管理的内存区域分为以下几个运行时数据区域：
1、虚拟机栈
这块内存区域是线程私有的，随线程启动而创建、线程销毁而销毁；虚拟机栈描述的java方法执行的内存模型：每个方法在执行开始会创建一个栈帧(Stack Frame)，用于存储局部变量表、操作数栈，动态链接、方法出口等。每个方法的调用执行和返回结束，都对应有一个栈帧在虚拟机栈入栈和出栈的过程。
局部变量表顾名思义是存储局部变量的内存区域：存放编译器期可知的基本数据类型（8种java基本数据类型）、引用类型、返回地址；其中占64位的long和double类型数据会占用2个局部变量空间，其它数据类型只占用1个；由于类型大小确定、变量数量编译期可知，所以局部变量表在创建时是已知大小，这部分内存空间能在编译期完成分配，并且在方法运行期间不需要修改局部变量表大小。
在虚拟机规范中，对这块内存区域规定了两种异常：
1.如果线程请求的栈深度大于虚拟机所允许的深度（？），将抛出StackOverflowError异常；
2.如果虚拟机可以动态扩展，当扩展是无法申请到足够内存，将抛出OutOfMemory异常；
2、本地方法栈
本地方法栈同样也是线程私有，而且和虚拟机栈作用几乎是一样的：虚拟机栈是为java方法执行提供出入栈服务，而本地方法栈则是为虚拟机执行Native方法提供服务。
在虚拟机规范中，对本地方法栈实现方式没有强制规定，可以由具体虚拟机自由实现；HotSpot虚拟机是直接把虚拟机栈和本地方法栈合二为一实现；对于其他虚拟机实现这一块的方法，读者有兴趣可以自行查询相关资料；
与虚拟机栈一样，本地方法栈同样会抛出StackOverflowError和OutOfMemory异常。
3、程序计算器
程序器计算器也是线程私有的内存区域，可以认为是线程执行字节码的行号指示器（指向一条指令），java执行时通过改变计数器的值来获的下一条需要执行的指令，分支、循环、跳转、异常处理、线程恢复等执行顺序都要依赖这个计数器来完成。虚拟机的多线程是通过轮流切换并分配处理器执行时间实现，处理器（对多核处理器来说是一个内核）在一个时刻只能在执行一条命令，因此线程执行切换后需要恢复到正确的执行位置，每个线程都有一个独立的程序计算器。
在执行一个java方法时，这个程序计算器记录（指向）当前线程正在执行的字节码指令地址，如果正在执行的是Native方法，这个计算器的值为undefined，这是因为HotSpot虚拟机线程模型是原生线程模型，即每个java线程直接映射OS（操作系统）的线程，执行Native方法时，由OS直接执行，虚拟机的这个计数器的值是无用的；由于这个计算器是一块占用空间很小的内存区域，为线程私有，不需要扩展，是虚拟机规范中唯一一个没有规定任何OutOfMemoryError异常的区域。
4、堆内存（Heap）
java 堆是线程共享的内存区域，可以说是虚拟机管理的内存最大的一块区域，在虚拟机启动时创建；java堆内存主要是存储对象实例，几乎所有的对象实例（包括数组）都是存储在这里，因此这也是垃圾回收（GC）最主要的内存区域，有关GC的内容这里不做描述；
按照虚拟机规范，java堆内存可以处于不连续的物理内存中，只要逻辑上是连续的，并且空间扩展也没有限制，既可以是固定大小，也可以是棵扩展的；如果堆内存没有足够的空间完成实例分配，而且也无法扩展，将会抛出OutOfMemoryError异常。
5、方法区
方法区和堆内存一样，是线程共享的内存区域；存储已经被虚拟机加载的类型信息、常量、静态变量、即时编译期编译后的代码等数据；虚拟机规范对于方法区的实现没有过多限制，和堆内存一样不需要连续的物理内存空间，大小可以固定或者可扩展，还可以选择不实现垃圾回收；当方法区无法满足内存分配需求时将会抛出OutOfMemoryError异常。
6、直接内存
直接内存并不是虚拟机管理内存的一部分，但是这部分内存还是可能被频繁用到；在java程序使用到Native方法时(如 NIO，有关NIO这里不做描述)，可能会直接在堆外分配内存，但是内存总空间大小是有限的，也会遇到内存不足的情况，一样会抛出OutOfMemoryError异常。
二、实例对象存储访问
上面第一点对虚拟机各区域内存有个总体的描述，对于每个区域，都存在数据是如何创建、布局、访问的问题，我们以最常使用的的堆内存为例基于HotSpot说下这三个方面。
1、实例对象创建
当虚拟机执行到一条new指令时，首先首先从常量池定位这个创建对象的类符号引用、判断检查类是否已经加载初始化，如果没有加载，则执行类加载初始化过程（关于类加载，这里不做描述），如果这个类找不到，则抛出常见的ClassNotFoundException异常；
通过类加载检查后，就是实际为对象分配物理内存（堆内存），对象所需的内存空间大小是由对应的类确定的，类加载后，这个类的对象所需的内存空间是固定的；为对象分配内存空间，相当于要从堆中划分出一块出来分配给这个对象；
根据内存空间是否连续（已分配和未分配是区分为完整的两部分）分为两种分配内存方式：
1. 连续的内存：已分配和未分配中间使用一个指针作为分界点，对象内存分配只需要指针向未分配内存段移动一段空间大小即可；这种方式称 为“指针碰撞”。
2. 非连续内存：虚拟机需要维护（记录）一个列表，记录堆中那些内存块的没有分配的，在分配对象内存时从中选择一块适合大小的内存区域 分配给对象，并更新这个列表；这种方式称为“空闲列表”。
对象内存的分配也会遇到并发的问题，虚拟机使用两种方案解决这个线程安全问题：第一使用CAS(Compare and set)+识别重试，保证分配操作的原子性；第二是内存分配按照线程划分不同的空间，即每个线程在堆中预先分配好一块线程私有的内存，称为本地线程分配缓存区(Thread Local Allocation Buffer,TLAB)；那个线程要分配内存时，直接从TLAB中分配出来，只有当线程的TLAB分配完需要重新分配，才需要同步操作从堆中分配，这个方案有效的减少线程间对象分配堆内存的并发情况出现；虚拟机是否使用TLAB这种方案，是通过JVM参数 -XX:+/-UseTLAB 设定。
完成内存分配后，除对象头信息外，虚拟机会将分配到的内存空间初始化为零值，保证对象实例的字段可以不赋值就可直接使用到数据类型对应的零值；紧接着，执行 init 方法按照代码完成初始化，才完成一个实例对象的创建；
2、对象在内存的布局
在HotSpot虚拟机中，对象在内存分为3个部分：对象头(Header)、实例数据(Instance Data)、对齐填充(Padding)：
其中对象头又分两个部分：一部分存储对象运行时数据，包括哈希码、垃圾回收分代年龄、对象锁状态、线程持有的锁、偏向线程ID、偏向 时间戳等；在32位和64位虚拟机中，这部分数据分别占用32位和64位；由于运行时数据较多，32位或者64位不足以完全存储全部数据，所以 这部分设计为非固定格式存储运行时数据，而是根据对象的状态不同而使用不同位来存储数据；另一部分存储对象类型指针，指向这个对象的 类，但这并不是必须的，对象的类元数据不一定要使用这部分存储来确定（下面会讲到）；
实例数据则是存储对象定义的各种类型数据的内容，而这些程序定义的数据并不是完全按照定义的顺序存储的，它们是按照虚拟机分配策略和定义的顺序确定：long/double、int、short/char、byte/boolean、oop(Ordinary Object Ponint)，可以看出，策略是按照类型占位多少分配的，相同的类型会在一起分配内存；而且，在满足这些前提条件下，父类变量顺序先于子类；
而对象填充这部分不是一定会存在，它仅仅是起到占位对齐的作用，在HotSpot虚拟机内存管理是按照8字节为单位管理，因此当分配完内存后，对象大小不是8的倍数，则由对齐填充补全；
3、对象的访问
在java程序中，我们创建了一个对象，实际上我们得到一个引用类型变量，通过这个变量来实际操作一个在堆内存中的实例；在虚拟机规范中，只规定了引用(reference)类型是指向对象的引用，没有规定这个引用是如何去定位、访问到堆中实例的；目前主流的虚拟机中，主要有两种方式实现对象的访问：
1. 句柄方式：堆内存中划分出一块区域作为句柄池，引用变量中存储的是对象的句柄地址，而句柄中存储了示例对象和对象类型的具体地址信息，因此对象头中可以不包含对象的类型：
2. 指针直接访问：引用类型直接存储的是实例对象在堆中的地址信息，但是这就必须要求实例对象的布局中，对象头必须包含对象的类型：
这两种访问方式各有优势：当对象地址改变（内存整理、垃圾回收），句柄方式访问对象，引用变量不需要改变，只需要改变句柄中的对象地址值就可；而使用指针直接访问方式，则需要修改这个对象全部的引用；但是指针方式，可以减少一次寻址操作，在大量对象访问的情况下，这种方式的优势比较明显；HotSpot虚拟机就是使用这中指针直接访问方式。
三、运行时内存异常
java程序内存在运行时主要可能发生两种异常情况：OutOfMemoryError、StackOverflowError；那个内存区域会发生什么异常，前面已经简单提到，除了程序计数器已外，其他内存区域都会发生；本节主要通过实例代码演示各个内存区域发生异常的情况，其中会使用到许多常用的虚拟机启动参数以便更好说明情况。（如何使用参数运行程序这里不做描述)
1、java堆内存溢出
堆内存溢出发生在堆容量达到最大堆容量后创建对象情况下，在程序中只要不断的创建对象，并且保证这些对象不会被垃圾回收：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
|
/** * 虚拟机参数: * -Xms20m 最小堆容量 * -Xmx20m 最大堆容量 * @author hwz * */public class HeadOutOfMemoryError { public static void main(String[] args) { //使用容器保存对象，保证对象不被垃圾回收 List<HeadOutOfMemoryError> listToHoldObj = new ArrayList<HeadOutOfMemoryError>(); while(true) { //不断创建对象并加入容器中 listToHoldObj.add(new HeadOutOfMemoryError()); } }} |
这里可以加上虚拟机参数：-XX:HeapDumpOnOutOfMemoryError，在发送OOM异常的时候让虚拟机转储当前堆的快照文件，后续可以通过这个文件分词异常问题，这个不做详细描述，后续再写个博客详细描述使用MAT工具分析内存问题。
2、虚拟机栈和本地方法栈溢出
在HotSpot虚拟机中，这两个方法栈是没有一起实现的，根据虚拟机规范，这两块内存区域会发生这两种异常：
1. 如果线程请求栈深度大于虚拟机允许的最大深度，抛出StackOverflowError异常；
2. 如果虚拟机在扩展栈空间时，无法申请大内存空间，将抛出OutOfMemoryError异常；
这两种情况实际上是存在重叠的：当栈空间无法继续分配是，到底是内存太小还是已使用的栈深度太大，这个无法很好的区分。
使用两种方式测试代码
1. 使用-Xss参数减少栈大小，无限递归调用一个方法，无限加大栈深度：
|
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
|
/** * 虚拟机参数:<br> * -Xss128k 栈容量 * @author hwz * */public class StackOverflowError { private int stackDeep = 1; /** * 无限递归，无限加大调用栈深度 */ public void recursiveInvoke() { stackDeep++; recursiveInvoke(); } public static void main(String[] args) { StackOverflowError soe = new StackOverflowError(); try { soe.recursiveInvoke(); } catch (Throwable e) { System.out.println("stack deep = " + soe.stackDeep); throw e; } }} |
方法中定义大量本地变量，增加方法栈中本地变量表的长度，同样无限递归调用:
|
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
|
/** * @author hwz * */public class StackOOMError { private int stackDeep = 1; /** * 定义大量本地变量，增大栈中本地变量表 * 无限递归，无限加大调用栈深度 */ public void recursiveInvoke() { Double i; Double i2; //.......此处省略大量变量定义 stackDeep++; recursiveInvoke(); } public static void main(String[] args) { StackOOMError soe = new StackOOMError(); try { soe.recursiveInvoke(); } catch (Throwable e) { System.out.println("stack deep = " + soe.stackDeep); throw e; } }} |
以上代码测试说明，无论是帧栈太大还是虚拟机容量太小，当内存无法分配时，抛出的都是StackOverflowError异常；
3、方法区和运行时常量池溢出
这里先描述一下String的intern方法：如果字符串常量池已经包含一个等于此String对象的字符串，则返回代表这个字符串的String对象，否则将此String对象添加到常量池中，并返回此String对象的引用；通过这个方法不断在常量池中增加String对象，导致溢出：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
|
/** * 虚拟机参数：<br> * -XX:PermSize=10M 永久区大小 * -XX:MaxPermSize=10M 永久区最大容量 * @author hwz * */public class RuntimeConstancePoolOOM { public static void main(String[] args) { //使用容器保存对象，保证对象不被垃圾回收 List<String> list = new ArrayList<String>(); //使用String.intern方法，增加常量池的对象 for (int i=1; true; i++) { list.add(String.valueOf(i).intern()); } }} |
但是这段测试代码在JDK1.7下没有发生运行时常量池溢出，在JDK1.6倒是会发生，为此再写一段测试代码验证这个问题：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
|
/** * String.intern方法在不同JDK下测试 * @author hwz * */public class StringInternTest { public static void main(String[] args) { String str1 = new StringBuilder("test").append("01").toString(); System.out.println(str1.intern() == str1); String str2 = new StringBuilder("test").append("02").toString(); System.out.println(str2.intern() == str2); }} |
在JDK1.6下运行结果为：false、false;
在JDK1.7下运行结果为：true、true;
原来在JDK1.6中，intern()方法把首次遇到的字符串实例复制到永久代，反回的是永久代中的实例的引用，而有StringBuilder创建的字符串实例在堆中，所以不相等；
而在JDK1.7中，intern()方法不会复制实例，只是在常量池记录首次出现的实例的引用，因此intern返回的引用和StringBuilder创建的实例是同一个，所以返回true；
所以常量池溢出的测试代码不会发生常量池溢出异常，而是在不断运行后可能发生堆内存不足溢出异常；
那要测试方法区溢出，只要不断往方法区加入东西就行了，比如类名、访问修饰符、常量池等。我们可以让程序加载大量的类去不断填充方法区从而导致溢出，这个我们使用CGLib直接操作字节码生成大量动态类：
|
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
|
/** * 方法区内存溢出测试类 * @author hwz * */public class MethodAreaOOM { public static void main(String[] args) { //使用GCLib无限动态创建子类 while (true) { Enhancer enhancer = new Enhancer(); enhancer.setSuperclass(MAOOMClass.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 MAOOMClass {}} |
通过VisualVM观察可以看到，JVM加载类的数量和PerGen的使用成直线上升：
4、直接内存溢出
直接内存的大小可以通过虚拟机参数设定：-XX:MaxDirectMemorySize，要使直接内存溢出，只需要不断的申请直接内存即可，以下同Java NIO 中直接内存缓存测试：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
|
/** * 虚拟机参数:<br> * -XX:MaxDirectMemorySize=30M 直接内存大小 * @author hwz * */public class DirectMemoryOOm { public static void main(String[] args) { List<Buffer> buffers = new ArrayList<Buffer>(); int i = 0; while (true) { //打印当前第几次 System.out.println(++i); //通过不断申请直接缓存区内存消耗直接内存 buffers.add(ByteBuffer.allocateDirect(1024*1024)); //每次申请1M } }} |
在循环中，每次申请1M直接内存，设置最大直接内存为30M，程序运行到31次时抛出异常：java.lang.OutOfMemoryError: Direct buffer memory
四、总结
以上就是本文的全部内容，本文主要描述JVM中内存的布局结构、对象存储和访问已经各个内存区域可能出现的内存异常；主要参考书目《深入理解Java虚拟机（第二版）》，如有不正确之处，还请在评论中指出；谢谢大家对服务器之家的支持。
原文链接：http://blog.csdn.net/wenhuayuzhihui/article/details/51981924
