jvm垃圾收集

jvm垃圾收集

今天在想一个问题，如果某个人问我介绍一下JVM垃圾收集机制，我该如何介绍？

大致思路

结合JVM垃圾收集的大致方向，我想会以这么个顺序进行介绍：

1. JVM的默认垃圾收集器，G1收集器，G1的特点。
2. 判断对象是否死亡的方法
3. 垃圾收集的算法以及垃圾收集器使用的算法。

JVM的默认垃圾收集器，G1收集器，G1的特点

JVM默认的垃圾收集器为Serial Old 与 Parallel Scavenge 配合使用。使用java -XX:+PrintCommandLineFlags -version，即可看到如图下所示的垃圾收集器，

从下图知道，该收集器是Serial Old 与 Parallel Scavenge 配合使用.（老年代是串行回收器（Serial），新生代是并行回收器（Parallel））

针对垃圾收集器的调优，可以将虚拟机的收集器改为G1收集器，G1收集器分为以下特点：
适用于多核大内存机器、GC 多线程并行执行，低停顿、高回收效率
G1收集器将新生代和老年代取消了，取而代之的是将堆划分为若干的区域，每个区域都可以根据需要扮演新生代的Eden和Survivor区或者老年代空间，仍然属于分代收集器，区域的一部分包含新生代，新生代采用复制算法，老年代采用标记-整理算法。

通过将JVM堆分为一个个的区域（region）,G1收集器可以避免在Java堆中进行全区域的垃圾收集。G1跟踪各个region里面的垃圾堆积的价值大小（回收所获得的空间大小以及回收所需时间的经验值），在后台维护一个优先列表，每次根据回收时间来优先回收价值最大的region。

G1收集器的特点：

并行与并发：G1能充分利用多CPU，多核环境下的硬件优势，来缩短Stop the World，是并发的收集器。
分代收集：G1不需要其他收集器就能独立管理整个GC堆，能够采用不同的方式去处理新建对象、存活一段时间的对象和熬过多次GC的对象。
空间整合：G1从整体来看是基于标记-整理算法，从局部（两个Region）上看基于复制算法实现，G1运作期间不会产生内存空间碎片。
可预测的停顿：能够建立可以预测的停顿时间模型，预测停顿时间。
对于生产环境的高配服务使用G1比默认收集器器更好。

判断对象是否死亡的方法

引用计数器

1. 为每一个对象添加一个引用计数器，统计指向该对象的引用次数。
2. 当一个对象有相应的引用更新操作时，则对目标对象的引用计数器进行增减。
3. 一旦当某个对象的引用计数器为 0 时，则表示此对象已经死亡，可以被垃圾回收。

这个方法存在一些问题： 在主流的Java 虚拟机中并没有选用引用计数算法来管理内存，主要是因为这个简单的计数方式在处理一些相互依赖、循环引用等就会非常复杂。可能会存在不再使用但又不能回收的内存，造成内存泄漏。

可达性分析算法

它的算法思路是通过定义一系列称为 GC Roots 根对象作为起始节点集，从这些节点出发，穷举该集合引用到的全部对象填充到该集合中（live set）。这个过程教过标记，只标记那些存活的对象 好，那么现在未被标记的对象就是可以被回收的对象了。

作为GC Roots的有：
1.启动且未停止的线程
2.全局性引用，对方法区的静态对象、常量对象的引用
3.执行上下文，对Java方法栈帧中的局部引用对象等。
这个方法同样存在几个问题：

1. 误报：已死亡对象被标记为存活，垃圾收集不到。多占用一会内存，影响较小。
2. 漏报：引用的对象（正在使用的）没有被标记为存活，被垃圾回收了。那么直接导致的就是 JVM 奔溃。（STW 可以确保可达性分析法的准确性，避免漏报）

垃圾收集的算法以及垃圾收集器使用的算法。

JVM虚拟机都是通过可达性分析算法来判断对象是否死亡的，对应的垃圾收集的算法有：
标记-清除
标记无引用的死亡对象所占据的空闲内存，并将其清除，简单高效，但内存碎片化严重。
标记-压缩
标记过程与标记清楚一样，但是在对象清理前，会先把存活对象往一端移动，然后在清理其他空间，解决了内存碎片化的问题，但是算法的性能开销不小。
标记-复制
把内存区域分为两部分，当发生内存回收的时候，将存活对象放到另一个区域。解决了内存碎片化问题，但是，也造成堆空间的浪费。

JVM虚拟机默认的垃圾收集器的垃圾回收算法是标记复制和标记压缩的配合使用，如何配合，目前不太了解。
G1收集器使用的是标记压缩算法。