Java自动内存管理机制

一、Java内存区域与内存溢出异常

1.1运行时数据区域

Java虚拟机在执行Java程序的过程中会把它所管理的内存划分为若干不同的数据区域。下图就是一个具象的示意图：

1.1.1程序计数器

程序计数器是一块较小的内存，可以看作是当前线程所执行的字节码的行号指示器；

简单理解就是，Java虚拟机多线程轮流切换处理器分配时间，通过程序计数器来记录上一次程序执行字节码的位置。因此，每条线程都需要有一个独立的程序计数器，各个线程之间互不影响，独立存储，属于“线程私有”。

1.1.2Java虚拟机栈

Java虚拟机栈是用于方法执行过程中，存放栈帧，在栈帧中会存储局部变量表、操作数栈、方法出口等信息，也是“线程私有”；

该内存区域中，存在两种异常：栈深度大于规定以及内存溢出。

1.1.3本地方法栈

同Java虚拟机栈，只不过本地方法栈是用于执行Native方法。

1.1.4Java堆

Java堆用于对象实例的分配，是Java虚拟机管理的最大一块内存，属于线程共享；

Java堆是垃圾收集器管理的主要区域，因此也称为“GC堆”。从内存回收的角度，Java堆还可以细分为新生代、老年代，新生代又可以分为Eden空间、From Survivor空间、To Survivor空间。

1.1.5方法区

方法区用于存储虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码等数据，属于线程共享。

1.1.6运行时常量池

运行时常量池是方法区的一部分。

1.1.7直接内存

直接内存并不是虚拟机运行时数据区的一部分，但也被频繁使用；

在JDK 1.4中新加入了NIO类，引入了一种基于通道与缓冲区的I/O方式，它可以使用Native函数库直接分配堆外内存，然后通过一个存储在Java堆中的DirectByteBuffer对象作为这块内存的引用进行操作。

1.2HotSpot虚拟机对象探秘

1.2.1对象的创建

虚拟机接收到new对象的指令，会去检查类的加载，然后为新生对象在堆中分配内存；

分配方式：指针碰撞、空间列表。指针碰撞是指在规整的内存空间中，通过指针，来界限使用内存和未使用内存；空间列表是通过维护列表来记录内存的分配，内存可以是不规整的；

线程安全：在并发情况下，指针碰撞和空间列表都不安全。解决方案有两种：一种是对分配内存空间的动作进行同步处理——CAS+重试；另一种是把内存分配的动作按线程划分在不同的空间中进行，即每个线程在Java堆中预先分配一小块内存，称为本地线程分配缓冲；

1.2.2对象的内存布局

对象在内存中的布局分为3块区域：对象头，实例数据和对齐填充；

对象头包括两部分信息：第一部分用于存储对象自身的运行时数据，如哈希码、GC分代年龄、锁状态标志、线程持有的锁、偏向线程ID、时间戳等，称为“Mark Word”；第二部分是类型指针，即对象指向它的类元数据的指针，虚拟机通过这个指针来确定这个对象是哪个类的实例（查找对象的元数据不一定要通过对象本身）。如果是Java数据，对象头还必须记录数组长度；第三部分是对齐填充，因为虚拟机规定对象的大小必须是8字节的整数倍，对其填充仅起到占位符的作用，没有特别的含义。

1.2.3对象的访问定位

建立对象是为了使用对象，Java程序需要通过栈上的reference数据来操作堆上的具体对象。目前主流的访问方式有使用句柄和直接指针两种。

如果是句柄，内存中会划分一块作为句柄池，reference中存储的就是对象的句柄地址，而句柄中包含了对象实例数据与类型数据各自的具体地址信息；

如果使用直接访问，reference中存储的就是对象地址，这时候就要考虑对象类型的相关信息（对象头中保存）；

句柄最大的好处是稳定，对象地址改变（垃圾回收时异动对象是非常普遍的），只会改变句柄中的实例数据指针，而reference本身不需要修改；

直接指针访问方式最大的好处就是速度块，节省一次指针定位的时间开销，Sun HotSpot使用直接指针的方式进行访问对象。

二、垃圾收集器与内存分配策略

2.1对象已死吗

2.1.1引用计数算法

给对象添加一个引用计数器，每当有一个地方引用它时，计数器值就加1；当引用失效时，计数器值就减1；任何时刻计数器为0的对象就是不可能再被使用的。

问题：没有解决对象之间相互循环引用的问题！

2.1.2可达性分析算法

通过一系列称为“GC Roots”的对象作为起始点，从这些节点开始向下搜索，搜索所走过的路劲称为引用链，当一个对象到GC Roots没有任何引用引用链相连时，则证明此对象不可用。

在Java语言中，可作为GC Roots的对象包括下面几种：

虚拟机栈中引用的对象；

方法区中静态属性引用的对象；

方法区中常量引用的对象；

本地方法栈中引用的对象。

2.1.3再谈引用

通过reference存储对象的直接地址，那么，对象的状态就只有引用和被引用两种。未免有些无趣。Java对引用的概念进行了扩充，强应用、软引用、弱引用和虚引用。

强引用即为常用的通过new对象创建的引用，只要存在，永不回收；

软引用，通过SoftReference类来实现，内存溢出之前，会对该对象进行二次回收；

MyObject aRef = new  MyObject(); 
//创建软引用
SoftReference aSoftRef=new SoftReference(aRef); 
//通过软引用获得强引用
MyObject aRef = aSoftRef.get();

弱引用，通过WeakReference类来实现，对象只能存活到下次垃圾收集发生之前；

虚引用，完全不会对其生存时间构成影响，只是通过这个关联在对象被回收之时收到通知；

2.1.4生存还是死亡

即使在可达性分析算法中不可达的对象，也并非是“非死不可”的，这是他们处于“缓刑”阶段，要宣布死亡，至少需要两次标记：可达性分析后没有引用，第一次标记并进行一次筛选，是否有必要执行finalize()方法。当对象没有覆盖finalize()方法或者已经执行，意味着没必要执行。finalize()是有且仅有一次的自救方法，通过将自己引用到GC Roots中完成自救，如果没有完成自救，第二次标记时，就会被回收。

finalize()只会执行一次，并且不能保证执行，它的运行代价高昂，不确定大，应避免使用。

2.1.5回收方法区

方法区（永久代）中垃圾收集主要是两部分：废弃常量和无用的类；

2.2垃圾收集算法

2.2.1标记-清除算法

标记-清除算法分为“标记”和“清除”两个阶段：首先标记所有需要回收的对象，完成后同一回收。

主要不足有两个：一个是效率问题，标记和清除两个过程的效率都不高；另一个是空间问题，标记清除之后会产生大量不连续的内存碎片。

2.2.2复制算法

复制算法将内存按容量大小划分为大小相等的两块，每次只使用其中一块，当其中一块内存用完了，就将存活的对象复制到另外一块上去，然后清空已使用的。这样每次都是对整个半区进行回收，不需要考虑碎片问题，问题是占用了太多的内存。

现在的商业虚拟机都是采用复制算法来回收新生代，因为新生代的对象98%都是“朝生夕死”，所以不需要按照1：1的比例来划分。Eden：From Survivor：To Survivor=8:1:1，每当使用Eden和一块Survivor，当回收时，将其中的存活对象复制到另一块Survivor上。

2.2.3标记-整理算法

标记-整理算法标记过程仍与“标记-清除”算法一样，但后续步骤不是回收，而是让存活对象向一端异动，然后直接清除掉端边界以外的内存。

2.2.4分代算法

把Java堆分为新生代和老年代，根据各个年代的特点采用最合适的收集算法。

2.3HotSpot的算法实现

前文介绍了理论上的对象存活判定算法和垃圾收集算法，而HotSpot虚拟机实现这些算法时，必须对算法的执行效率有严格的考量。

2.3.1枚举根节点

在可达性分析中从GC Roots节点找引用链，如果方法区、栈占用内存很大，逐个检查必然消耗大量时间。另外，准确式GC需要保证一致性，在整个分析期间，整个执行系统看起来就像被冻结在某个时间点上。这点是导致GC进行必须停顿所有Java执行线程的一个重要原因。

优化：当执行系统停顿后，并不需要检查完所有执行上下文和全局的引用位置，虚拟机应该有办法直接知道哪些地方存放着对象引用。在HotSpot的实现中，使用一组称为OopMap的数据结构来达到目的。在类加载完成的时候，HotSpot就把对象内什么偏移量上是什么类型的数据计算出来，在JIT编译过程中，也会在特定的位置记录下栈和寄存器中哪些位置是引用。这样GC扫描就可以直接得知这些信息了。

2.3.2安全点

在OopMap的协助下，HotSpot可以快速且准确的完成GC Roots枚举，但是又有问题，导致引用关系变化的指令非常多，为每条指令生成OopMap，需要大量空间。

优化：HotSpot并没有每条指令都生成OopMap，只有在“特定位置”记录，这些位置称为安全点，即程序执行只有到达安全点才能暂停。安全点的选择基本上是以程序“是否具有让程序长时间执行的特征”为标准进行选定的，单条指令执行都很快，除非像方法调用、循环跳转、异常跳转等，所以具有这些功能的指令才会产生Safepoint。

对于Safepoint，另一个需要考虑的问题是如何在GC时，让所有线程都跑到最近的安全点上。这里有两种方案：抢先式中断和主动式中断。抢先式中断不需要线程的代码主动去配合，在GC发生时，将所有线程全部中断，如果有线程不在安全点上，就恢复线程，让它“跑”到安全点上。

主动式中断的思想式当GC需要中断线程的时候，不直接对线程操作，仅简单地设置一个标志，各个线程执行时主动去轮询这个标志，发现中断标志为真时就自己中断挂起。轮询标志与安全点重合，另外加上创建对象需要分配内存地地方。

2.3.3安全区域

Safepoint貌似完美地解决了问题，但实际情况确不一定。Safepoint机制保证了程序执行时，在不太长地时间内就会遇到可进入GC的Safepoint。但是，程序不执行呢？

优化：安全区域是指在一段代码片段之中，应用关系不会发生变化。在这个区域中的任何地方开始GC都是安全的。当线程执行到安全区中的代码时，首先标识自己进入了Safe Region，这段时间Jvm要GC就不需要管自己了，当线程要离开时，要检查系统是否已经完成了根节点枚举，如果完成就继续执行，否则它就必须等待直到可以安全离开Safe Region的信号为止。

2.4垃圾收集器

如果说收集算法是内存回收的方法论，那么垃圾收集器就是内存回收的具体实现。不同厂商不同版本的虚拟机所提供的垃圾收集器可能差别很大，一般都会提供参数供用户根据自己的应用特点和要求组合出各个年代所使用的收集器。

这张图描述了所有的不同年代回收器的组合方式：单线程的Serial+单线程的Serial Old，单线程的Serial+CMS，多线程的ParNew+单线程的Serial Old，多线程的ParNew+CMS，多线程的Parallel Scavenge+单线程的Serial Old，多线程的Parallel Scavenge+多线程的Parallel Old，G1（独立管理）；其中，新生代多线程的ParNew和Parallel Scavenge的区别在于：ParNew只是Serial的多线程版本，而Parallel Scavenge是一个追求吞吐量的多线程版本。

2.4.1Serial收集器

Serial收集器是最基本的新生代单线程收集器，使用的复制算法。它的“单线程”并不仅仅说明它只会使用一个CPU或一个收集线程去完成垃圾收集工作，更重要的是它在进行垃圾收集时，必须暂停其他所有的工作线程，直到它收集结束。

2.4.2ParNew收集器

ParNew收集器是Serial收集器的多线程版本。

2.4.3Parallel Scanvenge收集器

Parallel Scavenge收集器是一个新生代收集器，它也是使用复制算法的收集器。

Parallel Scavenge收集器的目的是达到一个可控制的吞吐量。所谓吞吐量就是CPU运行用户代码的时间与CPU总消耗时间的比值，即吞吐量=运行用户代码时间/（运行用户代码时间+垃圾收集时间）。停顿时间越短就越适合需要与用户交互的程序，良好的相应速度能提升用户体验，而高吞吐量可以高效率地利用CPU时间，尽快完成程序地运算任务。

Parallel Scavenge收集器提供了两个参数用于精准控制吞吐量，分别是控制最大垃圾收集停顿时间的-XX：MaxGCPauseMillis参数以及直接设置吞吐量大小的-XX：GCTimeRatio参数。

MaxGCPauseMillis：允许设置一个大于0的毫秒数，收集器尽可能地保证内存回收花费地时间不超过设定值。GC停顿时间地缩短是以牺牲吞吐量和新生代空间换取的：系统把新生代调小一些，收集300M新生代肯定比500M快，这也直接导致垃圾收集发生的更频繁，原来10秒收集一次，每次停顿100毫秒，现在变成5秒一次，每次停顿70毫秒。停顿时间的确下降了，吞吐量也降下来了。

GCTimeRatio：应当是一个大于0且小于100的整数，也就是垃圾收集时间占总时间的比率，相当于是吞吐量的倒数。默认是99，就是最大1%（即1/（1+99））的垃圾收集时间。

由于与吞吐量关系密切，Parallel Scavenge收集器被称为“吞吐量优先”收集器。除了上述两个参数，还有一个-XX：+UseAdaptiveSizePolicy参数。这个参数打开之后，就不需要指定新生代的大小、晋升老年代对象年龄等细节参数，虚拟机会动态调整这些参数以提供最合适的停顿时间或者最大的吞吐量，这种称为GC自适应的调节策略。

2.4.4Serial Old收集器

Serial Old是老年代的一个单线程收集器，使用“标记-整理”算法。可以与新生代的单线程Serial收集器以及吞吐量Parallel Scavenge收集器搭配使用，也可以作为CMS老生代收集器的后备方案。

2.4.5Parallel Old收集器

Parallel Old是老年代的多线程收集器，使用“标记-整理”算法。搭配新生代Parallel Scavenge收集器使用。

Parallel Scavenge+Parallel Old组成了名副其实的“吞吐量优先”应用组合。

2.4.6CMS收集器

CMS是老年代的多线程收集器，使用“标记-清除”算法。CMS收集器是一种以获取最短回收停顿时间为目标的收集器。

算法实现的整个过程分为4个步骤：①初始标记，②并发标记，③重新标记，④并发清除。

其中，初始标记、重新标记这两个步骤仍然需要“Stop The World”。初始标记只是查找GC Roots能直接关联到的对象，速度很快，并发标记就是进行GC RootsTracing的过程，这个过程跟用户程序是并发执行，并不影响，重新标记则是为了修正因用户程序继续运作而导致标记产生变化的那一部分对象的标记记录，这个标记会相对时间长一些，但远比并发标记的时间短。

CMS是一款优秀的收集器，它的主要优点从名字已经体现出来了：并发收集、低停顿（Concurrent Low Pause Collector）。但是他也有明显的3个缺点：

①CMS收集器对CPU资源非常敏感。CMS默认启动的回收线程数是（CPU数量+3）/4，也就是当CPU在4个以上时，并发回收时垃圾收集线程不少于25%的CPU资源；

②CMS收集器无法处理浮动垃圾。由于CMS并发清理阶段用户线程还在运行，伴随程序运行自然就还会有新的垃圾不断产生；

③CMS收集器是基于“标记-清除”算法，这意味着可能会有大量的碎片。解决办法就是在执行多次不压缩的Full GC后，跟着来一次带压缩的。

2.4.7G1收集器

G1是一款面向服务端应用的垃圾收集器，是当今收集器技术发展的最前沿成果之一。G1具备如下特点：

①并行与并发：G1能充分利用多CPU、多核环境下的硬件优势，使用多个CPU来缩短Stop-The-World停顿的时间；

②分代收集：分代概念在G1中依然得以保留，能够采用不同的方式去处理新创建的对象和已近存活一段时间、熬过多次GC的旧对象；

③空间整合：G1从整体来看是基于“标记-整理”算法实现的收集器，从局部来看是基于“复制”算法实现的，这都意味着不会产生空间碎片；

④可预测的停顿：降低停顿时间是G1和CMS共同的关注点，但G1除了追求低停顿外，还能建立可预测的停顿时间模型，能让使用者明确指定一个长度为M毫秒的时间片段内，消耗在垃圾收集上的时间不超过M毫秒；

G1收集器将整个Java堆划分为多个大小相等的独立区域（Region），虽然保留有新生代和老年代的概念，但新生代和老年代不再是物理隔离的了，他们都是一部分Region的集合。

G1收集器之所以能建立可预测的停顿时间模型，是因为它可以有计划地避免在整个Java 堆中进行全区域的垃圾收集。G1跟踪各个Region里面的垃圾堆积的价值大小（回收所获得的 空间大小以及回收所需时间的经验值），在后台维护一个优先列表，每次根据允许的收集时 间，优先回收价值最大的Region（这也就是Garbage-First名称的来由）。这种使用Region划分 内存空间以及有优先级的区域回收方式，保证了G1收集器在有限的时间内可以获取尽可能高 的收集效率。

在G1收集器中，Region之间的对象引用以及其他收集器中的新生代与老年代之间的对象引用，虚拟机都是使用Remembered Set来避免全堆扫描的。G1中每个Region都有一个与之对应的Remembered Set，虚拟机发现程序在对Reference类型的数据进行写操作时，会产生一个Write Barrier暂时中断写操作，检查Reference引用的对象是否处于不同的Region之中（在分代的例子中就是检查是否老年代中的对象引用了新生代中的对象），如果是，便通过CardTable把相关引用信息记录到被引用对象所属的Region的Remembered Set之中。当进行内存回收时，在GC根节点的枚举范围中加入Remembered Set即可保证不对全堆扫描也不会有遗漏。

G1收集器运作步骤大致可以分为：①初始标记，②并发标记，③最终标记，④筛选回收；

前三个过程与CMS收集器类似，最后的筛选回收阶段，首先对各个Region的回收价值和成本进行排序，根据用户所期望的GC停顿时间来制定回收计划，这个阶段是可以做到与用户并发执行的，但是因为只回收一部分Region，停顿将大幅提升收集效率。其实用户期望的停顿时间中，已经包含了标记以及回收所需时间。

2.5内存分配与回收策略

对象优先在Eden分配，大对象直接进入老年代，长期存活的对象将进入老年代。如果对象在Eden出生并经过第一次Minor GC仍然存活，并且能够被Survivor容纳，将被移动到Survivor空间中，并且对象年龄设为1。

空间分配担保：在发生Minor GC之前，虚拟机会先检查老年代最大可用的连续空间是否大于新生代所有对象总空间，如果这个条件成立，那么确保Minor GC是安全的。否则就是“冒险”。