《深入理解Java虚拟机：JVM高级特性与最佳实践》读书笔记之自动内存管理机制
一、Java内存区域与内存溢出异常
1. 概述
Java程序员把内存控制的权力交给了Java虚拟机，在虚拟机的自动内存管理机制的帮助下，不再需要为每一个new操作去写配对的delete/free代码，而且不容易出现内存泄漏和内存溢出的问题。但是一旦出现上述方面的问题，如果不了解虚拟机是怎么样使用内存的，那排查错误将会成为一项异常艰难的工作。
2. 运行时数据区域
Java虚拟机在执行Java程序的过程中会把它所管理的内存划分为若干个不同的数据区域。这些区域都有各自的用途，以及创建和销毁的时间，有的区域随着虚拟机进程的启动而存在，有些区域则是依赖用户线程的启动和技术而建立和销毁。
Java运行时数据区：
2.1 程序计数器
程序计数器（Program Counter Register）的作用是当前线程所执行的字节码的行号指示器。字节码解释器工作时就是通过改变这个计数器的值来选区下一条需要执行的字节码指令。
由于Java虚拟机的多线程是通过线程轮流切换并分配处理器执行时间的方式来实现的，在任何一个确定的时刻，一个处理器只会执行一条线程中的指令。因此，为了线程切换后能恢复到正确的执行位置，每条线程都需要有一个独立的程序计数器，各条线程之间的计数器互不影响，独立存储。我们称这类内存区域为”线程私有“的内存。
如果线程正在执行的是一个Java方法，这个计数器记录的是正在执行的虚拟机字节码指令的地址。
如果正在执行的是Native方法，这个计数器值则为空（Undefined）。
此内存区域是唯一一个在Java虚拟机规范中没有规定任何OutOfMemoryError情况的区域。
2.2 Java虚拟机栈
Java虚拟机栈（Java Virtual Machine Stacks）是线程私有的，它的生命周期与线程相同。
Java虚拟机栈为执行Java方法（字节码）服务。
虚拟机栈描述的是Java方法执行的内存模型：每个方法被执行的时候都会同时创建一个栈帧（Stack Frame）用于存储局部变量表、操作栈、动态链接、方法出口等信息。每一个方法被调用至执行完成的过程，就对应着一个栈帧在虚拟机栈中从入栈到出栈的过程。
局部变量表所需的内存空间在编译期间完成分配。每个方法需要在帧中分配多大的局部变量空间是完全确定的，在方法运行期间不会改变局部变量表的大小。
JVM规范对该区域规定的两种异常状况：
- 如果线程请求的栈深度大于虚拟机所允许的深度，将抛出StackOverflowError异常。
- 如果虚拟机栈可以动态扩展，当扩展时无法申请到足够的内存时会抛出OutofMemoryError异常。
2.3 本地方法栈
本地方法栈(Native Method Stacks)为虚拟机使用到的Native方法服务。
Sun HortSpot虚拟机把本地方法栈和虚拟机栈合二为一。
本地方法栈也会抛出StackOverflowError和OutofMemoryError异常。
2.4 Java堆
Java堆是被所有线程共享的一块内存区域，在虚拟机启动时创建。此区域的唯一目的就是存放对象实例。
Java堆时垃圾收集器管理的主要区域，因此很多时候也被称为”GC堆“。
在JVM规范中，Java堆可以处于物理上不连续的内存空间中，只要逻辑上时连续的即可。
如果在堆中没有内存完成实力分配，并且堆也无法再扩展时，将会抛出OutOfMemoryError异常。
2.5 方法区
方法区（Method Area）与Java堆一样，是各个线程共享的内存区域，它用于存储已被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码等数据。
垃圾收集行为在这个区域是比较少出现的，这个区域的内存回收目标主要时针对常量池的回收和对类型的卸载。
在JVM规范中，当方法区无法满足内存分配需求时，将会抛出OutOfMemoryError异常。
2.6 运行时常量池
运行时常量池（Runtime Constant Pool）是方法区的一部分。用于存放编译期生成的各种字面量和符号引用，这部分内容在类加载后存放到方法区的运行时常量池中。
2.7 直接内存
直接内存（Direct Memory）并不是虚拟机运行时数据区的一部分，也不是JVM规范中定义的内存区域，但是这部分内存也被频繁的使用，而且也可能导致OutOfMemoryError异常。
在JDK1.4中新加入的NIO类，引入了一种基于通道与缓冲区的I/O方式，它可以使用Native函数库直接分配堆外内存，然后通过一个存储在Java堆里面的DirectByteBuffer对象作为这块内存的引用进行操作。避免了在Java堆和Native堆中来回复制数据。
本机直接内存的分配不会收到Java堆大小的限制，服务器管理员在配置虚拟机参数时，经常会忽略掉直接没存，使得各个内存区域的总和大于物理内存限制，从而导致动态扩展时出现OutOfMemoryError异常。
3. 对象访问
Object obj = new Object();
Object obj ：反映到Java栈的本地变量表中，作为一个reference类型数据出现。
new Object()：反映到Java堆中，形成一块存储了Object类型所有实例数据值（Instance Data）的结构化内存。根据具体类型及虚拟机时间的对象内存布局（Object Memory Layout）的不同，这块内存的长度是不固定的。另外，在Java堆中还必须包含能查找到此对象类型数据的地址信息，这些类型数据存储在方法区中。
3.1 对象的两种访问方式
- 句柄
Java堆中划分出一块内存作为句柄池，reference中存储的就是对象的句柄地址，而句柄中包含了对象实例数据的类型数据各自的具体地址信息。
2. 直接指针
使用直接指针访问时，Java堆对象的布局中就必须考虑如何防止访问类型数据的相关信息，reference中直接存储的就是对象地址。
3.2 两种访问方式各自的优点
- 句柄访问的优点在于reference中存储的时稳定的句柄地址，在对象被移动（垃圾收集时移动对象是非常普遍的行为）时只会改变句柄中的实例数据指针，而reference本身不需要被修改。
- 直接指针访问的优点在于速度更快，它节省了一次指针定位的时间开销。
Sun HotSpot虚拟机则是使用第二种方式进行对象访问的。
4. 实战：OutOfMemoryError异常
4.1 Java堆溢出
4.2 虚拟机栈和本地方法栈溢出
4.3 运行时常量池溢出
4.4 方法区溢出
4.5 本机直接内存溢出
二、垃圾收集器与内存分配策略
1. 对象已死？
堆中几乎存放着Java世界中所有的对象实例，垃圾收集器在对堆进行回收前，第一件事情就是要确定这些对象有哪些还”存活“着，哪些已经”死去“。
1.1 引用计数算法
给对象中添加一个引用计数器，每当有一个地方引用它时，计数器值就加1；当引用失效时，计数器值就减1；任何时刻计数器都为0的对象就是不可能在被使用的。
由于该算法很难解决对象之间的互相循环引用的问题，Java语言并没有选用引用计数算法来管理内存。
1.2 根搜索算法
通过一系列名为”GC Roots“的对象作为起始点，从这些节点开始向下搜索，搜索所走过的路径称为引用链（Reference Chain），当一个对象到GC Roots没有任何链相连（用图论的话来说就是从GC Roots到这个对象不可达）时，则证明此对象是不可用的。
可作为GC Roots的对象有：
- 虚拟机栈（栈帧中的本地变量表）中的引用的对象。
- 方法区中的类静态属性引用的对象。
- 方法区中的常量引用的对象。
- 本地方法栈中JNI（即一般说的Native方法）的引用的对象。
1.3 再谈引用
引用的四种分类：
- 强引用（Strong Reference）：
类似”Object obj = new Object();“，只要强引用还在，垃圾收集器永远不会回收掉被引用的对象。
- 软引用（Soft Reference）：
表示一些还有用，但并非必需的对象。在系统将要发生内存溢出异常之前，将会把这些对象列进回收范围中并进行第二次回收。
- 弱引用（Weak Reference）：
描述非必需对象，但是它的强度比软引用更弱一些。被弱引用关联的对象只能生存到下一次垃圾收集发生之前。
- 虚引用（Phantom Reference）：
也成为幽灵引用或者幻影引用。一个对象是否有虚引用的存在，完全不会对其生存时间构成影响，也无法通过虚引用来取得一个对象实例。
1.4 生存还是死亡
不可达对象至少要经历两次标记过程才能被判定是否被清除。
1.5 回收方法区
该区域的垃圾收集主要回收两部分内容：废弃常量和无用的类。
什么是无用的类：
- 该类所有的实例都已经被回收，也就是Java堆中不存在该类的任何示例。
- 加载该类的ClassLoader已经被回收。
- 该类对应的java.lang.Class对象没有在任何地方被引用，无法在任何地方通过反射访问该类的方法。
2. 垃圾收集算法
2.1 标记-清除算法
算法分为”标记“和”清除“两个阶段：首先标记出所有需要回收的对象，在标记完成后统一回收掉所有被标记的对象。
缺点：
- 效率问题：标记和清除过程的效率都不高。
- 空间问题：标记清楚后会产生大量不连续的内存碎片，空间碎片太多可能会导致当程序在以后的运行过程中需要分配较大对象时无法找到足够的连续内存而不得不提前触发另一次垃圾收集动作。
2.2 复制算法
复制算法将可用内存按容量划分为大小相等的两块，每次只使用其中的一块。当这一块的内存用完了，就将还存活者的对象复制到另外一块上面，然后再把已使用过的内存空间一次清理掉。
现在二点商业虚拟机都采用这种收集算法来回收新生代。
将内存分为一块较大的Eden空间和两块较小的Survivor空间，每次使用Eden和其中的一块Survivor空间上，最后清理掉Eden和刚才使用过的Survivor的空间。
HotSpot虚拟机默认Eden和Survivor的大小比例是8:1。
如果另外一块Survivor空间没有足够的空间存放上一次新生代收集下来的存活对象，这些对象将直接通过分配担保机制进入老年代。
2.3 标记-整理算法
标记过程与”标记-清除“算法一样，但后续步骤不是直接对可回收对象进行清理，而是让所有存活的对象都向一端移动，然后直接清理掉端边界以外的内存。
2.4 分代收集算法
该算法根据对象的存活周期的不同将内存划分为几块。一般是把Java堆分为新生代和老年代，这样就可以根据各个年代的特点采用最适当的收集算法。
在新生代中，每次垃圾收集时都会发现有大批对象死去，只有少量存活，那就选用复制算法，只需要付出少量存活对象的复制成本就可以完成收集。
老年代中因为对象存活率高、没有额外空间对它进行分配担保，就必须使用”标记-清理“或”标记-整理“算法来进行回收。
3. 垃圾收集器
Sun HotSpot 虚拟机 1.6版 Update22，该虚拟机包含的所有收集器如图；
3.1 Serial收集器
单线程的收集器，它只会使用一个CPU或者一条收集线程去完成垃圾收集，而且在它进行垃圾收集时，必须暂停其他所有的工作线程（Stop The World）。
Serial收集器到现在为止，依然是虚拟机运行在Client模式下的默认新生代收集器。
3.2 ParNew收集器
ParNew收集器其实就是Serial收集器的多线程版本。
浙公网安备 33010602011771号