JVM内存管理---垃圾收集器

时间  2019-11-25
标签 jvm 内存 管理 垃圾 收集 栏目 Java 繁體版
原文   原文链接

提及垃圾收集（Garbage Collection，GC），大部分人都把这项技术当作Java语言的伴生产物。事实上，GC的历史远比Java久远，1960年诞生于MIT的Lisp是第一门真正使用内存动态分配和垃圾收集技术的语言。当List还在胚胎时期时，人们就在思考GC须要完成的3件事情：算法

  • 哪些内存须要回收？
  • 何时回收？
  • 如何回收？

1、哪些内存须要回收？安全

从JVM区域结构看，可将这些区域划分为“静态内存”和“动态内存”两类。程序计数器、虚拟机栈、本地方法3个区域是“静态”的，由于这几个区域的内存分配和回收都具有肯定性，都随着线程而生，随着线程而灭。但Java堆和方法区不同，内存分配都存在不肯定性，只有在程序处于运行期间才能知道会建立哪些对象，这部份内存和回收都是动态的，垃圾收集器所关注的是这部份内存。多线程

在堆里面存放着Java世界几乎全部的对象实例，垃圾回收器在对堆进行回收前，第一件事情就是就是要肯定这些对象哪些还"存活"着，哪些已经"死去"。那么又怎么肯定对象已经"死去"呢？并发

1.引用计数法：测试

分配对象时给对象添加一个引用计数器，每当有一个地方引用它时，计数器值就加1；当引用失效时，计数器值就减1；任什么时候刻计数器为0的对象就是没有再被使用了。客观地说，引用计数法（Reference Counting）的实现简单，判断效率也很高，可是在主流的Java虚拟机里面没有选用引用计数法来管理内存，其中最主要的缘由是它很难解决对象之间相互循环引用的问题。例如：线程

public class ReferenceCountingGC {

    public Object instance = null;
    private byte[] bigsize = new byte[2*1024*1024];

    public static void testGC(){
        ReferenceCountingGC objA = new ReferenceCountingGC();
        ReferenceCountingGC objB = new ReferenceCountingGC();
        
        objA.instance = objB;
        objB.instance = objA;
        
        objA = null;
        objB = null;
        
        System.gc();
    }
}

当设置objA = null;objB = null后这两个对象再无任何引用，实际上这两个对象已经不可能再被访问，可是它们由于互相引用着对方，致使它们的引用计数都不为0，因而引用计数算法没法通知GC收集器回收它们。若是这个对象特别大，则会形成严重的内存泄露。设计

2.可达性分析算法：调试

可达性分析（Reachability Analysis）的基本思想是经过一系列的称为“GC Roots”的对象做为起始点，从这些节点开始向下搜索，搜索所走过的路径称为引用链（Reference Chain），当一个对象到GC Roots没有任何引用链相连时（也就是GC Roots到这个对象不可达），则证实此对象是不可用的。以下图所示：code

对象Object五、Object六、Object7相互虽然有关联，可是它们到GC Roots是不可达的，因此它们将会被断定为是可回收的对象。在Java语言中，可做为GC Roots的对象包括下面几种：对象

虚拟机栈（栈帧中的本地变量表）中引用的对象。
方法区中类静态属性引用的对象。
方法区中常量引用的对象。
本地方法栈中JNI（即通常说的Native方法）引用的对象。

2、何时回收？

虚拟机为了分析GC Roots这项工做必须在一个能确保一致性的快照中进行，这里的“一致性”的意思就是指在整个分析期间整个执行系统看起来就像被冻结在某个时间点上——这叫安全点。固然，程序执行时并不是在全部地方都能停顿下来开始GC，只有到达安全点时才能暂停。安全点选址也有规定的，选定基本上是以程序“是否具备让程序长时间执行的特征”为标准进行选定的。这里的长时间执行的最明显特征是指令列复用，例如方法调用、循环跳转、异常跳转等。

虚拟机为了能让全部线程都“跑”到安全点上停顿下来，设计了两个方案：抢先式中断和主动式中断。其中抢先式中断是虚拟机发生GC时，首先把全部线程所有中断，若是发生有线程中断的地方不在安全点上，就恢复线程，让它“跑”到安全点上。这种方式如今比较用了。而主动式中断是虚拟机须要GC时仅仅简单的设置一个标志，各个线程执行到安全点时主动去轮询这个标志，发现中断标志为真时就本身中断挂起。

3、如何回收？

3.1 垃圾收集算法:

（1）标记-清除（Mark-Sweep）算法

这是最基础的算法，就像它名字同样，算法分为“标记”和“清除”两个阶段：首先标记处全部须要回收的对象（如哪些内存须要回收所描述的对象），对标记完成后统一回收全部被标记的对象，以下图所示：

缺点：一个是效率问题，标记和清除两个过程的效率都不高；另外一个是空间问题，标记清除后悔产生大量的不连续的内存碎片，可能会致使后续没法分配大对象而致使再一次触发垃圾收集动做。

（2）复制算法

为了针对标记-清除算法的不足，复制算法将可用内存容量划分为大小相等的两块，每次只使用一块。当一块的内存用完了，就将还存活的对象复制到另外一块上面去。而后把已使用过的内存空间一次清理掉，以下图所示：

缺点：使用内存比原来缩小了一半。

如今的商业虚拟机都采用这种收集算法来回收新生代，有企业分析的得出其实并不需求将内存按1:1的比例划分，由于新生代中的对象大部分都是“朝生夕死”的。因此，HotSpot虚拟机默认的Eden和Survivor的大小比例是8:1。一块Eden和两块Survivor，每次使用一块Eden和一块Survivor，也就是说只有10%是浪费的。若是另外一块Survivor都没法存放上次垃圾回收的对象时，那这些对象将经过“担保机制”进入老年代了。

（3）标记-整理（Mark-Compact）算法
复制算法通常是对对象存活率较低的一种回收操做，但对于对象存活率较高的内存区域（老年代）来讲，效果就不是那么理想了，标记-整理算法所以诞生了。标记-整理算法和标记-清除算法差很少，都是一开始对回收对象进行标记，但后续不是直接对对象清理，而是让全部存活的对象都向一端移动，而后直接清理掉端边界之外的内存，以下图所示：

（4）分代收集算法

分代收集算法是目前大部分JVM的垃圾收集器采用的算法。它的核心思想是根据对象存活的生命周期将内存划分为若干个不一样的区域。通常状况下将堆区划分为老年代（Tenured Generation）和新生代（Young Generation），老年代的特色是每次垃圾收集时只有少许对象须要被回收，而新生代的特色是每次垃圾回收时都有大量的对象须要被回收，那么就能够根据不一样代的特色采起最适合的收集算法。

3.2 垃圾收集器：

（1）七种垃圾收集器:

  • Serial（串行GC）-复制
  • ParNew（并行GC）-复制
  • Parallel Scavenge（并行回收GC）-复制
  • Serial Old（MSC）（串行GC）-标记-整理
  • CMS（并发GC）-标记-清除
  • Parallel Old（并行GC）--标记-整理
  • G1（JDK1.7update14才能够正式商用）

说明：

  • 1~3用于年轻代垃圾回收：年轻代的垃圾回收称为minor GC
  • 4~6用于年老代垃圾回收（固然也能够用于方法区的回收）：年老代的垃圾回收称为full GC
  • G1独立完成"分代垃圾回收"

注意：并行与并发

  • 并行：多条垃圾回收线程同时操做
  • 并发：垃圾回收线程与用户线程一块儿操做

(2)经常使用五种组合:

  • Serial/Serial Old
  • ParNew/Serial Old：与上边相比，只是比年轻代多了多线程垃圾回收而已
  • ParNew/CMS：当下比较高效的组合
  • Parallel Scavenge/Parallel Old：自动管理的组合
  • G1：最早进的收集器，可是须要JDK1.7update14以上

(2.1)Serial/Serial Old：

特色：

  • 年轻代Serial收集器采用单个GC线程实现"复制"算法（包括扫描、复制）
  • 年老代Serial Old收集器采用单个GC线程实现"标记-整理"算法
  • Serial与Serial Old都会暂停全部用户线程（即STW）

说明：

STW（stop the world）：编译代码时为每个方法注入safepoint（方法中循环结束的点、方法执行结束的点），在暂停应用时，须要等待全部的用户线程进入safepoint，以后暂停全部线程，而后进行垃圾回收。

适用场合：

  • CPU核数<2，物理内存<2G的机器（简单来说，单CPU，新生代空间较小且对STW时间要求不高的状况下使用）
  • -XX:UseSerialGC：强制使用该GC组合
  • -XX:PrintGCApplicationStoppedTime：查看STW时间
  • 因为它实现相对简单，没有线程相关的额外开销（主要指线程切换与同步），所以很是适合运行于客户端PC的小型应用程序，或者桌面应用程序（好比swing编写的用户界面程序），以及咱们平时的开发、调试、测试等。

(2.2)ParNew/Serial Old：

说明：

  • ParNew除了采用多GC线程来实现复制算法之外，其余都与Serial同样，可是此组合中的Serial Old又是一个单GC线程，因此该组合是一个比较尴尬的组合，在单CPU状况下没有Serial/Serial Old速度快（由于ParNew多线程须要切换），在多CPU状况下又没有以后的三种组合快（由于Serial Old是单GC线程），因此使用其实很少。
  • -XX:ParallelGCThreads：指定ParNew GC线程的数量，默认与CPU核数相同，该参数在于CMS GC组合时，也可能会用到

(2.3)Parallel Scavenge/Parallel Old：

特色：

  • 年轻代Parallel Scavenge收集器采用多个GC线程实现"复制"算法（包括扫描、复制）
  • 年老代Parallel Old收集器采用多个GC线程实现"标记-整理"算法
  • Parallel Scavenge与Parallel Old都会暂停全部用户线程（即STW）

说明：

  • 吞吐量：CPU运行代码时间/(CPU运行代码时间+GC时间)
  • CMS主要注重STW的缩短（该时间越短，用户体验越好，因此主要用于处理不少的交互任务的状况）
  • Parallel Scavenge/Parallel Old主要注重吞吐量（吞吐量越大，说明CPU利用率越高，因此主要用于处理不少的CPU计算任务而用户交互任务较少的状况）

参数设置：

  • -XX:+UseParallelOldGC：使用该GC组合
  • -XX:GCTimeRatio：直接设置吞吐量大小，假设设为19，则容许的最大GC时间占总时间的1/(1 +19)，默认值为99，即1/(1+99)
  • -XX:MaxGCPauseMillis：最大GC停顿时间，该参数并不是越小越好
  • -XX:+UseAdaptiveSizePolicy：开启该参数，-Xmn/-XX:SurvivorRatio/-XX:PretenureSizeThreshold这些参数就不起做用了，虚拟机会自动收集监控信息，动态调整这些参数以提供最合适的的停顿时间或者最大的吞吐量（GC自适应调节策略），而咱们须要设置的就是-Xmx，-XX:+UseParallelOldGC或-XX:GCTimeRatio两个参数就好（固然-Xms也指定上与-Xmx相同就好）

适用场合：

  • 不少的CPU计算任务而用户交互任务较少的状况
  • 不想本身去过多的关注GC参数，想让虚拟机本身进行调优工做
  • 对吞吐量要求较高，或须要达到必定的量。

(2.4)ParNew/CMS：

说明：

  • 以上只是年老代CMS收集的过程，年轻代ParNew看"2.二、ParNew/Serial Old"就好
  • CMS是多回收线程的，不要被上图误导，默认的线程数：(CPU数量+3)/4

  • CMS主要注重STW的缩短（该时间越短，用户体验越好，因此主要用于处理不少的交互任务的状况）
    特色：

  • 年轻代ParNew收集器采用多个GC线程实现"复制"算法（包括扫描、复制）
  • 年老代CMS收集器采用多线程实现"标记-清除"算法
    • 初始标记：标记与根集合节点直接关联的节点。时间很是短，须要STW
    • 并发标记：遍历以前标记到的关联节点，继续向下标记全部存活节点。时间较长。
    • 从新标记：从新遍历trace并发期间修改过的引用关系对象。时间介于初始标记与并发标记之间，一般不会很长。须要STW
    • 并发清理：直接清除非存活对象，清理以后，将该线程占用的CPU切换给用户线程

  • 初始标记与从新标记都会暂停全部用户线程（即STW），可是时间较短；并发标记与并发清理时间较长，可是不须要STW

关于并发标记期间怎样记录发生变更的引用关系对象，在从新标记期间怎样扫描这些对象

缺点：

  • 并发标记与并发清理：按照说明的第二点来说，假设有2个CPU，那么其中有一个CPU会用于垃圾回收，而另外一个用于用户线程，这样的话，以前是两CPU运行用户线程，如今是一个，那么效率就会急剧降低。也就是说，下降了吞吐量（即下降了CPU使用率）。
  • 并发清理：在这一过程当中，产生的垃圾没法被清理（由于发生在从新标记以后）
  • 并发标记与并发清理：因为是与用户线程并发的，因此用户线程可能会分配对象，这样既可能对象直接进入年老代（例如，大对象），也可能进入年轻代后，年轻代发生minor GC，这样的话，实际上要求咱们的年老代须要预留必定空间，也就是说要在年老代还有必定空间的状况下就要进行垃圾回收，留出必定内存空间来供其余线程使用，而不能等到年老代快爆满了才进行垃圾回收，经过-XX:CMSInitiatingOccupancyFraction来指定当年老代空间满了多少后进行垃圾回收

  • 标记-清理算法：会产生内存碎片，因为是在老年代，可能会提早触发Full GC（这正是咱们要尽可能减小的）
    参数设置：

  • -XX:+UseConcMarkSweepGC：使用该GC组合
  • -XX:CMSInitiatingOccupancyFraction：指定当年老代空间满了多少后进行垃圾回收
  • -XX:+UseCMSCompactAtFullCollection：（默认是开启的）在CMS收集器顶不住要进行FullGC时开启内存碎片整理过程，该过程须要STW
  • -XX:CMSFullGCsBeforeCompaction：指定多少次FullGC后才进行整理

  • -XX:ParallelCMSThreads：指定CMS回收线程的数量，默认为：(CPU数量+3)/4

适用场合：

  • 用于处理不少的交互任务的状况
  • 方法区的回收通常使用CMS，配置两个参数：-XX:+CMSPermGenSweepingEnabled与-XX:+CMSClassUnloadingEnabled
  • 适用于一些须要长期运行且对相应时间有必定要求的后台程序

(2.5)G1

说明：

  • 从上图来看，G1与CMS相比，仅在最后的"筛选回收"部分不一样（CMS是并发清除），实际上G1回收器的整个堆内存的划分都与其余收集器不一样。
  • CMS须要配合ParNew，G1可单独回收整个空间

原理：

  • G1收集器将整个堆划分为多个大小相等的Region
  • G1跟踪各个region里面的垃圾堆积的价值（回收后所得到的空间大小以及回收所需时间长短的经验值），在后台维护一张优先列表，每次根据容许的收集时间，优先回收价值最大的region，这种思路：在指定的时间内，扫描部分最有价值的region（而不是扫描整个堆内存），并回收，作到尽量的在有限的时间内获取尽量高的收集效率。

运做流程：

  • 初始标记：标记出全部与根节点直接关联引用对象。须要STW
  • 并发标记：遍历以前标记到的关联节点，继续向下标记全部存活节点。
    在此期间全部变化引用关系的对象，都会被记录在Remember Set Logs中
  • 最终标记：标记在并发标记期间，新产生的垃圾。须要STW
  • 筛选回收：根据用户指定的指望回收时间回收价值较大的对象（看"原理"第二条）。须要STW

优势：

  • 停顿时间能够预测：咱们指定时间，在指定时间内只回收部分价值最大的空间，而CMS须要扫描整个年老代，没法预测停顿时间
  • 无内存碎片：垃圾回收后会整合空间，CMS采用"标记-清理"算法，存在内存碎片
  • 筛选回收阶段：
    • 因为只回收部分region，因此STW时间咱们可控，因此不须要与用户线程并发争抢CPU资源，而CMS并发清理须要占据一部分的CPU，会下降吞吐量。
    • 因为STW，因此不会产生"浮动垃圾"（即CMS在并发清理阶段产生的没法回收的垃圾）

适用范围：

  • 追求STW短：若ParNew/CMS用的挺好，就用这个；若不符合，用G1
  • 追求吞吐量：用Parallel Scavenge/Parallel Old，而G1在吞吐量方面没有优点
相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程