java虚拟机没有分配足够的内存_深入理解Java虚拟机——垃圾收集器和内存分配策略...

1.对象已死吗

通过第二章的学习我们了解了对象实例的分配是在堆内存里，垃圾收集器在对堆进行回收前，第一件事情就是确定哪些对象还“存活着”，哪些已经“死去”。

判断对象是否已死的算法有以下几种：引用记数法

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

这个方法实现简单，效率高，但主流的Java虚拟机没有选用该方法，原因是它很难解决对象之间互相循环引用的问题。如objA.instance = objB,objB.instance = objA，除此之外没有任何引用会调用这两个对象，这样就导致它们的引用计数永远不为0，于是永远不会被回收。可达性分析

在主流的商用程序语言中的主流实现中，都是用可达性分析来判定对象是否存活的。这个算法的基本思路就是通过一系列成为“GC Roots”的对象作为起始点，从这些节点向下搜索，搜索走过的路径称为引用链。当一个对象到GC Roots没有任何引用链的时候，那么就说明从GC Roots到这个对象不可达，则证明此对象是不可用的。

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

虚拟机栈中引用的对象，方法区中类静态属性引用的对象，方法区中常量引用的对象，本地方法栈中的Native方法引用的对象。

2.生存还是死亡

即使在可达性分析算法中不可达的对象，他们也不是“非死不可”的，要宣布一个对象的死亡，至少要经历两次标记过程：如果对象在进行可达性分析后发现没有与GC Roots相连的引用链，那么它会被第一次标记并进行一次筛选，条件是此对象是否有必要执行finalize()方法(此方法只执行一次)(当对象没有覆盖finalize()方法，或finalize()方法已经被虚拟机调用过，那么就没有必要执行)。

如果这个对象有必要执行finalize()方法，那就会将它放入F-Queue队列，并在稍后由一个由虚拟机自动创建的，低优先级的Finalizer线程取执行它(触发这个方法，但不承诺会等待它运行结束)。如果在finalize()方法中，对象重新与引用链上的任意一个对象关联，那么就将它移出“即将回收”的集合；如果对象没有逃脱，那么它将被回收。

3.回收方法区

很多人认为方法区(或HotSpot虚拟机中的永久代)是没有垃圾回收的，在Java虚拟机规范中不要求实现在方法区的垃圾回收，而且对方法区进行垃圾收集的“性价比”较低；在堆中，尤其是新生代中，进行一次垃圾收集一般可以回收百分之70-95的空间。

永久代的垃圾收集主要回收两部分：废弃常量和无用的类。例如字符串常量，假如系统中没有任何一个String对象指向“abc”，那么它将被清除。但是判定一个类是否“无用”的条件就要苛刻许多：在堆中不存在该类的任何实例

就在该类的ClassLoader已经被回收

该类对应的java.lang.Class对象没有在任何地方被引用，即无法在任何地方通过反射访问该类

4.垃圾收集算法标记-清除算法

如他的名字一样，该方法先标记出所有需要回收的对象(如何标记请看2)，在标记完成后统一回收被标记的对象。但它有两个明显的不足：一个是效率问题，标记和清除两个过程的效率都不高；另一个是空间问题，标记清除后产生大量不连续的内存碎片，可能导致以后在程序运行过程中需要分配较大对象时，无法找到足够的连续内存而不得不提前出发另一次垃圾回收。复制算法

该方法解决的是标记-清除算法的效率问题。它将可用内存划分为大小相等的两块，每次只是用其中一块。当这块内存用完了，就将还存活着的对象复制到另一块上面，然后把以使用过的内存空间一次性清理掉，这样每次只对半个区进行内存回收，也不用考虑内存碎片等复杂情况。但代价是将内存缩小为原来的一半。

现在商业的虚拟机都采用这种收集算法来回收新生代。

补充：

jvm区域总体分两类，heap区和非heap区。heap区又分：Eden Space(伊甸园)、Survivor Space(幸存者区)、Tenured Gen(老年代-养老区)。 非heap区又分：Code Cache(代码缓存区)、Perm Gen(永久代)、Jvm Stack(java虚拟机栈)、Local Method Statck(本地方法栈)。

新生代中百分之98的对象都是朝生夕死的所以HotSpot中Eden和Survivor空间的比例是8：1，当回收时，将Eden和Survivor中还存活的对象一次性复制到另一块Survivor(1)上，最后清理掉Eden和刚才用过的Survivor，当Survivor不够用时，就需要老年代进行分配担保。标记-整理算法

复制收集算法在对象存活率高时就要进行较多的复制操作，效率会变低。而在老年代中，存活的对象往往较多，没有额外空间可以为它担保，所以有人提出了这种算法。它与标记-清除类似，先标记需要回收的对象，然后将所有存活对象向一端移动，最后直接清理掉边界以外的内存。

分代收集算法

根据各个内存区域对象的特点采用不同的方法。

5.HotSpot算法实现枚举根节点

在可达性分析中，寻找从GC Roots节点找到引用链这个操作，需要先寻找GC Roots节点(需要到方法区和虚拟机栈中寻找)，如果要逐个遍历，必然会消耗很多时间。

另外，在寻找GC Roots节点时还必须保证“一致性”，这意味着一段时间内整个系统必须被冻结(“Stop The World”)。

在目前主流的Java虚拟机中，使用的都是准确式GC，也就是不需要检查完所有执行上下文和全局的引用位置，例如HotSpot的实现中，使用一组成为OopMap的数据结构来达到这个目的。当类加载完成后，HotSpot就把对象内什么偏移量上是什么类型的数据计算出来，这样GC扫描时就可以直接直到这些信息。安全点

如果为每条指令都生成对应的OopMap，那么将会需要大量的额外空间，实际上，HotSpot只在特定的位置记录下了这些信息，称为安全点。程序执行时并非所有地方都能停顿下来开始GC，只有达到安全点才能停顿。通常在方法调用，循环跳转，异常跳转处产生Safepoint。

对于Safepoint，另一个需要考虑的问题是如何在GC发生时让所有线程都运行到最近的安全点再停顿下来，这里有两种方案：抢先式中断和主动式中断。抢先式中断指在GC发生时，首先把所有线程终端，如果发现有不在安全点上的线程就恢复它，让运行到安全点上。而主动式终端的思想是当GC需要终端线程的时候，设置一个标志，各个线程执行时轮询这个标志，发现标志为真时就中断自己。轮询标志的地方和安全点是重合的。安全区域

安全点b保证了程序执行时，在不太长的时间内就会遇到可进入GC的安全点，但线程处于Sleep或Blocked状态，这种方法就不适用了，这时候就需要安全区域。

安全区域指一段代码中引用关系不会发生变化。在这个区域内任意地方开始GC都是安全的。当线程进入安全区域时，他会标记自己的状态，如果在这段时间里JVM要发起GC，那么是安全的；如果线程要离开Safe Region时，他要检查系统是否已经完成了根节点枚举，如果完成了那么它就继续执行，否则必须等待直到收到可以安全离开安全区域的信号为止。

6.HotSpot虚拟机GC算法采用分代收集算法一个对象出生后(new)会在Eden Space无忧无虑的生活，直到GC到来。GC会逐一询问每个对象的情况(根据GC Roots到各个对象的是否可达)，可达的对象们就会进入Survivor Space，不可达的就会被kill。

并不是进入Survivor Space就会安全。GC会定期检查Survivor Space中的对象是否依然可达，如果通过检查次数达到一定数量(默认15)，那么这个对象会进入Tenured Gen(老年代)。对于一些较大的对象 ( 即需要分配一块较大的连续内存空间 ) 则是直接进入到老年代。

进入到养老区的对象依然不是完全安全的，一段时间后GC发现它不可达依然会kill掉。

分区的目的：新生代大部分对象都是朝生夕灭的，所以直接采用复制算法，老年代对象生命力顽强，采用标记-整理算法。

7.垃圾收集器Serial收集器

最基本的收集器，单线程，进行垃圾回收时停掉所有工作，适用于新生代，采用复制算法。单线程应用效率高。ParNew收集器

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

也是新生代收集器，也采用复制算法，也是多线程收集器，它关注的是尽可能地缩短垃圾收集时用户线程的停顿时间。达到一个可控制的吞吐量(运行用户代码时间/(运行用户代码时间+垃圾回收时间))。Serial Old收集器

是Serial的老年代版本。采用标记整理算法。Parallel Old收集器

多线程和标记整理算法。Parallel Scavenge的老年代版本。CMS收集器

CMS收集器是目前老年代收集器中比较优秀的垃圾收集器。CMS是Concurrent Mark Sweep，从名字可以看出，这是一款使用"标记-清除"算法的并发收集器。CMS垃圾收集器是一款以获取最短停顿时间为目标的收集器。由于现代互联网中的应用，比较重视服务的响应速度和系统的停顿时间，所以CMS收集器非常适合在这种场景下使用。

CMS收集器运作过程分为下面四个步骤：

初始标记和重新标记依然需要“Stop The World”。初始标记标记下GC Roots能直接关联到的对象，速度很快；并发标记会从GC Roots 出发，标记处所有可达的对象；重新标记是为了修正并发标记期间因用户程序继续运作而导致标记产生变动的那一部分对象记录；最后并发的清除回收的对象。

但它依然有三个明显的缺点：首先，CMS收集器对CPU资源非常敏感。对于并发实现的收集器而言，虽然可以利用多核优势提高垃圾收集的效率，但是由于收集器在运行过程中会占用一部分的线程，这些线程会占用CPU资源，所以会影响到应用系统的运行，会导致系统总的吞吐量降低。

无法处理在并发清理阶段用户线程产生的新垃圾。

会产生大量碎片。

G1收集器

G1收集器不再将收集范围定为新生代或老年代，而是将整个Java堆划分为多个大小相等的独立区域，虽然保留着新生代老年代的概念，但它们不再物理隔离。G1跟踪各个区域里垃圾堆积的价值大小(回收所获得的空间以及回收所需时间的经验值)，在后台维护一个优先列表，每次根据允许的手机时间，优先回收价值最大的区域(Garbage-First)

在GC根节点的枚举范围中加入Remembered Set即可保证不对全堆扫描也不会遗漏。

如果不计算维护Remembered Set的操作，G1收集器的运作大致可划分为一下步骤：

(1)初始标记

(2)并发标记

(3)最终标记

(4)筛选回收

参考资料：

《深入理解Java虚拟机》