内存回收知识点

JVM内存回收/垃圾收集知识点总结，包括回收时机、回收算法等相关支持，，希望这份脑图会对你有所帮助。

内存回收

• 回收什么
  • 回收区域
    • 方法区
    • 堆
      • 新生代
        • Eden
        • Survivor0（回收时使用）
        • Survivor1
      • 老年代
  • 回收对象
    • 引用计数算法
      • 优点
        • 实现简单
        • 效率高
      • 缺点
        • 存在误判
    • 可达性分析算法
      • 原理：判断对象是否有到GC Roots的路径
        • GC Roots
          • 虚拟机栈中引用的对象
          • 类的静态属性引用的对象
          • 方法区中常量引用的对象
          • JNI引用的对象
        • 引用链
          • 强引用：存在引用就不回收
          • 软引用：发生OOM时回收
          • 弱引用：第二次GC时回收
          • 虚引用：照常回收，只发通知
      • 优点：解决循环引用问题
• 何时回收
  • 内存不足
    • 新生代内存不足
    • 老年代内存不足
      • Major GC多数情况发生在老年代，但并不是一定不在新生代发生
  • 程序主动调用System.gc
• 何处回收
  • 安全点
    • 回收时用户程序执行到安全点暂停
    • 概念：长时间执行的地方（指令复用）
    • 常见场景：方法调用、循环、异常跳转等
    • 问题：如果此时用户线程处于中断或Sleep则无法走到安全点
  • 安全区域
    • 概念：引用关系不会发生变化的代码片段
    • 可看作是安全点的扩展，用来解决安全点中的问题
    • 线程运行到安全区域时进行标记，GC时不关心该线程；线程离开安全区域时判断是否在GC，如果是则等待GC结束
• 怎么回收
  • 收集算法
    • 标记—清除算法
      • 原理：将不使用的对象/内存进行标记，然后将标记的内存清除
      • 优点：原理简单、直接、易于理解
      • 缺点：效率低、产生内存碎片
    • 标记—整理算法
      • 原理：将不使用的对象标记，并将所有存活的对象移到内存的一端
      • 优点：不存在内存碎片
    • 复制算法
      • 原理：将内存一分为二，当1内存不足时，将存活的对象复制到2上，同时清除1
      • 优点：实现简单、运行高效
      • 缺点：浪费空间、存活率高时效率急剧下降
    • 分代收集算法
      • 原理：根据内存不同的分区，采用以上不同的算法
      • 优点：能够根据内存特点最大限度利用最高效的算法，提升整体回收效率
  • 收集器
    • Serial
      • 复制算法
      • 单线程
      • STW/GC停顿
      • 单个线程简单高效
      • 适合Client模式应用
        • Client模式应用由于是用户桌面应用，分配的内存不会太多，因此回收时长不会太长，也就是说回收造成的停顿时间不会太长，因此对用户不会造成明显的感知变化
    • ParNew
      • 复制算法
      • 多线程、并行收集
      • STW/GC停顿
      • G1前Server应用的首选
        • 唯一能跟CMS配合使用且为多线程的收集器
      • Serial的多线程版本
    • Parallel Scavenge
      • 复制算法
      • 多线程、并行收集
      • STW/GC停顿
      • 吞吐量优先
        • 概念：用户代码的时间 / 总CPU时间
          • 总CPU时间 = （运行用户代码的时间 + 垃圾收集时间）
        • 配置参数
          • -XX:GCTimeRatio
            • 说明：取值范围1-100，如值为19，则吞吐量为95%（19/（19+1））
          • -XX:MaxGCPauseMillis
      • 适合不需要太多用户交互的应用
      • 具有自适应调节策略
    • G1
      • 标记—整理（+复制）算法
      • 原理：将内存划分为多块（Region），分块回收
        • -XX:G1HeapRegionSize
        • 内标记—整理，间复制
      • 物理上不存在新生代和老年代
      • 多线程、并发收集
      • STW/GC停顿
      • 面向Server应用
      • 步骤
        • 初始标记
        • 并发标记
        • 最终标记
        • 筛选回收
          • 分析每个Region内存情况，确定回收价值
          • 根据设定的停顿时间及回收价值确定回收的Region
      • 优点
        • 并行、并发
        • 分代收集，不需要任何其他收集器配合
        • 可预测停顿时间
          • -XX:MaxGCPauseMillis
          • JVM尽量去满足，但不保证一定满足
      • 最佳实践：使用G1时不要设置新生代大小
    • 新生代收集器
    • Serial Old
      • 标记—整理算法
      • 单线程
      • STW/GC停顿
      • Serial的老年代版本
      • 适合Client应用
      • CMS的后备预案
        • 在CMS发生Concurrent Mode Failure时使用
    • Parallel Old
      • 标记—整理算法
      • 多线程、并行收集
      • STW/GC停顿
      • Parallel Scanvenge的老年代版本
      • 吞吐量优先
      • 适合不需要太多用户交互的应用
      • 具有自适应调节策略
    • CMS
      • 标记—清除算法
      • 多线程、并发收集
      • STW/GC停顿（初始标记和重新标记阶段停顿）
      • 并发低停顿、最求最短停顿时间
      • 步骤
        • 初始标记：停顿，只标记GC Roots能直接关联到的对象
        • 并发标记：扫描标记所有对象
        • 重新标记：停顿，标记并发标记期间程序执行导致的变化
        • 并发清除：清除无用内存
      • 缺点
        • 对CPU资源非常敏感：回收期间程序运行会变慢
        • 无法处理“浮动垃圾”
          • 浮动垃圾：并发清除期间程序产生的垃圾
          • -XX:CMSInitiatingOccupancyFraction
            • 由于CMS回收内存期间程序依然在运行，而程序运行需要一部分内存，所以CMS并不是在内存不够分配时才进行垃圾回收，而是在内存占用到一定比例时进行回收，这个比例可通过该参数设置；JDK1.6后默认为92%
          • Concurrent Mode Failure
            • 如果CMS进行垃圾回收期间预留给程序运行的内存无法满足程序运行的需要，则会发生“Concurrent Mode Failure”，这时会启动后备预案临时采用Serial Old收集器对老年代进行一次垃圾回收
        • 产生内存碎片，浪费空间
          • -XX:UseCMSCompactAtFullCollection
            • 设置CMS每次执行Full GC都进行内存的合并整理，注意内存的合并整理是不能并发的，因此会有长时间的停顿
          • -XX:CMSFullGCsBeforeCompaction
            • 设置CMS在多少次Full GC后进行一次带有内存整理的Full GC
    • 老年代收集器