JVM-Garbage Collection(垃圾回收)

垃圾的定义

垃圾是指在运行程序中没有任何指针指向的对象,这个对象就是需要被回收的垃圾

GC的作用

• 防止内存被消耗完
• 整理出内存分配给新的对象

垃圾标记阶段

在堆里存放着几乎所有的Java对象实例,在GC执行垃圾回收之前,首先需要区分出内存中哪些是存活对象,哪些是已经死亡的对象.只有被标记为已经死亡的对象,GC才会在执行垃圾回收时,释放掉其所占用的内存空间,因此这个过程我们可以称之为垃圾标记阶段

对象死亡的标准

当一个对象已经不再被任何的存活对象继续引用时,就可以宣判为已经死亡

引用计数算法

引用计数算法(Reference Counting)比较简单,对每个对象保存一个整型对引用计数器属性.用于记录对象被引用的情况

优点

• 实现简单,垃圾对象便于标识
• 判定效率高,回收没有延迟性

缺点

• 需要单独的字段存储计数器,增加了存储空间开销
• 每次复制都需要更新计数器,增加了时间开销
• 引用计数器有一个严重的问题,即无法处理循环引用的情况,这是一条致命缺陷,所以HotSpot没有使用这种算法

循环引用

/**
 * @Author: wls  
 * @date: 2021/7/29 3:50 下午  
 */
public class RefCountGC {  
  
    //占用内存  
	private byte[] bigSize = new byte[5 * 1024 * 1024];  
  
 	Object reference = null;  
  
  
	public static void main(String[] args) {  
  
        RefCountGC a = new RefCountGC();  
 		RefCountGC b = new RefCountGC();  
 		a.reference = b;  
 		b.reference = a;  
  
 		a = null;  
 		b = null;  
	}
}

可达性分析算法(根搜索算法/追踪性垃圾收集)

相对于引用计数算法而言,可达性分析算法不仅同样具备实现简单和执行高效等特点,更重要的是该算法可以有效的解决在引用计数算法中循环引用的问题,防止内存泄漏的发生
如果要使用可达性分析算法来判断内存是否可回收,那么分析工作必须在一个能保证一致性的快照中进行.如果这点不满足的话,分析结果的准确性就无法保证,这也是导致GC进行时必须进行Stop The World的一个重要原因

基本思路

• 可达性分析算法是以根对象集合(GC Roots) 为起始点,按照从上至下的方式搜索被根对象集合所连接的目标对象是否可达
• 使用可达性分析算法后,内存中的存活对象都会被根对象集合直接或间接连接着,搜索所走过的路径称为引用链(Reference Chain)
• 如果目标对象没有任何引用链相连,则是不可达的,就意味着该对象已经死亡,可以标记为垃圾对象
• 在可达性分析算法中,只有能够被根对象集合直接或者间接连接的对象才是存活对象

GC Roots

所谓GC Roots根集合就是一组必须活跃的引用
由于GC Roots采用栈方式存放变量和指针,所以如果一个指针,它保存了堆内存里的对象,但是自己又不存放在堆内存里面,那他就是一个Root

GCRoots包括以下几类元素

• 虚拟机栈中引用的对象
  • 🌰 各个线程被调用的方法中使用到的参数、局部变量等
• 本地方法栈内JNI(本地方法)引用的对象
• 方法区中类静态属性引用的对象
  • 🌰 Java类的 引用类型 静态变量
• 方法区中的常量引用的对象
  • 🌰 字符串常量池里的引用
• 所有被Synchronized持有的对象
• Java虚拟机内部的引用
  • 🌰 基本数据类型对应的Class对象,一些常驻的异常对象,系统类加载器
• 反映Java虚拟机内部情况的JMXBean、JVMTI中注册的回调、本地代码缓存

对象的finalization机制

• Java语言提供了对象终止机制来允许开发人员提供对象被销毁前的自定义处理逻辑
• 当垃圾回收器回收没有引用指向的对象之前,总会先调用这个对象的finalize()方法
• finalize()方法允许在子类中被重写,用于在对象被回收时进行资源释放

对象的三种状态

• 可触及的 : 从根节点开始,可以到达这个对象
• 可复活的 : 对象的所有引用都被释放,但是对象有可能在finalize()中复活
• 不可触及的 : 对象的finalize()被调用,并且没有复活,那么就会进入不可触及状态.不可触及的对象不可能被,因为finalize()方法只会被调用一次

具体过程

判定一个对象是否可以被回收,至少要经历两次标记过程:

1. 如果一个对象a到 GC Roots 没有引用链,则进行一次标记
2. 进行筛选,判断对象a是否有必要执行finalize()方法
   1. 如果对象a没有重写方法,或者finalize()方法已经被虚拟机调用过,则虚拟机视为“没必要执行”,对象a被判定为不可触及的
   2. 如果对象a重写了finalize()方法,且还未执行过,那么对象a会被插入到F-Queue队列中,由一个虚拟机自动创建、低优先级的Finalizer线程触发其finalize()方法执行
   3. finalize()方法是对象逃脱死亡的最后机会,稍后GC会对F-Queue队列中的对象进行第二次标记,如果对象a在finalize()方法中与引用链上的任何一个对象建立了联系,那么在第二次标记时,对象a会被移出“即将回收”集合.之后,对象会再次出现没有引用存在的情况.在这个情况下,finalize方法不会被再次调用,对象会直接变成不可触及的状态,也就是说,一个对象的finalize方法只会被调用一次

垃圾清除阶段

当成功区分出内存中存活对象和死亡对象后,GC接下来的任务就是执行垃圾回收,释放掉无用对象所占用的内存空间,以便有足够的可用内存空间为新对象分配内存

标记-清除算法(Mark-Sweep)

![[第14章_标记-清除算法.jpg]]

执行过程

• 标记 : Collector从引用根节点开始遍历,标记所有被引用的对象.一般是在对象的Header中记录为可达对象
• 清除 : Collector对堆内存从头到尾进行线性遍历,如果发现某个对象在其Header中没有记录为可达对象,则将其回收

缺点

• 执行效率不高
• 在进行GC的时候需要停止整个应用程序,导致用户体验差
• 这种方式清理出来的空闲内存是不连续的,产生内存碎片.需要维护一个空闲列表

所谓的清除并不是真的置空,而是把需要清除的对象地址保存在空闲的地址列表里.下次有新对象需要加载时,判断垃圾的位置空间是否足够,如果够就存放

复制算法(Copying)

![[第14章_复制算法.jpg]]

核心思想

将内存空间分为两块,每次只使用其中一块,在垃圾回收时将正在使用的内存中的存活对象复制到未被使用的内存块中,之后清除正在使用的内存块中的所有对象,交换两个内存的角色,最后完成垃圾回收

优点

• 没有标记和清除过程,实现简单,运行高效
• 复制过去以后保证空间的连续性,不会出现“碎片”问题

缺点

• 此算法的缺点也很明显,就是需要两倍的内存空间
• 对于G1这种拆分成大量region的GC,复制而不是移动,意味着GC需要维护region之间对象引用关系,不管是内存占用或者时间开销都不小

应用场景

• 复制算法适用于系统中的垃圾对象很多,需要复制的存活对象数量非常低
• 在新生代,对常规应用对垃圾回收,一次通常可以回收70%-99%的内存空间.回收性价比很高.所以现在的商业虚拟机都是用这种收集算法回收新生代
  🌰 : Young区的 S0 和 S1 区

标记-压缩算法(Mark-Compact)

标记-压缩算法的最终效果等同于标记-清除算法执行完后,再进行一次内存碎片整理,因此,也可以把它称为标记-清除-压缩(Mark-Sweep-Compact)算法
二者的本质差异在于标记-清除算法是一种非移动式的回收算法,标记-压缩是移动式的.是否移动回收后的存活对象是一项优缺点并存的风险决策

执行过程

• 第一阶段和标记清除一样,从根节点开始标记所有被引用对象
• 第二阶段将所有的存活对象压缩到内存的一端,按顺序排放
• 清理边界外所有空间

优点

• 清除了标记-清除算法中,内存区域分散的缺点,我们需要给新对象分配内存时,JVM只需要持有一个内存的起始地址即可
• 消除了复制算法当中内存减半的高额代价

缺点

• 从效率上来说,标记-整理算法要低于复制算法
• 移动对象的同时,如果对象被其他对象引用,还需要调整引用地址
• 移动过程中,需要全程暂停用户应用程序.即STW

指针碰撞(Bump The Pointer)

如果内存空间以规整和有序的方式分布,即已用和未用的内存都格子以便,彼此之间维系着一个记录下次分配的起始点的标记指针,作为新对象分配内存是,只需要修改指针的偏移量将对象分配在第一个空闲内存位置上,这种分配方式就叫指针碰撞

分代收集算法

分代收集算法,是给予这样一个事实:不同的对象的生命周期是不一样的.因此,不同生命周期的对象可以采取不同的收集方式,以便提高回收效率.一般是把Java堆分为新生代和老年代,这样就可以根据各个年代的特点使用不同的回收算法,以提高回收的效率
目前几乎所有的GC都是采用分代收集(Generational Collecting)算法执行垃圾回收的

HotSpot

在HotSpot中,基于分代的概念,GC所使用的内存回收算法必须结合年轻代和老年代各自的特点

年轻代

特点 : 区域相对于老年代较小,对象生命周期短、存活率低,回收频繁
这种情况复制算法的回收整理,速度是最快的.复制算法的效率只和当前存活对象大小有关,因此很适用于年轻代的回收.而复制算法内存利用率不高的问题,通过HotSpot中的两个Survivor的设计得到缓解

老年代

特点 : 区域较大,对象生命周期长,存活率高,回收不及年轻代频繁
这种情况存在大量存活率高的对象,复制算法明显变得不合适.一般是由标记-清除或标记-整理的混合实现

• Mark阶段的开销与存活对象的数量成正比
• Sweep阶段的开销与所管理区域的大小成正相关
• Compact阶段的开销与存活对象的数据成正比

增量收集算法、分区算法

增量收集算法

基本思想

如果一次性将所有的垃圾进行处理,需要造成系统长时间的停顿,那么就可以让垃圾收集线程和应用程序线程交替执行.每次,垃圾收集线程只收集一小片区域的内存空间,接着切换到应用程序线程.依次反复,直到垃圾收集完成

增量收集算法的基础仍是传统的标记-清除和复制算法.增量收集算法通过对线程间冲突的妥善处理,允许垃圾收集线程以分阶段的方式完成标记、清理或复制工作

缺点

使用这种方式,由于在垃圾回收的过程中,间断性的还执行了应用程序代码,所以能减少系统的停顿时间.但是因为线程切换和上下文转换的消耗,会使得垃圾回收的总体成本上升,造成系统吞吐量的下降

分区算法

![[第14章_分区算法.jpg]]
一般来说,在相同条件下,堆空间越大,一次GC时所需时间就越长,有关GC产生的停顿也就越长.为了更好的控制GC产生的停顿时间,将一块大的内存区域分割成多个小块,根据目标的停顿时间,每次合理的回收若干个小区间,而不是整个堆空间,从而减少一次GC所产生的停顿

垃圾回收相关概念

System.gc()的理解

在默认情况下,通过System.gc()或者Runtime.getRuntime().gc()的调用,会显式触发Full GC,同时对老年代和新生代进行回收,尝试释放被丢弃对象占用的内存

然而System.gc()调用附带一个免责声明,无法保证对垃圾收集器的调用
JVM实现者可以通过System.gc()调用来决定JVM的GC行为.而一般情况下,垃圾回收应该是自动进行的,无需手动触发.

内存溢出(Out Of Memory)

• javadoc 中对OutOfMemoryError的解释是,没有空间内存,并且垃圾收集器也无法提供更多内存
• 由于GC一直在发展,所以一般情况下,除非应用程序占用的内存增长速度非常快,否则不太容易出现OOM的情况
• Java虚拟机的堆内存不足
  1. Java虚拟机的堆内存设置不够
  2. 代码中创建了大量大对象,并且长时间不能被垃圾收集器收集(存在被引用)

内存泄漏(Memory Leak)

也称作“存储渗漏”.严格来说 ,只有对象不会再被程序用到了,但是GC又不能回收他们的情况,才叫内存泄漏

但实际情况很多时候一些不太好的实践(或疏忽)会导致对象的生命周期变得很长甚至导致OOM,也可以叫做宽泛意义上的“内存泄漏”

🌰

1. 单例模式
   单例的生命周期和应用程序一样长,所以单例程序中,如果持有对外部对象的引用的话,那么这个外部对象是不能够被回收的,则会导致内存泄漏产生
2. 一些提供close的资源未关闭导致内存泄漏
   数据库连接,网络连接和IO连接等必须手动close,否则不能被回收

Stop The World

• Stop-The-World,简称STW,指的是GC事件发生过程中,会产生应用程序的停顿.停顿产生时整个应用程序线程都会被暂停,没有任何影响,有点像卡死的感觉,这个停顿称为STW.

  • 可达性分析算法中枚举根节点会导致所有Java执行线程停顿
    • 分析工作必须在一个能保证一致性的快照中进行
    • 一致性指整个分析期间整个执行系统看起来像被冻结在某个时间点上
    • 如果出现分析过程中对象引用关系还在不断变化,则分析结果的准确性无法保证

• STW事件和采用那款GC无关,所有的GC都有这个事件

• 哪怕是G1也不能完全避免Stop-The-World 情况发生,只能说垃圾回收器越来越优秀,回收效率越来越高,尽可能地缩短了暂停时间

• STW是JVM在后台自动发起和自动完成的.在用户不可见的情况下,把用户正常的工作线程都停掉

• 开发中不要用System.gc();会导致Stop-The-World发生

垃圾回收的并行与并发

并发(Concurrent)

• 在操作系统中,是指一个时间段中有几个程序都处于已启动运行到运行完毕之间,且这几个程序都是在同一个处理器上运行
• 并发不是真正意义上的“同时进行”,只是CPU把一个时间段划分成几个时间片段(时间区间),然后在这几个时间区间之间来回切换,由于CPU处理的速度非常快,只要时间间隔处理得当,即可让用户感觉是多个应用程序同时在进行

并行(Parallel)

• 当系统有一个以上CPU时,当一个CPU执行一个进程时,另一个CPU可以执行另一个进程,两个进程互不抢占CPU资源,可以同时进行,我们称之为并行(Parallel)
• 其实决定并行的因素不是CPU的数量,而是CPU的核心数量

安全点与安全区域

安全点(Safepoint)

程序执行时并非在所有地方都能停顿下来开始GC,只有在特定的位置才能停顿下来开始GC,这些位置称为“安全点”

Safe Point 的选择很重要,如果太少可能导致GC等待的时间太长,如果太频繁可能导致运行时的性能问题. 大部分指令的执行时间都非常短暂,通常会根据 “是否具有让程序长时间执行的特征”为标准.比如:选择一些执行时间较长的指令作为Safe Point.🌰 : 方法调用、循环跳转和异常跳转等

如何在GC发生时,检查所有线程都跑到最近的安全点停顿下来呢?

• 抢先式中断:(目前没有虚拟机采用了)
  首先中断所有线程.如果还有线程不再安全点,就恢复线程,让线程跑到安全点
• 主动式中断
  设置一个中断标志,将各个线程运行到Safe Point的时候主动轮询这个标志,如果中断标志为真,则将自己进行中断挂起

安全区域(Safe Region)

安全区域是指在一段代码片段中,对象的引用关系不会发生变化,在这个区域中的任何位置开始GC都是安全的.我们也可以把Safe Region看作是被扩展的Safe Point

实际执行时

1. 当线程运行到Safe Region的代码时,首先标识已经进入了Safe Region,如果这段时间内发生GC,JVM会忽略标识为Safe Region状态的线程
2. 当线程即将离开Safe Region时,会检查JVM是否已经完成GC,如果完成了,则继续运行,否则线程必须等待知道收到可以离开Safe Region的信号为止

引用

在JDK1.2 版本之后,Java对引用的概念进行了扩充,将引用分为强引用、软引用、弱引用、虚引.强 软 弱 虚 这四种引用强度依次逐渐减弱
除强引用外,其他3种可以在java.lang.ref包种找到它们的身影
![[WeChatf82f53fb9221d4017559513bee421bda.png]]

• 强引用(Strong Reference)
  最传统的“引用”的定义,是指在程序代码之中普遍存在的引用复制,即类似“Object obj = new Object()”这种引用关系.无论任何情况下,只要强引用关系还存在,垃圾收集器就永远不会回收掉被引用的对象
• 软引用(Soft Reference)
  在系统将要发生内存溢出之前,将会把这些对象列入回收范围之中进行第二次回收.如果这次回收之后还没有足够的内存,才会抛出内存溢出异常
• 弱引用(Weak Reference)
  被弱引用关联的对象只能生存到下一次垃圾收集之前.当垃圾收集器工作时,无论内存空间是否够,都会回收掉被弱引用关联当对象.
• 虚引用(Phantom Reference)
  一个对象是否有虚引用的存在,完全不会对其生存时间构成影响,也无法通过虚引用来获得一个对象的实例.为一个对象设置虚引用关联的唯一目的就是能在这个对象被收集器回收时收到一个系统通知

强引用(Strong Reference)—不回收

在Java程序中,最常见的引用类型是强引用(普通系统99%以上都是强引用),也就是最常见的普通对象引用,也是默认的引用类型

当在Java语言中使用new操作符创建一个新的对象,并将其赋值给一个变量当时候,这个变量就称为指向该对象的一个强引用

强引用的对象是可触及的,垃圾回收器就永远不会回收掉被引用的对象

对于一个普通的对象,如果没有其他的引用关系,只要超过了引用的作用域或者显式地将相应强引用赋值为null,就是可以当作垃圾被收集了

强引用是造成内存泄漏的主要原因之一

特点

• 强引用可以直接访问目标对象
• 强引用所指向的对象在任何时候都不会被系统回收,虚拟机宁愿抛出OOM异常,也不会回收强引用所指向对象
• 强引用可能导致内存泄漏

软引用(Soft Reference)—内存不足即回收

软引用用来描述一些还有用,但非必须的对象.只被软引用关联着的对象,在系统将要发生内存溢出异常之前,会把这些对象列进回收范围之中进行第二次回收,如果这次回收还没有足够的内存,才会抛出内存溢出异常

软引用通常用来实现内存敏感的缓存.比如:高速缓存就有用到软引用.如果还有空闲内存,就可以暂时保留缓存,当内存不足时清理掉,这样就保证了使用缓存的同时,不会耗尽内存.Mybatis的缓存也用到了软引用

垃圾回收器在某个时刻决定回收软可达的对象的时候,会清理软引用,并可选的把引用存放到一个软引用队列(Reference Queue)

在JDK 1.2版本后提供了java.lang.ref.SoftReference类来实现软引用

	//生命强引用  
	Object obj = new Object();  
	SoftReference<Object> sr = new SoftReference<>(obj);  
	//销毁强引用  
	obj = null;

弱引用(Weak Reference)—发现即回收

• 弱引用也是用来描述哪些人非必需对象,只被弱引用关联的对象只能生存到下一次垃圾收集发生为止.在系统GC时,只要发现弱引用,不管系统堆空间使用是否充足,都会回收掉只被弱引用关联的对象

• 但是,由于垃圾回收器的线程通常优先级很低,因此并不一定能很快地发现持有弱引用的对象.在这种情况下,弱引用对象可以存在较长的时间.

• 弱引用和软引用一样,在构造弱引用时,可以指定一个引用队列,当弱引用对象被回收时,就会加入指定的引用队列,通过这个队列可以跟踪对象的回收情况

• 软引用、弱引用都非常适合来保存那些可有可无的缓存数据

• 在JDK 1.2版本后提供了java.lang.ref.SoftReference类来实现软引用

	//生命强引用  
	Object obj = new Object();  
	WeakReference<Object> wr = new WeakReference<>(obj);  
	//销毁强引用  
	obj = null;

弱引用与软引用的区别

弱引用对象与软引用对象的最大不同就在与,当GC在进行回收时,需要通过语法检查是否回收软引用对象,而弱引用对象,GC总是进行回收.弱引用对象更容易、更快被GC回收

WeakHashMap

#TODO

虚引用(Phantom Reference)

• 也称为“幽灵引用” 或者“幻影引用”,是所有引用类型中最弱的一个.
• 一个对象是否有虚引用的存在,完全不会决定对象的生命周期.如果一个对象仅持有虚引用,那么它和没有引用几乎是一样的,随时都有可能被垃圾回收器回收.
• 它不能单独使用,也无法通过虚引用来获取被引用的对象.当试图通过虚引用的get()方法取得对象时,总是null
• 为一个对象设置虚引用关联对唯一目的在于跟踪垃圾回收过程.比如:能在这个对象被收集时收到一个系统通知
• 虚引用必须和引用队列一起使用.虚引用在创建时,必须提供一个引用队列作为参数.当垃圾回收器准备回收一个对象时,如果发现它还有虚引用,就会在回收对象后,将这个虚引用加入引用队列,以通知应用程序对象的回收情况
• 由于虚引用可以追踪对象的回收时间,因此可以将一些资源释放操作放置在虚引用中执行和记录
• 在JDK 1.2版本后提供了java.lang.ref.SoftReference类来实现软引用

	Object obj = new Object();  
	ReferenceQueue phantomQueue = new ReferenceQueue();  
	PhantomReference<Object> pr = new PhantomReference<Object>(obj, phantomQueue);  
	obj = null;

终结器引用

• 用以实现对象的finalize()方法,也可以称为终结器引用
• 无需手动编码,其内部配合引用队列使用
• 在GC时,终结器引用入队.由Finalizer线程通过终结器引用找到被引用对象,并调用它的finalize()方法,第二次GC时才能回收被引用对象