垃圾回收概述
- 什么是垃圾？
- 垃圾指的是运行程序中没有任何指针指向的对象，这个对象就是需要被回收的垃圾
- 垃圾回收不是Java的伴生产物，早在1960年，第一门使用动态内存分配和垃圾回收的Lisp语言就诞生了
- 为什么需要GC？
- 1.如果不进行垃圾回收，内存早晚用完
- 2.垃圾回收也可以整理内存碎片，jvm可以用整理出的内存分配对象
- 3.随着应用程序所应付的业务越来越庞大，复杂，用户越来越多，没有GC就无法保证程序的正常进行。而经常造成STW的GC又跟不上实际的需求，所以要不断对GC进行优化
- 早期垃圾回收
- 早期，C/C++都是程序员手动分配内存和回收内存的，很繁琐，这就很容易忘记回收内存，造成内存泄露。垃圾对象永远不能被清除，随着系统运行，垃圾对象越来越多，最后可能造成程序崩溃
- 现在，除了Java以外，C#、Python、Ruby等语言都使用了自动垃圾回收的思想，也是未来发展趋势。可以说，这种自动化的内存分配和垃圾回收的方式己经成为现代开发语言必备的标准。
- Java的垃圾回收机制
垃圾回收相关算法
一个对象不被任何引用指向的时候就可以宣判死亡
垃圾标记阶段
- 在垃圾回收之前，先在内存中标记哪些是需要清理的对象，这个阶段就是垃圾标记阶段
- 引用计数器
- 每个对象保存一个整型的引用计数器属性，用于记录对象被引用的情况。有一个对象引用它，它的计数器就加一，一个对象取消引用，计数器就减一，为零时就可以清除
- 优点：实现简单、垃圾对象便于标识；判定效率高，回收没有延迟
- 缺点：
- 1.需要单独的字段储存计数器，增加了内存开销
- 2.每次赋值给变量都需要更新计数器，增加了时间开销
- 3.循环引用的对象不能判断，容易造成内存泄露，这是Java虚拟机不使用这种方式的主要原��
- 可达性分析算法
- 它对比引用计数器的方式，不仅同样具备高效和简洁的特点，而且也很好地解决了判断循环引用的问题，防止内存泄露的发生
- 相较于引用计数器，这里的可达性分析就是Java，C#选择的。这种类型的垃圾收集也叫做 追踪性垃圾收集（Tracing Garbage Collection）
- 可达性分析算法基本思路：
- 可达性分析算法是以根对象集合（GC Roots）为起始点，按照从上到下的方式 搜索被根对象集合所连接的目标对象是否可达
- 使用可达性算法之后，内存中的存活对象都会被根对象集合直接活间接连接着，搜索所走过的路径称为引用链（Reference Chain)
- 如果目标对象没有任何引用链相连，就是不可达的，意味着该对象已经死亡，可以标记为垃圾对象
- 在可达性分析算法中，只有能够被根对象集合直接或间接连接的对象才是存活对象
- GC Roots
- 虚拟机栈中引用的对象
- 比如：各个线程被调用的方法中使用到的参数、局部变量等
- 本地方法栈内JNI(通常说的本地方法)引用的对象
- 方法区中类静态变量引用的对象
- 比如：Java类的引用类型静态变量
- 方法区中常量引用的对象
- 比如：字符串常量池（String Table）里的引用，final静态变量
- 所有被同步锁synchronized持有的对象
- Java虚拟机内部的引用
- 基本数据类型对应的Class对象，一些常驻的异常对象（如：NullPointerException、OutOfMemoryError），系统类加载器
- 反映Java虚拟机内部情况的JMXBean、JVMTI中注册的回调、本地代码缓存等。
- 【在面试答上的话，很加分】除了这些固定的GC Roots集合外，根据用户所选用的垃圾收集器以及当前回收的内存区域不同，还可以有其他对象"临时性"地加入，共同构成完整GC Roots集合。比如：分代收集和局部回收（Partial GC）
- 如果只针对Java堆中的某一块区域进行垃圾回收（比如：只针对新生代），必须考虑到内存区域是虚拟机自己的实现细节，更不是孤立封闭的，这个区域的对象完全有可能被其他区域的对象所引用（比如老年代），这时候就需要一并将关联的区域对象也加入GC Roots集合中考虑，才能确保可达性分析的准确性
- 【简单来说，有被GC区域外变量指向 / 对象引用 的对象，就是GC Roots】
- 虚拟机栈中引用的对象
对象的finalization机制
- Java语言提供了对象终止（finalization）机制来允许开发人员提供对象被销毁之前的自定义处理逻辑
- 当垃圾回收器发现没有引用指向一个对象，就会在回收这个对象之前，调用这个对象的finalize方法
- finalize方法允许在子类中被重写，用于在对象被回收时进行资源释放，比如关闭文件、套接字、数据库连接等
- 但是永远都要主动调用某个对象的finalize方法，应该交给垃圾回收机制调用
- 在finalize()时可能会导致对象复活
- finalize方法的执行时间是没有保障的，它完全由GC线程决定，极端情况下若不发生GC，则finalize方法将没有执行机会
- 一个糟糕的finalize方法会严重影响GC的性能
- 从功能上来说，finalize方法与C++中的析构函数比较相似，但是Java采用的是基于垃圾回收器的自动内存管理机制，所以finalize方法在本质上不同于C++中的析构函数
- 由于finalize方法的存在，虚拟机中的对象一般处于三种可能的状态
- 不被回收的（可触及的）：根节点开始，可以到达这个对象
- 可复活的：对象的所有引用都被释放，但是对象有可能在finalize中复活
- 将被回收的（不可触及的）：对象的finalize被调用，并且没有复活，那么就会进入将被回收的（不可触及）状态。将被回收的（不可触及）的对象不可能被复活，因为finalize只会被调用一次
- 判断一个对象objA是否可回收的标记过程：
- 1.如果对象objA到GC Roots没有引用链，则进行第一次标记
- 2.进行筛选，判断此对象是否有必要执行finalize方法
- a.如果对象objA没有重写finalize方法，或者finalize方法已经被虚拟机调用过，则虚拟机视为"没有必要执行"，objA被判定为不可触及的
- b.如果对象objA重写了finalize方法，且没有执行过，那么就把objA插入到F-Queue队列中，由一个虚拟机自动创建的、低优先级的Finalizer线程触发其finalize方法执行
- c.finalize方法是对象逃脱死亡的最后机会，稍后GC会对F-Queue队列中的对象进行第二次标记。如果objA在finalize方法中与引用链上任何一个对象建立了联系，那么在第二次标记时，objA会被移出"即将回收"集合。之后，对象会再次出现没有引用存在的情况。在这个情况下，finalize方法不会再被调用，对象会直接变成不可触及的状态，也就是说，一个对象的finalize方法只会被调用一次
垃圾清除阶段
- 当成功区分出存活对象和死亡对象后，GC接下来的任务就是清除无用对象，释放内存空间
- 目前jvm有三种常见的垃圾收集算法
- 标记---清除算法(Mark---Sweep)
- 背景：是一种非常基础和常见的垃圾收集算法，该算法被J.McCarthy等人在1960年提出并应用于Lisp语言
- 执行过程：
- 当堆中的有效内存空间(available memory)不足时，就会停止整个程序（SWT stop the world)，然后进行标记 和 清除
- 标记：
- 从GC Roots往下遍历，标记所有被引用的对象（很多帖子说是不被引用的对象，是错的）。一般是在对象的Header中记录为可达对象
- 清除：Collector对堆内存从头到尾遍历，如果发现某个对象在Header中没有被标记为可达对象，则将其进行回收
- 注意：这里的清除，其实不是真的删对象。而是把无用对象的内存地址 标记到空闲列表里。下次有新对象要加载时，判断内存空间是否足够，够的话就存放
- 缺点
- 效率不算高
- 在进行GC的时候，需要停止整个应用程序，导致用户体验差
- 这种方式清理出来的空闲内存是不连续的，产生内存碎片。需要维护一个空闲列表【碎片过多的话，导致大对象分配不了，OOM】
- 复制算法(Copying)
- 背景：为了解决标记-清除算法在垃圾收集效率方面的缺陷，M.工.Minsky于1963年发表了著名的论文，"使用双存储区的Lisp语言垃圾收集器CALISP Garbage Collector Algorithm Using SerialSecondary Storage)"。M.L.Minsky在该论文中描述的算法被人们称为复制(Copying)算法，它也被M.L.Minsky本人成功地引入到了Lisp语言的一个实现版本中。
- 核心思想：将内存空间分成相同大小的两半。每次只在一个区域使用对象，垃圾回收时，将GC Roots引用的对象复制到另一个区域，清除掉现在正在使用的区域的所有对象。后面再次垃圾回收，两个区域就调转角色，一直循环使用
- 优点：
- 没有标记和清除过程，实现简单，运行高效
- 复制过去以后保证了空间的连续性，不会出现内存碎片
- 缺点：
- 需要两倍的内存空间
- 对于G1这种拆分成大量region的GC，复制而不是移动，意味着GC需要维护region之间对象引用关系，不管是内存占用或者时间开销也不小
- 特别的：
- 如果系统的垃圾很少，每次要复制的对象数量很多，就不适用
- 特别适合垃圾对象很多，存活对象很少的场景：比如Survivor 0和Survivor 1区
- 标记---压缩(Mark---Compact)算法 或 标记---整理算法 或 标记---清除---压缩算法
- 背景：
- 复制算法的高效性是建立在存活对象少、垃圾对象多的前提下的。这种情况在新生代经常发生，但是在老年代，更常见的情况是大部分对象都是存活对象。如果依然使用复制算法，由于存活对象较多，复制的成本也将很高。因此，基于老年代垃圾回收的特性，需要使用其他的算法。
- 标记一清除算法的确可以应用在老年代中，但是该算法不仅执行效率低下，而且在执行完内存回收后还会产生内存碎片，所以JM的设计者需要在此基础之上进行改进。标记一压缩(Mark-Compact)算法由此诞生。
- 1970年前后，G.L.Steele、C.J.Chene和D.S.Wise等研究者发布标记-压缩算法。在许多现代的垃圾收集器中，人们都使用了标记-压缩算法或其改进版本。
- 执行过程：
- 第一阶段和标记---清除算法一样，都是标记被引用的对象
- 第二个阶段是把被标记的对象压缩到内存的一端，按顺序摆放
- 之后就是清理边界外的所有空间
- 和标记---清除算法的比较：
- 标记---压缩算法的最终效果等同于标记---清除算法执行完之后，再进行一次内存碎片整理。因此也可以称之为 标记---清除---压缩算法
- 二者的本质差异在于，标记---清除算法是一种非移动式的回收算法，标记---压缩是移动式的。是否移动回收后的内存对象是一项优缺点并存的风险决策
- 可以看到，标记---压缩算法会整理存活的对象，安装内存地址依次排列。这样的话，当我们需要给新对象分配内存时，jvm只需要持有一个内存的起始地址即可，比维护空闲内存表的花销低很多
- 指针碰撞：如果内存空间规整有序，已用和未用的内存各占一边，中间用一个指针隔开，为新对象分配内存时，只需要修改指针的偏移量，将新对象分配到第一个空闲内存位置上，这种分配方式称为指针碰撞
- 优点：
- 消除了标记---清除算法当中，内存区域分散的缺点，我们需要给新对象分配内存时，jvm只需要持有一个空闲内存的起始地址即可
- 消除了复制算法中，内存减半的高额代价
- 缺点：
- 效率低于复制算法
- 移动对象时，如果对象被其他对象引用，，需要调整引用的地址
- 移动过程中，需要全程暂停用户应用程序，STW
- 背景：
- 标记---清除算法(Mark---Sweep)
分代回收算法：其实就是因为不同的对象有不同的生命周期，然后就进行分代，不同的代用不同的垃圾回收算法
增量收集算法
- 背景：上面的垃圾回收算法，都需要STW，如果垃圾回收算法时间过长，应用程序会挂起很久，将严重影响用户体验或系统的稳定性
- 基本思想：每次垃圾回收线程只收集一小片的内存空间，然后切换到应用程序线程，依次反复，直到垃圾收集完成
- 这个算法还是基于传统的标记---清除 和 复制算法。增量收集算法通过对线程间冲突的妥善处理，允许垃圾收集线程以分阶段的方式完成标记、清理和复制工作
- 缺点：使用这种方式，在垃圾回收过程中，间断地执行应用程序代码，所以能减少系统的停顿时间。但是，因为线程切换和上下文转换的消耗，会使垃圾回收的总成本上升，造成系统吞吐量的下降
分区算法
- 一般来说，相同条件下，垃圾回收的区域越大，一次GC用的时间就越长。为了更好地控制GC的时间，可以将一块大的内存区域分割成多个小块，根据目标的停顿时间，每次合理地回收若干个小区间，而不是整个堆空间，从而减少一次GC的停顿
- 分代算法是按照对象生命周期长短划分成两个部分。分区算法是将整个堆空间划分成连续的不同小区间
- 每一个小区间单独使用，独立回收。这样的好处是可以控制一次回收多少个小区间，来控制GC的停顿时间