Java GC 必知必会

1. Java 如何标识垃圾

常用的标识算法主要是两类，一是计数器引用法，二是可达性分析（根搜索算法）。

• 计数器引用法

• 可达性分析
  基本思路：

  • 已根对象集合为起点，按照从上之下的方式搜索被根对象集合所连接的目标对象是否可达。
  • 使用可达性分析算法后，内存中的存活对象都会被根对象集合直接或间接连接着，搜索所走过的路径成为引用链.

image.png

2. GC ROOTS 包含哪些？

• 虚拟机栈中引用的对象
  》 比如各个线程中被调用的方法中使用的参数，局部变量
• 本地方法栈引用的对象
• 方法区中类静态属性引用的对象
  》 java类的引用类型静态变量
• 方法区中常量引用的对象
  》 字符串常量池里面的应用
• 被synchronized持有的对象
• java虚拟机内部的引用
• 反映java虚拟机内部情况的JMXBean，JVMTI中的回调，本地代码缓存等。

特殊情况：
有对象“临时性”的加入，共同构成完成GC Roots集合。比如分代收集和局部回收（Partial GC）

image.png image.png

3. 为什么会产生STW

如果要使用可达性分析算法来判断内存是否可回收，那么分析工作必须在一个能保障一致性的快照中进行。这点不满足的话，那分析的结果准确性也就无法保障。

所以就会产生了Stop The World的一个重要原因。

4. 对象的finalization机制

• 用于开发人员对对象被销毁前的自定义逻辑处理。通常用于对象被回收时，进行资源释放和清理的工作。

• 关闭文件流，关闭数据库连接等。

finalization为什么不要手工调用

• 有可能导致对象复活
• finalization的执行时间点不确定。在极端情况下，如果不发生GC，那么finalization将永远不会被执行。

finalization 导致对象复活的情况
在虚拟机定义中，对象存在三种状态
1. 可触及的：从GC ROOT可达
2. 可复活的：对象多有的引用都被释放了，但是对象可能在finalization（） 被复活。
3. 不可触及的：对象的finalization（）被调用，并且没有复活。那么就会就如不可触及的状态。不可触及的对象就一定会被回收。因为finalization只会被调用一次。

5. 如何判断一个对象是否可以被回收？

判断一个对象能否被收回，至少要经历两次判断。

1. 如果objA到GC Roots没有引用链，则进行第一次标记
2. 判断对象是否有必要执行finalization（）方法
   • 如果没有重写finalization（）或者finalization（）已经被执行过了，则被判断为不可触及的。
   • 如果对象重写了finalization（）方法，且还未被执行过。那么objA会被插入到F-Queue队列中，由一个虚拟机自动创建的低优先级的finalizer线程触发其finalization（）。

• finalization（）是对象逃脱死亡的最后机会。稍后GC会对F-Queue 队列中的对象进行二次标记。 如果objA在此时与引用链上的任何一个对象建立了联系，那么objA会被移出“即将回收”集合。

6. JVM GC 清除阶段的算法

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

image.png image.png

• 优点： 比较容易理解
• 缺点

1. 效率不算高
2. 会产生内存碎片，还需要额外的空间维护一个空闲列表。

6.2 复制算法（Copying）

image.png image.png

优点：

• 保证空间连续，不会出现碎片问题
• 实现相对简单，运行高效

缺点：

• 需要两倍的空间
• 当系统存活的对象数量很多时，性能较低。（所以只能用于新生代）

6.3 标记-压缩算法（Mark-Compact）

image.png image.png

优点

• 没有内存碎片
• 减少了内存的浪费

缺点

• 从效率来说，标记整理算法要低于复制算法
• 移动对象的同时，如果对象被其他对象引用，则还需调整引用地址。
• STW的时间相比于其他要长一些，因为涉及到对象的移动和引用更新。

image.png

7. GC 分带收集算法&增量收集算法&分区算法

分带收集算法

image.png

增量收集算法

image.png

分区算法

image.png

8. System.gc()和Runtime.getRuntime().gc()的理解

• 默认情况下，通过System.gc()和Runtime.getRuntime().gc()显示调用时，会触发Full GC，同时对老年代和新生代进行回收，尝试释放对象占用的内存。
• System.gc()无法保证对垃圾回收器的调用
• Sysmte.gc()等同与Runtime.getRuntime().gc()

gc与slot的关系

image.png

在这个案例中 buffer所占用空间不会被回收，因为slot=1的位置还是被buffer这个变量所占用。在gc时，属于GC Root可达的情况。

9. 程序的并行与并发

image.png

垃圾回收器的并行与并发

image.png image.png

10. GC 中的安全点与安全区域的说明

• Safepoint

  
  image.png

如何让线程在安全点中断：

image.png

• SafeRegion

  
  image.png

实际执行流程

image.png

11. java引用：强，软，弱，虚

• 强引用：不回收

  1. 强引用的对象的GC Root可达的，所以垃圾回收器永远不会回收。
  2. 强引用也是造成内存泄漏的主要原因之一。

• SoftReference 软引用：内存不足时及回收

  1. 用于描述一下有用但是非必须的对象。只被弱引用关联者的对象，在系统将要发生内存溢出前，会把这些对象列入回收范围内进行二次回收。如果这次回收还是没有足够的内存，才会报出OOM。
  2. 一般使用场景是：如mybaits中的本地缓存

• WeakReference 弱引用：发现即回收

1. 只被弱引用关联的对象，只能存活到下一次GC发生为止。
2. 常用的实现类是WeekHashMap，在Tomcat中作为了一个LRU的cache实现。

软引用和弱引用的区别点：

image.png

• PhantomReference 虚引用：
  image.png

2. 使用场景：追踪垃圾回收

• ** 终结器引用：**
  对象finalization的底层实现

  
  image.png