JVM学习笔记：垃圾回收Java虚拟机中线程不共享的部分：Java虚拟机栈、本地方法栈、程序计数器不需要回收，会随着线程

Java虚拟机中线程不共享的部分：Java虚拟机栈、本地方法栈、程序计数器不需要回收，会随着线程销毁而销毁

-XX:+TraceClassLoading打印类被加载过程

-XX:+TraceCkassYbkiadubf打印类被卸载的过程

手动触发垃圾回收：System.gc(); 调用System.gc();不一定会立即垃圾回收，仅仅是向Java虚拟机发送一个垃圾回收的请求，具体是否需要执行垃圾回收Java虚拟机会自行判断

查看垃圾回收信息：-verbose:gc

方法区回收

方法区中能回收的内容主要是不再使用的类

判断一个类可以被卸载需要满足下面三个条件

此类所有实例对象都已经被回收，在堆中不存在任何该类的实例对象以及子类对象
加载该类的类加载器已经被回收
该类对应的java.lang.Class对象没有在任何地方被引用

自己编写的类由于是使用应用程序类加载器加载的就不会被回收，开发中此类场景一般很少出现，主要在如OSGI、JSP的热部署等应用场景中。每个jsp文件对应一个唯一的类加载器，当一个jsp文件修改了，就直接卸载这个jsp类加载器。

堆回收(关键)

如何判断堆上的对象可以回收

Java中的对象是否能被回收，时根据对象是否被栈上的局部变量引用来决定的。如果对象被引用了，说明该对象还在使用，不允许回收。需要回收A的实例对象需要去除两个引用1、栈中a1变量到对象的引用 2、B对象到A对象的引用

a1=null,b1=null也能回收A和B的实例对象，去除了从局部变量访问A和B的实例对象的途径，所以可以被回收

常见有两种判断方式

引用计数法

引用计数法会为每个对象维护一个引用计数器，当对象被引用时加1，取消引用时减1

引用计数法的优点是实现简单，C++中的智能指针就采用了引用计数法，但它也存在缺点，主要有两点**：**

每次引用和取消引用都需要维护计数器，对系统性能会有一定影响
存在循环引用问题，所谓循环引用就是当A引用B，B同时引用A时会出现对象无法回收的问题

可达性分析法

Java使用的是可达性分析算法来判断对象是否可以被回收。可达性分析将对象分为两类**：垃圾回收的根对象（GC Root）和普通对象**，对象与对象之间存在引用关系

可达性分析算法指的是如果从GC Root引用链到该对象是可达的，对象就不可被回收

哪些对象是GC Root对象

线程Thread对象

在Java中每个线程都是由一个Thread对象来表示的。Thread类位于java.lang包中，用于创建和管理线程，该Thread对象就是GC Root对象

系统类加载器加载的java.lang.Class对象,引用类中的静态变量

sun.misc.Launcher主要作用是设置并启动应用的类加载器，初始化运行环境，负责加载核心类，管理不同的类加载器的顺序，尤其是Bootstrap ClassLoader、ExtClassLoader和AppClassLoader,确保核心库和应用类的加载顺序正确。

监视器对象，用来保存同步锁synchronized关键字持有的对象

synchronized持有的对象会通过一个监视器对象来引用

sychronized 可以通过以下两种方式来锁定对象：

    1. **实例方法上的 **`**synchronized**`**（锁当前实例）**

当一个实例方法被 synchronized 修饰时，线程需要获得当前实例对象（即 this）的锁才能执行该方法。也就是说，synchronized 修饰的实例方法会锁住调用该方法的对象实例。

示例：


public class Example {
    public synchronized void instanceMethod() {
        // 持有当前实例对象（this）的锁
        System.out.println("Executing synchronized instance method");
    }
}

在这里，线程进入 instanceMethod() 方法时，会持有该 Example 类实例（this）的锁，其他线程必须等待，直到锁被释放。

    2. **静态方法上的 **`**synchronized**`**（锁类对象）**

当静态方法被 synchronized 修饰时，线程需要获得类对象的锁（即 Example.class）才能执行方法。静态方法属于类而非实例，因此它的锁是整个类的 Class 对象，所有该类的实例共享同一个锁。

示例：


public class Example {
    public static synchronized void staticMethod() {
        // 持有 Example.class 的锁
        System.out.println("Executing synchronized static method");
    }
}

在这里，线程进入 staticMethod() 时会锁定整个 Example 类，而不只是单个实例。

    3. **代码块上的 **`**synchronized**`**（锁任意对象）**

使用 synchronized 代码块时，可以指定锁的对象，这个对象可以是任意的（如实例对象、类对象或其他共享资源对象）。这种方式灵活性更高，可以控制锁的粒度。

示例：


public class Example {
    private final Object lock = new Object();  // 任意对象

    public void syncBlockMethod() {
        synchronized (lock) {  // 锁定 lock 对象
            System.out.println("Executing synchronized block");
        }
    }
}

在这个例子中，syncBlockMethod() 方法内的代码块会锁定 lock 对象，不会与其他使用 this 或 Example.class 作为锁的同步方法发生竞争，除非其他代码也锁定了同一个 lock 对象。

本地方法调用时使用的全局对象

五种对象引用

可达性算法中描述的对象引用，一般指的是强引用，即是GCRoot对象对普通对象有引用关系，只有有这层关系存在，普通对象就不会被回收。除了强引用，还有其他几种引用方式：软引用、弱引用、虚引用、终结器引用

软引用

当程序内存不足时，就会将软引用中的数据进行回收。

软引用中的对象如果在内存不足时回收，SoftReference对象本身也需要被回收，如何知道哪些SoftReference对象需要回收呢?

SoftReference提供了一套队列机制：

软引用创建时，通过构造器传入引用队列
在软引用中包含的对象被回收时，该引用对象会放入引用队列
通过代码遍历引用队列，将SoftReference的强引用删除

软引用的使用场景-缓存

软引用对象需要保存HashMap的key以便在软引用被回收之后

弱引用

弱引用机制和软引用基本一致，区别在于弱引用包含的对象在垃圾回收时，不管内存够不够都会直接被回收

在JDK1.2之后提供了WeakReference类来实现弱引用，弱引用主要在ThreadLocal中使用

弱引用对象本身也可以使用引用队列进行回收

虚引用和终结器引用

这两种引用在常规开发中是不会使用的
虚引用也叫幽灵引用/幻影引用，不能通过虚引用对象获取到包含的对象。虚引用唯一的用途是当对象被垃圾回收器回收时可以接收到对应的通知。Java中使用PhantomReference实现了虚引用，直接内存中为了及时指导直接内存对象不再使用，从而回收内存，使用了虚引用来实现
终结器引用指的是在对象需要被回收时，终结器引用会关联对象并放置在Finalizer类中的引用队列中，在稍后由一条由FinalizerThread线程从队列中获取对象，然后执行对象的finalize方法，在对象第二次被回收时，该对象才真正的被回收。在这个过程中可以在finalize方法中再将自身对象使用强引用关联上，但是不建议这样做。

垃圾回收算法

垃圾回收要做的有两件事

找到内存中存活的对象
释放不在存活对象的内存，使得程序能再次利用这部分空间

垃圾回收算法历史

垃圾回收算法的评价标准

Java垃圾回收过程会通过单独的GC线程来完成，但是不管使用哪一种GC算法，都会有部分阶段需要停止所有的用户线程。这个过程被称之为Stop The World简称STW，如果STW时间过长则会影响用户的使用。

所以判断GC算法是否优秀可以从三个方面考虑

吞吐量

吞吐量指的是CPU用于执行用户代码的时间与CPU总执行时间的比值，即吞吐量=执行用户时间代码/(执行用户代码的时间+GC时间)吞吐量数值越高，垃圾回收的效率越高

比如虚拟机总共运行了100分钟，其中GC花费1分钟，吞吐量就是99%

最大暂停时间

最大暂停时间指的是在垃圾回收过程中的STW时间最大值

堆使用效率

不同垃圾回收算法对堆内存的使用方式是不同的。比如标记清楚算法可以使用完整的堆内存。而复制算法会将堆内存一分为二，每次只能使用一半内存。从堆的使用效率上来说，标记清除算法优于复制算法

三种评价标准不可兼得，一般来说堆内存越大，最大暂停时间就越长。想要减少最大暂停时间就会降低吞吐量

标记清除算法

标记清楚算法的核心思想分为两个阶段

1、标记阶段，标记所有存活的对象。Java中使用可达性分析算法，从GC Root开始通过引用链遍历出所有存活对

象。

2、清除阶段，从内存中删除没有被标记的对象

优点：实现简单，只需要在第一阶段给每个对象维护标志位，第二阶段删除对象即可

缺点：

1、碎片化问题

由于内存是连续的，所以在对象被删除之后，内存中会出现很多细小的可用内存单元。如果我们需要的是一个比较大的空间，很有可能这些内存单元的大小过小无法进行分配。

2、分配速度慢。由于内存碎片的存在，需要维护一个空闲链表，极有可能每次遍历到链表最后才能获得合适的内存空间

复制算法

1、复制算法的核心思想是把对内存分为两块，一块是From，一块是To

  在对象分配阶段，只能使用其中一块空间（From空间）

2、在垃圾回收GC阶段，将From中存活对象复制到To空间（GC Root及关联的对象搬运到To空间）

3、清理From空间，并互换名称

优点：

吞吐量高：复制算法只需要遍历一次存活对象复制到To空间即可，比标记-整理算法少了一次遍历过程，因而性能较好，但是不如标记-清除算法，因为标记-清除算法不需要进行对象的移动

不会发生碎片化：复制算法在复制之后就会将对象按顺序放入To空间中，所以对象意外的区域都是可用空间，不存在碎片化内存空间

缺点：内存使用效率低

标记整理算法

标记整理算法也叫标记压缩算法，是对标记清除算法中容易产生内存碎片问题的一种解决方案

核心思想分为两个阶段：

1、标记阶段，将所有存活的对象进行标记。Java中使用可达性分析算法，从GCRoot开始通过引用链遍历出

所有存活对象。

2、整理阶段，将存货对象移动到堆的一端。清理掉存活对象的内存空间

优点：

内存使用率高：整个堆内存都可以使用，不会像复制算法只能使用半个堆内存

不会发生碎片化：在整理阶段可以将对象往内存的一侧进行移动，剩下的空间都是可以分配对象的有效空间

缺点：

整理阶段的效率不高：整理算法有很多种，比如Lisp2整理算法需要对整个堆中的对象搜索3次，整体性能不佳。可以通过Two-Finger、表格算法、ImmixGc等高效的整理算法优化此阶段的性能

分代GC算法

以JDK8的**Serial GC(单线程)**为例

现代优秀的垃圾回收算法会将上述描述的垃圾回收算法组合进行使用，其中应用最广的就是分代垃圾回收算法

分代垃圾回收将整个内存划分为年轻代和老年代：

JDK8中添加-XX:+UserSerialGC参数使用分代回收的垃圾回收器

Arthas中通过memory命令查看分代之后的内存情况

调整新生代大小：虚拟机参数-Xmn

调整伊甸园区和幸存区比起，默认为8-XX:SurvivourRatio

打印GC日志-XX:+printGCDetails或者verbos:gc

分代回收时，创建出来的对象首先会被放入Eden伊甸园区

随着对象在Eden区越来越多，如果Eden区慢，新创建的对象已经无法放入，救护触发年轻代的GC，称为Minor GC或者Young GC

Minor GC过程中会把垃圾对象清理，存活对象会被复制到Survivor区（或老年代，若对象年龄达到某一阈值或者To区满了，阈值不能超过15，和垃圾回收器有关），Minor GC通常使用复制算法，复制算法适合对象生命周期短，垃圾对象多的情况

当老年代空间不足会尝试Minor GC,如果Minor GC还是不足，就会触发Full GC,Full GC会对整个堆进行垃圾回收

Full GC

老年带通常使用标记-清除算法和标记-整理算法的组合，SerialOld垃圾回收器使用标记-整理算法

为什么分代GC算法要把堆分成年轻代和老年代

系统中的大部分对象，都是创建出来之后很快就不再使用可以被回收，比如用户获取订单数据，订单数据返回给用户之后就可以释放了。
老年代中会存放长期存活的对象，比如Spring的大部分bean对象，在程序启动之后就不会被回收了。
在虚拟机的默认设置中，新生代大小要远小于老年代的大小。

主要原因：

可以通过调整年轻代和老年代的比例来适应不同类型的应用程序，提高内存的利用率和性能
新生代和老年代使用不同的垃圾回收算法，新生代一般选择复制算法，老年代可以选择标记-清除和标记-整理算法，由程序员来选择灵活度较高。
分代的设计中允许只回收新生代(Minor GC)，如果能满足对象分配的要求就不需要对整个堆进行回收(Full GC),STW时间就会减少。

垃圾回收器

垃圾回收器分为年轻代和老年代，除了G1之外其他垃圾回收器必须成对组合进行使用。

具体的关系图如下：

年轻代-Serial垃圾回收器

Serial是一种单线程串行回收年轻代的垃圾回收器，采用复制算法

优点：单CPU处理器下吞吐量非常出色

缺点：多CPU下吞吐量不如其他垃圾回收器，堆如果偏大会让用户线程处于长时间的等待

适用场景：Java编写的客户端程序或者硬件配置有限的场景

老年代-SerialOld垃圾回收器

SerialOld是Serial垃圾回收器的老年代版本，采用单线程串行回收，采用标记-整理算法

-XX:+UseSerialGC 新生代、老年代都使用串行回收器

优点：单CPU处理器下吞吐量非常出色

缺点：多CPU下吞吐量不如其他垃圾回收器，堆如果偏大会让用户线程处于长时间的等待

适用场景：与Serial垃圾回收器搭配使用，或者在CMS特殊情况下使用

年轻代-ParNew垃圾回收器

ParNew垃圾回收器本质上是堆Serial在多CPU下的优化，使用多线程进行垃圾回收

-XX:+UseParNewGC新生代使用ParNew回收器，老年代使用串行回收器

优点：多CPU处理器下停顿时间较短

缺点：吞吐量和停顿时间不如G1，JDK9之后不建议使用

适用场景：JDK8及之前的版本中，与CMS老年代垃圾回收器搭配使用

老年代-CMS（Concurrent Mark Sweep）垃圾回收器

CMS垃圾回收器关注的是系统的**暂停时间，**允许用户线程和垃圾回收线程在某些步骤中同时执行，减少了用户线程的等待时间

CMS垃圾回收器允许用户线程和垃圾回收线程在某些步骤中同时执行，减少了用户线程的等待时间。

-XX:+UseConcMarkSweepGC

CMS执行步骤：

初始标记，用极短的时间标记出GC Roots能直接关联到的对象
并发标记，标记所有对象，用户线程不需要暂停
重新标记，由于并发标记阶段有些对象会发生了编号，存在错标、漏标等情况，需要重新标记
并发清理，清理死亡的对象，用户线程不需要暂停

优点：系统由于垃圾回收出现的停顿时间较短，用户体验好

缺点：

内存碎片问题

CMS使用了标记-清除算法，在垃圾收集结束之后会出现大量的内存碎片，CMS会在Full GC时进行碎片的整理。这样会导致用户线程暂停，可以用-XX:CMSFullGCsBeforeCompaction=NN默认为0，调整N次Full GC之后再整理

退化问题

如果老年代内存不足无法分配对象，CMS就会退化成Serial Old单线程回收老年代

浮动垃圾问题

无法处理在并发清理过程中产生的"浮动垃圾"，不能做到完全的垃圾回收

适用场景：大型的互联网系统中用户请求数据量大、频率高的场景，比如订单接口、商品接口等

年轻代-Parallel Scavenge垃圾回收器

Parallel Scavenge是JDK8默认的年轻代垃圾回收器，多线程并行回收，关注的是系统的吞吐量。具备自动调整堆内存大小的特点

参数设置：

最大暂停时间：-XX:MaxGCPauseMillis=n设置每次垃圾回收时最大停顿毫秒数

吞吐量：-XX:GCTimeRatio=n设置吞吐量为n(用户线程执行时间=n/(n+1))

自动调整大小：-XX:+UseAdaptiveSizePolicy设置可以让垃圾回收器根据吞吐量和最大停顿的毫秒数自动调整内存大小

回收年代和算法：年轻代、复制算法

优点：吞吐量高，而且手动可控。为了提高吞吐量，虚拟机会动态调整堆的参数

缺点：不能保证单次的停顿时间

适用场景：后台任务，不需要与用户交互，并且容易产生大量的对象。比如：大数据处理、大文件导出

老年代-Parallel Old垃圾回收器

Parallel Old是为Parallel Scavenge收集器设计的老年代版本，利用多线程并发收集

参数：-XX:+UseParallelGC或者-XX:+UseParallelOldGC可以使用Parallel Scavenge + Parallel Old这种组合

回收年代和算法：老年代、标记-整理算法

优点：并发收集，在多核CPU下效率较高

缺点：暂停时间会比较长

适用场景：与Parallel Scavenge配套使用

G1垃圾回收器（JDK9之后默认的垃圾回收器是G1（Garbage First））

Parallel Scavenge关注吞吐量，允许用户设置最大暂停时间，但是会减少年轻代可用空间的大小。

CMS关注暂停时间，但是吞吐量方面会下降

G1的设计目标就是将上述两种垃圾回收器的优点融合：

支持巨大的堆空间回收，并有较高的吞吐量
支持多CPU并行垃圾回收
允许用户设置最大暂停时间

G1出现之前的垃圾回收器，内存结构一般是连续的，如下图：

G1整个堆会被划分成多个大小相等的区域，称之为区Region，区域不要求是连续的。分为Eden、Survivor、Old区。Region的大小通过堆空间大小/2048计算得到，也可以通过参数-XX:G1HeapRegionSize=32m手动指定（其中32m指定region大小为32M）,Region size 必须是2的指数幂，取值范围从1M到32M。

G1中垃圾回收有两种方式

年轻代回收（Young GC）

年轻代回收，回收Eden区和Survivor区中不用的对象，会导致STW,G1中可以通过参数-XX:MaxGCPauseMillis=n（默认200）设置每次垃圾回收时的最大暂停时间毫秒数，G1垃圾回收器会尽可能地保证暂停时间

混合回收（Mixed GC）

G1执行流程

新创建的对象会存放在Eden区。当G1判断年轻代不足（max默认60%），无法分配对象需要回收时会执行Young GC
标记出Eden和Survivor区域中的存活对象
根据配置的最大暂停时间选择某些区域将存活对象复制到一个新的Survivor区中（年龄+1），清空这些区域
年轻代采用的复制算法，不会产生内存碎片。G1在进行Young GC的过程中回去记录每次垃圾回收时每个Eden区和Survivor区的平均耗时，以作为下次回收时的参考依据。这样就可以根据配置的最大暂停时间计算出本次回收时最多能回收多少个Region区域了。比如-XX:MaxGGPauseMillis=n(默认200)，每个Region回收耗时40ms，那么这次回收最多只能回收4个Region
后续Young GC时与之前相同，只不过Survivor区中存活对象会被搬运到另一个Survivor区
当某个存活对象的年龄达到阈值（默认15），将被放入老年代。
部分对象如果大小超过Region的一半，会被直接放入老年代，这类老年代被称为Humongous区。比如堆内存是4G，每个Region是2M,只要一个大对象超过了1M就被放入Humongous区，如果对象过大会横跨多个Region
多次回收之后，会出现很多Old老年代区，此时总堆占有率达到阈值时（-XX:InitatingHeapOccupancyPercet默认45%）会触发混合回收MixedGC。回收所有年轻代和部分老年代对象以及大对象区域，采用复制算法完成。

G1垃圾回收器-混合回收

混合回收分为：初始标记（initial mark）、并发标记（concurrent mark）、最终标记（remark或者Finalize Marking）、并发清理（cleanup）
G1对老年代的清理会选择存活度最低的区域来进行回收，这样可以保证回收效率最高，这也是G1（Garbage first）名称的由来

最终标记只会标记并发标记过程中引用改变漏标的对象，而不管在并发标记阶段新创建的对象

并发清理阶段不是把所有非存活对象清理，优先会清理存活率最低的Region。比如一个Region有100个对象只存活1个和100个对象存活10个，优先清理存活1个的Region

注意：如果清理过程中发现没有足够的空Region存放转移的对象，会出现Full GC。单线程执行标记-整理算法。此时会导致用户线程的暂停。所以尽量保证应该用的堆内存有一定多余的空间。

参数：

-XX:+UseG1GC打开G1的开关，JDK9之后默认不需要打开

-XX:MaxGCPauseMillis=毫秒值最大暂停的时间

优点：

对比较大的堆如超过6G的堆回收时，延迟可控
不会产生内存碎片
并发标记的SATB算法效率高

缺点:JDK8之前还不够成熟

适用场景：JDK8最新版本，JDK9之后建议使用

垃圾回收器的组合关系虽然很多，但是针对几个特定的版本，比较好的组合选择如下：

JDK8及之前：

ParNew + CMS(关注暂停时间)、Parallel Scavenge + Parallel Old（关注吞吐量）、G1（JDK8之前不建议，堆较大并且关注暂停时间）

JDK9之后：

G1（默认）