什么才是线程安全？

《Java Concurrency in Practice》 有一个比较恰当的定义 ：“当多个线程访问一个对象时，如果不用考虑这些线程在运行时环境下的调度和交替执行，也不需要进行额外的同步或者在调用方法进行任何其他的协调操作，调用这个对象的行为都可以获得正确的结果，那这个对象是线程安全的。”

经典 Counter 计数例子🌰

/** * MultiErrorDemo 多线程环境下的常见的计数错误 * * @author suremotoo * @date 2022/11/07 12:24 */public class MultiErrorDemoCounter implements Runnable {    static int index = 0;    static MultiErrorDemoCounter errorDemo = new MultiErrorDemoCounter();    @Override    public void run() {        for (int i = 0; i < 10000; i++) {            index++;        }    }    public static void main(String[] args) throws InterruptedException {        Thread t1 = new Thread(errorDemo);        Thread t2 = new Thread(errorDemo);        t1.start();        t2.start();        t1.join();        t2.join();        System.out.println(index);    }}

没错，上述代码，我们启动了 2 个线程：t1、t2 ，分别对 index 进行 10 万次的计数，也就是分别执行 index++。

结果，index 最终我们 预期值为：200000，为实际运行结果，往往都是 小于 200000 ；

这就是典型的线程不安全问题操作，因为 两个线程执行同一个 index 对象的时候，总有可能是针对同一个数值计算，这样重复计算才导致真是数字往往小于预期！

小解决

当然，我们给 index++ 使用一个 synchronized 同步锁即可解决，run 方法调整后代码如下：

public void run() {    for (int i = 0; i < 10000; i++) {      // 需要获得 errorDemo 对象的锁才能进行 index++, 从而保证准确计算        synchronized(errorDemo) {            index++;        }    }}

当然，更多具体过程可以参考文档 synchronized 分析文章（我还没出呢😁）

尝试找出 Counter 例子中重复计算的数字！

鉴于上面的问题，大部分想法都是去解决这个问题，既然针对某些值进行了重复计算，那么能不能尝试着能不能找出到底是哪些值呢？本着研究学习的心态，去试一试！💪💪

第一步：记录

既然是重复计算，那么我们就每次计算的都记录一下，判断一下是不是已经计算过了，计算过了就打印出来。

public class FindErrorNumsCounter implements Runnable {    static FindErrorNumsCounter instance = new FindErrorNumsCounter();    int index = 0;    /**     * 真正运行的次数，该值正好和 index 理论上计算的值是一致     */    static AtomicInteger realCount = new AtomicInteger();    /**     * 错误的次数     */    static AtomicInteger errorCount = new AtomicInteger();    /**     * 记录标记计算的数字，容量比理论计算的数值大一些，以便都能装进去     */    static boolean[] marked = new boolean[1000000];    @Override    public void run() {        for (int i = 0; i < 100000; i++) {            index++;            realCount.incrementAndGet();            // 判断 index 是否已经计算过            if (marked[index]) {                System.out.println("出错了: " + index);                errorCount.incrementAndGet();            }            marked[index] = true;        }    }    public static void main(String[] args) throws InterruptedException {        Thread t1 = new Thread(instance);        Thread t2 = new Thread(instance);        t1.start();        t2.start();        t1.join();        t2.join();        System.out.println("真正计算的次数: " + realCount.get());        System.out.println("错误计算的次数: " + errorCount.get());        System.out.println("实际结果: " + instance.index);        System.out.println("----------------");    }}

为了方便，我们先定义了 3 个变量：

boolean[] marked：用于记录标记已经计算过的数值；
AtomicInteger realCount：用于记录理论预期的正确值；
AtomicInteger errorCount： 记录重复计算的次数；

重点就分析一下 run() 方法

@Overridepublic void run() {    for (int i = 0; i < 100000; i++) {        index++;        // 计算次数加 1，统计真正计算的次数，也就是理论上 index 的值        realCount.incrementAndGet();        // 判断 index 是否已经计算过，如果已经计算过，说明重复计算，则打印出来该值        if (marked[index]) {            System.out.println("出错了: " + index);            // 同时重复计算的次数加 1             errorCount.incrementAndGet();        }        // 没有重复计算则添加到数组中，标记已经计算过        marked[index] = true;    }}

运行一下：

真正计算的次数: 200000错误计算的次数: 255实际结果: 199604

会发现数字很离谱，理论上 实际结果+错误计算的次数=真正计算的次数 才对！

这里我们犯了一个错误，就是我们统计重复计算的逻辑，也是线程不安全的！就是这里：

// 判断 index 是否已经计算过，如果已经计算过，说明重复计算，则打印出来该值if (marked[index]) {    System.out.println("出错了: " + index);    // 同时重复计算的次数加 1     errorCount.incrementAndGet();}// 没有重复计算则添加到数组中，标记已经计算过marked[index] = true;

错误分析

错误分析

前提条件： 假如两个线程发生了重复计算，index 从 0 开始，都执行完 index++ 后 index 的值都为 1；

1. 第 1 个线程判断 if (marked[index]) 不符合，那么要标记该 index 已经计算过 ,也就是要执行 marked[index] = true;

2. 结果第 1 线程还没执行 marked[index] = true;，偏偏 CPU 调度切换执行第 2 个线程；

3. 第 2 个线程判断 if (marked[index]) 也不符合，然后第 2 个线程就执行了 marked[index] = true;

4. 第 2 个线程执行完成后，CPU 调度又切回第 1 个线程去执行 marked[index] = true;

那么最终两个线程对同一个 index 进行了标记！就跟 index++ 重复计算一样，这样就是两个线程冲突，却没有统计到出错的数字。

示例图

可以配合该动图，理解上面的话

没解决问题反而还新造出了新问题🤦🤦

第二步：记录调整-增加 synchronized

上面记录重复次数的代码不安全，那么我们用 synchronized 来同步这段代码试试呀！😏😏

@Overridepublic void run() {    for (int i = 0; i < 100000; i++) {        index++;        realCount.incrementAndGet();        // 使用 synchronized 保护        synchronized (instance) {            if (marked[index]) {                System.out.println("出错了: " + index);                errorCount.incrementAndGet();            }            marked[index] = true;        }    }}

这样我们再看看～

... ... 出错了: 183544出错了: 190630真正计算的次数: 200000错误计算的次数: 1781实际结果: 199999

多运行几次，实际结果 199999 都已经逼近 真正计算的次数 200000 了，可是这个 错误计算的次数 竟然高的离谱！应该是 1 的呀！😦😦

错误分析

错误分析
前提条件： 假如两个线程没有发生冲突，正常计算，index 从 0 开始，第 1 个线程执行完 index++ 后 index 的值为 1；

提示 2 ： 这个又要提到一个概念，就是 synchronized 拥有一个特性：线程可见。

1. 第 1 个线程正常执行 index++ ,index 值变为 1，紧接着进入 synchronized 中，第 2 个线程是无法进入 synchronized 代码块的。

2. 第 1 个线程此时即将要执行 if (marked[index]) 代码，却又没执行的时候， CPU 调度又回去让第 2 个线程继续执行；

3. 这时候第 2 个线程又执行 index++，index 变为 2，执行完后 CPU 调度又回去让第 1 个线程执行，这时候第 1 个线程要执行： if (marked[index]) 代码

5. 由于 synchronized 的线程可见性， 1 个线程可以看到之前的线程干了什么事情，这样第 1 个线程本来要 if (marked[index]) 判断的是 marked[1]，由于第 2 个线程的结果导致变成了 marked[2]

6. 如此的话，第 1 个线程将 index 2 就被标记为 true，然后退出 synchronzied 代码块。

7. 轮到第 2 个线程继续执行的时候，第 2 个线程执行 if (marked[index]) 判断的也是 marked[2]，因为第 1 个线程已经标记过了，所以会满足 if (marked[index]) 的条件， 从而打印出 出错了。

可实际上两个线程并没有冲突，1 个线程将 0+1=1，另 1 个线程将 1+1=2。

这样下来，本来正确的计算，却打印出了 1 次 出错了，就会导致上述 错误计算的次数 统计过多的问题了。

示例图

可以配合该动图，理解上面的话

第三步：记录调整-保持每两个线程一组

上面分析增加 synchronized 还不行，因为 CPU 调度，可能会让前面的线程一、线程二中的某一个线程步骤加快，进入下一次 index++ 的计算，那么我们就控制一下，每次 index++ 前确保是 2 个线程一起来！

这时候我们引入一个新的工具类：CyclicBarrier，先不用理解它到底是什么，只需要知道它到底有什么作用即可。

CyclicBarrier 其实就个栅栏，假如你有个牧场，养了一窝的阿拉斯加，它们也总是兴致勃勃，为了不让他们乱跑，你为了个栅栏把他们圈起来~，哪天你想放出来遛遛它们，打开栅栏，那叫一个：斯如涌泉 🤪，一下子全冲出来了～

CyclicBarrier 其实就跟这个差不多，我们可以设置一个条件，比如有 2 个线程都等待就绪后，然后才允许放行！我们看代码：

/** * FindErrorNumsCounter * * @author suremotoo * @date 2022/11/07 19:57 */public class FindErrorNumsCounter implements Runnable {    static FindErrorNumsCounter instance = new FindErrorNumsCounter();    int index = 0;    /**     * 真正运行的次数，该值正好和 index 理论上计算的值是一致     */    static AtomicInteger realCount = new AtomicInteger();    /**     * 错误的次数     */    static AtomicInteger errorCount = new AtomicInteger();    /**     * 记录标记计算的数字，容量比理论计算的数值大一些     */    static boolean[] marked = new boolean[1000000];    static volatile CyclicBarrier cyclicBarrier1 = new CyclicBarrier(2);    @Override    public void run() {        for (int i = 0; i < 100000; i++) {            try {                cyclicBarrier1.await();            } catch (InterruptedException e) {                throw new RuntimeException(e);            } catch (BrokenBarrierException e) {                throw new RuntimeException(e);            }            index++;            realCount.incrementAndGet();            synchronized (instance) {                if (marked[index]) {                    System.out.println("出错了: " + index);                    errorCount.incrementAndGet();                }                marked[index] = true;            }        }    }    public static void main(String[] args) throws InterruptedException {        Thread t1 = new Thread(instance);        Thread t2 = new Thread(instance);        t1.start();        t2.start();        t1.join();        t2.join();        System.out.println("真正计算的次数: " + realCount.get());        System.out.println("错误计算的次数: " + errorCount.get());        System.out.println("实际结果: " + instance.index);        System.out.println("----------------");    }}

重点看这里：

我们定义了一个变量 cyclicBarrier1 并且设置了栅栏开启的线程数量是 2 个，这里 cyclicBarrier1.await(); 就是 2 个线程就绪了才会执行下一行！

这下我们再运行，看看结果：

真正计算的次数: 200000错误计算的次数: 4实际结果: 200000

🎵眼睛瞪得像铜铃🔔 ~~~~

我… … 怎么还是有问题❓❓❓❓❓

错误分析

错误分析经过 cyclicBarrier1.await(); 代码后，我们有 2 个线程过来。

前提条件（很重要）： 我们 假设 index 为 0， 第 2 个线程进来就一直没有执行，就卡在 index++; ，注意：是没执行 index++;

1. 而第 1 个线程执行 index++, i 变成 1，并且进入 synchronized 代码块，if (marked[index]) marks[1] 也不满足条件（不记录错误），当即将执行 marked[index]=true 的时候却被 CPU 调度走了，让第 2 个线程继续执行了～

2. 第 2 个线程执行 index++; index 是从 1 开始计算的，因为第 1 个线程已经 index++ 了！

3. 这时候 第 2 个线程 index++ 完 index 就变成了 2 ，刚执行完又被 CPU 调度回去，继续让第 1 个线程执行，而这时候第 1 个线程继续执行：marked[index]=true，可此时 index 已经变成 2 了，本来是要执行 marked[1]=true，结果变成了 marked[2]=true！

4. 最后第 1 个线程执行完后退出 synchronized，第 2 个线程回来继续执行 进入 synchronized。

5. 这样第 2 个线程本来要 if (marked[index]) 判断的是 marked[1]，结果也变成了 marked[2]！

如此的话，第 2 个线程 if (marked[index]) 判断的也是 marked[2]，这样 2 就已经重复了，就会打印出来 “出错了：” ，可实际并没有重复呢！和之前分析导致 错误计算的次数 统计过多的问题一样。

其实你会发现，这和 第二步 的场景是完全一样的嘛！😁

第四步：记录调整-保持每两个线程一组-升级！

第三步，我们添加了 1 个 CyclicBarrier 栅栏来解决 第二步两轮计算 index++ 的问题，发现还是不行，依然存在一个在 synchronized 代码块里，因为线程切换执行 index++ 导致 index 值变的问题！

既然有可能线程半路才 index++，这样，那么我再加 1 个 CyclicBarrier 栅栏，放在 index++ 后面 synchronized 前面，这样就避免了其中 1 个线程在 synchronized 里执行代码的时候突然让别的线程 index++。

没问题，上代码：

/** * FindErrorNumsCounter * * @author suremotoo * @date 2022/11/07 19:57 */public class FindErrorNumsCounter implements Runnable {    static FindErrorNumsCounter instance = new FindErrorNumsCounter();    int index = 0;    /**     * 真正运行的次数，该值正好和 index 理论上计算的值是一致     */    static AtomicInteger realCount = new AtomicInteger();    /**     * 错误的次数     */    static AtomicInteger errorCount = new AtomicInteger();    /**     * 记录标记计算的数字，容量比理论计算的数值大一些     */    static boolean[] marked = new boolean[1000000];    static volatile CyclicBarrier cyclicBarrier1 = new CyclicBarrier(2);    static volatile CyclicBarrier cyclicBarrier2 = new CyclicBarrier(2);    @Override    public void run() {        for (int i = 0; i < 100000; i++) {            try {                cyclicBarrier2.reset();                cyclicBarrier1.await();            } catch (InterruptedException e) {                throw new RuntimeException(e);            } catch (BrokenBarrierException e) {                throw new RuntimeException(e);            }            index++;            try {                cyclicBarrier1.reset();                cyclicBarrier2.await();            } catch (InterruptedException e) {                throw new RuntimeException(e);            } catch (BrokenBarrierException e) {                throw new RuntimeException(e);            }            realCount.incrementAndGet();            synchronized (instance) {                if (marked[index]) {                    System.out.println("出错了: " + index);                    errorCount.incrementAndGet();                }                marked[index] = true;            }        }    }    public static void main(String[] args) throws InterruptedException {        Thread t1 = new Thread(instance);        Thread t2 = new Thread(instance);        t1.start();        t2.start();        t1.join();        t2.join();        System.out.println("真正计算的次数: " + realCount.get());        System.out.println("错误计算的次数: " + errorCount.get());        System.out.println("实际结果: " + instance.index);        System.out.println("----------------");    }}

我们在 index++ 前后都添加了 CyclicBarrier 栅栏！这样可以确保让两个线程都会执行 index++ 。

ok，我们运行一下代码。

出错了: 199920出错了: 199922出错了: 199924出错了: 199926出错了: 199928出错了: 199930出错了: 199932出错了: 199934出错了: 199936出错了: 199938出错了: 199940出错了: 199942出错了: 199944出错了: 199946出错了: 199948出错了: 199950出错了: 199952出错了: 199954出错了: 199956出错了: 199958出错了: 199960出错了: 199962出错了: 199964出错了: 199966出错了: 199968出错了: 199970出错了: 199972出错了: 199974出错了: 199976出错了: 199978出错了: 199980出错了: 199982出错了: 199984出错了: 199986出错了: 199988出错了: 199990出错了: 199992出错了: 199994出错了: 199996出错了: 199998真正计算的次数: 200000错误计算的次数: 100000实际结果: 199998

俏丽马！怎么还越来越离谱了❓❓❓❓❓❓而且出错的还都是偶数。

注意：

注意： 由于在 index++ 前后都加入了栅栏，所以 2 个线程都会执行 index++ 的。

错误分析

前提条件：index 为 0：

1. 假如现在 2 个线程是正常按照逻辑执行， 第 1 个线程 index++ index 变为 1；

2. 因为第 1 个线程的结果，第 2 个线程 index++ index 就变为 2；

3. 然后放开栅栏！两个都去执行 synchronized 代码，要进行锁竞争，由于 synchronized 的线程可见特性， 1 个线程可以看到之前的线程干了什么事情， 所以无论哪个线程抢到锁去执行，它们用的 index 值都是 2。

4. 第 1 个线程 if (marked[index]) 判断 marked[2] 不满足条件，则执行 marked[2]=true;

5. 第 2 个线程 if (marked[index]) 判断 marked[2] 满足条件，则打印 出错了:

这样的情况对吗？肯定不对啊，我们的目标、宗旨是要找出重复计算的，现在的 index 有重复计算吗？并没有！ 1 个线程将 index 从 0 变为 1，另 1 个线程从 1 变为 2，没问题呀，但我们现在这种代码就会多打印出来 出错了:。

🤨🤨你会发现，这还是和之前 第三步、第四步 类似呀，都是正常的逻辑情况下，因为其中 1 个线程将 index 变更后，导致另 1 个线程使用变更后的 index ，从而导致重复打印的问题！

第五步：记录调整-调整重复计算的判断处理！

基于上面 第四步，我们分析了正常情况多统计了，现在想办法要去掉，那么，同时我们也要会想一下错误的情况，应该是什么样的。

提示

提示：

因为 index 从 0 开始，index++ 对于 0 是不会漏算的，我们就把设置 marked[0]=true;

正常的情况，0→1→2：

或者

⚠️错误的情况，0→1→1：

从上面的表格，我们可以看到，因为 2 个线程去执行 index++, 所以 正常的情况，总会像 0→1→2 这样的规律，而且 0→1→2 中间的那个 1 是会略过 sychronized 的代码处理的，2 是正确的，但我们却多打印出来来了，不应该打印它，所以 marked[0] 总是 true，marked[1] 是 false，marked[2] 是 true；以此类推，后面都是 true、false 交替的结果。

错误的情况总会像 0→1→1 这样的规律，所以 marked[0] 总是 true，marked[1] 也是 true，这样呢，我就可以得出一个规律，只要出现了 marked[index] 和 marked[index-1] 都为 true 的情况，index 才是真正的重复计算，这种情况下才是需要将信息打印出来！

这样我们就知道调整哪里的代码了，就是 synchronized 代码块中 if (marked[index]) 这句代码，我们调整为 if (marked[index] && marked[index - 1])

run() 完整代码如下：

@Overridepublic void run() {   // 0 的时候永远不会重复计算，手动标记为 true    marked[0]=true;    for (int i = 0; i < 100000; i++) {        try {            cyclicBarrier2.reset();            cyclicBarrier1.await();        } catch (InterruptedException e) {            throw new RuntimeException(e);        } catch (BrokenBarrierException e) {            throw new RuntimeException(e);        }        index++;        try {            cyclicBarrier1.reset();            cyclicBarrier2.await();        } catch (InterruptedException e) {            throw new RuntimeException(e);        } catch (BrokenBarrierException e) {            throw new RuntimeException(e);        }        realCount.incrementAndGet();        synchronized (instance) {          // 判断条件，如果上一个和当前这个都为 true，则说明 index 漏算            if (marked[index] && marked[index - 1]) {                System.out.println("出错了: " + index);                errorCount.incrementAndGet();            }            marked[index] = true;        }    }}

这样我们再次运行

真正计算的次数: 200000错误计算的次数: 0实际结果: 200000

ok，没问题了！emm，运行好多次，只是一直没有失败的，这是因为我们调整多次代码后，线程碰撞的概率变小了，没关系！我们微调一下再测试就可以！

第六步：调整 main 方法，运行代码打印！

只要出现错误，errorCount 肯定能统计到值，我们就来个循环，直到遇到漏算的错误情况。

完整代码：

/** * FindErrorNumsCounter 找出并发情况下哪些计数被漏算 * * @author suremotoo * @date 2022/11/07 15:57 */public class FindErrorNumsCounter implements Runnable {    static FindErrorNumsCounter instance = new FindErrorNumsCounter();    int index = 0;    /**     * 真正运行的次数，该值正好和 index 理论上计算的值是一致     */    static AtomicInteger realCount = new AtomicInteger();    /**     * 错误的次数     */    static AtomicInteger errorCount = new AtomicInteger();    /**     * 记录标记计算的数字，容量比理论计算的数值大一些     */    static boolean[] marked = new boolean[1000000];    static volatile CyclicBarrier cyclicBarrier1 = new CyclicBarrier(2);    static volatile CyclicBarrier cyclicBarrier2 = new CyclicBarrier(2);    @Override    public void run() {        marked[0] = true;        for (int i = 0; i < 100000; i++) {            try {                cyclicBarrier2.reset();                cyclicBarrier1.await();            } catch (InterruptedException e) {                throw new RuntimeException(e);            } catch (BrokenBarrierException e) {                throw new RuntimeException(e);            }            index++;            try {                cyclicBarrier1.reset();                cyclicBarrier2.await();            } catch (InterruptedException e) {                throw new RuntimeException(e);            } catch (BrokenBarrierException e) {                throw new RuntimeException(e);            }            realCount.incrementAndGet();            synchronized (instance) {                if (marked[index] && marked[index - 1]) {                    System.out.println("出错了: " + index);                    errorCount.incrementAndGet();                }                marked[index] = true;            }        }    }    public static void main(String[] args) throws InterruptedException {        while (errorCount.get() == 0) {            realCount.set(0);            errorCount.set(0);            instance.index = 0;            marked = new boolean[1000000];            Thread t1 = new Thread(instance);            Thread t2 = new Thread(instance);            t1.start();            t2.start();            t1.join();            t2.join();            System.out.println("真正计算的次数: " + realCount.get());            System.out.println("错误计算的次数: " + errorCount.get());            System.out.println("实际结果: " + instance.index);            System.out.println("----------------");        }    }}

结果：

真正计算的次数: 200000错误计算的次数: 0实际结果: 200000----------------真正计算的次数: 200000错误计算的次数: 0实际结果: 200000----------------出错了: 77953真正计算的次数: 200000错误计算的次数: 1实际结果: 199999----------------

77953 重复计算了，错误 1 次，实际结果 199999，真正的计算为：200000，这次统计对咯~

可以多次运行验证，发现没问题~🎉🎉

一、引言

引言：“操作系统的线程状态和 java 的线程状态有什么关系？” 这是校招时被问到的一个问题。当时只顾着看博文、面经等零散的资料，没有形成系统的知识体系，一时语塞，答的不是很对。在网上也没找到足够细致的讲解博文，于是整理出了这篇内容。

Java 的线程状态牵扯到了同步语义，要探讨 Java 的线程状态的，必不可免要回顾其锁机制。因此本文的主要分为两大块：一是 Synchronized 源码粗析，分析了各类锁的进入、释放、升级过程，并大致说明了 monitor 原理；二是介绍了线程的实现方式和 Java 线程状态转换的部分细节。

P.S. 本文内容较啰嗦，时间不充裕的同学可以直接看 2.6 小结及 3.3 小结。

二、Synchronized 锁

Java 采用 synchronized 关键字、以互斥同步的方式的解决线程安全问题，那么什么是线程安全呢？这里引用《Java 并发编程实战》作者 Brian Goetz 给出的定义：

当多个线程同时访问一个对象时，如果不用考虑这些线程在运行时环境下的调度和交替执行，也不需要进行额外的同步，或者在调用方进行任何其他的协调操作，调用这个对象的行为都可以获得正确的结果，那就称这个对象是线程安全的。 —— Brian Goetz

2.1 Synchronized 的使用

先写过个 demo，大致过一下 synchronized 的使用，包含同步代码块、实例方法和静态方法。

  public synchronized void test1(){  }  public void test2(){    synchronized(new Test()){    }  }  public static synchronized void test3(){  }

反编译可查看字节码：

  public synchronized void test1();    descriptor: ()V    flags: ACC_PUBLIC, ACC_SYNCHRONIZED    // here  public void test2();    descriptor: ()    flags: ACC_PUBLIC    Code:      stack=2, locals=3, args_size=1         0: new           #2                  // class com/easy/helloworld/Test         3: dup         4: invokespecial #3                  // Method "<init>":()V         7: dup         8: astore_1         9: monitorenter                   // here        10: aload_1        11: monitorexit                    // here        12: goto          20        15: astore_2        16: aload_1        17: monitorexit                    // here        18: aload_2        19: athrow        20: return  public static synchronized void test3();    descriptor: ()V    flags: ACC_PUBLIC, ACC_STATIC, ACC_SYNCHRONIZED   // here

可以观察到：

• 同步代码：通过 moniterenter、moniterexit 关联到到一个 monitor 对象，进入时设置 Owner 为当前线程，计数 + 1、退出 - 1。除了正常出口的 monitorexit，还在异常处理代码里插入了 monitorexit。
• 实例方法：隐式调用 moniterenter、moniterexit
• 静态方法：隐式调用 moniterenter、moniterexit

2.2 Moniterenter、Moniterexit

monitorenter 和 monitorexit 这两个 jvm 指令，主要是基于 Mark Word 和 Object monitor 来实现的。

在 JVM 中，对象在内存中分为三块区域：

• 对象头：由 Mark Word 和 Klass Point 构成。

  • Mark Word（标记字段）：用于存储对象自身的运行时数据，例如存储对象的 HashCode，分代年龄、锁标志位等信息，是 synchronized 实现轻量级锁和偏向锁的关键。 64 位 JVM 的 Mark Word 组成如下：

    

  • Klass Point（类型指针）：对象指向它的类元数据的指针，虚拟机通过这个指针来确定这个对象是哪个类的实例。

• 实例数据：这部分主要是存放类的数据信息，父类的信息。

• 字节对齐：为了内存的 IO 性能，JVM 要求对象起始地址必须是 8 字节的整数倍。对于不对齐的对象，需要填充数据进行对齐。

在 JDK 1.6 之前，synchronized 只有传统的锁机制，直接关联到 monitor 对象，存在性能上的瓶颈。在 JDK 1.6 后，为了提高锁的获取与释放效率，JVM 引入了两种锁机制：偏向锁和轻量级锁。它们的引入是为了解决在没有多线程竞争或基本没有竞争的场景下因使用传统锁机制带来的性能开销问题。这几种锁的实现和转换正是依靠对象头中的 Mark Word。

2.3 偏向锁

引入偏向锁的目的：在没有多线程竞争的情况下，尽量减少不必要的轻量级锁的执行。轻量级锁的获取及释放依赖多次 CAS 原子指令，而偏向锁只依赖一次 CAS 原子指令。但在多线程竞争时，需要进行偏向锁撤销步骤，因此其撤销的开销必须小于节省下来的 CAS 开销，否则偏向锁并不能带来收益。JDK 1.6 中默认开启偏向锁，可以通过 - XX:-UseBiasedLocking 来禁用偏向锁。

2.3.1 进入偏向锁

关于 HotSpot 虚拟机中获取锁的入口，网上主要有两种看法：一为 interpreterRuntime.cpp#monitorenter#1608；二为 bytecodeInterpreter.cpp#1816。在 HotSpot 的中，有两处地方对 monitorenter 指令进行解析：一个是 bytecodeInterpreter.cpp#1816 ，另一个在 templateTable_x86_64.cpp#3667。其中，bytecodeInterpreter 是 JVM 中的字节码解释器， templateInterpreter 为模板解释器。HotSpot 对运行效率有着极其执着的追求，显然会倾向于用模板解释器来实现。R 大的读书笔记中有说明，HotSpot 中只用到了模板解释器，并没有用到字节码解释器。因此，本文认为 montorenter 的解析入口为 templateTable_x86_64.cpp#3667。

但模板解释器 templateInterpreter 都是汇编代码，不易读，且实现逻辑与字节码解释器 bytecodeInterpreter 大体一致。因此本文的源码都以 bytecodeInterpreter 来说明，借此窥探 synchronized 的实现原理。在看代码之前，先介绍几个在偏向锁中会被大量应用的概念，以便后续理解：

prototype_header：JVM 中的每个类有一个类似 mark word 的 prototype_header，用来标记该 class 的 epoch 和偏向开关等信息。

匿名偏向状态：锁对象 mark word 标志位为 101，且存储的 Thread ID 为空时的状态 (即锁对象为偏向锁，且没有线程偏向于这个锁对象)。

Atomic::cmpxchg_ptr：CAS 函数。这个方法有三个参数，依次为 exchange_value、dest、compare_value。如果 dest 的值为 compare_value 则更新为 exchange_value，并返回 compare_value。否则，不更新并返回实际原值。

接下来开始源码实现分析，HotSpot 中偏向锁的具体实现可参考 bytecodeInterpreter.cpp#1816，代码如下：

CASE(_monitorenter): {    //锁对象  oop lockee = STACK_OBJECT(-1);  // derefing's lockee ought to provoke implicit null check  CHECK_NULL(lockee);  // 步骤1  // 在栈中找到第一个空闲的Lock Record  // 会找到栈中最高的  BasicObjectLock* limit = istate->monitor_base();  BasicObjectLock* most_recent = (BasicObjectLock*) istate->stack_base();  BasicObjectLock* entry = NULL;  while (most_recent != limit ) {    if (most_recent->obj() == NULL) entry = most_recent;    else if (most_recent->obj() == lockee) break;    most_recent++;  }  // entry不为null，代表还有空闲的Lock Record  if (entry != NULL) {    // 将Lock Record的obj指针指向锁对象    entry->set_obj(lockee);    int success = false;    uintptr_t epoch_mask_in_place = (uintptr_t)markOopDesc::epoch_mask_in_place;    // markoop即对象头的mark word    markOop mark = lockee->mark();    intptr_t hash = (intptr_t) markOopDesc::no_hash;    // 步骤2    // implies UseBiasedLocking    // 如果为偏向模式，即判断标识位是否为101    if (mark->has_bias_pattern()) {      ...      // 一顿操作      anticipated_bias_locking_value =        (((uintptr_t)lockee->klass()->prototype_header() | thread_ident) ^ (uintptr_t)mark) &        ~((uintptr_t) markOopDesc::age_mask_in_place);      // 步骤3      if  (anticipated_bias_locking_value == 0) {        // already biased towards this thread, nothing to do        // 偏向的是自己，啥都不做        if (PrintBiasedLockingStatistics) {          (* BiasedLocking::biased_lock_entry_count_addr())++;        }        success = true;      }      // class的prototype_header不是偏向模式      else if ((anticipated_bias_locking_value & markOopDesc::biased_lock_mask_in_place) != 0) {        // 尝试撤销偏向                ...      }      // epoch过期，重新偏向      else if ((anticipated_bias_locking_value & epoch_mask_in_place) !=0) {        // try rebias                ...        success = true;          }      else {        // try to bias towards thread in case object is anonymously biased        // 尝试偏向该线程，只有匿名偏向能成功        // 构建了匿名偏向的mark word        markOop header = (markOop) ((uintptr_t) mark & ((uintptr_t)markOopDesc::biased_lock_mask_in_place |(uintptr_t)markOopDesc::age_mask_in_place |epoch_mask_in_place));        if (hash != markOopDesc::no_hash) {          header = header->copy_set_hash(hash);        }        // 用「或」操作设置thread ID        markOop new_header = (markOop) ((uintptr_t) header | thread_ident);、        // 只有匿名偏向才能成功        if (Atomic::cmpxchg_ptr((void*)new_header, lockee->mark_addr(), header) == header) {          // cas修改成功              if (PrintBiasedLockingStatistics)            (* BiasedLocking::anonymously_biased_lock_entry_count_addr())++;        }        else {          // 失败说明存在竞争，进入monitorenter          CALL_VM(InterpreterRuntime::monitorenter(THREAD, entry), handle_exception);        }        success = true;      }    }    // 步骤4    // traditional lightweight locking    // false走轻量级锁逻辑    if (!success) {      // 构造一个无锁状态的Displaced Mark Word，并将lock record指向它      markOop displaced = lockee->mark()->set_unlocked();      entry->lock()->set_displaced_header(displaced);      bool call_vm = UseHeavyMonitors;      if (call_vm || Atomic::cmpxchg_ptr(entry, lockee->mark_addr(), displaced) != displaced) {        // 如果CAS替换不成功，代表锁对象不是无锁状态，这时候判断下是不是锁重入        // Is it simple recursive case?        if (!call_vm && THREAD->is_lock_owned((address) displaced->clear_lock_bits())) {          // 如果是锁重入，则直接将Displaced Mark Word设置为null          // 轻量级锁重入是使用lock record的数量来计入的          entry->lock()->set_displaced_header(NULL);        } else {          CALL_VM(InterpreterRuntime::monitorenter(THREAD, entry), handle_exception);        }      }    }    UPDATE_PC_AND_TOS_AND_CONTINUE(1, -1);  } else {    // 没拿到lock record，重新执行    istate->set_msg(more_monitors);    UPDATE_PC_AND_RETURN(0); // Re-execute  }}

偏向锁流程：

步骤 1、从当前线程的栈中找到一个空闲的 Lock Record，并指向当前锁对象。

步骤 2、获取对象的 markOop 数据 mark，即对象头的 Mark Word；

步骤 3、判断锁对象的 mark word 是否是偏向模式，即低 3 位是否为 101。若不是，进入步骤 4。若是，计算 anticipated_bias_locking_value，判断偏向状态：

步骤 3.1、anticipated_bias_locking_value 若为 0，代表偏向的线程是当前线程且 mark word 的 epoch 等于 class 的 epoch，这种情况下直接执行同步代码块，什么都不用做。

步骤 3.2、判断 class 的 prototype_header 是否为非偏向模式。若为非偏向模式，CAS 尝试将对象恢复为无锁状态。无论 cas 是否成功都会进入轻量级锁逻辑。

步骤 3.3、如果 epoch 偏向时间戳已过期，则需要重偏向。利用 CAS 指令将锁对象的 mark word 替换为一个偏向当前线程且 epoch 为类的 epoch 的新的 mark word。

步骤 3.4、CAS 将偏向线程改为当前线程，如果当前是匿名偏向（即对象头中的 bit field 存储的 Thread ID 为空）且无并发冲突，则能修改成功获取偏向锁，否则进入锁升级的逻辑。

步骤 4、走到一步会进行轻量级锁逻辑。构造一个无锁状态的 mark word，然后存储到 Lock Record。设置为无锁状态的原因是：轻量级锁解锁时是将对象头的 mark wordcas 替换为 Lock Record 中的 Displaced Mark Word，所以设置为无锁状态。如果是锁重入，则将 Lock Record 的 Displaced Mark Word 设置为 null，放到栈帧中，起到计数作用。

以上是偏向锁加锁的大致流程，如果当前锁已偏向其他线程 || epoch 值过期 || class 偏向模式关闭 || 获取偏向锁的过程中存在并发冲突，都会进入到 InterpreterRuntime::monitorenter 方法， 在该方法中会进行偏向锁撤销和升级。流程如下图所示：

Issue：有的同学可能会问了，对象一开始不是无锁状态吗，为什么上述偏向锁逻辑没有判断无锁状态的锁对象（001）？

只有匿名偏向的对象才能进入偏向锁模式。JVM 启动时会延时初始化偏向锁，默认是 4000ms。初始化后会将所有加载的 Klass 的 prototype header 修改为匿名偏向样式。当创建一个对象时，会通过 Klass 的 prototype_header 来初始化该对象的对象头。简单的说，偏向锁初始化结束后，后续所有对象的对象头都为匿名偏向样式，在此之前创建的对象则为无锁状态。而对于无锁状态的锁对象，如果有竞争，会直接进入到轻量级锁。这也是为什么 JVM 启动前 4 秒对象会直接进入到轻量级锁的原因。

为什么需要延迟初始化？

JVM 启动时必不可免会有大量 sync 的操作，而偏向锁并不是都有利。如果开启了偏向锁，会发生大量锁撤销和锁升级操作，大大降低 JVM 启动效率。

因此，我们可以明确地说，只有锁对象处于匿名偏向状态，线程才能拿到到我们通常意义上的偏向锁。而处于无锁状态的锁对象，只能进入到轻量级锁状态。

2.3.2 偏向锁的撤销

偏向锁的 撤销（revoke）是一个很特殊的操作，为了执行撤销操作，需要等待全局安全点，此时所有的工作线程都停止了执行。偏向锁的撤销操作并不是将对象恢复到无锁可偏向的状态（注意区分偏向锁撤销和释放这两个概念，撤销的触发见上图），而是在偏向锁的获取过程中，发现竞争时，直接将一个被偏向的对象升级到被加了轻量级锁的状态。这个操作的具体完成方式如下：

IRT_ENTRY_NO_ASYNC(void, InterpreterRuntime::monitorenter(JavaThread* thread, BasicObjectLock* elem))    ...  Handle h_obj(thread, elem->obj());  assert(Universe::heap()->is_in_reserved_or_null(h_obj()),         "must be NULL or an object");    // 开启了偏向锁  if (UseBiasedLocking) {    // Retry fast entry if bias is revoked to avoid unnecessary inflation    ObjectSynchronizer::fast_enter(h_obj, elem->lock(), true, CHECK);  } else {    ObjectSynchronizer::slow_enter(h_obj, elem->lock(), CHECK);  }  ...

如果开启了 JVM 偏向锁，则会进入到 ObjectSynchronizer::fast_enter 方法中。

void ObjectSynchronizer::fast_enter(Handle obj, BasicLock* lock, bool attempt_rebias, TRAPS) {   //再次校验 if (UseBiasedLocking) {    if (!SafepointSynchronize::is_at_safepoint()) {      //不在安全点的执行      BiasedLocking::Condition cond = BiasedLocking::revoke_and_rebias(obj, attempt_rebias, THREAD);      if (cond == BiasedLocking::BIAS_REVOKED_AND_REBIASED) {        return;      }    } else {      assert(!attempt_rebias, "can not rebias toward VM thread");          //批量撤销,底层调用bulk_revoke_or_rebias_at_safepoint      BiasedLocking::revoke_at_safepoint(obj);    }    assert(!obj->mark()->has_bias_pattern(), "biases should be revoked by now"); } slow_enter (obj, lock, THREAD) ;}

主要看 BiasedLocking::revoke_and_rebias 方法。这个方法的主要作用像它的方法名：撤销或者重偏向。第一个参数封装了锁对象和当前线程，第二个参数代表是否允许重偏向，这里是 true。

BiasedLocking::Condition BiasedLocking::revoke_and_rebias(Handle obj, bool attempt_rebias, TRAPS) {    assert(!SafepointSynchronize::is_at_safepoint(), "must not be called while at safepoint");  markOop mark = obj->mark(); //获取锁对象的对象头  if (mark->is_biased_anonymously() && !attempt_rebias) {    // 如果锁对象为匿名偏向状态且不允许重偏向下，进入该分支。在一个非全局安全点进行偏向锁撤销    markOop biased_value       = mark;    // 创建一个匿名偏向的markword    markOop unbiased_prototype = markOopDesc::prototype()->set_age(mark->age());    // 通过cas重新设置偏向锁状态    markOop res_mark = (markOop) Atomic::cmpxchg_ptr(unbiased_prototype, obj->mark_addr(), mark);    if (res_mark == biased_value) {// 如果CAS成功，返回偏向锁撤销状态      return BIAS_REVOKED;    }  } else if (mark->has_bias_pattern()) {    // 锁为偏向模式（101）会走到这里     Klass* k = obj->klass();     markOop prototype_header = k->prototype_header();    // 如果对应class关闭了偏向模式    if (!prototype_header->has_bias_pattern()) {      markOop biased_value       = mark;      // CAS更新对象头markword为非偏向锁      markOop res_mark = (markOop) Atomic::cmpxchg_ptr(prototype_header, obj->mark_addr(), mark);      assert(!(*(obj->mark_addr()))->has_bias_pattern(), "even if we raced, should still be revoked");      return BIAS_REVOKED; // 返回偏向锁撤销状态    } else if (prototype_header->bias_epoch() != mark->bias_epoch()) {      // 如果epoch过期，则进入当前分支      if (attempt_rebias) {        // 如果允许重偏        assert(THREAD->is_Java_thread(), "");        markOop biased_value       = mark;        markOop rebiased_prototype = markOopDesc::encode((JavaThread*) THREAD, mark->age(), prototype_header->bias_epoch());        // 通过CAS操作， 将本线程的 ThreadID 、时间戳、分代年龄尝试写入对象头中        markOop res_mark = (markOop) Atomic::cmpxchg_ptr(rebiased_prototype, obj->mark_addr(), mark);        if (res_mark == biased_value) { //CAS成功，则返回撤销和重新偏向状态          return BIAS_REVOKED_AND_REBIASED;        }      } else {        // 如果不允许尝试获取偏向锁，进入该分支取消偏向        // 通过CAS操作更新分代年龄        markOop biased_value       = mark;        markOop unbiased_prototype = markOopDesc::prototype()->set_age(mark->age());        markOop res_mark = (markOop) Atomic::cmpxchg_ptr(unbiased_prototype, obj->mark_addr(), mark);        if (res_mark == biased_value) { //如果CAS操作成功，返回偏向锁撤销状态          return BIAS_REVOKED;        }      }    }  }  //执行到这里有以下两种情况：  //1.对象不是偏向模式  //2.上面的cas操作失败  HeuristicsResult heuristics = update_heuristics(obj(), attempt_rebias);  if (heuristics == HR_NOT_BIASED) {    // 非偏向从这出去    // 轻量级锁、重量级锁    return NOT_BIASED;  } else if (heuristics == HR_SINGLE_REVOKE) {    // 撤销单个线程    // Mark，最常见的执行分支    // Mark，最常见的执行分支    // Mark，最常见的执行分支    Klass *k = obj->klass();    markOop prototype_header = k->prototype_header();    if (mark->biased_locker() == THREAD &&        prototype_header->bias_epoch() == mark->bias_epoch()) {      // 偏向当前线程且不过期      // 这里撤销的是偏向当前线程的锁，调用Object#hashcode方法时也会走到这一步      // 因为只要遍历当前线程的栈就能拿到lock record了，所以不需要等到safe point再撤销。      ResourceMark rm;      if (TraceBiasedLocking) {        tty->print_cr("Revoking bias by walking my own stack:");      }      BiasedLocking::Condition cond = revoke_bias(obj(), false, false, (JavaThread*) THREAD);      ((JavaThread*) THREAD)->set_cached_monitor_info(NULL);      assert(cond == BIAS_REVOKED, "why not?");      return cond;    } else {      // 下面代码最终会在safepoint调用revoke_bias方法撤销偏向      VM_RevokeBias revoke(&obj, (JavaThread*) THREAD);      VMThread::execute(&revoke);      return revoke.status_code();    }  }  assert((heuristics == HR_BULK_REVOKE) ||         (heuristics == HR_BULK_REBIAS), "?");   //批量撤销、批量重偏向的逻辑  VM_BulkRevokeBias bulk_revoke(&obj, (JavaThread*) THREAD,                                (heuristics == HR_BULK_REBIAS),                                attempt_rebias);  VMThread::execute(&bulk_revoke);  return bulk_revoke.status_code();}

这块代码注释写的算是比较清楚，只简单介绍下最常见的情况：锁已经偏向线程 A，此时线程 B 尝试获取锁。这种情况下会走到 Mark 标记的分支。如果需要撤销的是当前线程，只要遍历当前线程的栈就能拿到 lock record，可以直接调用 revoke_bias，不需要等到 safe point 再撤销。在调用 Object#hashcode 时，也会走到该分支将为偏向锁的锁对象直接恢复为无锁状态。若不是当前线程，会被 push 到 VM Thread 中等到 safepoint 的时候再执行。

VMThread 内部维护了一个 VMOperationQueue 类型的队列，用于保存内部提交的 VM 线程操作 VM_operation。GC、偏向锁的撤销等操作都是在这里被执行。

撤销调用的 revoke_bias 方法的代码就不贴了。大致逻辑是：

步骤 1、查看偏向的线程是否存活，如果已经死亡，则直接撤销偏向锁。JVM 维护了一个集合存放所有存活的线程，通过遍历该集合判断某个线程是否存活。

步骤 2、偏向的线程是否还在同步块中，如果不在，则撤销偏向锁。如果在同步块中，执行步骤 3。这里是否在同步块的判断基于上文提到的偏向锁的重入计数方式：在偏向锁的获取中，每次进入同步块的时候都会在栈中找到第一个可用（即栈中最高的）的 Lock Record，将其 obj 字段指向锁对象。每次解锁的时候都会把最低的 Lock Record 移除掉，所以可以通过遍历线程栈中的 Lock Record 来判断是否还在同步块中。轻量级锁的重入也是基于 Lock Record 的计数来判断。

步骤 3、升级为轻量级锁。将偏向线程所有相关 Lock Record 的 Displaced Mark Word 设置为 null，再将最高位的 Lock Record 的 Displaced Mark Word 设置为无锁状态，然后将对象头指向最高位的 Lock Record。这里没有用到 CAS 指令，因为是在 safepoint，可以直接升级成轻量级锁。

2.3.3 偏向锁的释放

偏向锁的释放可参考 bytecodeInterpreter.cpp#1923，这里也不贴了。偏向锁的释放只要将对应 Lock Record 释放就好了，但这里的释放并不会将 mark word 里面的 thread ID 去掉，这样做是为了下一次更方便的加锁。而轻量级锁则需要将 Displaced Mark Word 替换到对象头的 mark word 中。如果 CAS 失败或者是重量级锁则进入到 InterpreterRuntime::monitorexit 方法中。

2.3.4 批量重偏向与撤销

从上节偏向锁的加锁解锁过程中可以看出，当只有一个线程反复进入同步块时，偏向锁带来的性能开销基本可以忽略，但是当有其他线程尝试获得锁时，就需要等到 safe point 时将偏向锁撤销为无锁状态或升级为轻量级 / 重量级锁。因此，JVM 中增加了一种批量重偏向 / 撤销的机制以减少锁撤销的开销，而 mark word 中的 epoch 也是在这里被大量应用，这里不展开说明。但无论怎么优化，偏向锁的撤销仍有一定不可避免的成本。如果业务场景存在大量多线程竞争，那偏向锁的存在不仅不能提高性能，而且会导致性能下降（偏向锁并不都有利，jdk15 默认不开启）。

2.4 轻量级锁

引入轻量级锁的目的：在多线程交替执行同步块的情况下，尽量避免重量级锁使用的操作系统互斥量带来的开销，但是如果多个线程在同一时刻进入临界区，会导致轻量级锁膨胀升级重量级锁，所以轻量级锁的出现并非是要替代重量级锁。

2.4.1 进入轻量级锁

轻量级锁在上文或多或少已经涉及到，其获取流程入口为 bytecodeInterpreter.cpp#1816。前大半部分都是偏向锁逻辑，还有一部分为轻量级锁逻辑。在偏向锁逻辑中，cas 失败会执行到 InterpreterRuntime::monitorenter。在轻量级锁逻辑中，如果当前线程不是轻量级锁的重入，也会执行到 InterpreterRuntime::monitorenter。我们再看看 InterpreterRuntime::monitorenter 方法：

IRT_ENTRY_NO_ASYNC(void, InterpreterRuntime::monitorenter(JavaThread* thread, BasicObjectLock* elem))    ...  Handle h_obj(thread, elem->obj());  assert(Universe::heap()->is_in_reserved_or_null(h_obj()),         "must be NULL or an object");  if (UseBiasedLocking) {    // Retry fast entry if bias is revoked to avoid unnecessary inflation    ObjectSynchronizer::fast_enter(h_obj, elem->lock(), true, CHECK);  } else {    ObjectSynchronizer::slow_enter(h_obj, elem->lock(), CHECK);  }  ...IRT_END  

fast_enter 的流程在偏向锁的撤销小节中已经分析过，主要逻辑为 revoke_and_rebias：如果当前是偏向模式且偏向的线程还在使用锁，会将锁的 mark word 改为轻量级锁的状态，并将偏向的线程栈中的 Lock Record 修改为轻量级锁对应的形式（此时 Lock Record 是无锁状态），且返回值不是 BIAS_REVOKED_AND_REBIASED，会继续执行 slow_enter。

我们直接看 slow_enter 的流程:

void ObjectSynchronizer::slow_enter(Handle obj, BasicLock* lock, TRAPS) {    // 步骤1  markOop mark = obj->mark();  assert(!mark->has_bias_pattern(), "should not see bias pattern here");  // 步骤2  // 如果为无锁状态  if (mark->is_neutral()) {    // 步骤3    // 设置mark word到栈     lock->set_displaced_header(mark);    // CAS更新指向栈中Lock Record的指针    if (mark == (markOop) Atomic::cmpxchg_ptr(lock, obj()->mark_addr(), mark)) {      TEVENT (slow_enter: release stacklock) ;      return ;    }    // Fall through to inflate() ... cas失败走下面锁膨胀方法  } else if (mark->has_locker() && THREAD->is_lock_owned((address)mark->locker())) {    // 步骤4    // 为轻量级锁且owner为当前线程    assert(lock != mark->locker(), "must not re-lock the same lock");    assert(lock != (BasicLock*)obj->mark(), "don't relock with same BasicLock");    // 设置Displaced Mark Word为null，重入计数用    lock->set_displaced_header(NULL);    return;  }  // 步骤5  // 走到这一步说明已经是存在多个线程竞争锁了，需要膨胀或已经是重量级锁  lock->set_displaced_header(markOopDesc::unused_mark());  // 进入、膨胀到重量级锁的入口  // 膨胀后再调用monitor的enter方法竞争锁  ObjectSynchronizer::inflate(THREAD, obj())->enter(THREAD);}

步骤 1、markOop mark = obj->mark() 方法获取对象的 markOop 数据 mark；

步骤 2、mark->is_neutral() 方法判断 mark 是否为无锁状态，标识位 001；

步骤 3、如果 mark 处于无锁状态，把 mark 保存到 BasicLock 对象 (Lock Record 的属性) 的 displaced_header 字段；

步骤 3.1、通过 CAS 尝试将 Mark Word 更新为指向 BasicLock 对象的指针，如果更新成功，表示竞争到锁，则执行同步代码，否则执行步骤 4；

步骤 4、如果是重入，则设置 Displaced Mark Word 为 null。

步骤 5、到这说明有多个线程竞争轻量级锁，轻量级锁需要膨胀升级为重量级锁；

结合上文偏向锁的流程，可以整理得到如下的流程图：

2.4.2 轻量级锁的释放

轻量级锁释放的入口在 bytecodeInterpreter.cpp#1923。

轻量级锁释放时需要将 Displaced Mark Word 替换回对象头的 mark word 中。如果 CAS 失败或者是重量级锁则进入到 InterpreterRuntime::monitorexit 方法中。monitorexit 直接调用 slow_exit 方法释放 Lock Record。直接看 slow_exit：

IRT_ENTRY_NO_ASYNC(void, InterpreterRuntime::monitorexit(JavaThread* thread, BasicObjectLock* elem))    Handle h_obj(thread, elem->obj());  assert(Universe::heap()->is_in_reserved_or_null(h_obj()),         "must be NULL or an object");  if (elem == NULL || h_obj()->is_unlocked()) {    THROW(vmSymbols::java_lang_IllegalMonitorStateException());  }  // 直接调用slow_exit  ObjectSynchronizer::slow_exit(h_obj(), elem->lock(), thread);  // Free entry. This must be done here, since a pending exception might be installed on  // exit. If it is not cleared, the exception handling code will try to unlock the monitor again.  elem->set_obj(NULL);IRT_ENDvoid ObjectSynchronizer::slow_exit(oop object, BasicLock* lock, TRAPS) {    fast_exit (object, lock, THREAD) ;}void ObjectSynchronizer::fast_exit(oop object, BasicLock* lock, TRAPS) {    ...  // displaced header就是对象mark word的拷贝  markOop dhw = lock->displaced_header();  markOop mark ;  if (dhw == NULL) {     // 什么也不做     // Recursive stack-lock. 递归堆栈锁     // Diagnostics -- Could be: stack-locked, inflating, inflated.      ...     return ;  }  mark = object->mark() ;  // 此处为轻量级锁的释放过程，使用CAS方式解锁。  // 如果对象被当前线程堆栈锁定，尝试将displaced header和锁对象中的MarkWord替换回来。  // If the object is stack-locked by the current thread, try to  // swing the displaced header from the box back to the mark.  if (mark == (markOop) lock) {     assert (dhw->is_neutral(), "invariant") ;     if ((markOop) Atomic::cmpxchg_ptr (dhw, object->mark_addr(), mark) == mark) {        TEVENT (fast_exit: release stacklock) ;        return;     }  }  //走到这里说明已经是重量级锁或者解锁时发生了竞争，膨胀后再调用monitor的exit方法释放  ObjectSynchronizer::inflate(THREAD, object)->exit (true, THREAD) ;}

最后执行的是如果是 fast_exit 方法。如果是轻量级锁，尝试 cas 替换 mark word。若解锁时有竞争，会调用 inflate 方法进行重量级锁膨胀，升级到到重量级锁后再执行 exit 方法。

2.5 重量级锁

2.5.1 重量级锁的进入

重量级锁通过对象内部的监视器（monitor）实现，其依赖于底层操作系统的 Mutex Lock 实现，需要额外的用户态到内核态切换的开销。由上文分析，slow_enter 获取轻量级锁未成功时，会在 inflate 中完成锁膨胀：

ObjectMonitor * ATTR ObjectSynchronizer::inflate (Thread * Self, oop object) {    ...  for (;;) {      const markOop mark = object->mark() ;      assert (!mark->has_bias_pattern(), "invariant") ;        // mark是以下状态中的一种：      // *  Inflated（重量级锁状态）     - 直接返回      // *  Stack-locked（轻量级锁状态） - 膨胀      // *  INFLATING（膨胀中）    - 忙等待直到膨胀完成      // *  Neutral（无锁状态）      - 膨胀      // *  BIASED（偏向锁）       - 非法状态，在这里不会出现      // CASE: inflated      if (mark->has_monitor()) {          // 已经是重量级锁状态了，直接返回          ObjectMonitor * inf = mark->monitor() ;          ...          return inf ;      }      // CASE: inflation in progress      if (mark == markOopDesc::INFLATING()) {         // 正在膨胀中，说明另一个线程正在进行锁膨胀，continue重试         TEVENT (Inflate: spin while INFLATING) ;         // 在该方法中会进行spin/yield/park等操作完成自旋动作          ReadStableMark(object) ;         continue ;      }      // 当前是轻量级锁，后面分析      // CASE: stack-locked          if (mark->has_locker()) {        ...      }      // 无锁状态      // CASE: neutral      // 分配以及初始化ObjectMonitor对象      ObjectMonitor * m = omAlloc (Self) ;      // prepare m for installation - set monitor to initial state      m->Recycle();      m->set_header(mark);      // owner为NULL      m->set_owner(NULL);      m->set_object(object);      m->OwnerIsThread = 1 ;      m->_recursions   = 0 ;      m->_Responsible  = NULL ;      m->_SpinDuration = ObjectMonitor::Knob_SpinLimit ;       // consider: keep metastats by type/class        // 用CAS替换对象头的mark word为重量级锁状态      if (Atomic::cmpxchg_ptr (markOopDesc::encode(m), object->mark_addr(), mark) != mark) {          // 不成功说明有另外一个线程在执行inflate，释放monitor对象          m->set_object (NULL) ;          m->set_owner  (NULL) ;          m->OwnerIsThread = 0 ;          m->Recycle() ;          omRelease (Self, m, true) ;          m = NULL ;          continue ;          // interference - the markword changed - just retry.          // The state-transitions are one-way, so there's no chance of          // live-lock -- "Inflated" is an absorbing state.      }      ...      return m ;}

inflate 其中是一个 for 循环，主要是为了处理多线程同时调用 inflate 的情况。然后会根据锁对象的状态进行不同的处理：

1. 已经是重量级状态，说明膨胀已经完成，返回并继续执行 ObjectMonitor::enter 方法。
2. 如果是轻量级锁则需要进行膨胀操作。
3. 如果是膨胀中状态，则进行忙等待。
4. 如果是无锁状态则需要进行膨胀操作。

轻量级锁膨胀流程如下：

if (mark->has_locker()) {    // 步骤1  // 当前轻量级锁状态，先分配一个ObjectMonitor对象，并初始化值  ObjectMonitor * m = omAlloc (Self) ;            m->Recycle();  m->_Responsible  = NULL ;  m->OwnerIsThread = 0 ;  m->_recursions   = 0 ;  m->_SpinDuration = ObjectMonitor::Knob_SpinLimit ;   // Consider: maintain by type/class  // 步骤2  // 将锁对象的mark word设置为INFLATING (0)状态   markOop cmp = (markOop) Atomic::cmpxchg_ptr (markOopDesc::INFLATING(), object->mark_addr(), mark) ;  if (cmp != mark) {    omRelease (Self, m, true) ;    continue ;       // Interference -- just retry  }  // 步骤3  // 栈中的displaced mark word  markOop dmw = mark->displaced_mark_helper() ;  assert (dmw->is_neutral(), "invariant") ;  // 设置monitor的字段  m->set_header(dmw) ;  // owner为Lock Record  m->set_owner(mark->locker());  m->set_object(object);  ...  // 步骤4  // 将锁对象头设置为重量级锁状态  object->release_set_mark(markOopDesc::encode(m));  ...  return m ;}

步骤 1、调用 omAlloc 获取一个可用的 ObjectMonitor 对象。在 omAlloc 方法中会先从线程私有的 monitor 集合 omFreeList 中分配对象，如果 omFreeList 中已经没有 monitor 对象，则从 JVM 全局的 gFreeList 中分配一批 monitor 到 omFreeList 中；

步骤 2、通过 CAS 尝试将 Mark Word 设置为 markOopDesc:INFLATING，标识当前锁正在膨胀中。如果 CAS 失败，说明同一时刻其它线程已经将 Mark Word 设置为 markOopDesc:INFLATING，当前线程进行自旋等待膨胀完成。

步骤 3、如果 CAS 成功，设置 monitor 的各个字段：设置 monitor 的 header 字段为 displaced mark word，owner 字段为 Lock Record，obj 字段为锁对象等；

步骤 4、设置锁对象头的 mark word 为重量级锁状态，指向第一步分配的 monitor 对象；

2.5.2 monitor 竞争

当锁膨胀 inflate 执行完并返回对应的 ObjectMonitor 时，并不表示该线程竞争到了锁，真正的锁竞争发生在 ObjectMonitor::enter 方法中。

void ATTR ObjectMonitor::enter(TRAPS) {    Thread * const Self = THREAD ;  void * cur ;  // 步骤1  // owner为null，如果能CAS设置成功，则当前线程直接获得锁  cur = Atomic::cmpxchg_ptr (Self, &_owner, NULL) ;  if (cur == NULL) {     ...     return ;  }  // 如果是重入的情况  if (cur == Self) {     // TODO-FIXME: check for integer overflow!  BUGID 6557169.     _recursions ++ ;     return ;  }  // 步骤2  // 如果当前线程是之前持有轻量级锁的线程  // 上节轻量级锁膨胀将owner指向之前Lock Record的指针  // 这里利用owner判断是否第一次进入。  if (Self->is_lock_owned ((address)cur)) {    assert (_recursions == 0, "internal state error");    // 重入计数重置为1    _recursions = 1 ;    // 设置owner字段为当前线程    _owner = Self ;    OwnerIsThread = 1 ;    return ;  }  ...  // 步骤3  // 在调用系统的同步操作之前，先尝试自旋获得锁  if (Knob_SpinEarly && TrySpin (Self) > 0) {         ...     //自旋的过程中获得了锁，则直接返回     Self->_Stalled = 0 ;     return ;  }  ...  {     ...    // 步骤4    for (;;) {      jt->set_suspend_equivalent();      // 在该方法中调用系统同步操作      EnterI (THREAD) ;      ...    }    Self->set_current_pending_monitor(NULL);   }  ...}

步骤 1、当前是无锁、锁重入，简单操作后返回。

步骤 2、当前线程是之前持有轻量级锁的线程，则为首次进入，设置 recursions 为 1，owner 为当前线程，该线程成功获得锁并返回。

步骤 3、先自旋尝试获得锁，尽可能减少同步操作带来的开销。

步骤 4、调用 EnterI 方法。

这里注意，轻量级锁膨胀成功时，会把 owner 字段设置为 Lock Record 的指针，并在竞争时判断。这么做的原因是，假设当前线程 A 持有锁对象的锁，线程 B 进入同步代码块，并把锁对象升级为重量级锁。但此时，线程 A 可能还在执行，并无法感知其持有锁对象的变化。因此，需要线程 B 在执行 ObjectMonitor::enter 时，将自己放入到阻塞等列等待。并需要线程 A 第二次进入、或者退出的时候对 monitor 进行一些操作，以此保证代码块的同步。

这里有个自旋操作，直接看 TrySpin 对应的方法：

// TrySpin对应的方法int ObjectMonitor::TrySpin_VaryDuration (Thread * Self) {      // Dumb, brutal spin.  Good for comparative measurements against adaptive spinning.    int ctr = Knob_FixedSpin ;  // 固定自旋次数    if (ctr != 0) {        while (--ctr >= 0) {            if (TryLock (Self) > 0) return 1 ;            SpinPause () ;        }        return 0 ;    }    // 上一次自旋次数    for (ctr = Knob_PreSpin + 1; --ctr >= 0 ; ) {      if (TryLock(Self) > 0) {  // 尝试获取锁        // Increase _SpinDuration ...        // Note that we don't clamp SpinDuration precisely at SpinLimit.        // Raising _SpurDuration to the poverty line is key.        int x = _SpinDuration ;        if (x < Knob_SpinLimit) {           if (x < Knob_Poverty) x = Knob_Poverty ;           _SpinDuration = x + Knob_BonusB ;        }        return 1 ;      }      ...      ...

从方法名和注释可以看出，这就是自适应自旋，和网上说的轻量级锁 cas 失败会自旋的说法并不一致。实际上，无论是轻量级锁 cas 自旋还是重量级锁 cas 自旋，都是在用户态尽可能减少同步操作带来的开销，并没有太多本质上的区别。 到此为止，我们可以再结合上述的内容，整理出如下的状态转换图：

2.5.3 monitor 等待

ObjectMonitor 竞争失败的线程，通过自旋执行 ObjectMonitor::EnterI 方法等待锁的释放，EnterI 方法的部分逻辑实现如下：

void ATTR ObjectMonitor::EnterI (TRAPS) {          // 尝试自旋    if (TrySpin (Self) > 0) {        ...        return ;    }    ...    // 将线程封装成node节点中    ObjectWaiter node(Self) ;    Self->_ParkEvent->reset() ;    node._prev   = (ObjectWaiter *) 0xBAD ;    node.TState  = ObjectWaiter::TS_CXQ ;    // 将node节点插入到_cxq队列的头部，cxq是一个单向链表    ObjectWaiter * nxt ;    for (;;) {        node._next = nxt = _cxq ;        if (Atomic::cmpxchg_ptr (&node, &_cxq, nxt) == nxt) break ;        // CAS失败的话 再尝试获得锁，这样可以降低插入到_cxq队列的频率        if (TryLock (Self) > 0) {            ...            return ;        }    }        ...}

EnterI 大致原理：一个 ObjectMonitor 对象包括两个同步队列（_cxq 和_EntryList） ，以及一个等待队列_WaitSet。cxq、EntryList 、WaitSet 都是由 ObjectWaiter 构成的链表结构。其中，_cxq 为单向链表，_EntryList 为双向链表。

当一个线程尝试获得重量级锁且没有竞争到时，该线程会被封装成一个 ObjectWaiter 对象插入到 cxq 的队列的队首，然后调用 park 函数挂起当前线程，进入 BLOCKED 状态。当线程释放锁时，会根据唤醒策略，从 cxq 或 EntryList 中挑选一个线程 unpark 唤醒。如果线程获得锁后调用 Object#wait 方法，则会将线程加入到 WaitSet 中，进入 WAITING 或 TIMED_WAITING 状态。当被 Object#notify 唤醒后，会将线程从 WaitSet 移动到 cxq 或 EntryList 中去，进入 BLOCKED 状态。需要注意的是，当调用一个锁对象的 wait 或 notify 方法时，若当前锁的状态是偏向锁或轻量级锁则会先膨胀成重量级锁。

2.5.4 monitor 释放

当某个持有锁的线程执行完同步代码块时，会进行锁的释放。在 HotSpot 中，通过退出 monitor 的方式实现锁的释放，并通知被阻塞的线程，具体实现位于 ObjectMonitor::exit 方法中。

void ATTR ObjectMonitor::exit(bool not_suspended, TRAPS) {     Thread * Self = THREAD ;   // 如果_owner不是当前线程   if (THREAD != _owner) {     // 轻量级锁膨胀上来，还没调用过enter方法，_owner还指向之前轻量级锁Lock Record的指针。     if (THREAD->is_lock_owned((address) _owner)) {       assert (_recursions == 0, "invariant") ;       _owner = THREAD ;       _recursions = 0 ;       OwnerIsThread = 1 ;     } else {       // 异常情况:当前不是持有锁的线程       TEVENT (Exit - Throw IMSX) ;       assert(false, "Non-balanced monitor enter/exit!");       if (false) {          THROW(vmSymbols::java_lang_IllegalMonitorStateException());       }       return;     }   }   // 重入计数器还不为0，则计数器-1后返回   if (_recursions != 0) {     _recursions--;        // this is simple recursive enter     TEVENT (Inflated exit - recursive) ;     return ;   }   ...   //这块开始是唤醒操作   for (;;) {     ...     ...     ObjectWaiter * w = NULL ;     // 根据QMode的不同会有不同的唤醒策略，默认为0     int QMode = Knob_QMode ;     if (QMode == 2 && _cxq != NULL) {          ...          ...

步骤 1、处理 owner 不是当前线程的状况。这里特指之前持有轻量级锁的线程，由于没有调用过 enter，owner 指向仍为 Lock Record 的指针，以及其他异常情况。

步骤 2、重入计数器还不为 0，则计数器 - 1 后返回。

步骤 3、唤醒操作。根据不同的策略（由 QMode 指定），从 cxq 或 EntryList 中获取头节点，通过 ObjectMonitor::ExitEpilog 方法唤醒该节点封装的线程，唤醒操作最终由 unpark 完成。

根据 QMode 的不同 (默认为 0)，有不同的处理方式：

QMode = 0：暂时什么都不做；
QMode = 2 且 cxq 非空：取 cxq 队列队首的 ObjectWaiter 对象，调用 ExitEpilog 方法，该方法会唤醒 ObjectWaiter 对象的线程，然后立即返回，后面的代码不会执行了；
QMode = 3 且 cxq 非空：把 cxq 队列插入到 EntryList 的尾部；
QMode = 4 且 cxq 非空：把 cxq 队列插入到 EntryList 的头部；

只有 QMode=2 的时候会提前返回，等于 0、3、4 的时继续执行：

1. 如果 EntryList 的首元素非空，就取出来调用 ExitEpilog 方法，该方法会唤醒 ObjectWaiter 对象的线程，然后立即返回；
2. 如果 EntryList 的首元素为空，就将 cxq 的所有元素放入到 EntryList 中，然后再从 EntryList 中取出来队首元素执行 ExitEpilog 方法，然后立即返回；
3. 被唤醒的线程，继续竞争 monitor；

2.6 本章小节

本章介绍了 Synchronized 的底层实现和锁升级过程。对于锁升级，再看看本文整理的图，一图胜千言：

这里有几个点可以注意一下:

1.HotSpot 中，只用到了模板解释器，并没有用到字节码解释器，monitorenter 的实际入口位于 templateTable_x86_64.cpp#3667。本文的分析是基于字节码解释器的，因此部分结论不能作为实际执行情况。本章的内容只能作为 Synchronized 锁升级原理、各类锁的适用场景的一种 窥探。
2. 再次强调，无锁状态只能升级为轻量级锁，匿名偏向状态才能进入到偏向锁。
3. 偏向锁并不都有利，其适用于单个线程重入的场景，原因为：偏向锁的撤销需要进入 safepoint，开销较大。需要进入 safepoint 是由于，偏向锁的撤销需要对锁对象的 lock record 进行操作，而 lock record 要到其他线程的栈帧中遍历寻找。在非 safepoint，栈帧是动态的，会引入更多的问题。目前看来，偏向锁存在的价值是为历史遗留的 Collection 类如 Vector 和 HashTable 等做优化，迟早药丸。Java 15 中默认不开启。
4. 执行 Object 类的 hashcode 方法，偏向锁撤销并且锁会膨胀为轻量级锁或者重量锁。执行 Object 类的 wait/notify/notifyall 方法，偏向锁撤销并膨胀成重量级锁。
5. 轻量级锁适用于两个线程的交替执行场景：线程 A 进入轻量级锁，退出同步代码块并释放锁，会将锁对象恢复为无锁状态；线程 B 再进入锁，发现为无锁状态，会 cas 尝试获取该锁对象的轻量级锁。如果有竞争，则直接膨胀为重量级锁，没有自旋操作，详情看 10。
6. 唤醒策略依赖于 QMode。重量级锁获取失败后，线程会加入 cxq 队列。当线程释放锁时，会从 cxq 或 EntryList 中挑选一个线程唤醒。线程获得锁后调用 Object#wait 方法，则会将线程加入到 WaitSet 中。当被 Object#notify 唤醒后，会将线程从 WaitSet 移动到 cxq 或 EntryList 中去。
7. 重量级锁，会将线程放进等待队列，等待操作系统调度。而偏向锁和轻量级锁，未交由操作系统调度，依然处于用户态，只是采用 CAS 无锁竞争的方式获取锁。CAS 通过 Unsafe 类中 compareAndSwap 方法，jni 调用 C++ 方法，通过汇编指令锁住 cpu 中的北桥信号。
8. 许多文章声称一个对象关联到一个 monitor，这个说法不够准确。如果对象已经是重量级锁了，对象头的确指向了一个 monitor。但对于正在膨胀的锁，会先从线程私有的 monitor 集合 omFreeList 中分配对象。如果 omFreeList 中已经没有 monitor 对象，再从 JVM 全局的 gFreeList 中分配一批 monitor 到 omFreeList 中。
9. 在编译期间还有锁消除和锁粗化这两步锁优化操作，本章没做介绍。
10. 字节码实现中没有体现轻量级锁自旋逻辑。这可能是模板解释器中的实现，或者是 jvm 在不同平台、不同 jvm 版本的不同实现。但本文分析的字节码链路中没有发现该逻辑，倒是发现了重量级锁会自适应自旋竞争锁。因此个人对轻量级锁自适应自旋的说法存疑，至少 hotspot jdk8u 字节码实现中没有这个逻辑。但两者都是在用户态进行自适应自旋，以尽可能减少同步操作带来的开销，没有太多本质上的区别，并不需要特别关心。

三、线程的实现与状态转换

3.1 线程的实现

（1）内核线程实现

内核线程（Kernel-Level Thread，KLT）：由内核来完成线程切换，内核通过调度器对线程进行调度，并负责将线程的任务映射到各个处理器上。 程序一般不会直接去使用内核线程，而是使用内核线程的一种高级接口 —— 轻量级进程（Light Weight Process，LWP），也就是通常意义上的线程。

优点：每个 LWP 都是独立的调度单元。一个 LWP 被阻塞，不影响其他 LWP。

缺点：基于 KLT，耗资源。线程的创建、析构、同步都需要进行系统调用，频繁的用户态、内核态切换。

(2) 用户线程实现（User Thread，UT）

广义：非内核线程，都可认为是用户线程。（包括 LWT，虽然 LWT 的大多操作都要映射到 KLT）

狭义：完全建立在用户空间的线程库上，系统内核不能感知线程存在的实现。UT 也只感知到掌管这些 UT 的进程 P。

优点：用户线程的创建、同步、销毁和调度完全在用户态中完成，不需要内核的帮助。

缺点：线程的创建、销毁、切换和调度都是用户必须考虑到问题。“阻塞如何处理”、“多处理器系统中如何将线程映射到其他处理器上” 这类问题解决起来将会异常困难。

（3) 混合实现 混合模式下，即存在用户线程，也存在轻量级进程。用户线程的创建、切换、析构等操作依然廉价，可以支持大规模的用户线程并发，且可以使用内核线程提供的线程调度功能及处理器映射。

线程的实现依赖操作系统支持的线程模型。在主流的操作系统上，hotspot、classic、art 等虚拟机默认是 1:1 的线程模型。在 Solaris 平台上，hotspot 支持 1:1、N：M 两种线程模型。

3.2 线程的转换

首先明确一点，当我们讨论一个线程的状态，指的是 Thread 类中 threadStatus 的值。

private volatile int threadStatus = 0;  

该值映射后对应的枚举为：

public enum State {      NEW,    RUNNABLE,    BLOCKED,    WAITING,    TIMED_WAITING,    TERMINATED;}

也就是说，线程的具体状态，看 threadStatus 就行了。

NEW

先要创建 Thread 类的对象，才能谈其状态。

Thread t = new Thread();  

这个时候，线程 t 就处于新建状态。但他还不是 “线程”。

RUNNABLE

然后调用 start () 方法。

t.start();  

调用 start () 后，会执行一个 native 方法创建内核线程，以 linux 为例：

private native void start0();// 最后走到这hotspot/src/os/linux/vm/os_linux.cpp  pthread_create(...);  

这时候才有一个真正的线程创建出来，并即刻开始运行。这个内核线程与线程 t 进行 1：1 的映射。这时候 t 具备运行能力，进入 RUNNABLE 状态。 RUNNABLE 可以细分为 READY 和 RUNNING，两者的区别只是是否等待到了资源并开始运行。
处于 RUNNABLE 且未运行的线程，会进入一个就绪队列中，等待操作系统的调度。处于就绪队列的线程都在等待资源，这个资源可以是 cpu 的时间片、也可以是系统的 IO。 JVM 并不关系 READY 和 RUNNING 这两种状态，毕竟上述的枚举类都不对 RUNNABLE 进行细分。

TERMINATED

当一个线程执行完毕（或者调用已经不建议的 stop 方法），线程的状态就变为 TERMINATED。进入 TERMINATED 后，线程的状态不可逆，无法再复活。

关于 BLOCKED、WAITING、TIMED_WAITING

BLOCKED、WAITING、TIMED_WAITING 都是带有同步语义的状态，我们先看一下 wait 和 notify 方法的底层实现。
wait 方法的底层实现:

void ObjectSynchronizer::wait(Handle obj, jlong millis, TRAPS) {      ...    ...  //获得Object的monitor对象  ObjectMonitor* monitor = ObjectSynchronizer::inflate(THREAD, obj());  DTRACE_MONITOR_WAIT_PROBE(monitor, obj(), THREAD, millis);  //调用monitor的wait方法  monitor->wait(millis, true, THREAD);    ...}  inline void ObjectMonitor::AddWaiter(ObjectWaiter* node) {    ...  if (_WaitSet == NULL) {    //_WaitSet为null，就初始化_waitSet    _WaitSet = node;    node->_prev = node;    node->_next = node;  } else {    //否则就尾插    ObjectWaiter* head = _WaitSet ;    ObjectWaiter* tail = head->_prev;    assert(tail->_next == head, "invariant check");    tail->_next = node;    head->_prev = node;    node->_next = head;    node->_prev = tail;  }}

主要流程：通过 object 获得 objectMonitor，将 Thread 封装成 OjectWaiter 对象，然后 addWaiter 将它插入 waitSet 中，进入 waiting 或 timed_waiting 状态。最后释放锁，并通过底层的 park 方法挂起线程；

notify 方法的底层实现：

void ObjectSynchronizer::notify(Handle obj, TRAPS) {      ...    ...    ObjectSynchronizer::inflate(THREAD, obj())->notify(THREAD);}    //通过inflate方法得到ObjectMonitor对象    ObjectMonitor * ATTR ObjectSynchronizer::inflate (Thread * Self, oop object) {    ...     if (mark->has_monitor()) {          ObjectMonitor * inf = mark->monitor() ;          assert (inf->header()->is_neutral(), "invariant");          assert (inf->object() == object, "invariant") ;          assert (ObjectSynchronizer::verify_objmon_isinpool(inf), "monitor is inva;lid");          return inf       }    ...      }    //调用ObjectMonitor的notify方法    void ObjectMonitor::notify(TRAPS) {    ...    //调用DequeueWaiter方法移出_waiterSet第一个结点    ObjectWaiter * iterator = DequeueWaiter() ;    //将上面DequeueWaiter尾插入_EntrySet或cxq等操作    ...    ...  }

通过 object 获得 objectMonitor，调用 objectMonitor 的 notify 方法。这个 notify 最后会走到 ObjectMonitor::DequeueWaiter 方法，获取 waitSet 列表中的第一个 ObjectWaiter 节点。并根据不同的策略，将取出来的 ObjectWaiter 节点，加入到 EntryList 或 cxq 中。 notifyAll 的实现类似于 notify，主要差别在多了个 for 循环。

由这里以及上一章 2.5.4 monitor 释放小节中可以了解到，notify 和 notifyAll 并不会立即释放所占有的 ObjectMonitor 对象，其真正释放 ObjectMonitor 的时间点是在执行 monitorexit 指令。

一旦释放 ObjectMonitor 对象了，entryList 和 cxq 中的 ObjectWaiter 节点会依据 QMode 所配置的策略，通过 ExitEpilog 方法唤醒取出来的 ObjectWaiter 节点。被唤醒的线程，继续参与 monitor 的竞争。若竞争失败，重新进入 BLOCKED 状态，再回顾一下 monitor 的核心结构。

既然聊到了 wait 和 notify，那顺便也看下 join、sleep 和 park。

打开 Thread.join () 的源码：

public final synchronized void join(long millis) throws InterruptedException {      ...  if (millis == 0) {    while (isAlive()) {      wait(0);    }  } else {    while (isAlive()) {      long delay = millis - now;      if (delay <= 0) {        break;      }      wait(delay);      now = System.currentTimeMillis() - base;    }  }}

join 的本质仍然是 wait() 方法。在使用 join 时，JVM 会帮我们隐式调用 notify，因此我们不需要主动 notify 唤醒主线程。 而 sleep() 方法最终是调用 SleepEvent 对象的 park 方法：

int os::sleep(Thread* thread, jlong millis, bool interruptible) {    //获取thread中的_SleepEvent对象  ParkEvent * const slp = thread->_SleepEvent ;  ...  //如果是允许被打断  if (interruptible) {    //记录下当前时间戳，这是时间比较的基准    jlong prevtime = javaTimeNanos();    for (;;) {      //检查打断标记，如果打断标记为true，则直接返回      if (os::is_interrupted(thread, true)) {        return OS_INTRPT;      }      //线程被唤醒后的当前时间戳      jlong newtime = javaTimeNanos();      //睡眠毫秒数减去当前已经经过的毫秒数      millis -= (newtime - prevtime) / NANOSECS_PER_MILLISEC;      //如果小于0，那么说明已经睡眠了足够多的时间，直接返回      if (millis <= 0) {        return OS_OK;      }      //更新基准时间      prevtime = newtime;      //调用_SleepEvent对象的park方法，阻塞线程      slp->park(millis);    }  } else {    //如果不能打断，除了不再返回OS_INTRPT以外，逻辑是完全相同的    for (;;) {      ...      slp->park(millis);      ...    }    return OS_OK ;  }}

Thread.sleep 在 jvm 层面上是调用 thread 中 SleepEvent 对象的 park() 方法实现阻塞线程，在此过程中会通过判断时间戳来决定线程的睡眠时间是否达到了指定的毫秒。看到这里，对于 sleep 和 wait 的区别应该会有更深入的理解。

park、unpark 方法也与同步语义无关。每个线程都与一个许可 (permit) 关联。unpark 函数为线程提供 permit，线程调用 park 函数则等待并消耗 permit。park 和 unpark 方法具体实现比较复杂，这里不展开。 到此为止，我们可以整理出如下的线程状态转换图。

3.3 本章小节

Java 将 OS 经典五种状态中的 ready 和 running，统一为 RUNNABLE。将 WAITING（即不可能得到 CPU 运行机会的状态）细分为了 BLOCKED、WAITING、TIMED_WAITING。本章的内容较为简短，因为部分的内容已囊括在第一章中。

这里提个会使人困惑的问题： 使用 socket 时，调用 accept ()，read () 等阻塞方法时，线程处于什么状态？

答案是 java 线程处于 RUNNABLE 状态，OS 线程处于 WAITING 状态。因为在 jvm 层面，等待 cpu 时间片和等待 io 资源是等价的。

这里有几个点可以注意一下：

1.JVM 线程状态不代表内核线程状态。
2.BLOCKED 的线程一定处于 entryList 或 cxq 中，而处于 WAITING 和 TIMED WAITING 的线程，可能是由于执行了 sleep 或 park 进入该状态，不一定在 waitSet 中。也就是说，处于 BLOCKED 状态的线程一定是与同步相关。由这可延伸出，调用 jdk 的 lock 并获取不到锁的线程，进入的是 WAITING 或 TIMED_WAITING 状态，而不是 BLOCKED 状态。

四、相关资料

本文主要参考资料：

死磕 Synchronized 底层实现 -- 概论

死磕 Synchronized 底层实现 -- 偏向锁

死磕 Synchronized 底层实现 -- 轻量级锁

死磕 Synchronized 底层实现 -- 重量级锁

本文转自有赞技术

辗转反侧之路

没错，我换了新的笔记本😓

我之前一直使用得 2015 年中期那款 15 寸 i7 16G 内存，256G 的硬盘！别看它有点年限了，但是它依然劲头十足，老当益壮！

最让我难受的就是硬盘空间不够，其实说实话，如果不是为了工作方便点，这个 256G 还是够用的。

系统➕一堆软件➕ maven 仓库➕微信聊天记录➕公司资料文件，就占得满满当当了～

像 IDEA、WPS、Microsoft Office 等等这种大型软件下来，十几 G 就没了；微信记录是由于工作需要，有时候经常会翻历史记录，私人的记录删了就删了，工作的记录那叫留痕，懂得都懂～

maven 本地仓库，大大小小也好几个 G，有时候自己折腾点其他项目，还有前端的一些小东西，一个项目 node_modules 几百 M，多来几个，也上 G～

尤其是公司的资料，虽说用了 SVN 这种版本管理工具，但是真大，每次项目上线，都需要备份，它就有 40 多个 G ❗️❗️

之所以会把这些文件都 download 本地，也是为了有时候用的方便，也偶尔会在家里排查个问题，看看代码，看看 SVN 里的资料、文档等，不至于到时候想找当时的东西发现却没有。

还有就是经常逛一些博客、网站，特效稍微多了点，明显就能感受到那个卡、掉帧，不过这到不影响工作 🥲🥲

种种因素吧，想过换硬盘，我这款是最后一款支持可以更换的，需要转接头一堆，怕换了性能差劲，不如不换，又怕换了，出了故障，我就这一个吃饭的家伙，想想还是别乱折腾了。

然后换电脑的计划就出来了，我是计划着到时候要换，肯定换当时的高配，也只是计划着，具体日子也没定。

恰巧，之前老妹就一直给我说，她那个旧电脑已经不行了！面试都经常黑屏死机，面试官都觉得她作弊😄😄

老妹需要换，我也需要换；我的不够用，给她绰绰有余，那我买个新的，旧的给她。

老妹还说发了奖学金补助我呢🥹🥹

本来打算今年年底，等她发了奖金，我就换~ 可是开学季教育优惠来了呀，还送耳机 AirPods ！

想了许久，在开学季 7.14 刚开始，我就下单了~

16 寸 M1 Pro 32G 内存 1TB 硬盘，算是 M1 Pro 的顶配了，硬盘没必要再大了~ 64G 只能给 M1 Max，奈何用不到 Max， M1 Pro 16 其实都够用，为了能提高效率以及多用几年，上 32G ~

开箱

emmm，没了！

T*D，用手机录了开箱视频，手机空间不够了，我就赶紧隔空投送到电脑，紧接着就把手机里的视频删了，彻底删除了那种。

最后我在电脑上打开一看，我去年买了个表，怎么是个图片！传错了。。。。。。

So，没开箱了视频了。

对了，有一个取快递的照片，那个快递柜刚刚好，感觉就是定制的一般

真实体验

爽！太爽了！

流畅，真流畅！

120Hz 刷新率，看了直接回不去！

效果图

Cron 表达式是一个具有时间含义的字符串，字符串以 5~6 个空格隔开，分为 6~7 个域，格式为X X X X X X X。 其中X是一个域的占位符。最后一个代表年份的域非必须，可省略。单个域有多个取值时，使用半角逗号,隔开取值。每个域可以是确定的取值，也可以是具有逻辑意义的特殊字符。每个域最多支持一个前导零。

说明 如指定 2022 年每天上午 8:15 执行任务，Cron 表达式可指定为0 15 8 ? * * 2022 或 0 15 08 ? * * 2022 ，而不能指定为 0 15 008 ? * * 2022。

域取值

下表为 Cron 表达式中六个域能够取的值以及支持的特殊字符。

特殊字符

Cron 表达式中的每个域都支持一定数量的特殊字符，每个特殊字符有其特殊含义。

取值示例

以下为 Cron 表达式的取值示例。

本文摘自阿里云

首先要说明，本文是使用的 Spring Cloud Gateway 自带的或者称原生的 Redis 限流！

背景

限流作用就不说了，往往都是防止一些恶意请求，无限制请求接口导致服务处理时间过长，继而导致响应延迟，服务阻塞等等，所以会对高频率的一些接口添加限流这样的功能。

通常，我们往往是针对 1 个路由或者说是对 1 个接口进行限流，限流的规则通常是：XXX 路由 XXX 在 XXX 时间内最多允许访问 XXX 次。

比如：查询用户信息接口 [路由] 每个用户 [条件] 每秒 [频率时间] 最多支持访问 10 次 [频率最大限制]。

举个明白点的例子，我 1 秒内连续请求 11 次 [查询用户信息接口]，那么第 11 次就应该被拦截，提示请求频繁，相信大家在一些双 11 这样的节日里会遇到过类似情况~

我们换个规则，再举个例子：[查询用户信息接口] 每秒 最多支持访问 100 次~，也就是说不管谁请求，反正 [查询用户信息接口] 1 秒内最大支持访问 100 次请求，超过 100 的都会被拦截~

以上两个例子，都是单独使用，是对 1 个路由指定了 1 个限流的规则，实际业务需求中，可能还需要 2 个或者多个规则同时使用。

比如：

[查询用户信息接口] 每个用户 每秒 最多支持访问 10 次 ，这是规则 1，用来限制单个用户的次数；

同时，[查询用户信息接口] 每秒 最多支持访问 100 次~，这是规则 2，用来限制接口的次数。

这个我再举个明白点的例子，假如有 10 个人在同 1 秒来请求 [查询用户信息接口]

前 8 个人都在 1 秒内请求 10 次，（8 个人每个人都不违反规则 1，接口请求总数也不超过 100 次，接口还可以请求 20 次，不违反规则 2）

第 9 个人请求 11 次，（达到规则 1 限流条件，这个人第 11 次请求肯定被拦截，接口请求总数不超过 100 次，接口还可以请求 9 次）

第 10 个人请求 10 次，（不违反规则 1，接口请求为 101 次，总数超过 100 次，达到规则 2 限流条件，所以这个人第 10 次请求肯定被拦截）

当然请求顺序这都是理想状态，实际场景中顺序会有差别~

既然了解后，那么现在的问题就是：Spring Cloud Gateway 自带的限流默认 1 个路由（或者说是 1 个接口）只能配置 1 个限流规则！本文就是来解决这种问题，让 1 个路由适配多个规则！🤯

！！！Spring Cloud Gateway 提供了一套限流方案的接口，并且也基于 Redis 实现了一套限流方案，这个也就是本文的要着重分析的点！

Spring Cloud Gateway 大致流程熟悉

大致流程图

具体流程这里就不说了，我直接说本文的涉及的要点。

当请求进入到网关，网关会根据请求路由来组装对应的过滤器，而我们的限流也是其中的过滤器，Spring Cloud Gateway 自己的实现就是：RequestRateLimiterGatewayFilterFactory，所以我们要分析其源码，了解它大致干了什么事，我们才好知道有没有办法调整！

平常配置使用回顾

分析前，我们先回顾下平常我们配置限流是怎么配置的。

附： RateLimiterConfig，首先我们定义好限流规则 KeyResolver

/** * Author: Suremotoo */@Configurationpublic class RateLimiterConfig {    @Primary    @Bean(value = "remoteAddrKeyResolver")    public KeyResolver remoteAddrKeyResolver() {        return exchange -> {            String hostAddress = exchange.getRequest().getRemoteAddress().getAddress().getHostAddress();            // log("remoteAddrKeyResolver 限流规则 ip {}", hostAddress);            return Mono.just(hostAddress);        };    }    /**     * 按照 Path 限流     *     * @return key     */    @Bean(value = "pathKeyResolver")    public KeyResolver pathKeyResolver() {        return exchange -> {            Route route = (Route)exchange.getAttribute(ServerWebExchangeUtils.GATEWAY_ROUTE_ATTR);            // log("pathKeyResolver 限流规则 ip {}", route.getId());            return Mono.just(exchange.getRequest().getPath().toString());        };    }}

然后在 application.yml 配置路由的限流， 示例:

spring:  cloud:    gateway:      routes:        - id: query_user_info_route          uri: lb://user-center          filters:            - name: RequestRateLimiter              args:                # 令牌桶每秒填充平均速率                redis-rate-limiter.replenishRate: 1                # 令牌桶的上限                redis-rate-limiter.burstCapacity: 10                # 使用 SpEL 表达式从 Spring 容器中获取 Bean 对象,pathKeyResolver 是根据地址来限流                key-resolver: "#{@remoteAddrKeyResolver}" # 详情见 RateLimiterConfig

可以看到，过滤器 （filters）,我们配置的是 RequestRateLimiter，这里的 RequestRateLimiter 其实指的就是 RequestRateLimiterGatewayFilterFactory ，只是省略了后面的 GatewayFilterFactory~

该过滤器的参数有 redis-rate-limiter、key-resolver,说明这两个其实是很重要的属性！

1 个限流规则我们配置 1 个过滤器及属性，那么我想再加一个规则，正常情况我们会这样做，示例：

spring:  cloud:    gateway:      routes:        - id: query_user_info_route          uri: lb://user-center          filters:          # 第一个限流过滤器和规则            - name: RequestRateLimiter              args:                # 令牌桶每秒填充平均速率                redis-rate-limiter.replenishRate: 1                # 令牌桶的上限                redis-rate-limiter.burstCapacity: 100                # 使用 SpEL 表达式从 Spring 容器中获取 Bean 对象,pathKeyResolver 是根据地址来限流                key-resolver: "#{@pathKeyResolver}" # 详情见 RateLimiterConfig          # 第二个限流过滤器和规则            - name: RequestRateLimiter              args:                # 令牌桶每秒填充平均速率                redis-rate-limiter.replenishRate: 1                # 令牌桶的上限                redis-rate-limiter.burstCapacity: 10                # 使用 SpEL 表达式从 Spring 容器中获取 Bean 对象,remoteAddrKeyResolver 是根据请求 ip 来限流                key-resolver: "#{@remoteAddrKeyResolver}" # 详情见 RateLimiterConfig

写的时候还洋洋洒洒~

写完后看上没问题，程序也能跑起来，但你会发现实际就只有 1 个生效，下面属性的把上面的覆盖了！，欧了买了噶，~

是配置了两个一样的过滤器，实际运行的时候，也确实都跑了两次这个过滤器，只是每次取的速率什么的，是相同的_{，相当于同一个限流规则，校验了两遍}

具体跑起来效果我就不展示了，接下来我们来正儿八经分析下源码，看看什么情况！

RequestRateLimiterGatewayFilterFactory 源码分析

这里仅列出核心代码分析😬

public class RequestRateLimiterGatewayFilterFactory extends AbstractGatewayFilterFactory<RequestRateLimiterGatewayFilterFactory.Config> {    public static final String KEY_RESOLVER_KEY = "keyResolver";    private static final String EMPTY_KEY = "____EMPTY_KEY__";       /**     * 限流算法及实现     */    private final RateLimiter defaultRateLimiter;       /**     * 限流关键字 key     */    private final KeyResolver defaultKeyResolver;    private boolean denyEmptyKey = true;    private String emptyKeyStatusCode;    public RequestRateLimiterGatewayFilterFactory(RateLimiter defaultRateLimiter, KeyResolver defaultKeyResolver) {        super(RequestRateLimiterGatewayFilterFactory.Config.class);        this.emptyKeyStatusCode = HttpStatus.FORBIDDEN.name();        this.defaultRateLimiter = defaultRateLimiter;        this.defaultKeyResolver = defaultKeyResolver;    }    public KeyResolver getDefaultKeyResolver() {        return this.defaultKeyResolver;    }    public RateLimiter getDefaultRateLimiter() {        return this.defaultRateLimiter;    }    public boolean isDenyEmptyKey() {        return this.denyEmptyKey;    }    public void setDenyEmptyKey(boolean denyEmptyKey) {        this.denyEmptyKey = denyEmptyKey;    }    public String getEmptyKeyStatusCode() {        return this.emptyKeyStatusCode;    }    public void setEmptyKeyStatusCode(String emptyKeyStatusCode) {        this.emptyKeyStatusCode = emptyKeyStatusCode;    }    public GatewayFilter apply(RequestRateLimiterGatewayFilterFactory.Config config) {        KeyResolver resolver = (KeyResolver)this.getOrDefault(config.keyResolver, this.defaultKeyResolver);        RateLimiter<Object> limiter = (RateLimiter)this.getOrDefault(config.rateLimiter, this.defaultRateLimiter);        boolean denyEmpty = (Boolean)this.getOrDefault(config.denyEmptyKey, this.denyEmptyKey);        HttpStatusHolder emptyKeyStatus = HttpStatusHolder.parse((String)this.getOrDefault(config.emptyKeyStatus, this.emptyKeyStatusCode));        return (exchange, chain) -> {            Route route = (Route)exchange.getAttribute(ServerWebExchangeUtils.GATEWAY_ROUTE_ATTR);            return resolver.resolve(exchange).defaultIfEmpty("____EMPTY_KEY__").flatMap((key) -> {                if ("____EMPTY_KEY__".equals(key)) {                    if (denyEmpty) {                        ServerWebExchangeUtils.setResponseStatus(exchange, emptyKeyStatus);                        return exchange.getResponse().setComplete();                    } else {                        return chain.filter(exchange);                    }                } else {                    // isAllowed 方法，根据 [路由 id] 和 [限流关键字 key] 来判断是否要限流                    return limiter.isAllowed(route.getId(), key).flatMap((response) -> {                        Iterator var4 = response.getHeaders().entrySet().iterator();                        while(var4.hasNext()) {                            Entry<String, String> header = (Entry)var4.next();                            exchange.getResponse().getHeaders().add((String)header.getKey(), (String)header.getValue());                        }                        if (response.isAllowed()) {                            return chain.filter(exchange);                        } else {                            ServerWebExchangeUtils.setResponseStatus(exchange, config.getStatusCode());                            return exchange.getResponse().setComplete();                        }                    });                }            });        };    }    private <T> T getOrDefault(T configValue, T defaultValue) {        return configValue != null ? configValue : defaultValue;    }

上述代码中，结合我们从 application.yml 配置中查看，该源码中其实最重要的就是：

RateLimiter ：限流算法及实现（实际实现是令牌桶算法，这里先不做深入探究）

KeyResolver ：限流关键字 key（这里 key 其实就是我们说的对用户限流、对接口限流，当我们要对 ip 限流时，这个 key 就是请求的 ip）

还有就是 limiter.isAllowed 这个函数，是校验是否达到限流条件的重要方法！

KeyResolver 看上去就不是影响多规则限流的重要因素~，那么我们就直接来看看 RateLimiter~

RateLimiter 源码分析

打开源码一看，哦是 interface，我们看看实现类（ idea 中点击下图标记📌处即可查看）

发现有两个实现类，一个是抽象类 AbstractRateLimiter,一个是基于 Redis 实现的 RedisRateLimiter,(o゜▽゜)o☆[BINGO!]，肯定是 RedisRateLimiter，我们直接打开它~

RedisRateLimiter 源码(别着急看代码，先往下翻)

@ConfigurationProperties("spring.cloud.gateway.redis-rate-limiter")public class RedisRateLimiter extends AbstractRateLimiter<RedisRateLimiter.Config> implements ApplicationContextAware {    /** @deprecated */    @Deprecated    public static final String REPLENISH_RATE_KEY = "replenishRate";    /** @deprecated */    @Deprecated    public static final String BURST_CAPACITY_KEY = "burstCapacity";    public static final String CONFIGURATION_PROPERTY_NAME = "redis-rate-limiter";    public static final String REDIS_SCRIPT_NAME = "redisRequestRateLimiterScript";    public static final String REMAINING_HEADER = "X-RateLimit-Remaining";    public static final String REPLENISH_RATE_HEADER = "X-RateLimit-Replenish-Rate";    public static final String BURST_CAPACITY_HEADER = "X-RateLimit-Burst-Capacity";    private Log log = LogFactory.getLog(this.getClass());    private ReactiveRedisTemplate<String, String> redisTemplate;    private RedisScript<List<Long>> script;    private AtomicBoolean initialized = new AtomicBoolean(false);    private RedisRateLimiter.Config defaultConfig;    private boolean includeHeaders = true;    private String remainingHeader = "X-RateLimit-Remaining";    private String replenishRateHeader = "X-RateLimit-Replenish-Rate";    private String burstCapacityHeader = "X-RateLimit-Burst-Capacity";    public RedisRateLimiter(ReactiveRedisTemplate<String, String> redisTemplate, RedisScript<List<Long>> script, Validator validator) {        super(RedisRateLimiter.Config.class, "redis-rate-limiter", validator);        this.redisTemplate = redisTemplate;        this.script = script;        this.initialized.compareAndSet(false, true);    }    public RedisRateLimiter(int defaultReplenishRate, int defaultBurstCapacity) {        super(RedisRateLimiter.Config.class, "redis-rate-limiter", (Validator)null);        this.defaultConfig = (new RedisRateLimiter.Config()).setReplenishRate(defaultReplenishRate).setBurstCapacity(defaultBurstCapacity);    }    static List<String> getKeys(String id) {        String prefix = "request_rate_limiter.{" + id;        String tokenKey = prefix + "}.tokens";        String timestampKey = prefix + "}.timestamp";        return Arrays.asList(tokenKey, timestampKey);    }    public boolean isIncludeHeaders() {        return this.includeHeaders;    }    public void setIncludeHeaders(boolean includeHeaders) {        this.includeHeaders = includeHeaders;    }    public String getRemainingHeader() {        return this.remainingHeader;    }    public void setRemainingHeader(String remainingHeader) {        this.remainingHeader = remainingHeader;    }    public String getReplenishRateHeader() {        return this.replenishRateHeader;    }    public void setReplenishRateHeader(String replenishRateHeader) {        this.replenishRateHeader = replenishRateHeader;    }    public String getBurstCapacityHeader() {        return this.burstCapacityHeader;    }    public void setBurstCapacityHeader(String burstCapacityHeader) {        this.burstCapacityHeader = burstCapacityHeader;    }    public void setApplicationContext(ApplicationContext context) throws BeansException {        if (this.initialized.compareAndSet(false, true)) {            this.redisTemplate = (ReactiveRedisTemplate)context.getBean("stringReactiveRedisTemplate", ReactiveRedisTemplate.class);            this.script = (RedisScript)context.getBean("redisRequestRateLimiterScript", RedisScript.class);            if (context.getBeanNamesForType(Validator.class).length > 0) {                this.setValidator((Validator)context.getBean(Validator.class));            }        }    }    RedisRateLimiter.Config getDefaultConfig() {        return this.defaultConfig;    }    public Mono<Response> isAllowed(String routeId, String id) {        if (!this.initialized.get()) {            throw new IllegalStateException("RedisRateLimiter is not initialized");        } else {            RedisRateLimiter.Config routeConfig = this.loadConfiguration(routeId);            int replenishRate = routeConfig.getReplenishRate();            int burstCapacity = routeConfig.getBurstCapacity();            try {                List<String> keys = getKeys(id);                List<String> scriptArgs = Arrays.asList(replenishRate + "", burstCapacity + "", Instant.now().getEpochSecond() + "", "1");                Flux<List<Long>> flux = this.redisTemplate.execute(this.script, keys, scriptArgs);                return flux.onErrorResume((throwable) -> {                    return Flux.just(Arrays.asList(1L, -1L));                }).reduce(new ArrayList(), (longs, l) -> {                    longs.addAll(l);                    return longs;                }).map((results) -> {                    boolean allowed = (Long)results.get(0) == 1L;                    Long tokensLeft = (Long)results.get(1);                    Response response = new Response(allowed, this.getHeaders(routeConfig, tokensLeft));                    if (this.log.isDebugEnabled()) {                        this.log.debug("response: " + response);                    }                    return response;                });            } catch (Exception var9) {                this.log.error("Error determining if user allowed from redis", var9);                return Mono.just(new Response(true, this.getHeaders(routeConfig, -1L)));            }        }    }    RedisRateLimiter.Config loadConfiguration(String routeId) {        RedisRateLimiter.Config routeConfig = (RedisRateLimiter.Config)this.getConfig().getOrDefault(routeId, this.defaultConfig);        if (routeConfig == null) {            routeConfig = (RedisRateLimiter.Config)this.getConfig().get("defaultFilters");        }        if (routeConfig == null) {            throw new IllegalArgumentException("No Configuration found for route " + routeId + " or defaultFilters");        } else {            return routeConfig;        }    }    @NotNull    public Map<String, String> getHeaders(RedisRateLimiter.Config config, Long tokensLeft) {        Map<String, String> headers = new HashMap();        if (this.isIncludeHeaders()) {            headers.put(this.remainingHeader, tokensLeft.toString());            headers.put(this.replenishRateHeader, String.valueOf(config.getReplenishRate()));            headers.put(this.burstCapacityHeader, String.valueOf(config.getBurstCapacity()));        }        return headers;    }    @Validated    public static class Config {        @Min(1L)        private int replenishRate;        @Min(1L)        private int burstCapacity = 1;        public Config() {        }        public int getReplenishRate() {            return this.replenishRate;        }        public RedisRateLimiter.Config setReplenishRate(int replenishRate) {            this.replenishRate = replenishRate;            return this;        }        public int getBurstCapacity() {            return this.burstCapacity;        }        public RedisRateLimiter.Config setBurstCapacity(int burstCapacity) {            this.burstCapacity = burstCapacity;            return this;        }        public String toString() {            return "Config{replenishRate=" + this.replenishRate + ", burstCapacity=" + this.burstCapacity + '}';        }    }}

别看代码多，不要慌！实际上就是基于 Redis 限流是怎么个算法实现的，但是和限流为什么只能有一个规则，好像啥都没有_{🤣，说明不在这里}

📢注意了，但是它 extends AbstractRateLimiter 了，继承了 AbstractRateLimiter 类，我们还是看看这个类吧~

AbstractRateLimiter 源码分析

AbstractRateLimiter 源码

public abstract class AbstractRateLimiter<C> extends AbstractStatefulConfigurable<C> implements RateLimiter<C>, ApplicationListener<FilterArgsEvent> {    private String configurationPropertyName;    private Validator validator;    protected AbstractRateLimiter(Class<C> configClass, String configurationPropertyName, Validator validator) {        super(configClass);        this.configurationPropertyName = configurationPropertyName;        this.validator = validator;    }    protected String getConfigurationPropertyName() {        return this.configurationPropertyName;    }    protected Validator getValidator() {        return this.validator;    }    public void setValidator(Validator validator) {        this.validator = validator;    }    public void onApplicationEvent(FilterArgsEvent event) {        Map<String, Object> args = event.getArgs();        if (!args.isEmpty() && this.hasRelevantKey(args)) {            String routeId = event.getRouteId();            C routeConfig = this.newConfig();            ConfigurationUtils.bind(routeConfig, args, this.configurationPropertyName, this.configurationPropertyName, this.validator);          // 重点            this.getConfig().put(routeId, routeConfig);        }    }    private boolean hasRelevantKey(Map<String, Object> args) {        return args.keySet().stream().anyMatch((key) -> {            return key.startsWith(this.configurationPropertyName + ".");        });    }    public String toString() {        return (new ToStringCreator(this)).append("configurationPropertyName", this.configurationPropertyName).append("config", this.getConfig()).append("configClass", this.getConfigClass()).toString();    }}

代码不多，就一个核心方法 onApplicationEvent，参数是个 FilterArgsEvent，看上去是把过滤器的参数 args 都获取出来，再做处理

小提示，看看人家的命名，一看就让人知道大概什么意思，以后大家也注意下命名！

贴一下限流的核心配置示例：

        - name: RequestRateLimiter          args:            # 令牌桶每秒填充平均速率            redis-rate-limiter.replenishRate: 1            # 令牌桶的上限            redis-rate-limiter.burstCapacity: 10            # 使用 SpEL 表达式从 Spring 容器中获取 Bean 对象,pathKeyResolver 是根据地址来限流            key-resolver: "#{@pathKeyResolver}"

捋一捋，这个过滤器的参数 args 就是限流参数，而

RedisRateLimiter extends AbstractRateLimiter<RedisRateLimiter.Config>

那么 onApplicationEvent,应该是把参数对应的 routeConfig 对象初始化出来~，也就是 RedisRateLimiter.Config 的这个 Config 对象，

Config 里就两个属性，也就是限流的重要参数，果然没错~

简单再贴一下 RedisRateLimiter.Config 代码

@Validatedpublic static class Config {    @Min(1L)    private int replenishRate;    @Min(1L)    private int burstCapacity = 1;    public Config() {    }    // 省略...}

最后最后有个 this.getConfig().put(routeId, routeConfig);

这不就是把路由和其对应的限流规则存到一个 Map 里嘛~，盲猜都知道这个 this.getConfig() 是个 Map,可以去 AbstractStatefulConfigurable 代码里看，这里就不展示了~

AbstractRateLimiter<C> extends AbstractStatefulConfigurable<C>

其实看到 this.getConfig().put(routeId, routeConfig); 这里我大概已经知道是什么问题了：我们针对一个 1 路由配置多个限流规则，最终名为 Config 的 Map 里存储的只有 1 个！！因为存储到 Map 里的 key 就是 routeId~

你的路由 id 是固定的，所以后面的规则把前面的覆盖了~~~🎉🎉🎉🎉

改造方案

既然找到问题了，我们就想办法改造它！经过前面的分析，我们应该要改造的就是 onApplicationEvent 方法里的 this.getConfig().put(routeId, routeConfig);

我们应该改造成，放入 Config 里的 Key 不用 RouteId!

用什么呢，我这里 使用 routeId 和 KeyResolver 的 hashcode 组合

改造前再捋清楚，Spring Cloud Gateway 自带的 Redis 限流实现类是 RedisRateLimiter,它继承的抽象类 AbstractRateLimiter,而我们要改造的方法在 AbstractRateLimiter，

所以我们重写一个 RedisRateLimiter，重写 onApplicationEvent 方法 ！

ok！Just Do It~

自定义 DiyRedisRateLimiter

首先，我们新建 1 个类，叫 DiyRedisRateLimiter，剩下的代码就从 RedisRateLimiter 全部拷贝过来！

然后重写 onApplicationEvent 方法！

DiyRedisRateLimiter 代码:

/** * Author: Suremotoo */public class DiyRedisRateLimiter extends AbstractRateLimiter<DiyRedisRateLimiter.Config>    implements ApplicationContextAware {    public static final String REPLENISH_RATE_KEY = "replenishRate";    public static final String BURST_CAPACITY_KEY = "burstCapacity";    public static final String CONFIGURATION_PROPERTY_NAME = "redis-rate-limiter";    public static final String REDIS_SCRIPT_NAME = "redisRequestRateLimiterScript";    public static final String REMAINING_HEADER = "X-RateLimit-Remaining";    public static final String REPLENISH_RATE_HEADER = "X-RateLimit-Replenish-Rate";    public static final String BURST_CAPACITY_HEADER = "X-RateLimit-Burst-Capacity";    private Log log = LogFactory.getLog(this.getClass());    private ReactiveRedisTemplate<String, String> redisTemplate;    private RedisScript<List<Long>> script;    private AtomicBoolean initialized = new AtomicBoolean(false);    private DiyRedisRateLimiter.Config defaultConfig;    private boolean includeHeaders = true;    private String remainingHeader = "X-RateLimit-Remaining";    private String replenishRateHeader = "X-RateLimit-Replenish-Rate";    private String burstCapacityHeader = "X-RateLimit-Burst-Capacity";    public DiyRedisRateLimiter(ReactiveRedisTemplate<String, String> redisTemplate, RedisScript<List<Long>> script,        Validator validator) {        super(DiyRedisRateLimiter.Config.class, "redis-rate-limiter", validator);        this.redisTemplate = redisTemplate;        this.script = script;        this.initialized.compareAndSet(false, true);    }    public DiyRedisRateLimiter(int defaultReplenishRate, int defaultBurstCapacity) {        super(DiyRedisRateLimiter.Config.class, "redis-rate-limiter", (Validator)null);        this.defaultConfig = (new DiyRedisRateLimiter.Config()).setReplenishRate(defaultReplenishRate)            .setBurstCapacity(defaultBurstCapacity);    }    static List<String> getKeys(String id) {        String prefix = "request_rate_limiter.{" + id;        String tokenKey = prefix + "}.tokens";        String timestampKey = prefix + "}.timestamp";        return Arrays.asList(tokenKey, timestampKey);    }    public boolean isIncludeHeaders() {        return this.includeHeaders;    }    public void setIncludeHeaders(boolean includeHeaders) {        this.includeHeaders = includeHeaders;    }    public String getRemainingHeader() {        return this.remainingHeader;    }    public void setRemainingHeader(String remainingHeader) {        this.remainingHeader = remainingHeader;    }    public String getReplenishRateHeader() {        return this.replenishRateHeader;    }    public void setReplenishRateHeader(String replenishRateHeader) {        this.replenishRateHeader = replenishRateHeader;    }    public String getBurstCapacityHeader() {        return this.burstCapacityHeader;    }    public void setBurstCapacityHeader(String burstCapacityHeader) {        this.burstCapacityHeader = burstCapacityHeader;    }    @Override    public void setApplicationContext(ApplicationContext context) throws BeansException {        if (this.initialized.compareAndSet(false, true)) {            this.redisTemplate =                (ReactiveRedisTemplate)context.getBean("stringReactiveRedisTemplate", ReactiveRedisTemplate.class);            this.script = (RedisScript)context.getBean("redisRequestRateLimiterScript", RedisScript.class);            if (context.getBeanNamesForType(Validator.class).length > 0) {                this.setValidator((Validator)context.getBean(Validator.class));            }        }    }    DiyRedisRateLimiter.Config getDefaultConfig() {        return this.defaultConfig;    }                                                                                                           //                                    ``.-/++oosyyyyyyyyyssso++/-.`                                    //                                ./oydmmmhyso+/:------://++oshdmmmhs/-`                               //                            `:odmdhs+:.``                   ```-/ohmNmyo:`                           //                         ./ymmy+-``                               ``-+ymNd+.                         //                      `:ymmy/.`            小哥哥                      `.-sdmy:                       //                    `/hmh/.                    小姐姐                      ./hmy:`                    //                   :hNy:./o-                                                `:dNh/`                  //                 `oNd:`:dNs.             帅哥                                  `+dNy.                 //                `sNd- /Nd:`                   美女                               .yNm/`               //               `yMh. +Nd-                                                        `+NNo`              //              `oNd` /Nm-                                           `ss.            :mNo`             //              /Nm- .dN/       `..-:/+osssssooooooooooooo+//:-.``   `dMo             +NN/             //             -mN:  /Nh``..:/oyhddddhysssoossssssssssyyhhhddmmmdhys+:hMh`            `hMd`            //            `hNo` `yMyohmmdhso/-..`                      ``.-:/oyhdmNMd`             :NM/            //            +Mh`  `yNmhmMd.                                       `.yMm.             `hMh            //           .mN:    `-. sMd`                                         oMm.              +MN-           //  ./+:.    oMy`        sMm.                                         sMm.              :NN:           // .dMNNms. .dN:--`      sMm.                                         yMh`              .mM/           // :NN+:yNmo/NmyNN-      sMm.        我是 Suremotoo                  `dMy               `mN/           // .mMo  :dMNMMMNN:    `+NNs`                                        .NN+               -Nm`           //  yMd.  `oNMMdyMs:///hMm:         看这里                            oMm.               oMy            //  .NMo    -hMMNNmdhmMMh.                                          -mMs           /yo`:mN-            //   +MN:    `/dMm/``hMh`              看这里                         oMMho/-.``    :NMMymN:             //    +NN+`    `/mMdsMN:                                            `:oydmNMNmdhhhmMNMMm:              //     /mMy`     .yNMMd`                  看这里                       ``.-yMNhhhyo.-:.               //      -dMd-      :mMh`                                                  .sNN+`                       //       `yMm/      /NNs.                     看这里                      .+mNh:                         //        `oNNo`    `/mMmo.`                                         `-smNd/`                          //          :dMh-    :dNmNNdo:.`                                ``-/sdNMMy.                            //           .yMm+` /mm/.:sdmNmdyo++/:--..`````````.---::::/+osydmNmdy+:yNh-                           //            `oNNy/mm:    `.-+oydNMNmmmNmmmmmmmmmmmNNNNNNNNNMNhyo:.`   `/mm+`                         //              :dMNMh`      .yy..dN+.-yMh///++++++//::sMd:-:Nm-          -yNy.                        //               .sNMh`      +Mm.-Nm.  sMs   下   |    -Nd. `dNy/          `oNh.                       //                `oNN+.    `hMh`+Mh`  yM+   面   |   `dN/  sMMN+`         `oNd.                      //                  -sdmy+-`.mMo sMs  `hN/   就   |     sMs  :NmdN+`         `hMs                      //                    ./sddddMN-`dM/  `dN:   是   |    /Nd` .mN/dN+`    `.:ohNM+                      //                       `-+NMh`-Nm.  .NN.   改   |     .mm. `hM/-dNo-:+shddhosNh.                     //                         -NMo +Mh   /Nd`   造   |   `mM+ `yMs .ymNMNy+:.` `sNy.                    //                         /NN: oMh   oMd`   的   |     `dMs `yMd` `.+Nd.      `yNs`                   //                         -ss` /s+   /yo`   方   |   `sdo  +dh`    +ms`      .hd-    //        这                                      |   //  这↓   // 👇👇👇👇👇👇👇👇👇👇👇👇👇👇    @Override    public void onApplicationEvent(FilterArgsEvent event) {        Map<String, Object> args = event.getArgs();        if (!args.isEmpty() && this.hasRelevantKey(args)) {            String routeId = event.getRouteId();            Config routeConfig = this.newConfig();            ConfigurationUtils.bind(routeConfig, args, super.getConfigurationPropertyName(),                this.getConfigurationPropertyName(), this.getValidator());            /**             * 这里重写 id，防止过冲规则重复被覆盖 by Suremotoo             */            // 使用 routeId + KeyResolver 的 hashcode 组合作为配置 id，防止重复            routeId = routeId + event.getArgs().get("key-resolver").hashCode();            // System.out.println("routeId put = " + routeId);            this.getConfig().put(routeId, routeConfig);        }    }      /*****************************************************************/    private boolean hasRelevantKey(Map<String, Object> args) {        return args.keySet().stream().anyMatch((key) -> {            return key.startsWith(this.getConfigurationPropertyName() + ".");        });    }    @Override    public Mono<Response> isAllowed(String routeId, String id) {        if (!this.initialized.get()) {            throw new IllegalStateException("DiyRedisRateLimiter is not initialized");        } else {            DiyRedisRateLimiter.Config routeConfig = this.loadConfiguration(routeId);            int replenishRate = routeConfig.getReplenishRate();            int burstCapacity = routeConfig.getBurstCapacity();            try {                List<String> keys = getKeys(id);                List<String> scriptArgs =                    Arrays.asList(replenishRate + "", burstCapacity + "", Instant.now().getEpochSecond() + "", "1");                Flux<List<Long>> flux = this.redisTemplate.execute(this.script, keys, scriptArgs);                return flux.onErrorResume((throwable) -> {                    return Flux.just(Arrays.asList(1L, -1L));                }).reduce(new ArrayList(), (longs, l) -> {                    longs.addAll(l);                    return longs;                }).map((results) -> {                    boolean allowed = (Long)results.get(0) == 1L;                    Long tokensLeft = (Long)results.get(1);                    Response response = new Response(allowed, this.getHeaders(routeConfig, tokensLeft));                    if (this.log.isDebugEnabled()) {                        this.log.debug("response: " + response);                    }                    return response;                });            } catch (Exception var9) {                this.log.error("Error determining if user allowed from redis", var9);                return Mono.just(new Response(true, this.getHeaders(routeConfig, -1L)));            }        }    }    DiyRedisRateLimiter.Config loadConfiguration(String routeId) {        DiyRedisRateLimiter.Config routeConfig =            (DiyRedisRateLimiter.Config)this.getConfig().getOrDefault(routeId, this.defaultConfig);        if (routeConfig == null) {            routeConfig = (DiyRedisRateLimiter.Config)this.getConfig().get("defaultFilters");        }        if (routeConfig == null) {            throw new IllegalArgumentException("No Configuration found for route " + routeId + " or defaultFilters");        } else {            return routeConfig;        }    }    @NotNull    public Map<String, String> getHeaders(DiyRedisRateLimiter.Config config, Long tokensLeft) {        Map<String, String> headers = new HashMap();        if (this.isIncludeHeaders()) {            headers.put(this.remainingHeader, tokensLeft.toString());            headers.put(this.replenishRateHeader, String.valueOf(config.getReplenishRate()));            headers.put(this.burstCapacityHeader, String.valueOf(config.getBurstCapacity()));        }        return headers;    }    @Validated    public static class Config {        @Min(1L)        private int replenishRate;        @Min(1L)        private int burstCapacity = 1;        public Config() {}        public int getReplenishRate() {            return this.replenishRate;        }        public DiyRedisRateLimiter.Config setReplenishRate(int replenishRate) {            this.replenishRate = replenishRate;            return this;        }        public int getBurstCapacity() {            return this.burstCapacity;        }        public DiyRedisRateLimiter.Config setBurstCapacity(int burstCapacity) {            this.burstCapacity = burstCapacity;            return this;        }        @Override        public String toString() {            return "Config{replenishRate=" + this.replenishRate + ", burstCapacity=" + this.burstCapacity + '}';        }    }}

创建完后，我们再在将这个类初始化为 Spring 里

/** * Author: Suremotoo */@Configurationpublic class RateLimiterConfig {    /**     * 使用自定义的限流类     *      * @param redisTemplate     * @param redisScript     * @param validator     * @return     */    @Bean    @Primary    public DiyRedisRateLimiter diyRedisRateLimiter(ReactiveRedisTemplate<String, String> redisTemplate,        @Qualifier(DiyRedisRateLimiter.REDIS_SCRIPT_NAME) RedisScript<List<Long>> redisScript, Validator validator) {        return new DiyRedisRateLimiter(redisTemplate, redisScript, validator);    }    // .... 其他 KeyResolver 省略，详情见上文描述中的 RateLimiterConfig  }

这就弄好了，但是注意，我们还没有改造完！

这仅仅是放入 Map 中已经不是 1 个了！但是用的时候呢？还记得前面提到的 isAllow 方法吗？这个方法是在 RequestRateLimiterGatewayFilterFactory 里的 apply 方法中 ，所以我们还要重写 这里！

自定义 DiyRequestRateLimiterGatewayFilterFactory

首先，我们新建 1 个类，叫 DiyRequestRateLimiterGatewayFilterFactory，继承 RequestRateLimiterGatewayFilterFactory

然后重写 apply 方法！

DiyRequestRateLimiterGatewayFilterFactory 代码示例：

/** * Author: Suremotoo */@Componentpublic class DiyRequestRateLimiterGatewayFilterFactory extends RequestRateLimiterGatewayFilterFactory {    private final RateLimiter defaultRateLimiter;    private final KeyResolver defaultKeyResolver;    private boolean denyEmptyKey = true;    public DiyRequestRateLimiterGatewayFilterFactory(RateLimiter defaultRateLimiter, KeyResolver defaultKeyResolver) {        super(defaultRateLimiter, defaultKeyResolver);        this.defaultKeyResolver = defaultKeyResolver;        this.defaultRateLimiter = defaultRateLimiter;    }    @Override    public GatewayFilter apply(RequestRateLimiterGatewayFilterFactory.Config config) {        KeyResolver resolver = (KeyResolver)this.getOrDefault(config.getKeyResolver(), this.defaultKeyResolver);        RateLimiter<Object> limiter = (RateLimiter)this.getOrDefault(config.getRateLimiter(), this.defaultRateLimiter);        boolean denyEmpty = (Boolean)this.getOrDefault(config.getDenyEmptyKey(), this.denyEmptyKey);        HttpStatusHolder emptyKeyStatus =            HttpStatusHolder.parse((String)this.getOrDefault(config.getEmptyKeyStatus(), this.getEmptyKeyStatusCode()));        return (exchange, chain) -> {            Route route = (Route)exchange.getAttribute(ServerWebExchangeUtils.GATEWAY_ROUTE_ATTR);            return resolver.resolve(exchange).defaultIfEmpty("____EMPTY_KEY__").flatMap((key) -> {                                if ("____EMPTY_KEY__".equals(key)) {                    if (denyEmpty) {                        ServerWebExchangeUtils.setResponseStatus(exchange, emptyKeyStatus);                        return exchange.getResponse().setComplete();                    } else {                        return chain.filter(exchange);                    }                } else {                                         //             `-/++//////+++-`                                //          .+o+:.          `:os+`                             //        .so:      在这里      .+o.                           //       :y:y.                    `yo                          //      -h.h`  .-://::///:-.` y`    os                         //     `h`+hyo+/-.``.....-:/ooN-    `d.                        // `:. o/ ``d.                d-     oo                        // +yssmd- `m.    在这里     `m`     +o                        // .d`.hmssd-                /h    /-h.                        //  :h. :hm:    在这里       .+oyyshy-                         //   .h: `h+                  `oy.                             //    `ss`+yys+:-.`````..-:/osyh`                              //      /dh  `soyod+ooo+doh+`  -y-                             //       .y+-/ys::s     o//N/   `d.                            //         `:m:d`++     -y.hsooooy/                            //           y.s +:     .y`h .y`  s.                          //                                //   👇👇👇👇👇🏻                                      /**                     * 改造校验时传入的 routeId                     */                    // 获取 routeId                    String routeId = route.getId();                    // 使用 routeId+KeyResolver 的 hashcode 获取 config                    routeId = routeId + resolver.hashCode();                                        return limiter.isAllowed(routeId, key).flatMap((response) -> {                        Iterator var4 = response.getHeaders().entrySet().iterator();                        while (var4.hasNext()) {                            Map.Entry<String, String> header = (Map.Entry)var4.next();                            exchange.getResponse().getHeaders().add((String)header.getKey(), (String)header.getValue());                        }                        if (response.isAllowed()) {                            return chain.filter(exchange);                        } else {                            // 原返回信息代码                            // ServerWebExchangeUtils.setResponseStatus(exchange, config.getStatusCode());                            // return exchange.getResponse().setComplete();                                                             // 自定义返回信息 | start                            ServerHttpResponse httpResponse = exchange.getResponse();                            httpResponse.setStatusCode(config.getStatusCode());                            Map<String, Object> dataMap = new HashMap<>(4);                            dataMap.put("errorCode", "1000");                            dataMap.put("errorMsg", "操作频繁，歇会再来~");                            DataBuffer buffer = httpResponse.bufferFactory()                                .wrap(JSONObject.wrap(dataMap).toString().getBytes(StandardCharsets.UTF_8));                            return httpResponse.writeWith(Mono.just(buffer));                            // 自定义返回信息 | end                        }                    });                }            });        };    }    private <T> T getOrDefault(T configValue, T defaultValue) {        return configValue != null ? configValue : defaultValue;    }}

然后在 application.yml 中使用的时候用自己定义的 DiyRequestRateLimiterGatewayFilterFactory

示例：

spring:  cloud:    gateway:      routes:        - id: query_user_info_route          uri: lb://user-center          filters:          # 第一个限流过滤器和规则            - name: DiyRequestRateLimiter              args:                # 令牌桶每秒填充平均速率                redis-rate-limiter.replenishRate: 1                # 令牌桶的上限                redis-rate-limiter.burstCapacity: 100                # 使用 SpEL 表达式从 Spring 容器中获取 Bean 对象,pathKeyResolver 是根据地址来限流                key-resolver: "#{@pathKeyResolver}" # 详情见 RateLimiterConfig          # 第二个限流过滤器和规则            - name: DiyRequestRateLimiter              args:                # 令牌桶每秒填充平均速率                redis-rate-limiter.replenishRate: 1                # 令牌桶的上限                redis-rate-limiter.burstCapacity: 10                # 使用 SpEL 表达式从 Spring 容器中获取 Bean 对象,remoteAddrKeyResolver 是根据请求 ip 来限流                key-resolver: "#{@remoteAddrKeyResolver}" # 详情见 RateLimiterConfig

终于大功告成~

使用 Docker 来构建 1 主 2 从的半同步复制的 MySQL 集群，并使用 MHA 来对 MySQL 集群进行监控，实现 MySQL 集群的故障转移。

01. 系统软件版本

Linux 构建：Docker version 19.03.13

Linux 版本：CentOS 7.9.2009

MySQL 版本：MySQL 5.7.31

MHA 版本：0.58-0.el7.centos

辅助软件： Docker Desktop

02. 系统架构

服务器清单 Container List

注意：本次使用 Docker 来构建，默认 Docker 启动时，端口都是 172.17.0.* 依次启动分配的，为保证和以上服务器的 ip 对应，请按照以下顺序依次启动：

1. mysql-master
2. msyql-slave-1
3. mysql-slave-2
4. Mysql-mha

03. 软件安装

3.1 创建 centos7_mysql:5.7.31 镜像

使用 Docker 拉取 CentOS 7.8 镜像到本地，启动该镜像为 centos 容器，注意 Docker 镜像源地址。

# 拉取 CentOS 7.9.2009 镜像docker pull centos:centos7.9.2009# 创建容器 centos docker run -dit --privileged --name centos-mysql -p 22:22 centos:centos7.9.2009 /usr/sbin/init# 进入容器docker exec -it centos-mysql /bin/bash

注意，如果提示 22 端口被监听占用，可任意改用其他未使用过的端口，比如： 222:22

完整示例：docker run -dit --privileged --name centos-mysql -p 222:22 centos:centos7.9.2009 /usr/sbin/init

创建完在 Docker Desktop 中可以查看到如下信息, 第一个 centos_mysql 就是刚刚建的

安装 SSH，MySQL 等软件。

## 换源 aliyunyum -y install wgetwget -O /etc/yum.repos.d/CentOS-Base.repo http://mirrors.aliyun.com/repo/Centos-7.repoyum clean all && yum makecache## 安装 SSH yum -y install openssh-server# 修改 root 密码为 rootecho 'root:root'|chpasswd# 修改系统语言编码echo "export LC_ALL=en_US.UTF-8"  >>  /etc/profilesource /etc/profile# 修改系统时间ln -sf /usr/share/zoneinfo/Asia/Shanghai /etc/localtime# 重启 sshd systemctl enable sshdsystemctl restart sshd## 安装 MySQL# 下载 mysql 源wget https://dev.mysql.com/get/mysql80-community-release-el7-3.noarch.rpm# 安装 mysql 源rpm -ivh mysql80-community-release-el7-3.noarch.rpm # 更新源yum clean all && yum makecache# 关闭 8.0 版本，开启 5.7 版本yum-config-manager --disable mysql80-community yum-config-manager --enable mysql57-community # 安装 mysql-community-serveryum install -y mysql-community-server# 查看 mysql 状态，先不要启动 mysql！！！systemctl status mysqld.service

安装完 MySQL 之后，导出 centos 容器。

# 导出 centos， centos-mysqldocker export  centos-mysql  > centos7_mysql57.tar# 导入 centos7_mysql57.tar 为本地镜像docker import centos7_mysql57.tar# 镜像重命名 “镜像 id” 就填写对应的镜像 ID 号docker tag 镜像id centos7_mysql:5.7.31

3.2 创建 MySQL 1 主 2 从容器

导出完毕后，关闭 centos 容器，然后使用 centos7_mysql:5.7.31 镜像创建 3 个容器。

# 创建容器 mysql-masterdocker run -dit  --privileged  --name mysql-master -p 33061:3306 -p 2201:22 centos7_mysql:5.7.31 /usr/sbin/init# 创建容器 mysql-slave-1docker run -dit  --privileged  --name  mysql-slave-1 -p 33062:3306 -p 2202:22 centos7_mysql:5.7.31 /usr/sbin/init# 创建容器 mysql-slave-2docker run -dit  --privileged  --name mysql-slave-2 -p 33063:3306 -p 2203:22 centos7_mysql:5.7.31 /usr/sbin/init

创建好这 3 个 mysql 容器后，就可以使用 ssh 工具进入容器了，注意区分端口号，用户名密码用安装 SSH 时设置的。

注意：使用 SSH 连接时，ip 地址为本机：127.0.0.1,并非虚拟机的虚拟 ip(172.17.0.*),端口为启动容器时候的代理端口

如:mysql-master -p 33061:3306 -p 2201:22 33061 代理的是 3306 端口，2201 代理的是 22 端口

mysql-master ssh 连接示意图

Navicat 连接 mysql-master 服务器的 MySQL 数据库示意图

3.3 创建 mysql-mha 容器

# 创建 mysql-mha 容器docker run -dit --privileged --name mysql-mha -p 2204:22 centos:7.9.2009 /usr/sbin/init# 进入容器docker exec -it mysql-mha /bin/bash## 安装 SSH yum -y install openssh-server# 修改 root 密码echo 'root:root'|chpasswd# 修改系统语言编码echo "export LC_ALL=en_US.UTF-8"  >>  /etc/profilesource /etc/profile# 修改系统时间ln -sf /usr/share/zoneinfo/Asia/Shanghai /etc/localtime# 重启 sshd systemctl enable sshdsystemctl restart sshd

安装完 SSH 就可以用 ssh 工具进入容器了，端口号为 2204。

使用 SSH 连接上 4 个容器后，安装 MHA。

如果不知道 Docker 各个容器的 ip，可以使用以下命令查看

docker inspect --format='{{.Name}} - {{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' $(docker ps -aq)

效果图：

3.4 安装 MHA

安装前，我们再看一下 MHA 的结构图，如下：

把 mha4mysql-node-0.58-0.el7.centos.noarch.rpm 文件传入这 4 个容器中，把 mha4mysql-manager-0.58-0.el7.centos.noarch.rpm 传入 mysql-mha 容器中

这两个文件下载地址：

链接: https://pan.baidu.com/s/1LE7lyanlk5ZV4VK_fSo9hg
密码: ge4o

传输工具可以使用： FileZilla 等这类工具，连接方式同 SSH

FileZilla 连接示意图

注意: mha4mysql-node-0.58-0.el7.centos.noarch.rpm、mha4mysql-manager-0.58-0.el7.centos.noarch.rpm 这两个包的版本的文件只支持 CentOS7

首先在 MySQL 主从 这 3 个容器上安装 mha4mysql-node 包以及需要的依赖

## 安装 epel 源yum install -y wgetwget -O /etc/yum.repos.d/epel-7.repo http://mirrors.aliyun.com/repo/epel-7.repoyum clean all && yum makecache# 安装 perl 依赖yum install -y perl-DBD-MySQL## 安装 node 注意文件位置rpm -ivh mha4mysql-node-0.58-0.el7.centos.noarch.rpm

在 mysql-mha 上安装 mha4mysql-node 和 mha4mysql-manager 包

## 安装 epel 源，适用于 CentOS7yum install -y wgetwget -O /etc/yum.repos.d/epel-7.repo http://mirrors.aliyun.com/repo/epel-7.repoyum clean all && yum makecache# 安装 perl 依赖yum install -y perl-DBD-MySQLyum install -y perl-Config-Tinyyum install -y perl-Log-Dispatchyum install -y perl-Parallel-ForkManager## 安装 noderpm -ivh mha4mysql-node-0.58-0.el7.centos.noarch.rpm## 安装 managerrpm -ivh mha4mysql-manager-0.58-0.el7.centos.noarch.rpm

04. MySQL 集群半同步复制

4.1 修改配置文件

修改 mysql-master 的 mysqld.cnf：

# 修改 master mysqld.cnfvi /etc/my.cnf# master idserver_id=1# 开启二进制日志log-bin=mysql-bin# 忽略系统库的数据同步binlog-ignore-db=information_schema binlog-ignore-db=mysql binlog-ignore-db=performance_schema binlog-ignore-db=sys

修改 mysql-slave-1 的 mysqld.cnf：

# 修改 mysql-slave-1 mysqld.cnfvi /etc/my.cnf# slave idserver-id=2# 中继日志relay_log=mysql-relay-bin# 只读关闭read_only=0# master 备用机开启log-bin=mysql-bin# 忽略的库，要和主库保持一致！！！！！！binlog-ignore-db=information_schema binlog-ignore-db=mysql binlog-ignore-db=performance_schema binlog-ignore-db=sys

修改 mysql-slave-2 的 mysqld.cnf：

# 修改 mysql-slave-2 mysqld.cnfvi /etc/my.cnf# slave idserver-id=3# 中继日志relay_log=mysql-relay-bin# 只读read_only=1# 忽略的库，要和主库保持一致！！！！！！binlog-ignore-db=information_schema binlog-ignore-db=mysql binlog-ignore-db=performance_schema binlog-ignore-db=sys

配置完毕，启动 3 台 MySQL：

# 启动 mysqld，卡住使用 ctrl+c 返回systemctl start mysqld

执行 systemctl start mysqld 如果一直卡住， Ctrl+C退出就行，只要 mysql 命令行工具可以正常连接基本上没什么影响

4.2 开启半同步复制

• mysql-master 开启半同步复制：

# 查看默认密码cat /var/log/mysqld.log | grep password# 初始密码登录mysql -uroot -p# 修改root密码，请确认密码规则ALTER USER 'root'@'localhost' IDENTIFIED BY 'root';# master开启授权grant replication slave on *.* to 'root'@'%' identified by 'root';grant all privileges on *.* to 'root'@'%' identified by 'root';# 安装 半同步复制 master 插件install plugin rpl_semi_sync_master soname 'semisync_master.so';# 开启 半同步复制 插件set global rpl_semi_sync_master_enabled=1;# 修改同步时间 1000 msset global rpl_semi_sync_master_timeout=1000;# 刷新flush privileges;# 查看 master 状态，若为空请重启 MySQLshow master status;

• 2 个 mysql-slave 开启半同步复制：

# 查看默认密码cat /var/log/mysqld.log | grep password# 初始密码登录mysql -uroot -p# 修改root密码，请确认密码规则ALTER USER 'root'@'localhost' IDENTIFIED BY 'root';# 开启远程登录grant all privileges on *.* to 'root'@'%' identified by 'root';# slave 设置 masterchange master to master_host='172.17.0.2',master_port=3306,master_user='root',master_password='root',master_log_file='mysql-bin.000001',master_log_pos=869;# 安装 半同步复制 slave 插件install plugin rpl_semi_sync_slave soname 'semisync_slave.so';# 开启 半同步复制 插件set global rpl_semi_sync_slave_enabled=1;# 刷新flush privileges;# 开启 slavestart slave;# 查看 slave 状态show slave status \G

05. 开启 MHA

5.1 配置 SSH 登录无密码验证

在 4 个容器 间配置 SSH 登录无密码验证

## 配置 SSH 登录无密码验证yum -y install openssh-clients# 配置 ssh key，默认即可，会在 /root/.ssh/ 生成 id_rsa 和 id_rsa.pub 文件ssh-keygen -t rsa

在容器 mysql-master（172.17.0.2） 中执行：

# 配置 SSH 登录无密码验证ssh-copy-id -i /root/.ssh/id_rsa.pub root@172.17.0.3ssh-copy-id -i /root/.ssh/id_rsa.pub root@172.17.0.4

执行 ssh-copy-id -i /root/.ssh/id_rsa.pub root@172.17.0.3 时的示意图如下，其余的几个方式一样

在容器 mysql-slave-1（172.17.0.3） 中执行：

ssh-copy-id -i /root/.ssh/id_rsa.pub root@172.17.0.2ssh-copy-id -i /root/.ssh/id_rsa.pub root@172.17.0.4

在容器 mysql-slave-2（172.17.0.4） 中执行：

ssh-copy-id -i /root/.ssh/id_rsa.pub root@172.17.0.2ssh-copy-id -i /root/.ssh/id_rsa.pub root@172.17.0.3

在容器 mysql-mha（172.17.0.5） 中执行：

ssh-copy-id -i /root/.ssh/id_rsa.pub root@172.17.0.2ssh-copy-id -i /root/.ssh/id_rsa.pub root@172.17.0.3ssh-copy-id -i /root/.ssh/id_rsa.pub root@172.17.0.4

5.2 配置 manager

在 mysql-mha(172.17.0.5) 中创建 mha 配置文件，先提前把该文件及目录创建出来

cd /etcmkdir masterhacd masterhatouch mha.cnf

然后再编辑 mha.cnf 的内容

# 创建 mha 配置文件vi /etc/masterha/mha.cnf

mha.cnf 文件内容：

[server default]# mysql user and passworduser=rootpassword=rootssh_user=root# working directory on the managermanager_workdir=/var/log/masterha/mha# working directory on MySQL serversremote_workdir=/var/log/masterha/mha# log filemanager_log=/var/log/masterha/MHA.log# mysql-master[server1]hostname=172.17.0.2# mysql-slave-1[server2]hostname=172.17.0.3# 作为备用主节点candidate_master=1# mysql-slave-2[server3]hostname=172.17.0.4

5.3 检查 manager

配置完成后，首先来检查容器间的 SSH：

masterha_check_ssh --conf=/etc/masterha/mha.cnf

检查没有问题后，再来检查 MySQL 的主从复制：

masterha_check_repl --conf=/etc/masterha/mha.cnf

5.4 启动 manager

检查完成没有问题后，启动 manage 查看，没有错误 Ctrl + C 退出即可，再使用后台启动的方式

masterha_manager --conf=/etc/masterha/mha.cnf

后台启动：

# 后台启动nohup masterha_manager --conf=/etc/masterha/mha.cnf < /dev/null > /var/log/masterha/mha/mha.log 2>&1 &

后台启动可查看 manager 状态

masterha_check_status --conf=/etc/masterha/mha.cnf# 输出mha (pid:17594) is running(0:PING_OK), master:172.17.0.2

示意图：

注意：当完成一次正常的故障转移后，manager 进程将会终止。

手动停止 manager-暂时不需要手动

masterha_stop --conf=/etc/masterha/mha.cnf

5.5 测试

去 **mysql-master（172.17.0.2）**上手动停止 mysql-master 服务

systemctl stop mysqld

然后去 mysql-mha（172.17.0.5） 查看 mysql-mha 输出：

tail -400f MHA.log

切换成功示意图

服务器列表（虚拟机、Docker 均可，ip 以实际为准）

给 Master、Slave1、Slave2 三台 DB 数据库服务器安装 MySQL，可以先将 MySQL 安装包上传至服务器（这里就不演示了）

[root@localhost ~]# lsanaconda-ks.cfg  mysql-5.7.28-1.el7.x86_64.rpm-bundle.tar[root@localhost ~]# tar -xvf mysql-5.7.28-1.el7.x86_64.rpm-bundle.tar mysql-community-embedded-5.7.28-1.el7.x86_64.rpmmysql-community-libs-compat-5.7.28-1.el7.x86_64.rpmmysql-community-devel-5.7.28-1.el7.x86_64.rpmmysql-community-embedded-compat-5.7.28-1.el7.x86_64.rpmmysql-community-libs-5.7.28-1.el7.x86_64.rpmmysql-community-test-5.7.28-1.el7.x86_64.rpmmysql-community-common-5.7.28-1.el7.x86_64.rpmmysql-community-embedded-devel-5.7.28-1.el7.x86_64.rpmmysql-community-client-5.7.28-1.el7.x86_64.rpmmysql-community-server-5.7.28-1.el7.x86_64.rpm

查看服务器中是否有自带的 mariadb，如果有，要移除，否则会冲突

[root@localhost ~]# rpm -qa|grep mariadbmariadb-libs-5.5.41-2.el7_0.x86_64[root@localhost ~]# rpm -e mariadb-libs-5.5.41-2.el7_0.x86_64 --nodeps## 再次查看[root@localhost ~]# rpm -qa|grep mariadb

正式安装 MySQL，注意安装顺序

1. 先来 mysql-community-common

[root@localhost ~]# rpm -ivh mysql-community-common-5.7.28-1.el7.x86_64.rpm warning: mysql-community-common-5.7.28-1.el7.x86_64.rpm: Header V3 DSA/SHA1 Signature, key ID 5072e1f5: NOKEYPreparing...                          ################################# [100%]Updating / installing...   1:mysql-community-common-5.7.28-1.e################################# [100%]

2. 再来 mysql-community-libs

[root@localhost ~]# rpm -ivh mysql-community-libs-5.7.28-1.el7.x86_64.rpm warning: mysql-community-libs-5.7.28-1.el7.x86_64.rpm: Header V3 DSA/SHA1 Signature, key ID 5072e1f5: NOKEYPreparing...                          ################################# [100%]Updating / installing...   1:mysql-community-libs-5.7.28-1.el7################################# [100%]

3. 再是 mysql-community-libs-compat

[root@localhost ~]# rpm -ivh mysql-community-libs-compat-5.7.28-1.el7.x86_64.rpm warning: mysql-community-libs-compat-5.7.28-1.el7.x86_64.rpm: Header V3 DSA/SHA1 Signature, key ID 5072e1f5: NOKEYPreparing...                          ################################# [100%]Updating / installing...   1:mysql-community-libs-compat-5.7.2################################# [100%]

4. 再接着 mysql-community-client

[root@localhost ~]# rpm -ivh mysql-community-client-5.7.28-1.el7.x86_64.rpm warning: mysql-community-client-5.7.28-1.el7.x86_64.rpm: Header V3 DSA/SHA1 Signature, key ID 5072e1f5: NOKEYPreparing...                          ################################# [100%]Updating / installing...   1:mysql-community-client-5.7.28-1.e################################# [100%]

5. 再接着 mysql-community-server

[root@localhost ~]# rpm -ivh mysql-community-server-5.7.28-1.el7.x86_64.rpm warning: mysql-community-server-5.7.28-1.el7.x86_64.rpm: Header V3 DSA/SHA1 Signature, key ID 5072e1f5: NOKEYPreparing...                          ################################# [100%]Updating / installing...   1:mysql-community-server-5.7.28-1.e################################# [100%]

6. 再接着 mysql-community-devel

[root@localhost ~]# rpm -ivh mysql-community-devel-5.7.28-1.el7.x86_64.rpm warning: mysql-community-devel-5.7.28-1.el7.x86_64.rpm: Header V3 DSA/SHA1 Signature, key ID 5072e1f5: NOKEYPreparing...                          ################################# [100%]Updating / installing...   1:mysql-community-devel-5.7.28-1.el################################# [100%]

初始化数据库

[root@localhost ~]# mysqld --initialize --user=mysql

查看初始化后 MySQL 的账户名和密码

[root@localhost ~]# cat /var/log/mysqld.log 2020-11-22T16:56:05.518869Z 0 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use --explicit_defaults_for_timestamp server option (see documentation for more details).2020-11-22T16:56:06.260995Z 0 [Warning] InnoDB: New log files created, LSN=457902020-11-22T16:56:06.368797Z 0 [Warning] InnoDB: Creating foreign key constraint system tables.2020-11-22T16:56:06.431422Z 0 [Warning] No existing UUID has been found, so we assume that this is the first time that this server has been started. Generating a new UUID: 9cc56a78-2ce3-11eb-9cb5-000c29150471.2020-11-22T16:56:06.496706Z 0 [Warning] Gtid table is not ready to be used. Table 'mysql.gtid_executed' cannot be opened.2020-11-22T16:56:07.122745Z 0 [Warning] CA certificate ca.pem is self signed.2020-11-22T16:56:07.302638Z 1 [Note] A temporary password is generated for root@localhost: ceZbIi5+OGbd

最后的 root@localhost: ceZbIi5+OGbd，eZbIi5+OGbd 这个就是用户名和密码

启动 MySQL

[root@localhost ~]# systemctl start mysqld.service

查看启动状态

[root@localhost ~]# systemctl status mysqld.servicemysqld.service - MySQL Server   Loaded: loaded (/usr/lib/systemd/system/mysqld.service; enabled)   Active: active (running) since Sun 2020-11-22 08:59:05 PST; 21s ago     Docs: man:mysqld(8)           http://dev.mysql.com/doc/refman/en/using-systemd.html  Process: 12003 ExecStart=/usr/sbin/mysqld --daemonize --pid-file=/var/run/mysqld/mysqld.pid $MYSQLD_OPTS (code=exited, status=0/SUCCESS)  Process: 11981 ExecStartPre=/usr/bin/mysqld_pre_systemd (code=exited, status=0/SUCCESS) Main PID: 12006 (mysqld)   CGroup: /system.slice/mysqld.service           └─12006 /usr/sbin/mysqld --daemonize --pid-file=/var/run/mysqld/mysqld.pid

登录 MySQL 命令行客户端，并修改密码

[root@localhost ~]# mysql -uroot -pEnter password: Welcome to the MySQL monitor.  Commands end with ; or \g.Your MySQL connection id is 2Server version: 5.7.28Copyright (c) 2000, 2019, Oracle and/or its affiliates. All rights reserved.Oracle is a registered trademark of Oracle Corporation and/or itsaffiliates. Other names may be trademarks of their respectiveowners.Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.mysql> set password=password('root');Query OK, 0 rows affected, 1 warning (0.00 sec)

exit 命令退出，重新登录

最好也关闭一下防火墙，免得有其他杂七杂八的问题

[root@localhost ~]# systemctl stop iptables[root@localhost ~]# systemctl stop firewalld[root@localhost ~]# systemctl disable firewalld.service

主从配置

主库的配置

编辑 my.cnf 文件

vi /etc/my.cnf

按字母 i 进入编辑模式，在文件中添加一下配置：

# 开启 binlog，后面配置从库的时候要保持一致log_bin=mysql-bin# 设置服务 id，每台服务器的 server 保持唯一，不可重复server-id=1# 每次 binlog 操作都进行磁盘同步sync-binlog=1# 忽略的库,后面配置从库的时候要保持一致binlog-ignore-db=performance_schemabinlog-ignore-db=information_schemabinlog-ignore-db=sysbinlog-ignore-db=mysql

server-id这里主设置为 1，从依次往后排，2、3…

编辑完成后，按 Esc 退出编辑模式，再输入 :wq 进行保存退出

紧接着在终端中重启 mysql 服务

systemctl restart mysqld

连接主客户端，进行操作授权

mysql -uroot -pEnter password: 这里输入密码，我的是：rootmysql> grant replication slave on *.* to 'root'@'%' identified by 'root';mysql> grant all privileges on *.* to 'root'@'%' identified by 'root';mysql> flush privileges;

查看主库状态：

mysql> show master status;

注意下图中标红的地方，配置从库会用到

从库 1 的配置

同理，编辑 my.cnf 文件，并重启

# 设置服务 id，每台服务器的 server 保持唯一，不可重复server-id=2relay_log=mysql-relay-bin# 只读read_only=1# 忽略的库,后面配置从库的时候要保持一致binlog-ignore-db=performance_schemabinlog-ignore-db=information_schemabinlog-ignore-db=sysbinlog-ignore-db=mysql

再登录查询从库状态

mysql> show slave status;

再配置从哪个主库同步

mysql> change master to master_host='172.17.0.2',master_port=3306,master_user='root',master_password='root',master_log_file='mysql-bin.000001',master_log_pos=869;

这里 master_log_file 和 master_log_pos 对应下面查询主库状态图中的红线

然后开启从库配置

mysql> start slave;

然后就可以查询从库的状态

mysql> show slave staus;

从库 2 的配置

同理从库 2 同从库 1 配置一样，注意 server-id 改成 3

切回主库创建表语句

在主库每执行一条语句，就去两个从库查询一下，是否同步到从库

# 创建库create database suremotoo_master;# 创建完数据库，可以去从库查询一下，从库也会有该数据库# 商品表CREATE TABLE products(    pid INT PRIMARY KEY,    pname VARCHAR(50),    price DOUBLE,    flag VARCHAR(2)   #是否上架标记为：1表示上架、0表示下架) engine=innodb charset=utf8;# 创建完表，可以去从库查询一下，从库也会有该表# 再尝试插入一条数据INSERT INTO products(pid,pname,price,flag) VALUES('1','联想',5000.00,'1');

这里就不一一展示了，看个效果图

半同步复制

先登录主库的命令行客户端

mysql -uroot -pEnter password: root## 查看是否支持动态加载插件mysql> select @@have_dynamic_loading;

YES 说明支持

接下来安装半同步工具插件

mysql> install plugin rpl_semi_sync_master soname 'semisync_master.so';

安装完成后查看插件信息

mysql> show variables like '%semi%';

rpl_semi_sync_master_enabled 的值为 OFF， 说明现在处于关闭状态

rpl_semi_sync_master_timeout是延迟时间（单位毫秒），当前是 10 秒

我们调整一下这两个参数

mysql> set global rpl_semi_sync_master_enabled=1;mysql> set global rpl_semi_sync_master_timeout=1000;

最后还可以再进行查看：

mysql> show variables like '%semi%';

然后登陆从库，进行安装插件配置！

同样登陆命令行客户端（此处登陆就略过了…）

mysql> install plugin rpl_semi_sync_slave soname 'semisync_slave.so';

也可以查看下同步配置信息：

mysql> show variables like '%semi%';

从库的配置信息比较少，我们就调整将其打开就行

mysql> set global rpl_semi_sync_slave_enabled=1;# 打开后再查看mysql> show variables like '%semi%';

最后，我们将从库重新进行加载

mysql> stop slave;mysql> start slave;

回到主库，再进行插入数据测试，看看从库是否同步~ 😁😁，这里就不演示了

Minicat 的目标

我们可以通过浏览器客户端发送 http 请求， Minicat 可以接收到请求进⾏处理，处理之后的结果可以返回浏览器客户端。

基本方向

• 提供服务，接收请求（Socket 通信）

• 请求信息封装成 Request 对象，同样响应信息封装成 Response 对象

• 客户端请求资源，资源分为静态资源（HTML）和动态资源（Servlet）

• 资源返回给客户端浏览器

迭代实现

我们实现时候呢，一步一步来，可以制定的小版本计划

• V1.0 需求：浏览器请求 http://localhost:8080, 返回⼀个固定的字符串到⻚⾯"Hello Minicat."
• V2.0 需求：封装 Request 和 Response 对象，返回 HTML 静态资源⽂件
• V3.0 需求：可以请求动态资源（Servlet）
• V4.0 需求：可以多线程访问
• V5.0 需求：在已有 Minicat 基础上进⼀步扩展，模拟出 webapps 部署效果,磁盘上放置⼀个 webapps ⽬录，webapps 中可以有多个项⽬，⽐如 demo1,demo2,demo3… 具体的项⽬⽐如 demo1 中有 serlvet（也即为：servlet 是属于具体某⼀个项⽬的 servlet），这样的话在 Minicat 初始化配置加载，以及根据请求 url 查找对应 serlvet 时都需要进⼀步处理。

V1.0 版本

环境搭建

确定好方向，就进行项目搭建开发

新建一个 Maven 项目，并调整在 pom.xml

  <groupId>site.suremotoo</groupId>  <artifactId>Minicat</artifactId>  <version>1.0-SNAPSHOT</version>  <build>      <plugins>          <plugin>              <groupId>org.apache.maven.plugins</groupId>              <artifactId>maven-compiler-plugin</artifactId>              <version>3.1</version>              <configuration>                  <source>11</source>                  <target>11</target>                  <encoding>utf-8</encoding>              </configuration>          </plugin>      </plugins>  </build>

编写启动类 Bootstrap

public class Bootstrap {  /**   * 设定启动和监听端口   */  private int port = 8080;  /**   * 启动函数   *   * @throws IOException   */  public void start() throws IOException {      System.out.println("Minicat starting...");      String responseData = "Hello Minicat.";      ServerSocket socket = new ServerSocket(port);      while (true) {          Socket accept = socket.accept();          OutputStream outputStream = accept.getOutputStream();          String responseText = HttpProtocolUtil.getHttpHeader200(responseData.length()) + responseData;          outputStream.write(responseText.getBytes());          accept.close();      }  }  /**   * 启动入口   *   * @param args   */  public static void main(String[] args) throws IOException {      Bootstrap bootstrap = new Bootstrap();      bootstrap.start();  }}

HTTP 协议辅助类 HttpProtocolUtil

public class HttpProtocolUtil {    /**     * 200 状态码，头信息     *     * @param contentLength 响应信息长度     * @return 200 header info     */    public static String getHttpHeader200(long contentLength) {        return "HTTP/1.1 200 OK \n" + "Content-Type: text/html \n"                + "Content-Length: " + contentLength + " \n" + "\r\n";    }    /**     * 为响应码 404 提供请求头信息(此处也包含了数据内容)     *     * @return 404 header info     */    public static String getHttpHeader404() {        String str404 = "<h1>404 not found</h1>";        return "HTTP/1.1 404 NOT Found \n" + "Content-Type: text/html \n"                + "Content-Length: " + str404.getBytes().length + " \n" + "\r\n" + str404;    }}

然后我们访问浏览器：http://localhost:8080，页面显示 Hello Minicat.,就说明成功啦。

这就完成 V1.0 版本了 🎉

V2.0 版本

紧接着我们实现请求信息、响应信息的封装，即：Request、Response 的实现

public class Request {  /**   * 请求方式, eg: GET、POST   */  private String method;  /**   * 请求路径,eg: /index.html   */  private String url;  /**   * 请求信息输入流 <br>   * 示例   * <pre>   *  GET / HTTP/1.1   *  Host: www.baidu.com   *  Connection: keep-alive   *  Pragma: no-cache   *  Cache-Control: no-cache   *  Upgrade-Insecure-Requests: 1   *  User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/85.0.4183.83 Safari/537.36   * </pre>   */  private InputStream inputStream;  public Request() {  }  public Request(InputStream inputStream) throws IOException {      this.inputStream = inputStream;      int count = 0;      while (count == 0) {          count = inputStream.available();      }      byte[] bytes = new byte[count];      inputStream.read(bytes);      // requestString 参考：this.inputStream 示例      String requestString = new String(bytes);      // 按换行分隔      String[] requestStringArray = requestString.split("\\n");      // 读取第一行数据,即： GET / HTTP/1.1      String firstLine = requestStringArray[0];      // 把厉第一行数据按空格分隔      String[] firstLineArray = firstLine.split(" ");      this.method = firstLineArray[0];      this.url = firstLineArray[1];  }}

Response

public class Response {    /**     * 响应信息     */    private OutputStream outputStream;    public Response() {    }    public Response(OutputStream outputStream) {        this.outputStream = outputStream;    }    public void output(String content) throws IOException {        outputStream.write(content.getBytes());    }    /**     * 根据 url 拼接绝对路径，根据绝对路径再读取文件资源，再响应     *     * @param url 请求 url     */    public void outputHtml(String url) throws IOException {        // 获取 url 资源的全路径        String absoluteResourcePath = StaticResourceUtil.getAbsolutePath(url);        File file = new File(absoluteResourcePath);        if (file.exists() && file.isFile()) {            // 输出静态资源            StaticResourceUtil.outputStaticResource(new FileInputStream(file), outputStream);        } else {            output(HttpProtocolUtil.getHttpHeader404());        }    }}

我们也提取了一些共用类和函数，StaticResourceUtil

public class StaticResourceUtil {    /**     * 根据请求 url 获取完整绝对路径     *     * @param url 请求 url     * @return 完整绝对路径     */    public static String getAbsolutePath(String url) {        String path = StaticResourceUtil.class.getResource("/").getPath();        return path.replaceAll("\\\\", "/") + url;    }    /**     * 输出静态资源信息     *     * @param inputStream  静态资源文件的读取流     * @param outputStream 响应的输出流     * @throws IOException     */    public static void outputStaticResource(InputStream inputStream, OutputStream outputStream) throws IOException {        int count = 0;        while (count == 0) {            count = inputStream.available();        }        // 输出 http 请求头,然后再输出具体内容        int resourceSize = count;        // 读取内容输出        outputStream.write(HttpProtocolUtil.getHttpHeader200(resourceSize).getBytes());        // 已经读取的内容⻓度        long written = 0;        // 计划每次缓冲的⻓度        int byteSize = 1024;        byte[] bytes = new byte[byteSize];        while (written < resourceSize) {            // 说明剩余未读取⼤⼩不⾜⼀个 1024 ⻓度，那就按真实⻓度处理            if (written + byteSize > resourceSize) {                // 计算实际剩余内容                byteSize = (int) (resourceSize - written);                bytes = new byte[byteSize];            }            inputStream.read(bytes);            outputStream.write(bytes);            outputStream.flush();            // 计算已经读取的长度            written += byteSize;        }    }}

最后调整一下Bootstrap中的start()函数

public void start() throws IOException {    System.out.println("Minicat starting...");    ServerSocket socket = new ServerSocket(port);    while (true) {        Socket accept = socket.accept();        OutputStream outputStream = accept.getOutputStream();        // 分别封装 Request 和 Response        Request request = new Request(accept.getInputStream());        Response response = new Response(outputStream);        // 根据 request 中的 url，输出        response.outputHtml(request.getUrl());        accept.close();    }}

哦对了，还缺少 1 个具体的 HTML 静态资源⽂件，我们创建一个名为 index.html 的吧

<!DOCTYPE html><html lang="en"><head>    <meta charset="UTF-8">    <title>Hello Minicat</title></head><body>    <h1>Hello Minicat,  index.html</h1></body></html>

然后我们访问浏览器：http://localhost:8080/index.html，页面显示 Hello Minicat, index.html,就说明成功啦。

这就完成 V2.0 版本了 🎉🎉

V3.0 版本

接下来就来实现请求动态资源

我们先定义 Servlet 的接口，指定规范

public interface Servlet {    void init() throws Exception;    void destroy() throws Exception;    void service(Request request, Response response) throws Exception;}

紧接着再完成 1 个公共的抽象父类 HttpServlet

public abstract class HttpServlet implements Servlet {    public abstract void doGet(Request request, Response response) throws Exception;    public abstract void doPost(Request request, Response response) throws Exception;    @Override    public void service(Request request, Response response) throws Exception {        String method = request.getMethod();        if ("GET".equalsIgnoreCase(method)) {            doGet(request, response);        } else {            doPost(request, response);        }    }}

实际的 doGet、doPost 由实际配置的业务 Servlet 来实现，那么我们就创建 1 个实际业务： ShowServlet

public class ShowServlet extends HttpServlet {    @Override    public void doGet(Request request, Response response) throws Exception {        String repText = "<h1>ShowServlet by GET</h1>";        response.output(HttpProtocolUtil.getHttpHeader200(repText.length()) + repText);    }    @Override    public void doPost(Request request, Response response) throws Exception {        String repText = "<h1>ShowServlet by POST</h1>";        response.output(HttpProtocolUtil.getHttpHeader200(repText.length()) + repText);    }    @Override    public void init() throws Exception {}    @Override    public void destroy() throws Exception {}}

我们再在项目 resources 文件夹中创建 web.xml，并配置我们的业务 Servlet: ShowServlet 的名称和访问路径

<?xml version="1.0" encoding="utf-8"?><web-app>    <servlet>        <servlet-name>show</servlet-name>        <servlet-class>server.ShowServlet</servlet-class>    </servlet>    <servlet-mapping>        <servlet-name>show</servlet-name>        <url-pattern>/show</url-pattern>    </servlet-mapping></web-app>

既然配置了 web.xml，那我们还需要再对其进行解析和处理

解析 XML，我们在 pom.xml 里引入相关坐标依赖

<dependencies>    <dependency>        <groupId>dom4j</groupId>        <artifactId>dom4j</artifactId>        <version>1.6.1</version>    </dependency>    <dependency>        <groupId>jaxen</groupId>        <artifactId>jaxen</artifactId>        <version>1.1.6</version>    </dependency></dependencies>

我们把处理逻辑写在 Bootstrap 启动类中

/** * 存放 Servlet信息，url: Servlet 实例 */private Map<String, HttpServlet> servletMap = new HashMap<>();/** * 加载配置的 Servlet * * @throws Exception */public void loadServlet() throws Exception {    InputStream resourceAsStream = this.getClass().getClassLoader().getResourceAsStream("web.xml");    SAXReader saxReader = new SAXReader();    Document document = saxReader.read(resourceAsStream);    Element rootElement = document.getRootElement();    List<Element> list = rootElement.selectNodes("//servlet");    for (Element element : list) {        // <servlet-name>show</servlet-name>        Element servletnameElement = (Element) element.selectSingleNode("servlet-name");        String servletName = servletnameElement.getStringValue();        // <servlet-class>server.ShowServlet</servlet-class>        Element servletclassElement = (Element) element.selectSingleNode("servlet-class");        String servletClass = servletclassElement.getStringValue();        // 根据 servlet-name 的值找到 url-pattern        Element servletMapping = (Element) rootElement.selectSingleNode("/web-app/servlet-mapping[servlet-name='" + servletName + "']");        // /show        String urlPattern = servletMapping.selectSingleNode("url-pattern").getStringValue();        servletMap.put(urlPattern, (HttpServlet) Class.forName(servletClass).getDeclaredConstructor().newInstance());    }}

再调整 start 方法，在方法里执行 loadServlet 函数来初始化 Servlet

public void start() throws Exception {      System.out.println("Minicat starting...");// 此处加载并初始化 Servlet  loadServlet();      ServerSocket socket = new ServerSocket(port);      while (true) {          Socket accept = socket.accept();          OutputStream outputStream = accept.getOutputStream();          // 分别封装 Request 和 Response          Request request = new Request(accept.getInputStream());          Response response = new Response(outputStream);        // 根据 url 来获取 Servlet          HttpServlet httpServlet = servletMap.get(request.getUrl());        // 如果 Servlet 为空，说明是静态资源，不为空即为动态资源，需要执行 Servlet 里的方法          if (httpServlet == null) {              response.outputHtml(request.getUrl());          } else {              httpServlet.service(request, response);          }          accept.close();      }  }

然后我们访问浏览器: http://localhost:8080/index.html，页面显示 Hello Minicat, index.html,就说明静态资源访问成功啦。

我们再访问: http://localhost:8080/show, 页面显示 ShowServlet by GET,就说明动态资源也访问成功啦。

这就完成 V3.0 版本了 🎉🎉🎉

V4.0 版本

完成 V3.0 之后，3.0 还是有点问题的，比如在多线程访问情况下

我们假设业务 ShowServlet 里，动态资源处理延迟，这里使用 Thread.sleep 模拟延迟的情况

@Overridepublic void doGet(Request request, Response response) throws Exception {    // 模拟延迟    Thread.sleep(100000);    String repText = "<h1>ShowServlet by GET</h1>";    response.output(HttpProtocolUtil.getHttpHeader200(repText.length()) + repText);}

然后再重新启动，先访问:http://localhost:8080/show，会发现一直在加载处理，此时再去访问 http://localhost:8080/index.html，也会一直在加载处理。

意思就是我们访问动态资源时候的一直等待，此时，再去访问静态资源的时候，也会一直等待，这样就不行了。

这里就可以使用线程来解决，每个请求过来的 Socket 都分配 1 个线程，各自处理各自的请求

所以再在 Bootstrap 中的 start 方法做个改造

public void start() throws Exception {    System.out.println("Minicat starting...");    loadServlet();    ServerSocket socket = new ServerSocket(port);    while (true) {        Socket accept = socket.accept();        // 多线程改造，每个 socket 是个单独的线程        RequestProcessor requestProcessor = new RequestProcessor(accept, servletMap);        requestProcessor.start();    }}

RequestProcessor 就集成 Thread ，重写 run 函数，实现具体的输入输出的处理

public class RequestProcessor extends Thread {    private Socket socket;    private Map<String, HttpServlet> servletMap;    public RequestProcessor() {    }    public RequestProcessor(Socket socket, Map<String, HttpServlet> servletMap) {        this.socket = socket;        this.servletMap = servletMap;    }    @Override    public void run() {        try {            OutputStream outputStream = socket.getOutputStream();            // 分别封装 Request 和 Response            Request request = new Request(socket.getInputStream());            Response response = new Response(outputStream);            HttpServlet httpServlet = servletMap.get(request.getUrl());            if (httpServlet == null) {                response.outputHtml(request.getUrl());            } else {                httpServlet.service(request, response);            }            socket.close();        } catch (Exception e) {            e.printStackTrace();        }    }}

每个都分配个线程，有点消耗资源，所以我们再升级下，使用线程池，所以再对 start 函数进行一次简单的调整

public void start() throws Exception {    System.out.println("Minicat starting...");    loadServlet();    // 定义一个线程池    int corePoolSize = 10;    int maximumPoolSize =50;    long keepAliveTime = 100L;    TimeUnit unit = TimeUnit.SECONDS;    BlockingQueue<Runnable> workQueue = new ArrayBlockingQueue<>(50);    ThreadFactory threadFactory = Executors.defaultThreadFactory();    RejectedExecutionHandler handler = new ThreadPoolExecutor.AbortPolicy();    ThreadPoolExecutor threadPoolExecutor = new ThreadPoolExecutor(            corePoolSize,            maximumPoolSize,            keepAliveTime,            unit,            workQueue,            threadFactory,            handler    );    ServerSocket socket = new ServerSocket(port);    while (true) {        Socket accept = socket.accept();        // 多线程改造，每个 socket 是个单独的线程        RequestProcessor requestProcessor = new RequestProcessor(accept, servletMap);         // 线程池执行        threadPoolExecutor.execute(requestProcessor);    }}

这就完成 V4.0 版本了 🎉🎉🎉🎉

V5.0 版本

开始之前，我们先捋一下之前实现 Minicat 的步骤，来看个图

5.0 版本来了，我们要模拟出 webapps 部署效果，这个功能说简单点了，就是把一个指定的文件夹 webapps 下面的所有的 Servlet 给读取出来并加载，然后在请求的时候去解析对应的 servlet 就行了。

那么我们就 resources 里写个配置文件：server.xml 来配置指定的文件夹路径信息，为了模仿实际的 Tomcat，我们再加几个标签

<Server>    <Service name="Mojave">        <Connector port="8080"/>        <Engine defaultHost="localhost">          <!-- appBase 就是指定的文件夹 -->            <Host name="localhost" appBase="/Users/suremotoo/Documents/webapps"/>        </Engine>    </Service></Server>

而业务 Servlet 呢，肯定要在单独的项目中写了，Minicat 是要部署加载它们的，后面再说。

根据面向对象的思想，我们在编写一些 POJO 类

Context 就是在指定的 webapps 目录中的，每个项目，每个项目里有自己的 Servlet 集合

public class Context {    public Context() {    }    public Context(Map<String, HttpServlet> servletMap) {        this.servletMap = servletMap;    }  // Context 中的 Servlet    private Map<String, HttpServlet> servletMap;    public Map<String, HttpServlet> getServletMap() {        return servletMap;    }    public void setServletMap(Map<String, HttpServlet> servletMap) {        this.servletMap = servletMap;    }}

Host 作为配置中的主机信息，每个主机下面有自己的 Context 项目集合

public class Host {    public Host() {    }    public Host(Map<String, Context> contextMap) {        this.contextMap = contextMap;    }  // hHst 中的 Context    private Map<String, Context> contextMap;    public Map<String, Context> getContextMap() {        return contextMap;    }    public void setContextMap(Map<String, Context> contextMap) {        this.contextMap = contextMap;    }}

Mapper 其实指的是 Service,每个 Service 下面有自己的 Host 主机集合

public class Mapper {  // Service 中的 Host    private Map<String, Host> hostMap;    public Mapper(Map<String, Host> hostMap) {        this.hostMap = hostMap;    }    public Map<String, Host> getHostMap() {        return hostMap;    }    public void setHostMap(Map<String, Host> hostMap) {        this.hostMap = hostMap;    }}

Server 指 Minicat 服务实例, 1 个 Minicat 就 1 个 Server,每个 Server 下面有自己的 Mapper 集合

public class Server {  // Server 里的 Service    private Map<String, Mapper> serviceMap;    public Server() {    }    public Server(Map<String, Mapper> serviceMap) {        this.serviceMap = serviceMap;    }    public Map<String, Mapper> getServiceMap() {        return serviceMap;    }    public void setServiceMap(Map<String, Mapper> serviceMap) {        this.serviceMap = serviceMap;    }}

POJO 类完成后，就开始改造程序入口 Bootstrap 了，要加载指定目录下的文件，所以我们要改造 loadServlet

/** * 加载实际项目里配置的 Servlet * * @throws Exception */@SuppressWarnings({"unchecked"})public Context loadContextServlet(String path) throws Exception {    String webPath = path + "/web.xml";    if (!(new File(webPath).exists())) {        System.out.println("not found " + webPath);        return null;    }    InputStream resourceAsStream = new FileInputStream(webPath);    SAXReader saxReader = new SAXReader();    Document document = saxReader.read(resourceAsStream);    Element rootElement = document.getRootElement();    List<Element> list = rootElement.selectNodes("//servlet");    Map<String, HttpServlet> servletMap = new HashMap<>(16);    for (Element element : list) {        // <servlet-name>show</servlet-name>        Element servletnameElement = (Element) element.selectSingleNode("servlet-name");        String servletName = servletnameElement.getStringValue();        // <servlet-class>server.ShowServlet</servlet-class>        Element servletclassElement = (Element) element.selectSingleNode("servlet-class");        String servletClass = servletclassElement.getStringValue();        // 根据 servlet-name 的值找到 url-pattern        Element servletMapping = (Element) rootElement.selectSingleNode("/web-app/servlet-mapping[servlet-name='" + servletName + "']");        // /show        String urlPattern = servletMapping.selectSingleNode("url-pattern").getStringValue();        // 自定义类加载器，来加载 webapps 目录下的 class        WebClassLoader webClassLoader = new WebClassLoader();        Class<?> aClass = webClassLoader.findClass(path, servletClass);        servletMap.put(urlPattern, (HttpServlet) aClass.getDeclaredConstructor().newInstance());    }    return new Context(servletMap);}/** * 加载 server.xml，解析并初始化 webapps 下面的各个项目的 servlet */@SuppressWarnings({"unchecked"})public void loadServlet() {    InputStream resourceAsStream = this.getClass().getClassLoader().getResourceAsStream("server.xml");    SAXReader saxReader = new SAXReader();    try {        Document document = saxReader.read(resourceAsStream);        Element rootElement = document.getRootElement();        // 解析 server 标签        Element serverElement = (Element) rootElement.selectSingleNode("//Server");        // 解析 server 下的 Service 标签        List<Element> serviceNodes = serverElement.selectNodes("//Service");        // 存储各个 Host        Map<String, Host> hostMap = new HashMap<>(8);        //遍历 service        for (Element service : serviceNodes) {            String serviceName = service.attributeValue("name");            Element engineNode = (Element) service.selectSingleNode("//Engine");            List<Element> hostNodes = engineNode.selectNodes("//Host");            // 存储有多少个项目            Map<String, Context> contextMap = new HashMap<>(8);            for (Element hostNo : hostNodes) {                String hostName = hostNo.attributeValue("name");                String appBase = hostNo.attributeValue("appBase");                File file = new File(appBase);                if (!file.exists() || file.list() == null) {                    break;                }                String[] list = file.list();                //遍历子文件夹，即：实际的项目列表                for (String path : list) {                    //将项目封装成 context，并保存入map                    contextMap.put(path, loadContextServlet(appBase + "/" + path));                }                // hsot:port                // eg: localhost:8080                hostMap.put(hostName + ":" + port, new Host(contextMap));            }            serviceMap.put(serviceName, new Mapper(hostMap));        }    } catch (Exception e) {        e.printStackTrace();    }}

代码有点长，稍微说明下理解起来还是比较简单的：

先解析 server.xml ，然后根据配置的指定文件夹目录去解析，目录下面的每个文件夹就是一个 Context；

而 Context 里的 servlet 信息，都会配置在 Context 自己的 web.xml 中；

所以再解析每个 Context 里自己的 web.xml，封装所有的 Servlet

当然了，Context、Host、Mapper、Server 也都会一并封装

封装所有的 Servlet 的时候，需要自己去写个类加载器去实例化，所以加了个自定义的类加载器

public class WebClassLoader extends ClassLoader {    @Override    protected Class<?> findClass(String basePath, String className) {        byte[] classBytes = getClassBytes(basePath, className);        return defineClass(className, classBytes, 0, classBytes.length);    }    /**     * 读取类的字节码     *     * @param basePath  根路径     * @param className 类的全限定名     * @return servlet 的字节码信息     * @throws IOException     */    private byte[] getClassBytes(String basePath, String className) {        InputStream in = null;        ByteArrayOutputStream out = null;        String path = basePath + File.separatorChar +                className.replace('.', File.separatorChar) + ".class";        try {            in = new FileInputStream(path);            out = new ByteArrayOutputStream();            byte[] buffer = new byte[2048];            int len = 0;            while ((len = in.read(buffer)) != -1) {                out.write(buffer, 0, len);            }            return out.toByteArray();        } catch (Exception e) {            e.printStackTrace();        } finally {            try {                in.close();                out.close();            } catch (IOException e) {                e.printStackTrace();            }        }        return null;    }}

基础的工作都做好了，就差解析了，我们要改造 RequestProcessor

public class RequestProcessor extends Thread {    private Socket socket;    private Server server;    public RequestProcessor() {    }    public RequestProcessor(Socket socket, Server server) {        this.socket = socket;        this.server = server;    }    @Override    public void run() {        try {            OutputStream outputStream = socket.getOutputStream();            // 分别封装 Request 和 Response            Request request = new Request(socket.getInputStream());            Response response = new Response(outputStream);            HttpServlet httpServlet = findHttpServlet(request);            if (httpServlet == null) {                response.outputHtml(request.getUrl());            } else {                httpServlet.service(request, response);            }            socket.close();        } catch (Exception e) {            e.printStackTrace();        }    }    /**     * 根据请求信息找到对应业务 Servlet     * <pre>     *  GET web-greet/greet HTTP/1.1     *  Host: suremotoo.com     * </pre>     *     * @param request     * @return 具体要执行的 servlet     */    private HttpServlet findHttpServlet(Request request) {        HttpServlet businessServlet = null;        Map<String, Mapper> serviceMap = server.getServiceMap();        for (String key : serviceMap.keySet()) {            String hostName = request.getHost();            Map<String, Host> hostMap = serviceMap.get(key).getHostMap();            Host host = hostMap.get(hostName);            if (host != null) {                Map<String, Context> contextMap = host.getContextMap();                // 处理 url                // eg: web-greet/greet                String url = request.getUrl();                String[] urlPattern = url.split("/");                String contextName = urlPattern[1];                String servletStr = "/";                if (urlPattern.length > 2) {                    servletStr += urlPattern[2];                }                // 获取上下文                Context context = contextMap.get(contextName);                if (context != null) {                    Map<String, HttpServlet> servletMap = context.getServletMap();                    businessServlet = servletMap.get(servletStr);                }            }        }        return businessServlet;    }}

核心就是 findHttpServlet 方法，从 Server、Mapper、Host、Context 依次取出，直到最后的 Servlet 配置集合，

根据 url 找到对应的 Servlet 执行

至于我们的测试项目，用于部署到 webapps 目录嘛，我这里就简单说一下就行

先把 Minicat 打个 jar 包，给测试项目用！

参考 Minicat 的目录，可以建立 maven 项目，编写自定义的业务 Servlet ，然后在 resources 文件夹中，建立 web.xml 文件，用于配置自定义的 Servlet

📣📣 注意啦：而自定义的 Servlet 一定要 extends Minicat 中的 HttpServet！！

至此就 V5.0 就大功告成 🎉🎉🎉🎉🎉

各版本实现回顾

附-精美 PDF 版本

😘😘 精美 PDF 版本 👈

本文采用的源码版本是 4.3.11.RELEASE，算是 5.0.x 前比较新的版本了。为了降低难度，本文所说的所有的内容都是基于 xml 的配置的方式，实际使用已经很少人这么做了，至少不是纯 xml 配置，不过从理解源码的角度来看用这种方式来说无疑是最合适的。

阅读建议：读者至少需要知道怎么配置 Spring，了解 Spring 中的各种概念，少部分内容我还假设读者使用过 SpringMVC。本文要说的 IoC 总体来说有两处地方最重要，一个是创建 Bean 容器，一个是初始化 Bean，如果读者觉得一次性看完本文压力有点大，那么可以按这个思路分两次消化。读者不一定对 Spring 容器的源码感兴趣，也许附录部分介绍的知识对读者有些许作用。

希望通过本文可以让读者不惧怕阅读 Spring 源码，也希望大家能反馈表述错误或不合理的地方。

引言

先看下最基本的启动 Spring 容器的例子：

public static void main(String[] args) {    ApplicationContext context = new ClassPathXmlApplicationContext("classpath:applicationfile.xml");}

以上代码就可以利用配置文件来启动一个 Spring 容器了，请使用 maven 的小伙伴直接在 dependencies 中加上以下依赖即可，个人比较反对那些不知道要添加什么依赖，然后把 Spring 的所有相关的东西都加进来的方式。

<dependency>  <groupId>org.springframework</groupId>  <artifactId>spring-context</artifactId>  <version>4.3.11.RELEASE</version></dependency>

spring-context 会自动将 spring-core、spring-beans、spring-aop、spring-expression 这几个基础 jar 包带进来。

多说一句，很多开发者入门就直接接触的 SpringMVC，对 Spring 其实不是很了解，Spring 是渐进式的工具，并不具有很强的侵入性，它的模块也划分得很合理，即使你的应用不是 web 应用，或者之前完全没有使用到 Spring，而你就想用 Spring 的依赖注入这个功能，其实完全是可以的，它的引入不会对其他的组件产生冲突。

废话说完，我们继续。ApplicationContext context = new ClassPathXmlApplicationContext(...) 其实很好理解，从名字上就可以猜出一二，就是在 ClassPath 中寻找 xml 配置文件，根据 xml 文件内容来构建 ApplicationContext。当然，除了 ClassPathXmlApplicationContext 以外，我们也还有其他构建 ApplicationContext 的方案可供选择，我们先来看看大体的继承结构是怎么样的：

读者可以大致看一下类名，源码分析的时候不至于找不着看哪个类，因为 Spring 为了适应各种使用场景，提供的各个接口都可能有很多的实现类。对于我们来说，就是揪着一个完整的分支看完。

当然，读本文的时候读者也不必太担心，每个代码块分析的时候，我都会告诉读者我们在说哪个类第几行。

我们可以看到，ClassPathXmlApplicationContext 兜兜转转了好久才到 ApplicationContext 接口，同样的，我们也可以使用绿颜色的 FileSystemXmlApplicationContext 和 AnnotationConfigApplicationContext 这两个类。

1、FileSystemXmlApplicationContext 的构造函数需要一个 xml 配置文件在系统中的路径，其他和 ClassPathXmlApplicationContext 基本上一样。

2、AnnotationConfigApplicationContext 是基于注解来使用的，它不需要配置文件，采用 java 配置类和各种注解来配置，是比较简单的方式，也是大势所趋吧。

不过本文旨在帮助大家理解整个构建流程，所以决定使用 ClassPathXmlApplicationContext 进行分析。

我们先来一个简单的例子来看看怎么实例化 ApplicationContext。

首先，定义一个接口：

public interface MessageService {    String getMessage();}

定义接口实现类：

public class MessageServiceImpl implements MessageService {    public String getMessage() {        return "hello world";    }}

接下来，我们在 resources 目录新建一个配置文件，文件名随意，通常叫 application.xml 或 application-xxx.xml 就可以了：

<?xml version="1.0" encoding="UTF-8" ?><beans xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"       xmlns="http://www.springframework.org/schema/beans"       xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd" default-autowire="byName">    <bean id="messageService" class="com.javadoop.example.MessageServiceImpl"/></beans>

这样，我们就可以跑起来了：

public class App {    public static void main(String[] args) {        // 用我们的配置文件来启动一个 ApplicationContext        ApplicationContext context = new ClassPathXmlApplicationContext("classpath:application.xml");              System.out.println("context 启动成功");              // 从 context 中取出我们的 Bean，而不是用 new MessageServiceImpl() 这种方式        MessageService messageService = context.getBean(MessageService.class);        // 这句将输出: hello world        System.out.println(messageService.getMessage());    }}

以上例子很简单，不过也够引出本文的主题了，就是怎么样通过配置文件来启动 Spring 的 ApplicationContext ？也就是我们今天要分析的 IOC 的核心了。ApplicationContext 启动过程中，会负责创建实例 Bean，往各个 Bean 中注入依赖等。

BeanFactory 简介

BeanFactory，从名字上也很好理解，生产 bean 的工厂，它负责生产和管理各个 bean 实例。

初学者可别以为我之前说那么多和 BeanFactory 无关，前面说的 ApplicationContext 其实就是一个 BeanFactory。我们来看下和 BeanFactory 接口相关的主要的继承结构：

我想，大家看完这个图以后，可能就不是很开心了。ApplicationContext 往下的继承结构前面一张图说过了，这里就不重复了。这张图呢，背下来肯定是不需要的，有几个重点和大家说明下就好。

1. ApplicationContext 继承了 ListableBeanFactory，这个 Listable 的意思就是，通过这个接口，我们可以获取多个 Bean，大家看源码会发现，最顶层 BeanFactory 接口的方法都是获取单个 Bean 的。
2. ApplicationContext 继承了 HierarchicalBeanFactory，Hierarchical 单词本身已经能说明问题了，也就是说我们可以在应用中起多个 BeanFactory，然后可以将各个 BeanFactory 设置为父子关系。
3. AutowireCapableBeanFactory 这个名字中的 Autowire 大家都非常熟悉，它就是用来自动装配 Bean 用的，但是仔细看上图，ApplicationContext 并没有继承它，不过不用担心，不使用继承，不代表不可以使用组合，如果你看到 ApplicationContext 接口定义中的最后一个方法 getAutowireCapableBeanFactory() 就知道了。
4. ConfigurableListableBeanFactory 也是一个特殊的接口，看图，特殊之处在于它继承了第二层所有的三个接口，而 ApplicationContext 没有。这点之后会用到。
5. 请先不用花时间在其他的接口和类上，先理解我说的这几点就可以了。

然后，请读者打开编辑器，翻一下 BeanFactory、ListableBeanFactory、HierarchicalBeanFactory、AutowireCapableBeanFactory、ApplicationContext 这几个接口的代码，大概看一下各个接口中的方法，大家心里要有底，限于篇幅，我就不贴代码介绍了。

启动过程分析

下面将会是冗长的代码分析，记住，一定要自己打开源码来看，不然纯看是很累的。

第一步，我们肯定要从 ClassPathXmlApplicationContext 的构造方法说起。

public class ClassPathXmlApplicationContext extends AbstractXmlApplicationContext {  private Resource[] configResources;    // 如果已经有 ApplicationContext 并需要配置成父子关系，那么调用这个构造方法  public ClassPathXmlApplicationContext(ApplicationContext parent) {    super(parent);  }  ...  public ClassPathXmlApplicationContext(String[] configLocations, boolean refresh, ApplicationContext parent)      throws BeansException {    super(parent);    // 根据提供的路径，处理成配置文件数组(以分号、逗号、空格、tab、换行符分割)    setConfigLocations(configLocations);    if (refresh) {      refresh(); // 核心方法    }  }    ...}

接下来，就是 refresh()，这里简单说下为什么是 refresh()，而不是 init() 这种名字的方法。因为 ApplicationContext 建立起来以后，其实我们是可以通过调用 refresh() 这个方法重建的，refresh() 会将原来的 ApplicationContext 销毁，然后再重新执行一次初始化操作。

往下看，refresh() 方法里面调用了那么多方法，就知道肯定不简单了，请读者先看个大概，细节之后会详细说。

@Overridepublic void refresh() throws BeansException, IllegalStateException {   // 来个锁，不然 refresh() 还没结束，你又来个启动或销毁容器的操作，那不就乱套了嘛   synchronized (this.startupShutdownMonitor) {      // 准备工作，记录下容器的启动时间、标记“已启动”状态、处理配置文件中的占位符      prepareRefresh();           // 这步比较关键，这步完成后，配置文件就会解析成一个个 Bean 定义，注册到 BeanFactory 中，      // 当然，这里说的 Bean 还没有初始化，只是配置信息都提取出来了，      // 注册也只是将这些信息都保存到了注册中心(说到底核心是一个 beanName-> beanDefinition 的 map)      ConfigurableListableBeanFactory beanFactory = obtainFreshBeanFactory();      // 设置 BeanFactory 的类加载器，添加几个 BeanPostProcessor，手动注册几个特殊的 bean      // 这块待会会展开说      prepareBeanFactory(beanFactory);      try {         // 【这里需要知道 BeanFactoryPostProcessor 这个知识点，Bean 如果实现了此接口，         // 那么在容器初始化以后，Spring 会负责调用里面的 postProcessBeanFactory 方法。】                 // 这里是提供给子类的扩展点，到这里的时候，所有的 Bean 都加载、注册完成了，但是都还没有初始化         // 具体的子类可以在这步的时候添加一些特殊的 BeanFactoryPostProcessor 的实现类或做点什么事         postProcessBeanFactory(beanFactory);         // 调用 BeanFactoryPostProcessor 各个实现类的 postProcessBeanFactory(factory) 方法         invokeBeanFactoryPostProcessors(beanFactory);         // 注册 BeanPostProcessor 的实现类，注意看和 BeanFactoryPostProcessor 的区别         // 此接口两个方法: postProcessBeforeInitialization 和 postProcessAfterInitialization         // 两个方法分别在 Bean 初始化之前和初始化之后得到执行。注意，到这里 Bean 还没初始化         registerBeanPostProcessors(beanFactory);         // 初始化当前 ApplicationContext 的 MessageSource，国际化这里就不展开说了，不然没完没了了         initMessageSource();         // 初始化当前 ApplicationContext 的事件广播器，这里也不展开了         initApplicationEventMulticaster();         // 从方法名就可以知道，典型的模板方法(钩子方法)，         // 具体的子类可以在这里初始化一些特殊的 Bean（在初始化 singleton beans 之前）         onRefresh();         // 注册事件监听器，监听器需要实现 ApplicationListener 接口。这也不是我们的重点，过         registerListeners();         // 重点，重点，重点         // 初始化所有的 singleton beans         //（lazy-init 的除外）         finishBeanFactoryInitialization(beanFactory);         // 最后，广播事件，ApplicationContext 初始化完成         finishRefresh();      }      catch (BeansException ex) {         if (logger.isWarnEnabled()) {            logger.warn("Exception encountered during context initialization - " +                  "cancelling refresh attempt: " + ex);         }         // Destroy already created singletons to avoid dangling resources.         // 销毁已经初始化的 singleton 的 Beans，以免有些 bean 会一直占用资源         destroyBeans();         // Reset 'active' flag.         cancelRefresh(ex);         // 把异常往外抛         throw ex;      }      finally {         // Reset common introspection caches in Spring's core, since we         // might not ever need metadata for singleton beans anymore...         resetCommonCaches();      }   }}

下面，我们开始一步步来肢解这个 refresh() 方法。

创建 Bean 容器前的准备工作

这个比较简单，直接看代码中的几个注释即可。

protected void prepareRefresh() {   // 记录启动时间，   // 将 active 属性设置为 true，closed 属性设置为 false，它们都是 AtomicBoolean 类型   this.startupDate = System.currentTimeMillis();   this.closed.set(false);   this.active.set(true);   if (logger.isInfoEnabled()) {      logger.info("Refreshing " + this);   }   // Initialize any placeholder property sources in the context environment   initPropertySources();   // 校验 xml 配置文件   getEnvironment().validateRequiredProperties();   this.earlyApplicationEvents = new LinkedHashSet<ApplicationEvent>();}

创建 Bean 容器，加载并注册 Bean

我们回到 refresh() 方法中的下一行 obtainFreshBeanFactory()。

注意，这个方法是全文最重要的部分之一，这里将会初始化 BeanFactory、加载 Bean、注册 Bean 等等。

当然，这步结束后，Bean 并没有完成初始化。这里指的是 Bean 实例并未在这一步生成。

// AbstractApplicationContext.java

protected ConfigurableListableBeanFactory obtainFreshBeanFactory() {   // 关闭旧的 BeanFactory (如果有)，创建新的 BeanFactory，加载 Bean 定义、注册 Bean 等等   refreshBeanFactory();     // 返回刚刚创建的 BeanFactory   ConfigurableListableBeanFactory beanFactory = getBeanFactory();   if (logger.isDebugEnabled()) {      logger.debug("Bean factory for " + getDisplayName() + ": " + beanFactory);   }   return beanFactory;}

// AbstractRefreshableApplicationContext.java 120

@Overrideprotected final void refreshBeanFactory() throws BeansException {   // 如果 ApplicationContext 中已经加载过 BeanFactory 了，销毁所有 Bean，关闭 BeanFactory   // 注意，应用中 BeanFactory 本来就是可以多个的，这里可不是说应用全局是否有 BeanFactory，而是当前   // ApplicationContext 是否有 BeanFactory   if (hasBeanFactory()) {      destroyBeans();      closeBeanFactory();   }   try {      // 初始化一个 DefaultListableBeanFactory，为什么用这个，我们马上说。      DefaultListableBeanFactory beanFactory = createBeanFactory();      // 用于 BeanFactory 的序列化，我想不部分人应该都用不到      beanFactory.setSerializationId(getId());           // 下面这两个方法很重要，别跟丢了，具体细节之后说      // 设置 BeanFactory 的两个配置属性：是否允许 Bean 覆盖、是否允许循环引用      customizeBeanFactory(beanFactory);           // 加载 Bean 到 BeanFactory 中      loadBeanDefinitions(beanFactory);      synchronized (this.beanFactoryMonitor) {         this.beanFactory = beanFactory;      }   }   catch (IOException ex) {      throw new ApplicationContextException("I/O error parsing bean definition source for " + getDisplayName(), ex);   }}

看到这里的时候，我觉得读者就应该站在高处看 ApplicationContext 了，ApplicationContext 继承自 BeanFactory，但是它不应该被理解为 BeanFactory 的实现类，而是说其内部持有一个实例化的 BeanFactory（DefaultListableBeanFactory）。以后所有的 BeanFactory 相关的操作其实是委托给这个实例来处理的。

我们说说为什么选择实例化 DefaultListableBeanFactory ？前面我们说了有个很重要的接口 ConfigurableListableBeanFactory，它实现了 BeanFactory 下面一层的所有三个接口，我把之前的继承图再拿过来大家再仔细看一下：

我们可以看到 ConfigurableListableBeanFactory 只有一个实现类 DefaultListableBeanFactory，而且实现类 DefaultListableBeanFactory 还通过实现右边的 AbstractAutowireCapableBeanFactory 通吃了右路。所以结论就是，最底下这个家伙 DefaultListableBeanFactory 基本上是最牛的 BeanFactory 了，这也是为什么这边会使用这个类来实例化的原因。

如果你想要在程序运行的时候动态往 Spring IOC 容器注册新的 bean，就会使用到这个类。那我们怎么在运行时获得这个实例呢？

之前我们说过 ApplicationContext 接口能获取到 AutowireCapableBeanFactory，就是最右上角那个，然后它向下转型就能得到 DefaultListableBeanFactory 了。

那怎么拿到 ApplicationContext 实例呢？如果你不会，说明你没用过 Spring。

在继续往下之前，我们需要先了解 BeanDefinition。我们说 BeanFactory 是 Bean 容器，那么 Bean 又是什么呢？

这里的 BeanDefinition 就是我们所说的 Spring 的 Bean，我们自己定义的各个 Bean 其实会转换成一个个 BeanDefinition 存在于 Spring 的 BeanFactory 中。

所以，如果有人问你 Bean 是什么的时候，你要知道 Bean 在代码层面上可以简单认为是 BeanDefinition 的实例。

BeanDefinition 中保存了我们的 Bean 信息，比如这个 Bean 指向的是哪个类、是否是单例的、是否懒加载、这个 Bean 依赖了哪些 Bean 等等。

BeanDefinition 接口定义

我们来看下 BeanDefinition 的接口定义：

public interface BeanDefinition extends AttributeAccessor, BeanMetadataElement {   // 我们可以看到，默认只提供 sington 和 prototype 两种，   // 很多读者可能知道还有 request, session, globalSession, application, websocket 这几种，   // 不过，它们属于基于 web 的扩展。   String SCOPE_SINGLETON = ConfigurableBeanFactory.SCOPE_SINGLETON;   String SCOPE_PROTOTYPE = ConfigurableBeanFactory.SCOPE_PROTOTYPE;   // 比较不重要，直接跳过吧   int ROLE_APPLICATION = 0;   int ROLE_SUPPORT = 1;   int ROLE_INFRASTRUCTURE = 2;   // 设置父 Bean，这里涉及到 bean 继承，不是 java 继承。请参见附录的详细介绍   // 一句话就是：继承父 Bean 的配置信息而已   void setParentName(String parentName);     // 获取父 Bean   String getParentName();     // 设置 Bean 的类名称，将来是要通过反射来生成实例的   void setBeanClassName(String beanClassName);      // 获取 Bean 的类名称   String getBeanClassName();    // 设置 bean 的 scope   void setScope(String scope);   String getScope();   // 设置是否懒加载   void setLazyInit(boolean lazyInit);      boolean isLazyInit();   // 设置该 Bean 依赖的所有的 Bean，注意，这里的依赖不是指属性依赖(如 @Autowire 标记的)，   // 是 depends-on="" 属性设置的值。   void setDependsOn(String... dependsOn);   // 返回该 Bean 的所有依赖   String[] getDependsOn();   // 设置该 Bean 是否可以注入到其他 Bean 中，只对根据类型注入有效，   // 如果根据名称注入，即使这边设置了 false，也是可以的   void setAutowireCandidate(boolean autowireCandidate);   // 该 Bean 是否可以注入到其他 Bean 中   boolean isAutowireCandidate();   // 主要的。同一接口的多个实现，如果不指定名字的话，Spring 会优先选择设置 primary 为 true 的 bean   void setPrimary(boolean primary);   // 是否是 primary 的   boolean isPrimary();   // 如果该 Bean 采用工厂方法生成，指定工厂名称。对工厂不熟悉的读者，请参加附录   // 一句话就是：有些实例不是用反射生成的，而是用工厂模式生成的   void setFactoryBeanName(String factoryBeanName);   // 获取工厂名称   String getFactoryBeanName();   // 指定工厂类中的 工厂方法名称   void setFactoryMethodName(String factoryMethodName);   // 获取工厂类中的 工厂方法名称   String getFactoryMethodName();   // 构造器参数   ConstructorArgumentValues getConstructorArgumentValues();   // Bean 中的属性值，后面给 bean 注入属性值的时候会说到   MutablePropertyValues getPropertyValues();   // 是否 singleton   boolean isSingleton();   // 是否 prototype   boolean isPrototype();   // 如果这个 Bean 是被设置为 abstract，那么不能实例化，   // 常用于作为 父bean 用于继承，其实也很少用......   boolean isAbstract();   int getRole();   String getDescription();   String getResourceDescription();   BeanDefinition getOriginatingBeanDefinition();}

这个 BeanDefinition 其实已经包含很多的信息了，暂时不清楚所有的方法对应什么东西没关系，希望看完本文后读者可以彻底搞清楚里面的所有东西。

这里接口虽然那么多，但是没有类似 getInstance() 这种方法来获取我们定义的类的实例，真正的我们定义的类生成的实例到哪里去了呢？别着急，这个要很后面才能讲到。

有了 BeanDefinition 的概念以后，我们再往下看 refreshBeanFactory() 方法中的剩余部分：

customizeBeanFactory(beanFactory);loadBeanDefinitions(beanFactory);

虽然只有两个方法，但路还很长啊。。。

customizeBeanFactory

customizeBeanFactory(beanFactory) 比较简单，就是配置是否允许 BeanDefinition 覆盖、是否允许循环引用。

protected void customizeBeanFactory(DefaultListableBeanFactory beanFactory) {   if (this.allowBeanDefinitionOverriding != null) {      // 是否允许 Bean 定义覆盖      beanFactory.setAllowBeanDefinitionOverriding(this.allowBeanDefinitionOverriding);   }   if (this.allowCircularReferences != null) {      // 是否允许 Bean 间的循环依赖      beanFactory.setAllowCircularReferences(this.allowCircularReferences);   }}

BeanDefinition 的覆盖问题可能会有开发者碰到这个坑，就是在配置文件中定义 bean 时使用了相同的 id 或 name，默认情况下，allowBeanDefinitionOverriding 属性为 null，如果在同一配置文件中重复了，会抛错，但是如果不是同一配置文件中，会发生覆盖。

循环引用也很好理解：A 依赖 B，而 B 依赖 A。或 A 依赖 B，B 依赖 C，而 C 依赖 A。

默认情况下，Spring 允许循环依赖，当然如果你在 A 的构造方法中依赖 B，在 B 的构造方法中依赖 A 是不行的。

至于这两个属性怎么配置？我在附录中进行了介绍，尤其对于覆盖问题，很多人都希望禁止出现 Bean 覆盖，可是 Spring 默认是不同文件的时候可以覆盖的。

之后的源码中还会出现这两个属性，读者有个印象就可以了，它们不是非常重要。

加载 Bean: loadBeanDefinitions

接下来是最重要的 loadBeanDefinitions(beanFactory) 方法了，这个方法将根据配置，加载各个 Bean，然后放到 BeanFactory 中。

读取配置的操作在 XmlBeanDefinitionReader 中，其负责加载配置、解析。

// AbstractXmlApplicationContext.java 80

/** 我们可以看到，此方法将通过一个 XmlBeanDefinitionReader 实例来加载各个 Bean。*/@Overrideprotected void loadBeanDefinitions(DefaultListableBeanFactory beanFactory) throws BeansException, IOException {   // 给这个 BeanFactory 实例化一个 XmlBeanDefinitionReader   XmlBeanDefinitionReader beanDefinitionReader = new XmlBeanDefinitionReader(beanFactory);   // Configure the bean definition reader with this context's   // resource loading environment.   beanDefinitionReader.setEnvironment(this.getEnvironment());   beanDefinitionReader.setResourceLoader(this);   beanDefinitionReader.setEntityResolver(new ResourceEntityResolver(this));   // 初始化 BeanDefinitionReader，其实这个是提供给子类覆写的，   // 我看了一下，没有类覆写这个方法，我们姑且当做不重要吧   initBeanDefinitionReader(beanDefinitionReader);   // 重点来了，继续往下   loadBeanDefinitions(beanDefinitionReader);}

现在还在这个类中，接下来用刚刚初始化的 Reader 开始来加载 xml 配置，这块代码读者可以选择性跳过，不是很重要。也就是说，下面这个代码块，读者可以很轻松地略过。

// AbstractXmlApplicationContext.java 120

protected void loadBeanDefinitions(XmlBeanDefinitionReader reader) throws BeansException, IOException {   Resource[] configResources = getConfigResources();   if (configResources != null) {      // 往下看      reader.loadBeanDefinitions(configResources);   }   String[] configLocations = getConfigLocations();   if (configLocations != null) {      // 2      reader.loadBeanDefinitions(configLocations);   }}// 上面虽然有两个分支，不过第二个分支很快通过解析路径转换为 Resource 以后也会进到这里@Overridepublic int loadBeanDefinitions(Resource... resources) throws BeanDefinitionStoreException {   Assert.notNull(resources, "Resource array must not be null");   int counter = 0;   // 注意这里是个 for 循环，也就是每个文件是一个 resource   for (Resource resource : resources) {      // 继续往下看      counter += loadBeanDefinitions(resource);   }   // 最后返回 counter，表示总共加载了多少的 BeanDefinition   return counter;}// XmlBeanDefinitionReader 303@Overridepublic int loadBeanDefinitions(Resource resource) throws BeanDefinitionStoreException {   return loadBeanDefinitions(new EncodedResource(resource));}// XmlBeanDefinitionReader 314public int loadBeanDefinitions(EncodedResource encodedResource) throws BeanDefinitionStoreException {   Assert.notNull(encodedResource, "EncodedResource must not be null");   if (logger.isInfoEnabled()) {      logger.info("Loading XML bean definitions from " + encodedResource.getResource());   }   // 用一个 ThreadLocal 来存放配置文件资源   Set<EncodedResource> currentResources = this.resourcesCurrentlyBeingLoaded.get();   if (currentResources == null) {      currentResources = new HashSet<EncodedResource>(4);      this.resourcesCurrentlyBeingLoaded.set(currentResources);   }   if (!currentResources.add(encodedResource)) {      throw new BeanDefinitionStoreException(            "Detected cyclic loading of " + encodedResource + " - check your import definitions!");   }   try {      InputStream inputStream = encodedResource.getResource().getInputStream();      try {         InputSource inputSource = new InputSource(inputStream);         if (encodedResource.getEncoding() != null) {            inputSource.setEncoding(encodedResource.getEncoding());         }         // 核心部分是这里，往下面看         return doLoadBeanDefinitions(inputSource, encodedResource.getResource());      }      finally {         inputStream.close();      }   }   catch (IOException ex) {      throw new BeanDefinitionStoreException(            "IOException parsing XML document from " + encodedResource.getResource(), ex);   }   finally {      currentResources.remove(encodedResource);      if (currentResources.isEmpty()) {         this.resourcesCurrentlyBeingLoaded.remove();      }   }}// 还在这个文件中，第 388 行protected int doLoadBeanDefinitions(InputSource inputSource, Resource resource)      throws BeanDefinitionStoreException {   try {      // 这里就不看了，将 xml 文件转换为 Document 对象      Document doc = doLoadDocument(inputSource, resource);      // 继续      return registerBeanDefinitions(doc, resource);   }   catch (...}// 还在这个文件中，第 505 行// 返回值：返回从当前配置文件加载了多少数量的 Beanpublic int registerBeanDefinitions(Document doc, Resource resource) throws BeanDefinitionStoreException {   BeanDefinitionDocumentReader documentReader = createBeanDefinitionDocumentReader();   int countBefore = getRegistry().getBeanDefinitionCount();   // 这里   documentReader.registerBeanDefinitions(doc, createReaderContext(resource));   return getRegistry().getBeanDefinitionCount() - countBefore;}// DefaultBeanDefinitionDocumentReader 90@Overridepublic void registerBeanDefinitions(Document doc, XmlReaderContext readerContext) {   this.readerContext = readerContext;   logger.debug("Loading bean definitions");   Element root = doc.getDocumentElement();   // 从 xml 根节点开始解析文件   doRegisterBeanDefinitions(root);}         

经过漫长的链路，一个配置文件终于转换为一颗 DOM 树了，注意，这里指的是其中一个配置文件，不是所有的，读者可以看到上面有个 for 循环的。下面开始从根节点开始解析：

doRegisterBeanDefinitions：

// DefaultBeanDefinitionDocumentReader 116protected void doRegisterBeanDefinitions(Element root) {   // 我们看名字就知道，BeanDefinitionParserDelegate 必定是一个重要的类，它负责解析 Bean 定义，   // 这里为什么要定义一个 parent? 看到后面就知道了，是递归问题，   // 因为 <beans /> 内部是可以定义 <beans /> 的，所以这个方法的 root 其实不一定就是 xml 的根节点，也可以是嵌套在里面的 <beans /> 节点，从源码分析的角度，我们当做根节点就好了   BeanDefinitionParserDelegate parent = this.delegate;   this.delegate = createDelegate(getReaderContext(), root, parent);   if (this.delegate.isDefaultNamespace(root)) {      // 这块说的是根节点 <beans ... profile="dev" /> 中的 profile 是否是当前环境需要的，      // 如果当前环境配置的 profile 不包含此 profile，那就直接 return 了，不对此 <beans /> 解析      // 不熟悉 profile 为何物，不熟悉怎么配置 profile 读者的请移步附录区      String profileSpec = root.getAttribute(PROFILE_ATTRIBUTE);      if (StringUtils.hasText(profileSpec)) {         String[] specifiedProfiles = StringUtils.tokenizeToStringArray(               profileSpec, BeanDefinitionParserDelegate.MULTI_VALUE_ATTRIBUTE_DELIMITERS);         if (!getReaderContext().getEnvironment().acceptsProfiles(specifiedProfiles)) {            if (logger.isInfoEnabled()) {               logger.info("Skipped XML bean definition file due to specified profiles [" + profileSpec +                     "] not matching: " + getReaderContext().getResource());            }            return;         }      }   }   preProcessXml(root); // 钩子   // 往下看   parseBeanDefinitions(root, this.delegate);   postProcessXml(root); // 钩子   this.delegate = parent;}

preProcessXml(root) 和 postProcessXml(root) 是给子类用的钩子方法，鉴于没有被使用到，也不是我们的重点，我们直接跳过。

这里涉及到了 profile 的问题，对于不了解的读者，我在附录中对 profile 做了简单的解释，读者可以参考一下。

接下来，看核心解析方法 parseBeanDefinitions(root, this.delegate) :

// default namespace 涉及到的就四个标签 <import />、<alias />、<bean /> 和 <beans />，// 其他的属于 custom 的protected void parseBeanDefinitions(Element root, BeanDefinitionParserDelegate delegate) {   if (delegate.isDefaultNamespace(root)) {      NodeList nl = root.getChildNodes();      for (int i = 0; i < nl.getLength(); i++) {         Node node = nl.item(i);         if (node instanceof Element) {            Element ele = (Element) node;            if (delegate.isDefaultNamespace(ele)) {               // 解析 default namespace 下面的几个元素               parseDefaultElement(ele, delegate);            }            else {               // 解析其他 namespace 的元素               delegate.parseCustomElement(ele);            }         }      }   }   else {      delegate.parseCustomElement(root);   }}

从上面的代码，我们可以看到，对于每个配置来说，分别进入到 parseDefaultElement(ele, delegate); 和 delegate.parseCustomElement(ele); 这两个分支了。

parseDefaultElement(ele, delegate) 代表解析的节点是 <import />、<alias />、<bean />、<beans /> 这几个。

这里的四个标签之所以是 default 的，是因为它们是处于这个 namespace 下定义的：

http://www.springframework.org/schema/beans

又到初学者科普时间，不熟悉 namespace 的读者请看下面贴出来的 xml，这里的第二行 xmlns 就是咯。

<beans xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"       xmlns="http://www.springframework.org/schema/beans"       xsi:schemaLocation="            http://www.springframework.org/schema/beans          http://www.springframework.org/schema/beans/spring-beans.xsd"       default-autowire="byName">

而对于其他的标签，将进入到 delegate.parseCustomElement(element) 这个分支。如我们经常会使用到的 <mvc />、<task />、<context />、<aop />等。

这些属于扩展，如果需要使用上面这些 ”非 default“ 标签，那么上面的 xml 头部的地方也要引入相应的 namespace 和 .xsd 文件的路径，如下所示。同时代码中需要提供相应的 parser 来解析，如 MvcNamespaceHandler、TaskNamespaceHandler、ContextNamespaceHandler、AopNamespaceHandler 等。

假如读者想分析 <context:property-placeholder location="classpath:xx.properties" /> 的实现原理，就应该到 ContextNamespaceHandler 中找答案。

<beans xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"      xmlns="http://www.springframework.org/schema/beans"      xmlns:context="http://www.springframework.org/schema/context"      xmlns:mvc="http://www.springframework.org/schema/mvc"      xsi:schemaLocation="           http://www.springframework.org/schema/beans            http://www.springframework.org/schema/beans/spring-beans.xsd           http://www.springframework.org/schema/context           http://www.springframework.org/schema/context/spring-context.xsd           http://www.springframework.org/schema/mvc              http://www.springframework.org/schema/mvc/spring-mvc.xsd         "      default-autowire="byName">

同理，以后你要是碰到 <dubbo /> 这种标签，那么就应该搜一搜是不是有 DubboNamespaceHandler 这个处理类。

回过神来，看看处理 default 标签的方法：

private void parseDefaultElement(Element ele, BeanDefinitionParserDelegate delegate) {   if (delegate.nodeNameEquals(ele, IMPORT_ELEMENT)) {      // 处理 <import /> 标签      importBeanDefinitionResource(ele);   }   else if (delegate.nodeNameEquals(ele, ALIAS_ELEMENT)) {      // 处理 <alias /> 标签定义      // <alias name="fromName" alias="toName"/>      processAliasRegistration(ele);   }   else if (delegate.nodeNameEquals(ele, BEAN_ELEMENT)) {      // 处理 <bean /> 标签定义，这也算是我们的重点吧      processBeanDefinition(ele, delegate);   }   else if (delegate.nodeNameEquals(ele, NESTED_BEANS_ELEMENT)) {      // 如果碰到的是嵌套的 <beans /> 标签，需要递归      doRegisterBeanDefinitions(ele);   }}

如果每个标签都说，那我不吐血，你们都要吐血了。我们挑我们的重点 <bean /> 标签出来说。

processBeanDefinition 解析 bean 标签

下面是 processBeanDefinition 解析 <bean /> 标签：

// DefaultBeanDefinitionDocumentReader 298

protected void processBeanDefinition(Element ele, BeanDefinitionParserDelegate delegate) {   // 将 <bean /> 节点中的信息提取出来，然后封装到一个 BeanDefinitionHolder 中，细节往下看   BeanDefinitionHolder bdHolder = delegate.parseBeanDefinitionElement(ele);     // 下面的几行先不要看，跳过先，跳过先，跳过先，后面会继续说的     if (bdHolder != null) {      bdHolder = delegate.decorateBeanDefinitionIfRequired(ele, bdHolder);      try {         // Register the final decorated instance.         BeanDefinitionReaderUtils.registerBeanDefinition(bdHolder, getReaderContext().getRegistry());      }      catch (BeanDefinitionStoreException ex) {         getReaderContext().error("Failed to register bean definition with name '" +               bdHolder.getBeanName() + "'", ele, ex);      }      // Send registration event.      getReaderContext().fireComponentRegistered(new BeanComponentDefinition(bdHolder));   }}

继续往下看怎么解析之前，我们先看下 <bean /> 标签中可以定义哪些属性：

上面表格中的内容我想大家都非常熟悉吧，如果不熟悉，那就是你不够了解 Spring 的配置了。

简单地说就是像下面这样子：

<bean id="exampleBean" name="name1, name2, name3" class="com.javadoop.ExampleBean"      scope="singleton" lazy-init="true" init-method="init" destroy-method="cleanup">      <!-- 可以用下面三种形式指定构造参数 -->    <constructor-arg type="int" value="7500000"/>    <constructor-arg name="years" value="7500000"/>    <constructor-arg index="0" value="7500000"/>      <!-- property 的几种情况 -->    <property name="beanOne">        <ref bean="anotherExampleBean"/>    </property>    <property name="beanTwo" ref="yetAnotherBean"/>    <property name="integerProperty" value="1"/></bean>

当然，除了上面举例出来的这些，还有 factory-bean、factory-method、<lockup-method />、<replaced-method />、<meta />、<qualifier /> 这几个，大家是不是熟悉呢？自己检验一下自己对 Spring 中 bean 的了解程度。

有了以上这些知识以后，我们再继续往里看怎么解析 bean 元素，是怎么转换到 BeanDefinitionHolder 的。

// BeanDefinitionParserDelegate 428

public BeanDefinitionHolder parseBeanDefinitionElement(Element ele) {    return parseBeanDefinitionElement(ele, null);}public BeanDefinitionHolder parseBeanDefinitionElement(Element ele, BeanDefinition containingBean) {   String id = ele.getAttribute(ID_ATTRIBUTE);   String nameAttr = ele.getAttribute(NAME_ATTRIBUTE);   List<String> aliases = new ArrayList<String>();         // 将 name 属性的定义按照 “逗号、分号、空格” 切分，形成一个 别名列表数组，   // 当然，如果你不定义 name 属性的话，就是空的了   // 我在附录中简单介绍了一下 id 和 name 的配置，大家可以看一眼，有个20秒就可以了   if (StringUtils.hasLength(nameAttr)) {      String[] nameArr = StringUtils.tokenizeToStringArray(nameAttr, MULTI_VALUE_ATTRIBUTE_DELIMITERS);      aliases.addAll(Arrays.asList(nameArr));   }   String beanName = id;   // 如果没有指定id, 那么用别名列表的第一个名字作为beanName   if (!StringUtils.hasText(beanName) && !aliases.isEmpty()) {      beanName = aliases.remove(0);      if (logger.isDebugEnabled()) {         logger.debug("No XML 'id' specified - using '" + beanName +               "' as bean name and " + aliases + " as aliases");      }   }   if (containingBean == null) {      checkNameUniqueness(beanName, aliases, ele);   }     // 根据 <bean ...>...</bean> 中的配置创建 BeanDefinition，然后把配置中的信息都设置到实例中,   // 细节后面细说，先知道下面这行结束后，一个 BeanDefinition 实例就出来了。   AbstractBeanDefinition beanDefinition = parseBeanDefinitionElement(ele, beanName, containingBean);      // 到这里，整个 <bean /> 标签就算解析结束了，一个 BeanDefinition 就形成了。   if (beanDefinition != null) {      // 如果都没有设置 id 和 name，那么此时的 beanName 就会为 null，进入下面这块代码产生      // 如果读者不感兴趣的话，我觉得不需要关心这块代码，对本文源码分析来说，这些东西不重要      if (!StringUtils.hasText(beanName)) {         try {            if (containingBean != null) {// 按照我们的思路，这里 containingBean 是 null 的               beanName = BeanDefinitionReaderUtils.generateBeanName(                     beanDefinition, this.readerContext.getRegistry(), true);            }            else {               // 如果我们不定义 id 和 name，那么我们引言里的那个例子：               //   1. beanName 为：com.javadoop.example.MessageServiceImpl#0               //   2. beanClassName 为：com.javadoop.example.MessageServiceImpl                             beanName = this.readerContext.generateBeanName(beanDefinition);                              String beanClassName = beanDefinition.getBeanClassName();               if (beanClassName != null &&                     beanName.startsWith(beanClassName) && beanName.length() > beanClassName.length() &&                     !this.readerContext.getRegistry().isBeanNameInUse(beanClassName)) {                  // 把 beanClassName 设置为 Bean 的别名                  aliases.add(beanClassName);               }            }            if (logger.isDebugEnabled()) {               logger.debug("Neither XML 'id' nor 'name' specified - " +                     "using generated bean name [" + beanName + "]");            }         }         catch (Exception ex) {            error(ex.getMessage(), ele);            return null;         }      }      String[] aliasesArray = StringUtils.toStringArray(aliases);      // 返回 BeanDefinitionHolder      return new BeanDefinitionHolder(beanDefinition, beanName, aliasesArray);   }   return null;}

然后，我们再看看怎么根据配置创建 BeanDefinition 实例的：

public AbstractBeanDefinition parseBeanDefinitionElement(      Element ele, String beanName, BeanDefinition containingBean) {   this.parseState.push(new BeanEntry(beanName));   String className = null;   if (ele.hasAttribute(CLASS_ATTRIBUTE)) {      className = ele.getAttribute(CLASS_ATTRIBUTE).trim();   }   try {      String parent = null;      if (ele.hasAttribute(PARENT_ATTRIBUTE)) {         parent = ele.getAttribute(PARENT_ATTRIBUTE);      }      // 创建 BeanDefinition，然后设置类信息而已，很简单，就不贴代码了      AbstractBeanDefinition bd = createBeanDefinition(className, parent);      // 设置 BeanDefinition 的一堆属性，这些属性定义在 AbstractBeanDefinition 中      parseBeanDefinitionAttributes(ele, beanName, containingBean, bd);      bd.setDescription(DomUtils.getChildElementValueByTagName(ele, DESCRIPTION_ELEMENT));          /**       * 下面的一堆是解析 <bean>......</bean> 内部的子元素，       * 解析出来以后的信息都放到 bd 的属性中       */           // 解析 <meta />      parseMetaElements(ele, bd);      // 解析 <lookup-method />      parseLookupOverrideSubElements(ele, bd.getMethodOverrides());      // 解析 <replaced-method />      parseReplacedMethodSubElements(ele, bd.getMethodOverrides());    // 解析 <constructor-arg />      parseConstructorArgElements(ele, bd);      // 解析 <property />      parsePropertyElements(ele, bd);      // 解析 <qualifier />      parseQualifierElements(ele, bd);      bd.setResource(this.readerContext.getResource());      bd.setSource(extractSource(ele));      return bd;   }   catch (ClassNotFoundException ex) {      error("Bean class [" + className + "] not found", ele, ex);   }   catch (NoClassDefFoundError err) {      error("Class that bean class [" + className + "] depends on not found", ele, err);   }   catch (Throwable ex) {      error("Unexpected failure during bean definition parsing", ele, ex);   }   finally {      this.parseState.pop();   }   return null;}

到这里，我们已经完成了根据 <bean /> 配置创建了一个 BeanDefinitionHolder 实例。注意，是一个。

我们回到解析 <bean /> 的入口方法:

protected void processBeanDefinition(Element ele, BeanDefinitionParserDelegate delegate) {   // 将 <bean /> 节点转换为 BeanDefinitionHolder，就是上面说的一堆   BeanDefinitionHolder bdHolder = delegate.parseBeanDefinitionElement(ele);   if (bdHolder != null) {      // 如果有自定义属性的话，进行相应的解析，先忽略      bdHolder = delegate.decorateBeanDefinitionIfRequired(ele, bdHolder);      try {         // 我们把这步叫做 注册Bean 吧         BeanDefinitionReaderUtils.registerBeanDefinition(bdHolder, getReaderContext().getRegistry());      }      catch (BeanDefinitionStoreException ex) {         getReaderContext().error("Failed to register bean definition with name '" +               bdHolder.getBeanName() + "'", ele, ex);      }      // 注册完成后，发送事件，本文不展开说这个      getReaderContext().fireComponentRegistered(new BeanComponentDefinition(bdHolder));   }}

大家再仔细看一下这块吧，我们后面就不回来说这个了。这里已经根据一个 <bean /> 标签产生了一个 BeanDefinitionHolder 的实例，这个实例里面也就是一个 BeanDefinition 的实例和它的 beanName、aliases 这三个信息，注意，我们的关注点始终在 BeanDefinition 上：

public class BeanDefinitionHolder implements BeanMetadataElement {  private final BeanDefinition beanDefinition;  private final String beanName;  private final String[] aliases;...

然后我们准备注册这个 BeanDefinition，最后，把这个注册事件发送出去。

下面，我们开始说说注册 Bean 吧。

注册 Bean

// BeanDefinitionReaderUtils 143

public static void registerBeanDefinition(      BeanDefinitionHolder definitionHolder, BeanDefinitionRegistry registry)      throws BeanDefinitionStoreException {   String beanName = definitionHolder.getBeanName();   // 注册这个 Bean   registry.registerBeanDefinition(beanName, definitionHolder.getBeanDefinition());   // 如果还有别名的话，也要根据别名全部注册一遍，不然根据别名就会找不到 Bean 了   String[] aliases = definitionHolder.getAliases();   if (aliases != null) {      for (String alias : aliases) {         // alias -> beanName 保存它们的别名信息，这个很简单，用一个 map 保存一下就可以了，         // 获取的时候，会先将 alias 转换为 beanName，然后再查找         registry.registerAlias(beanName, alias);      }   }}

别名注册的放一边，毕竟它很简单，我们看看怎么注册 Bean。

// DefaultListableBeanFactory 793

@Overridepublic void registerBeanDefinition(String beanName, BeanDefinition beanDefinition)      throws BeanDefinitionStoreException {   Assert.hasText(beanName, "Bean name must not be empty");   Assert.notNull(beanDefinition, "BeanDefinition must not be null");   if (beanDefinition instanceof AbstractBeanDefinition) {      try {         ((AbstractBeanDefinition) beanDefinition).validate();      }      catch (BeanDefinitionValidationException ex) {         throw new BeanDefinitionStoreException(...);      }   }   // old? 还记得 “允许 bean 覆盖” 这个配置吗？allowBeanDefinitionOverriding   BeanDefinition oldBeanDefinition;     // 之后会看到，所有的 Bean 注册后会放入这个 beanDefinitionMap 中   oldBeanDefinition = this.beanDefinitionMap.get(beanName);     // 处理重复名称的 Bean 定义的情况   if (oldBeanDefinition != null) {      if (!isAllowBeanDefinitionOverriding()) {         // 如果不允许覆盖的话，抛异常         throw new BeanDefinitionStoreException(beanDefinition.getResourceDescription()...      }      else if (oldBeanDefinition.getRole() < beanDefinition.getRole()) {         // log...用框架定义的 Bean 覆盖用户自定义的 Bean       }      else if (!beanDefinition.equals(oldBeanDefinition)) {         // log...用新的 Bean 覆盖旧的 Bean      }      else {         // log...用同等的 Bean 覆盖旧的 Bean，这里指的是 equals 方法返回 true 的 Bean      }      // 覆盖      this.beanDefinitionMap.put(beanName, beanDefinition);   }   else {      // 判断是否已经有其他的 Bean 开始初始化了.      // 注意，"注册Bean" 这个动作结束，Bean 依然还没有初始化，我们后面会有大篇幅说初始化过程，      // 在 Spring 容器启动的最后，会 预初始化 所有的 singleton beans      if (hasBeanCreationStarted()) {         // Cannot modify startup-time collection elements anymore (for stable iteration)         synchronized (this.beanDefinitionMap) {            this.beanDefinitionMap.put(beanName, beanDefinition);            List<String> updatedDefinitions = new ArrayList<String>(this.beanDefinitionNames.size() + 1);            updatedDefinitions.addAll(this.beanDefinitionNames);            updatedDefinitions.add(beanName);            this.beanDefinitionNames = updatedDefinitions;            if (this.manualSingletonNames.contains(beanName)) {               Set<String> updatedSingletons = new LinkedHashSet<String>(this.manualSingletonNames);               updatedSingletons.remove(beanName);               this.manualSingletonNames = updatedSingletons;            }         }      }      else {         // 最正常的应该是进到这个分支。                 // 将 BeanDefinition 放到这个 map 中，这个 map 保存了所有的 BeanDefinition         this.beanDefinitionMap.put(beanName, beanDefinition);         // 这是个 ArrayList，所以会按照 bean 配置的顺序保存每一个注册的 Bean 的名字         this.beanDefinitionNames.add(beanName);         // 这是个 LinkedHashSet，代表的是手动注册的 singleton bean，         // 注意这里是 remove 方法，到这里的 Bean 当然不是手动注册的         // 手动指的是通过调用以下方法注册的 bean ：         //     registerSingleton(String beanName, Object singletonObject)         // 这不是重点，解释只是为了不让大家疑惑。Spring 会在后面"手动"注册一些 Bean，         // 如 "environment"、"systemProperties" 等 bean，我们自己也可以在运行时注册 Bean 到容器中的         this.manualSingletonNames.remove(beanName);      }      // 这个不重要，在预初始化的时候会用到，不必管它。      this.frozenBeanDefinitionNames = null;   }   if (oldBeanDefinition != null || containsSingleton(beanName)) {      resetBeanDefinition(beanName);   }}

总结一下，到这里已经初始化了 Bean 容器，<bean /> 配置也相应的转换为了一个个 BeanDefinition，然后注册了各个 BeanDefinition 到注册中心，并且发送了注册事件。

--------- 分割线 ---------

到这里是一个分水岭，前面的内容都还算比较简单，不过应该也比较繁琐，大家要清楚地知道前面都做了哪些事情。

Bean 容器实例化完成后

说到这里，我们回到 refresh() 方法，我重新贴了一遍代码，看看我们说到哪了。是的，我们才说完 obtainFreshBeanFactory() 方法。

考虑到篇幅，这里开始大幅缩减掉没必要详细介绍的部分，大家直接看下面的代码中的注释就好了。

@Overridepublic void refresh() throws BeansException, IllegalStateException {   // 来个锁，不然 refresh() 还没结束，你又来个启动或销毁容器的操作，那不就乱套了嘛   synchronized (this.startupShutdownMonitor) {      // 准备工作，记录下容器的启动时间、标记“已启动”状态、处理配置文件中的占位符      prepareRefresh();           // 这步比较关键，这步完成后，配置文件就会解析成一个个 Bean 定义，注册到 BeanFactory 中，      // 当然，这里说的 Bean 还没有初始化，只是配置信息都提取出来了，      // 注册也只是将这些信息都保存到了注册中心(说到底核心是一个 beanName-> beanDefinition 的 map)      ConfigurableListableBeanFactory beanFactory = obtainFreshBeanFactory();      // 设置 BeanFactory 的类加载器，添加几个 BeanPostProcessor，手动注册几个特殊的 bean      // 这块待会会展开说      prepareBeanFactory(beanFactory);      try {         // 【这里需要知道 BeanFactoryPostProcessor 这个知识点，Bean 如果实现了此接口，         // 那么在容器初始化以后，Spring 会负责调用里面的 postProcessBeanFactory 方法。】                 // 这里是提供给子类的扩展点，到这里的时候，所有的 Bean 都加载、注册完成了，但是都还没有初始化         // 具体的子类可以在这步的时候添加一些特殊的 BeanFactoryPostProcessor 的实现类或做点什么事         postProcessBeanFactory(beanFactory);         // 调用 BeanFactoryPostProcessor 各个实现类的 postProcessBeanFactory(factory) 回调方法         invokeBeanFactoryPostProcessors(beanFactory);                                      // 注册 BeanPostProcessor 的实现类，注意看和 BeanFactoryPostProcessor 的区别         // 此接口两个方法: postProcessBeforeInitialization 和 postProcessAfterInitialization         // 两个方法分别在 Bean 初始化之前和初始化之后得到执行。这里仅仅是注册，之后会看到回调这两方法的时机         registerBeanPostProcessors(beanFactory);         // 初始化当前 ApplicationContext 的 MessageSource，国际化这里就不展开说了，不然没完没了了         initMessageSource();         // 初始化当前 ApplicationContext 的事件广播器，这里也不展开了         initApplicationEventMulticaster();         // 从方法名就可以知道，典型的模板方法(钩子方法)，不展开说         // 具体的子类可以在这里初始化一些特殊的 Bean（在初始化 singleton beans 之前）         onRefresh();         // 注册事件监听器，监听器需要实现 ApplicationListener 接口。这也不是我们的重点，过         registerListeners();         // 重点，重点，重点         // 初始化所有的 singleton beans         //（lazy-init 的除外）         finishBeanFactoryInitialization(beanFactory);         // 最后，广播事件，ApplicationContext 初始化完成，不展开         finishRefresh();      }      catch (BeansException ex) {         if (logger.isWarnEnabled()) {            logger.warn("Exception encountered during context initialization - " +                  "cancelling refresh attempt: " + ex);         }         // Destroy already created singletons to avoid dangling resources.         // 销毁已经初始化的 singleton 的 Beans，以免有些 bean 会一直占用资源         destroyBeans();         // Reset 'active' flag.         cancelRefresh(ex);         // 把异常往外抛         throw ex;      }      finally {         // Reset common introspection caches in Spring's core, since we         // might not ever need metadata for singleton beans anymore...         resetCommonCaches();      }   }}

准备 Bean 容器: prepareBeanFactory

之前我们说过，Spring 把我们在 xml 配置的 bean 都注册以后，会"手动"注册一些特殊的 bean。

这里简单介绍下 prepareBeanFactory(factory) 方法：

/** * Configure the factory's standard context characteristics, * such as the context's ClassLoader and post-processors. * @param beanFactory the BeanFactory to configure */protected void prepareBeanFactory(ConfigurableListableBeanFactory beanFactory) {   // 设置 BeanFactory 的类加载器，我们知道 BeanFactory 需要加载类，也就需要类加载器，   // 这里设置为加载当前 ApplicationContext 类的类加载器   beanFactory.setBeanClassLoader(getClassLoader());       // 设置 BeanExpressionResolver   beanFactory.setBeanExpressionResolver(new StandardBeanExpressionResolver(beanFactory.getBeanClassLoader()));   //    beanFactory.addPropertyEditorRegistrar(new ResourceEditorRegistrar(this, getEnvironment()));   // 添加一个 BeanPostProcessor，这个 processor 比较简单：   // 实现了 Aware 接口的 beans 在初始化的时候，这个 processor 负责回调，   // 这个我们很常用，如我们会为了获取 ApplicationContext 而 implement ApplicationContextAware   // 注意：它不仅仅回调 ApplicationContextAware，   //   还会负责回调 EnvironmentAware、ResourceLoaderAware 等，看下源码就清楚了   beanFactory.addBeanPostProcessor(new ApplicationContextAwareProcessor(this));     // 下面几行的意思就是，如果某个 bean 依赖于以下几个接口的实现类，在自动装配的时候忽略它们，   // Spring 会通过其他方式来处理这些依赖。   beanFactory.ignoreDependencyInterface(EnvironmentAware.class);   beanFactory.ignoreDependencyInterface(EmbeddedValueResolverAware.class);   beanFactory.ignoreDependencyInterface(ResourceLoaderAware.class);   beanFactory.ignoreDependencyInterface(ApplicationEventPublisherAware.class);   beanFactory.ignoreDependencyInterface(MessageSourceAware.class);   beanFactory.ignoreDependencyInterface(ApplicationContextAware.class);   /**    * 下面几行就是为特殊的几个 bean 赋值，如果有 bean 依赖了以下几个，会注入这边相应的值，    * 之前我们说过，"当前 ApplicationContext 持有一个 BeanFactory"，这里解释了第一行。    * ApplicationContext 还继承了 ResourceLoader、ApplicationEventPublisher、MessageSource    * 所以对于这几个依赖，可以赋值为 this，注意 this 是一个 ApplicationContext    * 那这里怎么没看到为 MessageSource 赋值呢？那是因为 MessageSource 被注册成为了一个普通的 bean    */   beanFactory.registerResolvableDependency(BeanFactory.class, beanFactory);   beanFactory.registerResolvableDependency(ResourceLoader.class, this);   beanFactory.registerResolvableDependency(ApplicationEventPublisher.class, this);   beanFactory.registerResolvableDependency(ApplicationContext.class, this);   // 这个 BeanPostProcessor 也很简单，在 bean 实例化后，如果是 ApplicationListener 的子类，   // 那么将其添加到 listener 列表中，可以理解成：注册 事件监听器   beanFactory.addBeanPostProcessor(new ApplicationListenerDetector(this));   // 这里涉及到特殊的 bean，名为：loadTimeWeaver，这不是我们的重点，忽略它   // tips: ltw 是 AspectJ 的概念，指的是在运行期进行织入，这个和 Spring AOP 不一样，   //    感兴趣的读者请参考我写的关于 AspectJ 的另一篇文章 https://www.javadoop.com/post/aspectj   if (beanFactory.containsBean(LOAD_TIME_WEAVER_BEAN_NAME)) {      beanFactory.addBeanPostProcessor(new LoadTimeWeaverAwareProcessor(beanFactory));      // Set a temporary ClassLoader for type matching.      beanFactory.setTempClassLoader(new ContextTypeMatchClassLoader(beanFactory.getBeanClassLoader()));   }   /**    * 从下面几行代码我们可以知道，Spring 往往很 "智能" 就是因为它会帮我们默认注册一些有用的 bean，    * 我们也可以选择覆盖    */     // 如果没有定义 "environment" 这个 bean，那么 Spring 会 "手动" 注册一个   if (!beanFactory.containsLocalBean(ENVIRONMENT_BEAN_NAME)) {      beanFactory.registerSingleton(ENVIRONMENT_BEAN_NAME, getEnvironment());   }   // 如果没有定义 "systemProperties" 这个 bean，那么 Spring 会 "手动" 注册一个   if (!beanFactory.containsLocalBean(SYSTEM_PROPERTIES_BEAN_NAME)) {      beanFactory.registerSingleton(SYSTEM_PROPERTIES_BEAN_NAME, getEnvironment().getSystemProperties());   }   // 如果没有定义 "systemEnvironment" 这个 bean，那么 Spring 会 "手动" 注册一个   if (!beanFactory.containsLocalBean(SYSTEM_ENVIRONMENT_BEAN_NAME)) {      beanFactory.registerSingleton(SYSTEM_ENVIRONMENT_BEAN_NAME, getEnvironment().getSystemEnvironment());   }}

在上面这块代码中，Spring 对一些特殊的 bean 进行了处理，读者如果暂时还不能消化它们也没有关系，慢慢往下看。

初始化所有的 singleton beans

我们的重点当然是 finishBeanFactoryInitialization(beanFactory); 这个巨头了，这里会负责初始化所有的 singleton beans。

注意，后面的描述中，我都会使用初始化或预初始化来代表这个阶段，Spring 会在这个阶段完成所有的 singleton beans 的实例化。

我们来总结一下，到目前为止，应该说 BeanFactory 已经创建完成，并且所有的实现了 BeanFactoryPostProcessor 接口的 Bean 都已经初始化并且其中的 postProcessBeanFactory(factory) 方法已经得到回调执行了。而且 Spring 已经“手动”注册了一些特殊的 Bean，如 environment、systemProperties 等。

剩下的就是初始化 singleton beans 了，我们知道它们是单例的，如果没有设置懒加载，那么 Spring 会在接下来初始化所有的 singleton beans。

// AbstractApplicationContext.java 834

// 初始化剩余的 singleton beansprotected void finishBeanFactoryInitialization(ConfigurableListableBeanFactory beanFactory) {   // 首先，初始化名字为 conversionService 的 Bean。本着送佛送到西的精神，我在附录中简单介绍了一下 ConversionService，因为这实在太实用了   // 什么，看代码这里没有初始化 Bean 啊！   // 注意了，初始化的动作包装在 beanFactory.getBean(...) 中，这里先不说细节，先往下看吧   if (beanFactory.containsBean(CONVERSION_SERVICE_BEAN_NAME) &&         beanFactory.isTypeMatch(CONVERSION_SERVICE_BEAN_NAME, ConversionService.class)) {      beanFactory.setConversionService(            beanFactory.getBean(CONVERSION_SERVICE_BEAN_NAME, ConversionService.class));   }   // Register a default embedded value resolver if no bean post-processor   // (such as a PropertyPlaceholderConfigurer bean) registered any before:   // at this point, primarily for resolution in annotation attribute values.   if (!beanFactory.hasEmbeddedValueResolver()) {      beanFactory.addEmbeddedValueResolver(new StringValueResolver() {         @Override         public String resolveStringValue(String strVal) {            return getEnvironment().resolvePlaceholders(strVal);         }      });   }   // 先初始化 LoadTimeWeaverAware 类型的 Bean   // 之前也说过，这是 AspectJ 相关的内容，放心跳过吧   String[] weaverAwareNames = beanFactory.getBeanNamesForType(LoadTimeWeaverAware.class, false, false);   for (String weaverAwareName : weaverAwareNames) {      getBean(weaverAwareName);   }   // Stop using the temporary ClassLoader for type matching.   beanFactory.setTempClassLoader(null);   // 没什么别的目的，因为到这一步的时候，Spring 已经开始预初始化 singleton beans 了，   // 肯定不希望这个时候还出现 bean 定义解析、加载、注册。   beanFactory.freezeConfiguration();   // 开始初始化   beanFactory.preInstantiateSingletons();}

从上面最后一行往里看，我们就又回到 DefaultListableBeanFactory 这个类了，这个类大家应该都不陌生了吧。

preInstantiateSingletons

// DefaultListableBeanFactory 728

@Overridepublic void preInstantiateSingletons() throws BeansException {   if (this.logger.isDebugEnabled()) {      this.logger.debug("Pre-instantiating singletons in " + this);   }   // this.beanDefinitionNames 保存了所有的 beanNames   List<String> beanNames = new ArrayList<String>(this.beanDefinitionNames);   // 下面这个循环，触发所有的非懒加载的 singleton beans 的初始化操作   for (String beanName : beanNames) {           // 合并父 Bean 中的配置，注意 <bean id="" class="" parent="" /> 中的 parent，用的不多吧，      // 考虑到这可能会影响大家的理解，我在附录中解释了一下 "Bean 继承"，不了解的请到附录中看一下      RootBeanDefinition bd = getMergedLocalBeanDefinition(beanName);           // 非抽象、非懒加载的 singletons。如果配置了 'abstract = true'，那是不需要初始化的      if (!bd.isAbstract() && bd.isSingleton() && !bd.isLazyInit()) {         // 处理 FactoryBean(读者如果不熟悉 FactoryBean，请移步附录区了解)         if (isFactoryBean(beanName)) {            // FactoryBean 的话，在 beanName 前面加上 ‘&’ 符号。再调用 getBean，getBean 方法别急            final FactoryBean<?> factory = (FactoryBean<?>) getBean(FACTORY_BEAN_PREFIX + beanName);            // 判断当前 FactoryBean 是否是 SmartFactoryBean 的实现，此处忽略，直接跳过            boolean isEagerInit;            if (System.getSecurityManager() != null && factory instanceof SmartFactoryBean) {               isEagerInit = AccessController.doPrivileged(new PrivilegedAction<Boolean>() {                  @Override                  public Boolean run() {                     return ((SmartFactoryBean<?>) factory).isEagerInit();                  }               }, getAccessControlContext());            }            else {               isEagerInit = (factory instanceof SmartFactoryBean &&                     ((SmartFactoryBean<?>) factory).isEagerInit());            }            if (isEagerInit) {                              getBean(beanName);            }         }         else {            // 对于普通的 Bean，只要调用 getBean(beanName) 这个方法就可以进行初始化了            getBean(beanName);         }      }   }   // 到这里说明所有的非懒加载的 singleton beans 已经完成了初始化   // 如果我们定义的 bean 是实现了 SmartInitializingSingleton 接口的，那么在这里得到回调，忽略   for (String beanName : beanNames) {      Object singletonInstance = getSingleton(beanName);      if (singletonInstance instanceof SmartInitializingSingleton) {         final SmartInitializingSingleton smartSingleton = (SmartInitializingSingleton) singletonInstance;         if (System.getSecurityManager() != null) {            AccessController.doPrivileged(new PrivilegedAction<Object>() {               @Override               public Object run() {                  smartSingleton.afterSingletonsInstantiated();                  return null;               }            }, getAccessControlContext());         }         else {            smartSingleton.afterSingletonsInstantiated();         }      }   }}

接下来，我们就进入到 getBean(beanName) 方法了，这个方法我们经常用来从 BeanFactory 中获取一个 Bean，而初始化的过程也封装到了这个方法里。

getBean

在继续前进之前，读者应该具备 FactoryBean 的知识，如果读者还不熟悉，请移步附录部分了解 FactoryBean。

// AbstractBeanFactory 196

@Overridepublic Object getBean(String name) throws BeansException {   return doGetBean(name, null, null, false);}// 我们在剖析初始化 Bean 的过程，但是 getBean 方法我们经常是用来从容器中获取 Bean 用的，注意切换思路，// 已经初始化过了就从容器中直接返回，否则就先初始化再返回@SuppressWarnings("unchecked")protected <T> T doGetBean(      final String name, final Class<T> requiredType, final Object[] args, boolean typeCheckOnly)      throws BeansException {   // 获取一个 “正统的” beanName，处理两种情况，一个是前面说的 FactoryBean(前面带 ‘&’)，   // 一个是别名问题，因为这个方法是 getBean，获取 Bean 用的，你要是传一个别名进来，是完全可以的   final String beanName = transformedBeanName(name);     // 注意跟着这个，这个是返回值   Object bean;    // 检查下是不是已经创建过了   Object sharedInstance = getSingleton(beanName);     // 这里说下 args 呗，虽然看上去一点不重要。前面我们一路进来的时候都是 getBean(beanName)，   // 所以 args 传参其实是 null 的，但是如果 args 不为空的时候，那么意味着调用方不是希望获取 Bean，而是创建 Bean   if (sharedInstance != null && args == null) {      if (logger.isDebugEnabled()) {         if (isSingletonCurrentlyInCreation(beanName)) {            logger.debug("...");         }         else {            logger.debug("Returning cached instance of singleton bean '" + beanName + "'");         }      }      // 下面这个方法：如果是普通 Bean 的话，直接返回 sharedInstance，      // 如果是 FactoryBean 的话，返回它创建的那个实例对象      // (FactoryBean 知识，读者若不清楚请移步附录)      bean = getObjectForBeanInstance(sharedInstance, name, beanName, null);   }   else {      if (isPrototypeCurrentlyInCreation(beanName)) {         // 创建过了此 beanName 的 prototype 类型的 bean，那么抛异常，         // 往往是因为陷入了循环引用         throw new BeanCurrentlyInCreationException(beanName);      }      // 检查一下这个 BeanDefinition 在容器中是否存在      BeanFactory parentBeanFactory = getParentBeanFactory();      if (parentBeanFactory != null && !containsBeanDefinition(beanName)) {         // 如果当前容器不存在这个 BeanDefinition，试试父容器中有没有         String nameToLookup = originalBeanName(name);         if (args != null) {            // 返回父容器的查询结果            return (T) parentBeanFactory.getBean(nameToLookup, args);         }         else {            // No args -> delegate to standard getBean method.            return parentBeanFactory.getBean(nameToLookup, requiredType);         }      }      if (!typeCheckOnly) {         // typeCheckOnly 为 false，将当前 beanName 放入一个 alreadyCreated 的 Set 集合中。         markBeanAsCreated(beanName);      }      /*       * 稍稍总结一下：       * 到这里的话，要准备创建 Bean 了，对于 singleton 的 Bean 来说，容器中还没创建过此 Bean；       * 对于 prototype 的 Bean 来说，本来就是要创建一个新的 Bean。       */      try {         final RootBeanDefinition mbd = getMergedLocalBeanDefinition(beanName);         checkMergedBeanDefinition(mbd, beanName, args);         // 先初始化依赖的所有 Bean，这个很好理解。         // 注意，这里的依赖指的是 depends-on 中定义的依赖         String[] dependsOn = mbd.getDependsOn();         if (dependsOn != null) {            for (String dep : dependsOn) {               // 检查是不是有循环依赖，这里的循环依赖和我们前面说的循环依赖又不一样，这里肯定是不允许出现的，不然要乱套了，读者想一下就知道了               if (isDependent(beanName, dep)) {                  throw new BeanCreationException(mbd.getResourceDescription(), beanName,                        "Circular depends-on relationship between '" + beanName + "' and '" + dep + "'");               }               // 注册一下依赖关系               registerDependentBean(dep, beanName);               // 先初始化被依赖项               getBean(dep);            }         }         // 如果是 singleton scope 的，创建 singleton 的实例         if (mbd.isSingleton()) {            sharedInstance = getSingleton(beanName, new ObjectFactory<Object>() {               @Override               public Object getObject() throws BeansException {                  try {                     // 执行创建 Bean，详情后面再说                     return createBean(beanName, mbd, args);                  }                  catch (BeansException ex) {                     destroySingleton(beanName);                     throw ex;                  }               }            });            bean = getObjectForBeanInstance(sharedInstance, name, beanName, mbd);         }         // 如果是 prototype scope 的，创建 prototype 的实例         else if (mbd.isPrototype()) {            // It's a prototype -> create a new instance.            Object prototypeInstance = null;            try {               beforePrototypeCreation(beanName);               // 执行创建 Bean               prototypeInstance = createBean(beanName, mbd, args);            }            finally {               afterPrototypeCreation(beanName);            }            bean = getObjectForBeanInstance(prototypeInstance, name, beanName, mbd);         }         // 如果不是 singleton 和 prototype 的话，需要委托给相应的实现类来处理         else {            String scopeName = mbd.getScope();            final Scope scope = this.scopes.get(scopeName);            if (scope == null) {               throw new IllegalStateException("No Scope registered for scope name '" + scopeName + "'");            }            try {               Object scopedInstance = scope.get(beanName, new ObjectFactory<Object>() {                  @Override                  public Object getObject() throws BeansException {                     beforePrototypeCreation(beanName);                     try {                        // 执行创建 Bean                        return createBean(beanName, mbd, args);                     }                     finally {                        afterPrototypeCreation(beanName);                     }                  }               });               bean = getObjectForBeanInstance(scopedInstance, name, beanName, mbd);            }            catch (IllegalStateException ex) {               throw new BeanCreationException(beanName,                     "Scope '" + scopeName + "' is not active for the current thread; consider " +                     "defining a scoped proxy for this bean if you intend to refer to it from a singleton",                     ex);            }         }      }      catch (BeansException ex) {         cleanupAfterBeanCreationFailure(beanName);         throw ex;      }   }   // 最后，检查一下类型对不对，不对的话就抛异常，对的话就返回了   if (requiredType != null && bean != null && !requiredType.isInstance(bean)) {      try {         return getTypeConverter().convertIfNecessary(bean, requiredType);      }      catch (TypeMismatchException ex) {         if (logger.isDebugEnabled()) {            logger.debug("Failed to convert bean '" + name + "' to required type '" +                  ClassUtils.getQualifiedName(requiredType) + "'", ex);         }         throw new BeanNotOfRequiredTypeException(name, requiredType, bean.getClass());      }   }   return (T) bean;}

大家应该也猜到了，接下来当然是分析 createBean 方法：

protected abstract Object createBean(String beanName, RootBeanDefinition mbd, Object[] args) throws BeanCreationException;

第三个参数 args 数组代表创建实例需要的参数，不就是给构造方法用的参数，或者是工厂 Bean 的参数嘛，不过要注意，在我们的初始化阶段，args 是 null。

这回我们要到一个新的类了 AbstractAutowireCapableBeanFactory，看类名，AutowireCapable？类名是不是也说明了点问题了。

主要是为了以下场景，采用 @Autowired 注解注入属性值：

public class MessageServiceImpl implements MessageService {    @Autowired    private UserService userService;      public String getMessage() {        return userService.getMessage();    }}

<bean id="messageService" class="com.javadoop.example.MessageServiceImpl" />

以上这种属于混用了 xml 和 注解 两种方式的配置方式，Spring 会处理这种情况。

好了，读者要知道这么回事就可以了，继续向前。

// AbstractAutowireCapableBeanFactory 447

/** * Central method of this class: creates a bean instance, * populates the bean instance, applies post-processors, etc. * @see #doCreateBean */@Overrideprotected Object createBean(String beanName, RootBeanDefinition mbd, Object[] args) throws BeanCreationException {   if (logger.isDebugEnabled()) {      logger.debug("Creating instance of bean '" + beanName + "'");   }   RootBeanDefinition mbdToUse = mbd;   // 确保 BeanDefinition 中的 Class 被加载   Class<?> resolvedClass = resolveBeanClass(mbd, beanName);   if (resolvedClass != null && !mbd.hasBeanClass() && mbd.getBeanClassName() != null) {      mbdToUse = new RootBeanDefinition(mbd);      mbdToUse.setBeanClass(resolvedClass);   }   // 准备方法覆写，这里又涉及到一个概念：MethodOverrides，它来自于 bean 定义中的 <lookup-method />    // 和 <replaced-method />，如果读者感兴趣，回到 bean 解析的地方看看对这两个标签的解析。   // 我在附录中也对这两个标签的相关知识点进行了介绍，读者可以移步去看看   try {      mbdToUse.prepareMethodOverrides();   }   catch (BeanDefinitionValidationException ex) {      throw new BeanDefinitionStoreException(mbdToUse.getResourceDescription(),            beanName, "Validation of method overrides failed", ex);   }   try {      // 让 InstantiationAwareBeanPostProcessor 在这一步有机会返回代理，      // 在 《Spring AOP 源码分析》那篇文章中有解释，这里先跳过      Object bean = resolveBeforeInstantiation(beanName, mbdToUse);      if (bean != null) {         return bean;       }   }   catch (Throwable ex) {      throw new BeanCreationException(mbdToUse.getResourceDescription(), beanName,            "BeanPostProcessor before instantiation of bean failed", ex);   }   // 重头戏，创建 bean   Object beanInstance = doCreateBean(beanName, mbdToUse, args);   if (logger.isDebugEnabled()) {      logger.debug("Finished creating instance of bean '" + beanName + "'");   }   return beanInstance;}

创建 Bean

我们继续往里看 doCreateBean 这个方法：

/** * Actually create the specified bean. Pre-creation processing has already happened * at this point, e.g. checking {@code postProcessBeforeInstantiation} callbacks. * <p>Differentiates between default bean instantiation, use of a * factory method, and autowiring a constructor. * @param beanName the name of the bean * @param mbd the merged bean definition for the bean * @param args explicit arguments to use for constructor or factory method invocation * @return a new instance of the bean * @throws BeanCreationException if the bean could not be created * @see #instantiateBean * @see #instantiateUsingFactoryMethod * @see #autowireConstructor */protected Object doCreateBean(final String beanName, final RootBeanDefinition mbd, final Object[] args)      throws BeanCreationException {   // Instantiate the bean.   BeanWrapper instanceWrapper = null;   if (mbd.isSingleton()) {      instanceWrapper = this.factoryBeanInstanceCache.remove(beanName);   }   if (instanceWrapper == null) {      // 说明不是 FactoryBean，这里实例化 Bean，这里非常关键，细节之后再说      instanceWrapper = createBeanInstance(beanName, mbd, args);   }   // 这个就是 Bean 里面的 我们定义的类 的实例，很多地方我直接描述成 "bean 实例"   final Object bean = (instanceWrapper != null ? instanceWrapper.getWrappedInstance() : null);   // 类型   Class<?> beanType = (instanceWrapper != null ? instanceWrapper.getWrappedClass() : null);   mbd.resolvedTargetType = beanType;   // 建议跳过吧，涉及接口：MergedBeanDefinitionPostProcessor   synchronized (mbd.postProcessingLock) {      if (!mbd.postProcessed) {         try {            // MergedBeanDefinitionPostProcessor，这个我真不展开说了，直接跳过吧，很少用的            applyMergedBeanDefinitionPostProcessors(mbd, beanType, beanName);         }         catch (Throwable ex) {            throw new BeanCreationException(mbd.getResourceDescription(), beanName,                  "Post-processing of merged bean definition failed", ex);         }         mbd.postProcessed = true;      }   }   // Eagerly cache singletons to be able to resolve circular references   // even when triggered by lifecycle interfaces like BeanFactoryAware.   // 下面这块代码是为了解决循环依赖的问题，以后有时间，我再对循环依赖这个问题进行解析吧   boolean earlySingletonExposure = (mbd.isSingleton() && this.allowCircularReferences &&         isSingletonCurrentlyInCreation(beanName));   if (earlySingletonExposure) {      if (logger.isDebugEnabled()) {         logger.debug("Eagerly caching bean '" + beanName +               "' to allow for resolving potential circular references");      }      addSingletonFactory(beanName, new ObjectFactory<Object>() {         @Override         public Object getObject() throws BeansException {            return getEarlyBeanReference(beanName, mbd, bean);         }      });   }   // Initialize the bean instance.   Object exposedObject = bean;   try {      // 这一步也是非常关键的，这一步负责属性装配，因为前面的实例只是实例化了，并没有设值，这里就是设值      populateBean(beanName, mbd, instanceWrapper);      if (exposedObject != null) {         // 还记得 init-method 吗？还有 InitializingBean 接口？还有 BeanPostProcessor 接口？         // 这里就是处理 bean 初始化完成后的各种回调         exposedObject = initializeBean(beanName, exposedObject, mbd);      }   }   catch (Throwable ex) {      if (ex instanceof BeanCreationException && beanName.equals(((BeanCreationException) ex).getBeanName())) {         throw (BeanCreationException) ex;      }      else {         throw new BeanCreationException(               mbd.getResourceDescription(), beanName, "Initialization of bean failed", ex);      }   }   if (earlySingletonExposure) {      //       Object earlySingletonReference = getSingleton(beanName, false);      if (earlySingletonReference != null) {         if (exposedObject == bean) {            exposedObject = earlySingletonReference;         }         else if (!this.allowRawInjectionDespiteWrapping && hasDependentBean(beanName)) {            String[] dependentBeans = getDependentBeans(beanName);            Set<String> actualDependentBeans = new LinkedHashSet<String>(dependentBeans.length);            for (String dependentBean : dependentBeans) {               if (!removeSingletonIfCreatedForTypeCheckOnly(dependentBean)) {                  actualDependentBeans.add(dependentBean);               }            }            if (!actualDependentBeans.isEmpty()) {               throw new BeanCurrentlyInCreationException(beanName,                     "Bean with name '" + beanName + "' has been injected into other beans [" +                     StringUtils.collectionToCommaDelimitedString(actualDependentBeans) +                     "] in its raw version as part of a circular reference, but has eventually been " +                     "wrapped. This means that said other beans do not use the final version of the " +                     "bean. This is often the result of over-eager type matching - consider using " +                     "'getBeanNamesOfType' with the 'allowEagerInit' flag turned off, for example.");            }         }      }   }   // Register bean as disposable.   try {      registerDisposableBeanIfNecessary(beanName, bean, mbd);   }   catch (BeanDefinitionValidationException ex) {      throw new BeanCreationException(            mbd.getResourceDescription(), beanName, "Invalid destruction signature", ex);   }   return exposedObject;}

到这里，我们已经分析完了 doCreateBean 方法，总的来说，我们已经说完了整个初始化流程。

接下来我们挑 doCreateBean 中的三个细节出来说说。一个是创建 Bean 实例的 createBeanInstance 方法，一个是依赖注入的 populateBean 方法，还有就是回调方法 initializeBean。

注意了，接下来的这三个方法要认真说那也是极其复杂的，很多地方我就点到为止了，感兴趣的读者可以自己往里看，最好就是碰到不懂的，自己写代码去调试它。

创建 Bean 实例

我们先看看 createBeanInstance 方法。需要说明的是，这个方法如果每个分支都分析下去，必然也是极其复杂冗长的，我们挑重点说。此方法的目的就是实例化我们指定的类。

protected BeanWrapper createBeanInstance(String beanName, RootBeanDefinition mbd, Object[] args) {   // 确保已经加载了此 class   Class<?> beanClass = resolveBeanClass(mbd, beanName);   // 校验一下这个类的访问权限   if (beanClass != null && !Modifier.isPublic(beanClass.getModifiers()) && !mbd.isNonPublicAccessAllowed()) {      throw new BeanCreationException(mbd.getResourceDescription(), beanName,            "Bean class isn't public, and non-public access not allowed: " + beanClass.getName());   }   if (mbd.getFactoryMethodName() != null)  {      // 采用工厂方法实例化，不熟悉这个概念的读者请看附录，注意，不是 FactoryBean      return instantiateUsingFactoryMethod(beanName, mbd, args);   }   // 如果不是第一次创建，比如第二次创建 prototype bean。   // 这种情况下，我们可以从第一次创建知道，采用无参构造函数，还是构造函数依赖注入 来完成实例化   boolean resolved = false;   boolean autowireNecessary = false;   if (args == null) {      synchronized (mbd.constructorArgumentLock) {         if (mbd.resolvedConstructorOrFactoryMethod != null) {            resolved = true;            autowireNecessary = mbd.constructorArgumentsResolved;         }      }   }   if (resolved) {      if (autowireNecessary) {         // 构造函数依赖注入         return autowireConstructor(beanName, mbd, null, null);      }      else {         // 无参构造函数         return instantiateBean(beanName, mbd);      }   }   // 判断是否采用有参构造函数   Constructor<?>[] ctors = determineConstructorsFromBeanPostProcessors(beanClass, beanName);   if (ctors != null ||         mbd.getResolvedAutowireMode() == RootBeanDefinition.AUTOWIRE_CONSTRUCTOR ||         mbd.hasConstructorArgumentValues() || !ObjectUtils.isEmpty(args))  {      // 构造函数依赖注入      return autowireConstructor(beanName, mbd, ctors, args);   }   // 调用无参构造函数   return instantiateBean(beanName, mbd);}

挑个简单的无参构造函数构造实例来看看：

protected BeanWrapper instantiateBean(final String beanName, final RootBeanDefinition mbd) {   try {      Object beanInstance;      final BeanFactory parent = this;      if (System.getSecurityManager() != null) {         beanInstance = AccessController.doPrivileged(new PrivilegedAction<Object>() {            @Override            public Object run() {                              return getInstantiationStrategy().instantiate(mbd, beanName, parent);            }         }, getAccessControlContext());      }      else {         // 实例化         beanInstance = getInstantiationStrategy().instantiate(mbd, beanName, parent);      }      // 包装一下，返回      BeanWrapper bw = new BeanWrapperImpl(beanInstance);      initBeanWrapper(bw);      return bw;   }   catch (Throwable ex) {      throw new BeanCreationException(            mbd.getResourceDescription(), beanName, "Instantiation of bean failed", ex);   }}

我们可以看到，关键的地方在于：

beanInstance = getInstantiationStrategy().instantiate(mbd, beanName, parent);

这里会进行实际的实例化过程，我们进去看看:

// SimpleInstantiationStrategy 59

@Overridepublic Object instantiate(RootBeanDefinition bd, String beanName, BeanFactory owner) {   // 如果不存在方法覆写，那就使用 java 反射进行实例化，否则使用 CGLIB,   // 方法覆写 请参见附录"方法注入"中对 lookup-method 和 replaced-method 的介绍   if (bd.getMethodOverrides().isEmpty()) {      Constructor<?> constructorToUse;      synchronized (bd.constructorArgumentLock) {         constructorToUse = (Constructor<?>) bd.resolvedConstructorOrFactoryMethod;         if (constructorToUse == null) {            final Class<?> clazz = bd.getBeanClass();            if (clazz.isInterface()) {               throw new BeanInstantiationException(clazz, "Specified class is an interface");            }            try {               if (System.getSecurityManager() != null) {                  constructorToUse = AccessController.doPrivileged(new PrivilegedExceptionAction<Constructor<?>>() {                     @Override                     public Constructor<?> run() throws Exception {                        return clazz.getDeclaredConstructor((Class[]) null);                     }                  });               }               else {                  constructorToUse = clazz.getDeclaredConstructor((Class[]) null);               }               bd.resolvedConstructorOrFactoryMethod = constructorToUse;            }            catch (Throwable ex) {               throw new BeanInstantiationException(clazz, "No default constructor found", ex);            }         }      }      // 利用构造方法进行实例化      return BeanUtils.instantiateClass(constructorToUse);   }   else {      // 存在方法覆写，利用 CGLIB 来完成实例化，需要依赖于 CGLIB 生成子类，这里就不展开了。      // tips: 因为如果不使用 CGLIB 的话，存在 override 的情况 JDK 并没有提供相应的实例化支持      return instantiateWithMethodInjection(bd, beanName, owner);   }}

到这里，我们就算实例化完成了。我们开始说怎么进行属性注入。

bean 属性注入

看完了 createBeanInstance(...) 方法，我们来看看 populateBean(...) 方法，该方法负责进行属性设值，处理依赖。

// AbstractAutowireCapableBeanFactory 1203

protected void populateBean(String beanName, RootBeanDefinition mbd, BeanWrapper bw) {   // bean 实例的所有属性都在这里了   PropertyValues pvs = mbd.getPropertyValues();   if (bw == null) {      if (!pvs.isEmpty()) {         throw new BeanCreationException(               mbd.getResourceDescription(), beanName, "Cannot apply property values to null instance");      }      else {         // Skip property population phase for null instance.         return;      }   }   // 到这步的时候，bean 实例化完成（通过工厂方法或构造方法），但是还没开始属性设值，   // InstantiationAwareBeanPostProcessor 的实现类可以在这里对 bean 进行状态修改，   // 我也没找到有实际的使用，所以我们暂且忽略这块吧   boolean continueWithPropertyPopulation = true;   if (!mbd.isSynthetic() && hasInstantiationAwareBeanPostProcessors()) {      for (BeanPostProcessor bp : getBeanPostProcessors()) {         if (bp instanceof InstantiationAwareBeanPostProcessor) {            InstantiationAwareBeanPostProcessor ibp = (InstantiationAwareBeanPostProcessor) bp;            // 如果返回 false，代表不需要进行后续的属性设值，也不需要再经过其他的 BeanPostProcessor 的处理            if (!ibp.postProcessAfterInstantiation(bw.getWrappedInstance(), beanName)) {               continueWithPropertyPopulation = false;               break;            }         }      }   }   if (!continueWithPropertyPopulation) {      return;   }   if (mbd.getResolvedAutowireMode() == RootBeanDefinition.AUTOWIRE_BY_NAME ||         mbd.getResolvedAutowireMode() == RootBeanDefinition.AUTOWIRE_BY_TYPE) {      MutablePropertyValues newPvs = new MutablePropertyValues(pvs);      // 通过名字找到所有属性值，如果是 bean 依赖，先初始化依赖的 bean。记录依赖关系      if (mbd.getResolvedAutowireMode() == RootBeanDefinition.AUTOWIRE_BY_NAME) {         autowireByName(beanName, mbd, bw, newPvs);      }      // 通过类型装配。复杂一些      if (mbd.getResolvedAutowireMode() == RootBeanDefinition.AUTOWIRE_BY_TYPE) {         autowireByType(beanName, mbd, bw, newPvs);      }      pvs = newPvs;   }   boolean hasInstAwareBpps = hasInstantiationAwareBeanPostProcessors();   boolean needsDepCheck = (mbd.getDependencyCheck() != RootBeanDefinition.DEPENDENCY_CHECK_NONE);   if (hasInstAwareBpps || needsDepCheck) {      PropertyDescriptor[] filteredPds = filterPropertyDescriptorsForDependencyCheck(bw, mbd.allowCaching);      if (hasInstAwareBpps) {         for (BeanPostProcessor bp : getBeanPostProcessors()) {            if (bp instanceof InstantiationAwareBeanPostProcessor) {               InstantiationAwareBeanPostProcessor ibp = (InstantiationAwareBeanPostProcessor) bp;               // 这里有个非常有用的 BeanPostProcessor 进到这里: AutowiredAnnotationBeanPostProcessor               // 对采用 @Autowired、@Value 注解的依赖进行设值，这里的内容也是非常丰富的，不过本文不会展开说了，感兴趣的读者请自行研究               pvs = ibp.postProcessPropertyValues(pvs, filteredPds, bw.getWrappedInstance(), beanName);               if (pvs == null) {                  return;               }            }         }      }      if (needsDepCheck) {         checkDependencies(beanName, mbd, filteredPds, pvs);      }   }   // 设置 bean 实例的属性值   applyPropertyValues(beanName, mbd, bw, pvs);}

initializeBean

属性注入完成后，这一步其实就是处理各种回调了，这块代码比较简单。

protected Object initializeBean(final String beanName, final Object bean, RootBeanDefinition mbd) {   if (System.getSecurityManager() != null) {      AccessController.doPrivileged(new PrivilegedAction<Object>() {         @Override         public Object run() {            invokeAwareMethods(beanName, bean);            return null;         }      }, getAccessControlContext());   }   else {      // 如果 bean 实现了 BeanNameAware、BeanClassLoaderAware 或 BeanFactoryAware 接口，回调      invokeAwareMethods(beanName, bean);   }   Object wrappedBean = bean;   if (mbd == null || !mbd.isSynthetic()) {      // BeanPostProcessor 的 postProcessBeforeInitialization 回调      wrappedBean = applyBeanPostProcessorsBeforeInitialization(wrappedBean, beanName);   }   try {      // 处理 bean 中定义的 init-method，      // 或者如果 bean 实现了 InitializingBean 接口，调用 afterPropertiesSet() 方法      invokeInitMethods(beanName, wrappedBean, mbd);   }   catch (Throwable ex) {      throw new BeanCreationException(            (mbd != null ? mbd.getResourceDescription() : null),            beanName, "Invocation of init method failed", ex);   }   if (mbd == null || !mbd.isSynthetic()) {      // BeanPostProcessor 的 postProcessAfterInitialization 回调      wrappedBean = applyBeanPostProcessorsAfterInitialization(wrappedBean, beanName);   }   return wrappedBean;}

大家发现没有，BeanPostProcessor 的两个回调都发生在这边，只不过中间处理了 init-method，是不是和读者原来的认知有点不一样了？

附录

id 和 name

每个 Bean 在 Spring 容器中都有一个唯一的名字（beanName）和 0 个或多个别名（aliases）。

我们从 Spring 容器中获取 Bean 的时候，可以根据 beanName，也可以通过别名。

beanFactory.getBean("beanName or alias");

在配置 <bean /> 的过程中，我们可以配置 id 和 name，看几个例子就知道是怎么回事了。

<bean id="messageService" name="m1, m2, m3" class="com.javadoop.example.MessageServiceImpl">

以上配置的结果就是：beanName 为 messageService，别名有 3 个，分别为 m1、m2、m3。

<bean name="m1, m2, m3" class="com.javadoop.example.MessageServiceImpl" />

以上配置的结果就是：beanName 为 m1，别名有 2 个，分别为 m2、m3。

<bean class="com.javadoop.example.MessageServiceImpl">

beanName 为：com.javadoop.example.MessageServiceImpl#0，

别名 1 个，为： com.javadoop.example.MessageServiceImpl

<bean id="messageService" class="com.javadoop.example.MessageServiceImpl">

以上配置的结果就是：beanName 为 messageService，没有别名。

配置是否允许 Bean 覆盖、是否允许循环依赖

我们说过，默认情况下，allowBeanDefinitionOverriding 属性为 null。如果在同一配置文件中 Bean id 或 name 重复了，会抛错，但是如果不是同一配置文件中，会发生覆盖。

可是有些时候我们希望在系统启动的过程中就严格杜绝发生 Bean 覆盖，因为万一出现这种情况，会增加我们排查问题的成本。

循环依赖说的是 A 依赖 B，而 B 又依赖 A。或者是 A 依赖 B，B 依赖 C，而 C 却依赖 A。默认 allowCircularReferences 也是 null。

它们两个属性是一起出现的，必然可以在同一个地方一起进行配置。

添加这两个属性的作者 Juergen Hoeller 在这个 jira 的讨论中说明了怎么配置这两个属性。

public class NoBeanOverridingContextLoader extends ContextLoader {   @Override  protected void customizeContext(ServletContext servletContext, ConfigurableWebApplicationContext applicationContext) {    super.customizeContext(servletContext, applicationContext);    AbstractRefreshableApplicationContext arac = (AbstractRefreshableApplicationContext) applicationContext;    arac.setAllowBeanDefinitionOverriding(false);  }}

public class MyContextLoaderListener extends org.springframework.web.context.ContextLoaderListener {   @Override  protected ContextLoader createContextLoader() {    return new NoBeanOverridingContextLoader();  }  }

<listener>    <listener-class>com.javadoop.MyContextLoaderListener</listener-class>  </listener>

如果以上方式不能满足你的需求，请参考这个链接：解决spring中不同配置文件中存在name或者id相同的bean可能引起的问题

profile

我们可以把不同环境的配置分别配置到单独的文件中，举个例子：

<beans profile="development"    xmlns="http://www.springframework.org/schema/beans"    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"    xmlns:jdbc="http://www.springframework.org/schema/jdbc"    xsi:schemaLocation="...">    <jdbc:embedded-database id="dataSource">        <jdbc:script location="classpath:com/bank/config/sql/schema.sql"/>        <jdbc:script location="classpath:com/bank/config/sql/test-data.sql"/>    </jdbc:embedded-database></beans>

<beans profile="production"    xmlns="http://www.springframework.org/schema/beans"    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"    xmlns:jee="http://www.springframework.org/schema/jee"    xsi:schemaLocation="...">    <jee:jndi-lookup id="dataSource" jndi-name="java:comp/env/jdbc/datasource"/></beans>

应该不必做过多解释了吧，看每个文件第一行的 profile=""。

当然，我们也可以在一个配置文件中使用：

<beans xmlns="http://www.springframework.org/schema/beans"    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"    xmlns:jdbc="http://www.springframework.org/schema/jdbc"    xmlns:jee="http://www.springframework.org/schema/jee"    xsi:schemaLocation="...">    <beans profile="development">        <jdbc:embedded-database id="dataSource">            <jdbc:script location="classpath:com/bank/config/sql/schema.sql"/>            <jdbc:script location="classpath:com/bank/config/sql/test-data.sql"/>        </jdbc:embedded-database>    </beans>    <beans profile="production">        <jee:jndi-lookup id="dataSource" jndi-name="java:comp/env/jdbc/datasource"/>    </beans></beans>

理解起来也很简单吧。

接下来的问题是，怎么使用特定的 profile 呢？Spring 在启动的过程中，会去寻找 “spring.profiles.active” 的属性值，根据这个属性值来的。那怎么配置这个值呢？

Spring 会在这几个地方寻找 spring.profiles.active 的属性值：操作系统环境变量、JVM 系统变量、web.xml 中定义的参数、JNDI。

最简单的方式莫过于在程序启动的时候指定：

-Dspring.profiles.active="profile1,profile2"

profile 可以激活多个

当然，我们也可以通过代码的形式从 Environment 中设置 profile：

AnnotationConfigApplicationContext ctx = new AnnotationConfigApplicationContext();ctx.getEnvironment().setActiveProfiles("development");ctx.register(SomeConfig.class, StandaloneDataConfig.class, JndiDataConfig.class);ctx.refresh(); // 重启

如果是 Spring Boot 的话更简单，我们一般会创建 application.properties、application-dev.properties、application-prod.properties 等文件，其中 application.properties 配置各个环境通用的配置，application-.properties 中配置特定环境的配置，然后在启动的时候指定 profile：

java -Dspring.profiles.active=prod -jar JavaDoop.jar

如果是单元测试中使用的话，在测试类中使用 @ActiveProfiles 指定，这里就不展开了。

工厂模式生成 Bean

请读者注意 factory-bean 和 FactoryBean 的区别。这节说的是前者，是说静态工厂或实例工厂，而后者是 Spring 中的特殊接口，代表一类特殊的 Bean，附录的下面一节会介绍 FactoryBean。

设计模式里，工厂方法模式分静态工厂和实例工厂，我们分别看看 Spring 中怎么配置这两个，来个代码示例就什么都清楚了。

静态工厂：

<bean id="clientService"    class="examples.ClientService"    factory-method="createInstance"/>

public class ClientService {    private static ClientService clientService = new ClientService();    private ClientService() {}    // 静态方法    public static ClientService createInstance() {        return clientService;    }}

实例工厂：

<bean id="serviceLocator" class="examples.DefaultServiceLocator">    <!-- inject any dependencies required by this locator bean --></bean><bean id="clientService"    factory-bean="serviceLocator"    factory-method="createClientServiceInstance"/><bean id="accountService"    factory-bean="serviceLocator"    factory-method="createAccountServiceInstance"/>

public class DefaultServiceLocator {    private static ClientService clientService = new ClientServiceImpl();    private static AccountService accountService = new AccountServiceImpl();    public ClientService createClientServiceInstance() {        return clientService;    }    public AccountService createAccountServiceInstance() {        return accountService;    }}

FactoryBean

FactoryBean 适用于 Bean 的创建过程比较复杂的场景，比如数据库连接池的创建。

public interface FactoryBean<T> {    T getObject() throws Exception;    Class<T> getObjectType();    boolean isSingleton();}

public class Person {     private Car car ;    private void setCar(Car car){ this.car = car;  }  }

我们假设现在需要创建一个 Person 的 Bean，首先我们需要一个 Car 的实例，我们这里假设 Car 的实例创建很麻烦，那么我们可以把创建 Car 的复杂过程包装起来：

public class MyCarFactoryBean implements FactoryBean<Car>{    private String make;     private int year ;        public void setMake(String m){ this.make =m ; }        public void setYear(int y){ this.year = y; }        public Car getObject(){       // 这里我们假设 Car 的实例化过程非常复杂，反正就不是几行代码可以写完的那种      CarBuilder cb = CarBuilder.car();            if(year!=0) cb.setYear(this.year);      if(StringUtils.hasText(this.make)) cb.setMake( this.make );       return cb.factory();     }        public Class<Car> getObjectType() { return Car.class ; }         public boolean isSingleton() { return false; }}

我们看看装配的时候是怎么配置的：

<bean class = "com.javadoop.MyCarFactoryBean" id = "car">  <property name = "make" value ="Honda"/>  <property name = "year" value ="1984"/></bean><bean class = "com.javadoop.Person" id = "josh">  <property name = "car" ref = "car"/></bean>

看到不一样了吗？id 为 “car” 的 bean 其实指定的是一个 FactoryBean，不过配置的时候，我们直接让配置 Person 的 Bean 直接依赖于这个 FactoryBean 就可以了。中间的过程 Spring 已经封装好了。

说到这里，我们再来点干货。我们知道，现在还用 xml 配置 Bean 依赖的越来越少了，更多时候，我们可能会采用 java config 的方式来配置，这里有什么不一样呢？

@Configuration public class CarConfiguration {     @Bean     public MyCarFactoryBean carFactoryBean(){       MyCarFactoryBean cfb = new MyCarFactoryBean();      cfb.setMake("Honda");      cfb.setYear(1984);      return cfb;    }    @Bean    public Person aPerson(){     Person person = new Person();      // 注意这里的不同    person.setCar(carFactoryBean().getObject());    return person;     } }

这个时候，其实我们的思路也很简单，把 MyCarFactoryBean 看成是一个简单的 Bean 就可以了，不必理会什么 FactoryBean，它是不是 FactoryBean 和我们没关系。

初始化 Bean 的回调

有以下四种方案：

<bean id="exampleInitBean" class="examples.ExampleBean" init-method="init"/>

public class AnotherExampleBean implements InitializingBean {    public void afterPropertiesSet() {        // do some initialization work    }}

@Bean(initMethod = "init")public Foo foo() {    return new Foo();}

@PostConstructpublic void init() {    }

销毁 Bean 的回调

<bean id="exampleInitBean" class="examples.ExampleBean" destroy-method="cleanup"/>

public class AnotherExampleBean implements DisposableBean {    public void destroy() {        // do some destruction work (like releasing pooled connections)    }}

@Bean(destroyMethod = "cleanup")public Bar bar() {    return new Bar();}

@PreDestroypublic void cleanup() {    }

ConversionService

既然文中说到了这个，顺便提一下好了。

最有用的场景就是，它用来将前端传过来的参数和后端的 controller 方法上的参数进行绑定的时候用。

像前端传过来的字符串、整数要转换为后端的 String、Integer 很容易，但是如果 controller 方法需要的是一个枚举值，或者是 Date 这些非基础类型（含基础类型包装类）值的时候，我们就可以考虑采用 ConversionService 来进行转换。

<bean id="conversionService"  class="org.springframework.context.support.ConversionServiceFactoryBean">  <property name="converters">    <list>      <bean class="com.javadoop.learning.utils.StringToEnumConverterFactory"/>    </list>  </property></bean>

ConversionService 接口很简单，所以要自定义一个 convert 的话也很简单。

下面再说一个实现这种转换很简单的方式，那就是实现 Converter 接口。

来看一个很简单的例子，这样比什么都管用。

public class StringToDateConverter implements Converter<String, Date> {    @Override    public Date convert(String source) {        try {            return DateUtils.parseDate(source, "yyyy-MM-dd", "yyyy-MM-dd HH:mm:ss", "yyyy-MM-dd HH:mm", "HH:mm:ss", "HH:mm");        } catch (ParseException e) {            return null;        }    }}

只要注册这个 Bean 就可以了。这样，前端往后端传的时间描述字符串就很容易绑定成 Date 类型了，不需要其他任何操作。

Bean 继承

在初始化 Bean 的地方，我们说过了这个：

RootBeanDefinition bd = getMergedLocalBeanDefinition(beanName);

这里涉及到的就是 <bean parent="" /> 中的 parent 属性，我们来看看 Spring 中是用这个来干什么的。

首先，我们要明白，这里的继承和 java 语法中的继承没有任何关系，不过思路是相通的。child bean 会继承 parent bean 的所有配置，也可以覆盖一些配置，当然也可以新增额外的配置。

Spring 中提供了继承自 AbstractBeanDefinition 的 ChildBeanDefinition 来表示 child bean。

看如下一个例子:

<bean id="inheritedTestBean" abstract="true" class="org.springframework.beans.TestBean">    <property name="name" value="parent"/>    <property name="age" value="1"/></bean><bean id="inheritsWithDifferentClass" class="org.springframework.beans.DerivedTestBean"        parent="inheritedTestBean" init-method="initialize">            <property name="name" value="override"/></bean>

parent bean 设置了 abstract="true" 所以它不会被实例化，child bean 继承了 parent bean 的两个属性，但是对 name 属性进行了覆写。

child bean 会继承 scope、构造器参数值、属性值、init-method、destroy-method 等等。

当然，我不是说 parent bean 中的 abstract = true 在这里是必须的，只是说如果加上了以后 Spring 在实例化 singleton beans 的时候会忽略这个 bean。

比如下面这个极端 parent bean，它没有指定 class，所以毫无疑问，这个 bean 的作用就是用来充当模板用的 parent bean，此处就必须加上 abstract = true。

<bean id="inheritedTestBeanWithoutClass" abstract="true">    <property name="name" value="parent"/>    <property name="age" value="1"/></bean>

方法注入

一般来说，我们的应用中大多数的 Bean 都是 singleton 的。singleton 依赖 singleton，或者 prototype 依赖 prototype 都很好解决，直接设置属性依赖就可以了。

但是，如果是 singleton 依赖 prototype 呢？这个时候不能用属性依赖，因为如果用属性依赖的话，我们每次其实拿到的还是第一次初始化时候的 bean。

一种解决方案就是不要用属性依赖，每次获取依赖的 bean 的时候从 BeanFactory 中取。这个也是大家最常用的方式了吧。怎么取，我就不介绍了，大部分 Spring 项目大家都会定义那么个工具类的。

另一种解决方案就是这里要介绍的通过使用 Lookup method。

lookup-method

我们来看一下 Spring Reference 中提供的一个例子：

package fiona.apple;// no more Spring imports!public abstract class CommandManager {    public Object process(Object commandState) {        // grab a new instance of the appropriate Command interface        Command command = createCommand();        // set the state on the (hopefully brand new) Command instance        command.setState(commandState);        return command.execute();    }    // okay... but where is the implementation of this method?    protected abstract Command createCommand();}

xml 配置 <lookup-method />：

<!-- a stateful bean deployed as a prototype (non-singleton) --><bean id="myCommand" class="fiona.apple.AsyncCommand" scope="prototype">    <!-- inject dependencies here as required --></bean><!-- commandProcessor uses statefulCommandHelper --><bean id="commandManager" class="fiona.apple.CommandManager">    <lookup-method name="createCommand" bean="myCommand"/></bean>

Spring 采用 CGLIB 生成字节码的方式来生成一个子类。我们定义的类不能定义为 final class，抽象方法上也不能加 final。

lookup-method 上的配置也可以采用注解来完成，这样就可以不用配置 <lookup-method /> 了，其他不变：

public abstract class CommandManager {    public Object process(Object commandState) {        MyCommand command = createCommand();        command.setState(commandState);        return command.execute();    }    @Lookup("myCommand")    protected abstract Command createCommand();}

注意，既然用了注解，要配置注解扫描：<context:component-scan base-package="com.javadoop" />

甚至，我们可以像下面这样：

public abstract class CommandManager {    public Object process(Object commandState) {        MyCommand command = createCommand();        command.setState(commandState);        return command.execute();    }    @Lookup    protected abstract MyCommand createCommand();}

上面的返回值用了 MyCommand，当然，如果 Command 只有一个实现类，那返回值也可以写 Command。

replaced-method

记住它的功能，就是替换掉 bean 中的一些方法。

public class MyValueCalculator {    public String computeValue(String input) {        // some real code...    }    // some other methods...}

方法覆写，注意要实现 MethodReplacer 接口：

public class ReplacementComputeValue implements org.springframework.beans.factory.support.MethodReplacer {    public Object reimplement(Object o, Method m, Object[] args) throws Throwable {        // get the input value, work with it, and return a computed result        String input = (String) args[0];        ...        return ...;    }}

配置也很简单：

<bean id="myValueCalculator" class="x.y.z.MyValueCalculator">    <!-- 定义 computeValue 这个方法要被替换掉 -->    <replaced-method name="computeValue" replacer="replacementComputeValue">        <arg-type>String</arg-type>    </replaced-method></bean><bean id="replacementComputeValue" class="a.b.c.ReplacementComputeValue"/>

arg-type 明显不是必须的，除非存在方法重载，这样必须通过参数类型列表来判断这里要覆盖哪个方法。

BeanPostProcessor

应该说 BeanPostProcessor 概念在 Spring 中也是比较重要的。我们看下接口定义：

public interface BeanPostProcessor {   Object postProcessBeforeInitialization(Object bean, String beanName) throws BeansException;   Object postProcessAfterInitialization(Object bean, String beanName) throws BeansException;}

看这个接口中的两个方法名字我们大体上可以猜测 bean 在初始化之前会执行 postProcessBeforeInitialization 这个方法，初始化完成之后会执行 postProcessAfterInitialization 这个方法。但是，这么理解是非常片面的。

首先，我们要明白，除了我们自己定义的 BeanPostProcessor 实现外，Spring 容器在启动时自动给我们也加了几个。如在获取 BeanFactory 的 obtainFactory() 方法结束后的 prepareBeanFactory(factory)，大家仔细看会发现，Spring 往容器中添加了这两个 BeanPostProcessor：ApplicationContextAwareProcessor、ApplicationListenerDetector。

我们回到这个接口本身，读者请看第一个方法，这个方法接受的第一个参数是 bean 实例，第二个参数是 bean 的名字，重点在返回值将会作为新的 bean 实例，所以，没事的话这里不能随便返回个 null。

那意味着什么呢？我们很容易想到的就是，我们这里可以对一些我们想要修饰的 bean 实例做一些事情。但是对于 Spring 框架来说，它会决定是不是要在这个方法中返回 bean 实例的代理，这样就有更大的想象空间了。

最后，我们说说如果我们自己定义一个 bean 实现 BeanPostProcessor 的话，它的执行时机是什么时候？

如果仔细看了代码分析的话，其实很容易知道了，在 bean 实例化完成、属性注入完成之后，会执行回调方法，具体请参见类 AbstractAutowireCapableBeanFactory#initBean 方法。

首先会回调几个实现了 Aware 接口的 bean，然后就开始回调 BeanPostProcessor 的 postProcessBeforeInitialization 方法，之后是回调 init-method，然后再回调 BeanPostProcessor 的 postProcessAfterInitialization 方法。

总结

按理说，总结应该写在附录前面，我就不讲究了。

在花了那么多时间后，这篇文章终于算是基本写完了，大家在惊叹 Spring 给我们做了那么多的事的时候，应该透过现象看本质，去理解 Spring 写得好的地方，去理解它的设计思想。

本文的缺陷在于对 Spring 预初始化 singleton beans 的过程分析不够，主要是代码量真的比较大，分支旁路众多。同时，虽然附录条目不少，但是庞大的 Spring 真的引出了很多的概念，希望日后有精力可以慢慢补充一些。

（全文完）

From: https://www.javadoop.com/post/spring-ioc

文章目录

• 前言
• 一、Java 虚拟机架构 (JVM Architecture)
  • 1.1 Class 文件 (字节码文件)
  • 1.2 类加载器子系统 (ClassLoader Subsystem)
  • 1.3 Java 虚拟机运行时数据区 (JVM Runtime Data Area)
  • 1.4 执行引擎 (Execution Engine)
  • 1.5 本地库接口 (JNI，Java Native Interface)
  • 1.6 本地方法库 (Native Method Library)
• 二、Java 虚拟机运行时数据区
  • 2.1 程序计数器 (Program Counter Register)
  • 2.2 Java 虚拟机栈 (JVM Stacks)
    • 2.2.1 局部变量表
    • 2.2.2 操作数栈
    • 2.2.3 动态连接
    • 2.2.4 方法出口
  • 2.3 本地方法栈 (Native Method Stacks)
  • 2.4 Java 堆 (Heap)
  • 2.5 方法区 (Method Area)
  • 2.6 运行时常量池 (Runtime Constant Pool)
• 总结

前言

之前写博客一直比较随性，主题也很随意，就是想到什么写什么，对什么感兴趣就写什么。虽然写起来无拘无束，自在随意，但也带来了一些问题，每次写完一篇后就要去纠结下一篇到底写什么，看来选择太多也不是好事儿，更重要的是不成体系的内容对读者也不够友好。所以以后的博客尽量按系列来写，不过偶尔也会穿插其他的内容。接下来一段时间我会把写博客的重点放在 JVM (Java Virtual Machine) 和 JUC (java util concurrent ) 上，对 Java 虚拟机和 Java 并发编程进行一系列的介绍，欢迎关注。

了解 JVM 是对 Java 开发人员的基本要求，JVM 的相关内容自然也成了现在 Java 程序员面试的重要考点。不过估计很多小伙伴和我一样，长时间醉心于 CRUD，却忘了去了解一下更底层、更基础的东西，殊不知这些才是决定你能在这条路上走多远的关键因素，那接下来我们就一起来深入学习一下看似神秘的 JVM 吧。JVM 总体来看内容还是很多的，我会把最重要的内容介绍给大家，不过如果你有时间和精力的话，还是推荐你去看一下《深入理解Java虚拟机》这本书，确实是有口皆碑。本系列文章也会引用很多此书的内容并加上我自己的理解，如果你坚持看下去的话，相信会有很大的收获。

首先对 JVM 做个简单的介绍，JVM 是 JDK 的一部分，《Java 虚拟机规范》(The Java Virtual Machine Specification) 是平行于《Java 语言规范》(The Java Language Specification)的一套独立的规范，不同的公司对其有不同的实现 (类似于一个接口被不同的类实现)，比较著名的 Java 虚拟机实现版本有 HotSpot、JRockit 和 J9 等。

本文分为两大部分，将分别为大家介绍 JVM 的整体架构和运行时数据区，这两部分的依据均是《Java 虚拟机规范》，而不针对任何特定的 JVM 具体实现版本。

一、Java 虚拟机架构 (JVM Architecture)

在我看来，不管学习什么样的知识或技术，首先要做的就是从全局上去认识它，这样才能避免盲人摸象，事倍功半的情况发生。既然要学习 JVM，就要先了解它的整体架构，于是我画了个 JVM 架构图来帮助大家认识它。

Java 虚拟机架构图

对 JVM 还不太了解的同学第一次看到这张花里胡哨的图肯定会一脸懵逼，不用怕，其实我们只需要重点理解并掌握其中一部分 (同时也是面试重点) 就好了，比如运行时数据区、垃圾收集器、内存分配策略和类加载机制等，类文件结构也可以学习一下，其他的稍作了解即可。既然本篇文章是要带领大家认识 JVM 架构的，那就先把图中各个部分都介绍一下吧 (注：本文只做介绍，让各位先对 JVM 有个整体的认识，本系列后续文章会做深入探讨)。

1.1 Class 文件 (字节码文件)

Java 之所以号称“一次编写，处处运行”，就是得益于虚拟机和 Class 文件 (注：CLass 文件、字节码文件和类文件是一个意思) 的组合机制。程序员并不需要自己去适配不同的操作系统，大家都知道我们平时编写的 java 代码在编译成 Class 文件后才能执行，而 Class 文件可以在任何操作系统上的 JVM 上执行，这样就做到了“平台无关性”。下面是一个最简单的 HelloWorld 程序及其对应的 Class 文件。

HelloWorld 程序及其编译后的 Class 文件

得益于 Class 文件，JVM 还可以做到“语言无关性”，也就是说不只有 Java 程序可以运行于 JVM 之上，很多其他语言例如最近在安卓开发者中大火的 Kotlin 语言，还有 Scala、Groovy 等语言也都是基于 JVM 平台的，这些语言的代码都可以编译成 Class 文件，然后在 JVM 上运行。

JVM提供的平台无关性和语言无关性

1.2 类加载器子系统 (ClassLoader Subsystem)

要执行 Class 文件就需要先将其加载进内存，这一工作正是由类加载器 (ClassLoader) 完成的，系统为我们提供了三种类加载器，分别是启动类加载器 (Bootstrap ClassLoader)、扩展类加载器 (Extension ClassLoader) 和应用程序类加载器 (Application ClassLoader)，如果有必要，我们也可以加入自定义的类加载器。类加载过程如下：

类加载过程

类加载过程分为加载、连接和初始化三个阶段，其中的连接阶段又分为验证、准备和解析三个阶段 (详细的类加载机制在后续文章中进行介绍)。

1.3 Java 虚拟机运行时数据区 (JVM Runtime Data Area)

这部分内容较多，放在本文第二部分单独进行介绍。

1.4 执行引擎 (Execution Engine)

字节码被加载进运行时数据区后，执行引擎会进行读取并执行，执行引擎主要包含以下模块：

• 解释器 (Interpreter)：相信大家很久以前就听过“计算机只认识0和1”这句话，时至今日，计算机依然只认识0和1，所以任何编程语言的代码最终都要转化成机器码 (二进制代码)才能执行，Java 也不例外，而解释器的工作正是将编译得到的字节码再转化成机器码，然后才能执行。正因为如此，Java 才被称为解释型语言，也正是因为边解释边执行的特点，Java 程序在执行时才会慢于 C++ 之类的编译型语言。
• 即时编译器 (JIT Compiler，just-in-time compiler)：即时编译器百度百科，为了弥补解释执行带来的速度劣势，JVM 引入了即时编译器，它的作用就是把热点代码，比如重复调用的方法和循环代码等，编译成机器码并存放在 code cache 中，这样之后再用到这些代码就不用重新解释执行了，可以提高程序运行效率。
• 垃圾收集器 (Garbage Collector)：Java 程序员可以不用手动释放内存，全是垃圾收集器的功劳，这也是 JVM 中尤其重要的内容，后续会有多篇文章对其进行介绍。

1.5 本地库接口 (JNI，Java Native Interface)

如果你经常看 JDK 源码的话，一定会注意到 native 这个关键词，被它修饰的方法是没有方法体的，是因为它调用了计算机本地的方法库 (通常是 C 或 C++ 代码)。JDK 源码中有很多类的方法，特别是一些需要操作计算机硬件的方法，都调用了本地方法库，毕竟与硬件打交道还是用 C 和 C++ 更方便，比如下面这些方法：

public static native Thread currentThread();

​
private native void open0(String name) throws FileNotFoundException;

1.6 本地方法库 (Native Method Library)

本地库接口所调用的对象正是位于这个库中，一般是位于计算机本地的 C 或 C++ 语言代码。

二、Java 虚拟机运行时数据区

Java 虚拟机运行时数据区是我们需要重点了解并熟悉的部分，因为这与我们写的程序息息相关，平时常见的 StackOverflowError 和 OutOfMemoryError 也几乎都是来自这个区域。说“几乎”是因为当本机直接内存不够用时也会抛出 OutOfMemoryError。如下图所示，程序计数器、Java 虚拟机栈和本地方法栈是线程私有的，堆和方法区是线程共享的，其中方法区又包含了运行时常量池。下面就对这个部分做个详细的介绍吧 (注：本部分引用内容来自《深入理解Java虚拟机》)。

Java 虚拟机运行时数据区

2.1 程序计数器 (Program Counter Register)

怕有些小伙伴不清楚，提示一下：下面这样的段落格式就是 Markdown 里的引用格式，，一般用于引用他人的文章或别处的内容。

程序计数器(Program Counter Register)是一块较小的内存空间，它可以看作是当前线程所执行的字节码的行号指示器。在Java虚拟机的概念里，字节码解释器工作时就是通过改变这个计数器 的值来选取下一条需要执行的字节码指令，它是程序控制流的指示器，分支、循环、跳转、异常处理、线程恢复等基础功能都需要依赖这个计数器来完成。

由于Java虚拟机的多线程是通过线程轮流切换、分配处理器执行时间的方式来实现的，在任何一个确定的时刻，一个处理器(对于多核处理器来说是一个内核)都只会执行一条线程中的指令。因此，为了线程切换后能恢复到正确的执行位置，每条线程都需要有一个独立的程序计数器，各条线程之间计数器互不影响，独立存储，我们称这类内存区域为“线程私有”的内存。

如果线程正在执行的是一个Java方法，这个计数器记录的是正在执行的虚拟机字节码指令的地址；如果正在执行的是本地 (Native) 方法，这个计数器值则应为空 (Undefined)。此内存区域是唯一一个在《Java虚拟机规范》中没有规定任何 OutOfMemoryError 情况的区域。

这里引用了《深入理解Java虚拟机》书中的内容，其实不难理解，程序计数器的作用就是保存线程的执行状态，引用部分的第三段中说“如果线程正在执行的是一个Java方法，这个计数器记录的是正在执行的虚拟机字节码指令的地址”，这个地址就是字节码执行到的位置。我们平时说的 Java 多线程上下文切换就需要程序计数器的辅助，当 CPU 从一个线程切换到另一个线程时，要从程序计数器中读取线程执行状态从而恢复现场。后面又说“如果执行的是本地 (Native)方法，这个计数器值为空(Undefined)”，这是为何呢？是因为本地方法执行的是 C / C++ 代码，在原生平台直接运行，也就不存在 Java 虚拟机的概念，自然也无法保存字节码指令地址，此时要想记录代码运行状态的话，只能使用原生 CPU 的 PC 寄存器。

2.2 Java 虚拟机栈 (JVM Stacks)

与程序计数器一样，Java虚拟机栈(Java Virtual Machine Stack)也是线程私有的，它的生命周期与线程相同。虚拟机栈描述的是 Java 方法执行的线程内存模型:每个方法被执行的时候，Java 虚拟机都 会同步创建一个栈帧(Stack Frame)用于存储局部变量表、操作数栈、动态连接、方法出口等信息。每一个方法被调用直至执行完毕的过程，就对应着一个栈帧在虚拟机栈中从入栈到出栈的过程。

局部变量表存放了编译期可知的各种Java虚拟机基本数据类型(boolean、byte、char、short、int、 float、long、double)、对象引用 (reference 类型，它并不等同于对象本身，可能是一个指向对象起始地址的引用指针，也可能是指向一个代表对象的句柄或者其他与此对象相关的位置) 和 returnAddress 类型(指向了一条字节码指令的地址)。

这些数据类型在局部变量表中的存储空间以局部变量槽 (Slot) 来表示，其中64位长度的 long 和 double 类型的数据会占用两个变量槽，其余的数据类型只占用一个。局部变量表所需的内存空间在编译期间完成分配，当进入一个方法时，这个方法需要在栈帧中分配多大的局部变量空间是完全确定的，在方法运行期间不会改变局部变量表的大小。请读者注意，这里说的“大小”是指变量槽的数量，虚拟机真正使用多大的内存空间 (譬如按照1个变量槽占用32个比特、64个比特，或者更多)来实现一个变量槽，这是完全由具体的虚拟机实现自行决定的事情。

在《Java虚拟机规范》中，对这个内存区域规定了两类异常状况：如果线程请求的栈深度大于虚拟机所允许的深度，将抛出 StackOverflowError 异常；如果 Java 虚拟机栈容量可以动态扩展，当栈扩展时无法申请到足够的内存会抛出 OutOfMemoryError 异常。

Java 虚拟机栈的内部结构如下图所示：

Java 虚拟机栈

2.2.1 局部变量表

局部变量表是存放方法参数和局部变量的区域。 局部变量没有准备阶段， 必须显式初始化。如果是非静态方法，则在 index[0] 位置上存储的是方法所属对象的实例引用，一个引用变量占 4 个字节，随后存储的是参数和局部变量。

2.2.2 操作数栈

操作数栈是个初始状态为空的桶式结构栈。在方法执行过程中， 会有各种指令往栈中写入和提取信息。JVM 的执行引擎是基于栈的执行引擎，其中的栈指的就是操作数栈。字节码指令集的定义都是基于栈类型的，栈的深度在方法元信息的 stack 属性中。下面使用 i++ 和 ++i 的区别来帮助理解操作数栈：

i++ 和 ++i 的区别：

1. i++：从局部变量表取出 i 并压入操作栈，然后对局部变量表中的 i 自增 1，将操作栈栈顶值取出使用，最后，使用栈顶值更新局部变量表，如此线程从操作栈读到的是自增之前的值。
2. ++i：先对局部变量表的 i 自增 1，然后取出并压入操作栈，再将操作栈栈顶值取出使用，最后，使用栈顶值更新局部变量表，线程从操作栈读到的是自增之后的值。

之所以说 i++ 不是原子操作，即使使用 volatile 修饰也不是线程安全，就是因为，可能 i 被从局部变量表（内存）取出，压入操作栈（寄存器），操作栈中自增，使用栈顶值更新局部变量表（寄存器更新写入内存），其中分为 3 步，volatile 保证可见性，保证每次从局部变量表读取的都是最新的值，但可能这 3 步可能被另一个线程的 3 步打断，产生数据互相覆盖问题，从而导致 i 的值比预期的小。

2.2.3 动态连接

每个栈帧中包含一个在常量池中对当前方法的引用， 目的是支持方法调用过程的动态连接。

2.2.4 方法出口

方法执行时有两种退出情况：

1. 正常退出，即正常执行到任何方法的返回字节码指令，如 RETURN、IRETURN、ARETURN 等；
2. 异常退出。

无论何种退出情况，都将返回至方法当前被调用的位置。方法退出的过程相当于弹出当前栈帧，退出可能有三种方式：

1. 返回值压入上层调用栈帧。
2. 异常信息抛给能够处理的栈帧。
3. 程序计数器指向方法调用后的下一条指令。

2.3 本地方法栈 (Native Method Stacks)

本地方法栈与虚拟机栈所发挥的作用是非常相似的，其区别只是虚拟机栈为虚拟机执行 Java 方法 (也就是字节码)服务，而本地方法栈则是为虚拟机使用到的本地 (Native) 方法服务。

《Java虚拟机规范》对本地方法栈中方法使用的语言、使用方式与数据结构并没有任何强制规定，因此具体的虚拟机可以根据需要自由实现它，甚至有的Java虚拟机 (譬如Hot-Spot虚拟机)直接就把本地方法栈和虚拟机栈合二为一。与虚拟机栈一样，本地方法栈也会在栈深度溢出或者栈扩展失 败时分别抛出 StackOverflowError 和OutOfMemoryError 异常。

这部分比较好理解，就不做解析了。

2.4 Java 堆 (Heap)

对于Java应用程序来说，Java 堆 (Java Heap)是虚拟机所管理的内存中最大的一块。Java 堆是被所有线程共享的一块内存区域，在虚拟机启动时创建。此内存区域的唯一目的就是存放对象实例，Java 世界里“几乎”所有的对象实例都在这里分配内存。Java 堆是垃圾收集器管理的内存区域，因此也常被称为“GC 堆”。

根据《Java虚拟机规范》的规定，Java堆可以处于物理上不连续的内存空间中，但在逻辑上它应该被视为连续的，这点就像我们用磁盘空间去存储文件一样，并不要求每个文件都连续存放。但对于大 对象(典型的如数组对象)，多数虚拟机实现出于实现简单、存储高效的考虑，很可能会要求连续的内存空间。

Java 堆既可以被实现成固定大小的，也可以是可扩展的，不过当前主流的Java虚拟机都是按照可扩展来实现的(通过参数-Xmx和-Xms设定)。如果在 Java 堆中没有内存完成实例分配，并且堆也无法再扩展时，Java 虚拟机将会抛出 OutOfMemoryError 异常。

Java 堆的唯一作用就是存放对象实例，这也是垃圾收集器最关注的内存区域，因为大多数对象实例的存活时间都很短，比如在方法内部创建的实例在方法执行完之后就没有存在价值了，所以这个区域的垃圾回收性价比最高。关于垃圾回收的详细内容，见后续文章。

2.5 方法区 (Method Area)

方法区 (Method Area)与 Java 堆一样，是各个线程共享的内存区域，它用于存储已被虚拟机加载 的类型信息、常量、静态变量、即时编译器编译后的代码缓存等数据。虽然《Java虚拟机规范》中把方法区描述为堆的一个逻辑部分，但是它却有一个别名叫作“非堆”(Non-Heap)，目的是与 Java 堆区分开来。

说到方法区，不得不提一下“永久代”这个概念，尤其是在JDK 8以前，许多 Java 程序员都习惯在 HotSpot 虚拟机上开发、部署程序，很多人都更愿意把方法区称呼为“永久代”(Permanent Generation)，或将两者混为一谈。本质上这两者并不是等价的，因为仅仅是当时的 HotSpot 虚拟机设计团队选择把收集器的分代设计扩展至方法区，或者说使用永久代来实现方法区而已，这样使得 HotSpot的垃圾收集器能够像管理Java堆一样管理这部分内存，省去专门为方法区编写内存管理代码的工作。但是对于其他虚拟机实现，譬如 BEA JRockit、IBM J9 等来说，是不存在永久代的概念的。原则上如何实现方法区属于虚拟机实现细节，不受《Java虚拟机规范》管束，并不要求统一。但现在回头来看，当年使用永久代来实现方法区的决定并不是一个好主意，这种设计导致了 Java 应用更容易遇到 内存溢出的问题(永久代有-XX:M axPermSize 的上限，即使不设置也有默认大小，而 J9 和 JRockit 只要没有触碰到进程可用内存的上限，例如32位系统中的4GB限制，就不会出问题 )，而且有极少数方法 (例如 String :: intern() ) 会因永久代的原因而导致不同虚拟机下有不同的表现。当 Oracle 收购 BEA 获得了 JRockit 的所有权后，准备把 JRockit 中的优秀功能，譬如 Java Mission Control 管理工具，移植到 HotSpot 虚拟机时，但因为两者对方法区实现的差异而面临诸多困难。考虑到 HotSpot 未来的发展，在 JDK 6 的 时候 HotSpot 开发团队就有放弃永久代，逐步改为采用本地内存 (Native Memory) 来实现方法区的计划了，到了JDK 7 的 HotSpot，已经把原本放在永久代的字符串常量池、静态变量等移出，而到了 JDK 8，终于完全废弃了永久代的概念，改用与 JRockit、J9 一样在本地内存中实现的元空间(Metaspace)来代替，把JDK 7中永久代还剩余的内容(主要是类型信息)全部移到元空间中。

《Java虚拟机规范》对方法区的约束是非常宽松的，除了和 Java 堆一样不需要连续的内存和可以选择固定大小或者可扩展外，甚至还可以选择不实现垃圾收集。相对而言，垃圾收集行为在这个区域的确是比较少出现的，但并非数据进入了方法区就如永久代的名字一样“永久”存在了。这区域的内存回收目标主要是针对常量池的回收和对类型的卸载，一般来说这个区域的回收效果比较难令人满意，尤其是类型的卸载，条件相当苛刻，但是这部分区域的回收有时又确实是必要的。

根据《Java虚拟机规范》的规定，如果方法区无法满足新的内存分配需求时，将抛出 OutOfMemoryError 异常。

这部分引用内容对方法区的介绍十分全面，切记不要将方法区和永久代混为一谈，从JDK 8 以后已经没有永久代的概念了。

2.6 运行时常量池 (Runtime Constant Pool)

运行时常量池 (Runtime Constant Pool) 是方法区的一部分。Class 文件中除了有类的版本、字段、方法、接口等描述信息外，还有一项信息是常量池表 (Constant Pool Table)，用于存放编译期生成的各种字面量与符号引用，这部分内容将在类加载后存放到方法区的运行时常量池中。

既然运行时常量池是方法区的一部分，自然受到方法区内存的限制，当常量池无法再申请到内存 时会抛出OutOfMemoryError异常。

常量池是为了避免频繁的创建和销毁对象而影响系统性能，其实现了对象的共享。

总结

本文作为 Java 虚拟机系列的第一篇文章，为大家介绍了 Java 虚拟机的整体架构和运行时数据区，相信大家对 JVM 已经有了整体的认识。但这还远远不够，JVM 还有更多而内容和细节等着我们去探索，后续文章敬请期待。

最后是参考文章和文献：

• 周志明《深入理解Java虚拟机：JVM高级特性与最佳实践》(强烈推荐)
• Java虚拟机规范
• Java内存区域（运行时数据区域）和内存模型（JMM
• Architecture of JVM Java Virtual Machine
• 编译型与解释型的区别
• JVM总括三-字节码、字节码指令、JIT编译执行
• 彻底弄懂java中的常量池

文章目录

• 前言
• 一、需要进行垃圾收集的内存区域
• 二、判断对象是否可回收的方法
  • 2.1 引用计数法
  • 2.2 可达性分析法
• 三、垃圾收集算法介绍
  • 3.1 标记-清除算法
  • 3.2 标记-复制算法
  • 3.3 标记-整理算法
  • 3.4 分代收集算法
• 四、JVM 的内存分配和垃圾收集机制
  • 4.1 JVM 堆内存的划分
  • 4.2 分代收集原理
    • 4.2.1 新生代中对象的分配与回收
    • 4.2.2 对象晋升老年代
• 总结

前言

上篇文章已经给大家介绍了 JVM 的架构和运行时数据区 (内存区域)，本篇文章将给大家介绍 JVM 的重点内容——垃圾收集。众所周知，相比 C / C++ 等语言，Java 可以省去手动管理内存的繁琐操作，很大程度上解放了 Java 程序员的生产力，而这正是得益于 JVM 的垃圾收集机制和内存分配策略。我们平时写程序时并感知不到这一点，但是如果是在生产环境中，JVM 的不同配置对于服务器性能的影响是非常大的，所以掌握 JVM 调优是高级 Java 工程师的必备技能。正所谓“基础不牢，地动山摇”，在这之前我们先来了解一下底层的 JVM 垃圾收集机制。

既然要介绍垃圾收集机制，就要搞清楚以下几个问题：

1. 哪些内存区域需要进行垃圾收集？
2. 如何判断对象是否可回收？
3. 新的对象是如何进行内存分配的？
4. 如何进行垃圾收集？

本文将按以下行文结构展开，对上述问题一一解答。

1. 需要进行垃圾收集的内存区域；
2. 判断对象是否可回收的方法；
3. 主流的垃圾收集算法介绍；
4. JVM 的内存分配与垃圾收集机制。

下面开始正文，还是图文并茂的老配方，走起。

一、需要进行垃圾收集的内存区域

先来回顾一下 JVM 的运行时数据区：

JVM 运行时数据区

其中程序计数器、Java 虚拟机栈和本地方法栈都是线程私有的，与其对应的线程是共生关系，随线程而生，随线程而灭，栈中的栈帧也随着方法的进入和退出井然有序地进行入栈和出栈操作。所以这几个区域的内存分配和回收都是有很大确定性的，在方法结束或线程结束时，内存也会随之释放，因此也就不需要考虑这几个区域的内存回收问题了。

而堆和方法区就不一样了，Java 的对象几乎都是在堆上创建出来的，方法区则存储了被虚拟机加载的类型信息、常量、静态变量、即时编译器编译后的代码缓存等数据，方法区中的运行时常量池则存放了各种字面量与符号引用，上述的这些数据大部分都是在运行时才能确定的，所以需要进行动态的内存管理。

还要说明一点，JVM 中的垃圾收集器的最主要的关注对象是 Java 堆，因为这里进行垃圾收集的“性价比”是最高的，尤其是在新生代 (后文对分代算法进行介绍) 中的垃圾收集，一次就可以回收 70% - 99% 的内存。而方法区由于垃圾收集判定条件，尤其是类型卸载的判定条件相当苛刻，其回收性价比是非常低的，因此有些垃圾收集器就干脆不支持或不完全支持方法区的垃圾收集，比如 JDK 11 中的 ZGC 收集器就不支持类型卸载。

二、判断对象是否可回收的方法

2.1 引用计数法

引用计数法的实现很简单，在对象中添加一个引用计数器，每当有一个地方引用它时，计数器值就加一；当引用失效时，计数器值就减一；任何时刻计数器为零的对象就是不可能再被使用的。大部分情况下这个方法是可以发挥作用的，但是在存在循环引用的情况下，引用计数法就无能为力了。比如下面这种情况：

public class Student {            public Student friend = null;      public static void test() {        Student a = new Student();        Student b = new Student();        a.friend = b;        b.friend = a;        a = null;        b = null;        System.gc();    }}

上述代码创建了 a 和 b 两个 Student 实例，并把它们各自的 friend 字段赋值为对方，除此之外，这两个对象再无任何引用，然后将它们都赋值为 null，在这种情况下，这两个对象已经不可能再被访问，但是它们因为互相引用着对方，导致它们的引用计数都不为零，引用计数算法也就无法回收它们。如下图所示：

循环引用

但是在 Java 程序中，a 和 b 是可以被回收的，因为 JVM 并没有使用引用计数法判定对象是否可回收，而是采用了可达性分析法。

2.2 可达性分析法

这个算法的基本思路就是通过一系列称为“GC Roots”的根对象作为起始节点集 (GC Root Set)，从这些节点开始，根据引用关系向下搜索，搜索过程所走过的路径称为“引用链” (Reference Chain)，如果某个对象到GC Roots间没有任何引用链相连，则说明此对象不再被使用，也就可以被回收了。要进行可达性分析就需要先枚举根节点 (GC Roots)，在枚举根节点过程中，为防止对象的引用关系发生变化，需要暂停所有用户线程 (垃圾收集之外的线程)，这种暂停全部用户线程的行为被称为 (Stop The World)。可达性分析法如下图所示：

可达性分析法

图中绿色的都是位于 GC Root Set 中的 GC Roots，所有与其有关联的对象都是可达的，被标记为蓝色，而所有与其没有任何关联的对象都是不可达的，被标记为灰色。即使是不可达对象，也并非一定会被回收，如果该对象同时满足以下几个条件，那么它仍有“逃生”的可能：

1. 该对象有重写的 finalize()方法 (Object 类中的方法)；
2. finalize()方法中将其自身链接到了引用链上；
3. JVM 此前没有调用过该对象的finalize()方法 (因为 JVM 在收集可回收对象时会调用且仅调用一次该对象的finalize()方法)。

不过由于finalize()方法的运行代价高昂，不确定性大，且无法保证各个对象的调用顺序，所以并不推荐使用。那么 GC Roots 又是何方神圣呢？在 Java 语言中，固定可作为GC Roots的对象包括以下几种：

1. 在虚拟机栈 (栈帧中的本地变量表) 中引用的对象，比如各个线程被调用的方法堆栈中使用到的参数、局部变量、临时变量等。
2. 在方法区中类静态属性引用的对象，比如Java类的引用类型静态变量。
3. 在方法区中常量引用的对象，比如字符串常量池(String Table)里的引用。
4. 在本地方法栈中JNI (即通常所说的Native方法) 引用的对象。
5. Java虚拟机内部的引用，如基本数据类型对应的Class对象，一些常驻的异常对象 (比如
   NullPointExcepiton、OutOfMemoryError) 等，还有系统类加载器。
6. 所有被同步锁 (synchronized关键字) 持有的对象。
7. 反映Java虚拟机内部情况的 JM XBean、JVM TI 中注册的回调、本地代码缓存等。

三、垃圾收集算法介绍

3.1 标记-清除算法

标记-清除算法的思想很简单，顾名思义，该算法的过程分为标记和清除两个阶段：首先标记出所有需要回收的对象，其中标记过程就是使用可达性分析法判断对象是否属于垃圾的过程。在标记完成后，统一回收掉所有被标记的对象，也可以反过来，标记存活的对象，统一回收所有未被标记的对象。示意图如下：

标记清除算法

这个算法虽然很简单，但是有两个明显的缺点：

1. 执行效率不稳定。如果 Java 堆中包含大量对象，而且其中大部分是需要被回收的，这时必须进行大量标记和清除的动作，导致标记和清除两个过程的执行效率都随对象数量增长而降低;
2. 导致内存空间碎片化。标记、清除之后会产生大量不连续的内存碎片，空间碎片太多可能会导致当以后在程序运行过程中需要分配较大对象时无法找到足够的连续内存而不得不提前触发另一次垃圾收集动作，非常影响程序运行效率。

3.2 标记-复制算法

标记-复制算法常简称复制算法，这一算法正好解决了标记-清除算法在面对大量可回收对象时执行效率低下的问题。其实现方法也很易懂：在可用内存中划分出两块大小相同的区域，每次只使用其中一块，另一块保持空闲状态，第一块用完的时候，就把存活的对象全部复制到第二块区域，然后把第一块全部清空。如下图所示：

标记-复制算法

这个算法很适合用于对象存活率低的情况，因为它只关注存活对象而无需理会可回收对象，所以 JVM 中新生代的垃圾收集正是采用的这一算法。但是其缺点也很明显，每次都要浪费一半的内存，未免太过奢侈，不过新生代有更精细的内存划分，比较好地解决了这个问题，见下文。

3.3 标记-整理算法

这个算法完美解决了标记-清除算法的空间碎片化问题，其标记过程与“标记-清除”算法一样，但后续步骤不是直接对可回收对象进行清理，而是让所有存活的对象都向内存空间一端移动，然后直接清理掉边界以外的内存。

标记整理算法

这个算法虽然可以很好地解决空间碎片化问题，但是每次垃圾回收都要移动存活的对象，还要对引用这些对象的地方进行更新，对象移动的操作也需要全程暂停用户线程 (Stop The World)。

3.4 分代收集算法

与其说是算法，不如说是理论。如今大多数虚拟机的实现版本都遵循了“分代收集”的理论进行设计，这个理论可以看作是经验之谈，因为开发人员在开发过程中发现了 JVM 中存活对象的数量和它们的年龄之间有着某种规律，如下图：

JVM 中存活对象数量与年龄之间的关系

在此基础上，人们得出了以下假说：

1. 绝大多数对象都是朝生夕灭的。
2. 熬过越多次垃圾收集过程的对象就越难以消亡。

根据这两个假说，可以把 JVM 的堆内存大致分为新生代和老年代，新生代对象大多存活时间短，每次回收时只关注如何保留少量存活而不是去标记那些大量将要被回收的对象，就能以较低代价回收到大量的空间，所以这一区域一般采用标记-复制算法进行垃圾收集，频率比较高。而老年代则是一些难以消亡的对象，可以采用标记-清除和标记整理算法进行垃圾收集，频率可以低一些。

按照 Hotspot 虚拟机的实现，针对新生代和老年代的垃圾收集又分为不同的类型，也有不同的名词，如下：

1. 部分收集 (Partial GC)：指目标不是完整收集整个Java堆的垃圾收集，其中又分为:

• 新生代收集 (Minor GC / Young GC)：指目标只是新生代的垃圾收集。

• 老年代收集 (Major GC / Old GC)：指目标只是老年代的垃圾收集，目前只有CMS收集器的并发收集阶段是单独收集老年代的行为。

• 混合收集 (Mixed GC)：指目标是收集整个新生代以及部分老年代的垃圾收集，目前只有G1收集器会有这种行为。

2. 整堆收集 (Full GC)：收集整个Java堆和方法区的垃圾收集。

人们经常会混淆 Major GC 和 Full GC，不过这也有情可原，因为这两种 GC 行为都包含了老年代的垃圾收集，而单独的老年代收集 (Major GC) 又比较少见，大多数情况下只要包含老年代收集，就会是整堆收集 (Full GC)，不过还是分得清楚一点比较好哈。

四、JVM 的内存分配和垃圾收集机制

经过前面的铺垫，现在终于可以一窥 JVM 的内存分配和垃圾收集机制的真面目了。

4.1 JVM 堆内存的划分

JVM 堆内存划分

Java 堆是 JVM 所管理的内存中最大的一块，也是垃圾收集器的管理区域。大多数垃圾收集器都会将堆内存划分为上图所示的几个区域，整体分为新生代和老年代，比例为 1 : 2，新生代又进一步分为 Eden、From Survivor 和 To Survivor，默认比例为 8 : 1 : 1，请注意，可通过 SurvivorRatio 参数进行设置。请注意，从 JDK 8 开始，JVM 中已经不再有永久代的概念了。Java 堆上的无论哪个区域，存储的都只能是对象的实例，将Java 堆细分的目的只是为了更好地回收内存，或者更快地分配内存。

4.2 分代收集原理

4.2.1 新生代中对象的分配与回收

大多数情况下，对象优先在新生代 Eden 区中分配，当 Eden 区没有足够空间进行分配时，虚拟机将发起一次 Minor GC。Eden、From Survivor 和 To Survivor 的比例为 8 : 1 : 1，之所以按这个比例是因为绝大多数对象都是朝生夕灭的，垃圾收集时 Eden 存活的对象数量不会太多，Survivor 空间小一点也足以容纳，每次新生代中可用内存空间为整个新生代容量的90% (Eden 的 80% 加上 To Survivor 的 10%)，只有From Survivor 空间，即 10% 的新生代是会被“浪费”的。不会像原始的标记-复制算法那样浪费一半的内存空间。From Survivor 和 To Survivor 的空间并不是固定的，而是在 S0 和 S1 之间动态转换的，第一次 Minor GC 时会选择 S1 作为 To Survivor，并将 Eden 中存活的对象复制到其中，并将对象的年龄加1，注意新生代使用的垃圾收集算法是标记-复制算法的改良版。下面是示意图，请注意其中第一步的变色是为了醒目，虚拟机只做了标记存活对象的操作。

第一次 Minor GC 示意图

在后续的 Minor GC 中，S0 和 S1会交替转化为 From Survivor 和 To Survivor，Eden 和 From Survivor 中的存活对象会复制到 To Survivor 中，并将年龄加 1。如下图所示：

后续 Minor GC 示意图

4.2.2 对象晋升老年代

在以下这些情况下，对象会晋升到老年代。

1. 长期存活对象将进入老年代

对象在 Survivor 区中每熬过一次Minor GC，年龄就增加1岁，当它的年龄增加到一定程度 (默认为15)，就会被晋升到老年代中。对象晋升老年代的年龄阈值，可以通过参数 -XX:MaxTenuringThreshold 设置。

长期存活对象晋升老年代示意图

2. 大对象可以直接进入老年代

对于大对象，尤其是很长的字符串，或者元素数量很多的数组，如果分配在 Eden 中，会很容易过早占满 Eden 空间导致 Minor GC，而且大对象在 Eden 和两个 Survivor 之间的来回复制也还会有很大的内存复制开销。所以我们可以通过设置 -XX:PretenureSizeThreshold 的虚拟机参数让大对象直接进入老年代。

3. 动态对象年龄判断

为了能更好地适应不同程序的内存状况，HotSpot 虚拟机并不是永远要求对象的年龄必须达到 -XX:MaxTenuringThreshold 才能晋升老年代，如果在 Survivor 空间中相同年龄所有对象大小的总和大于 Survivor 空间的一半，年龄大于或等于该年龄的对象就可以直接进入老年代，无须等到 -XX:MaxTenuringThreshold 中要求的年龄。

4. 空间分配担保 (Handle Promotion)

当 Survivor 空间不足以容纳一次 Minor GC 之后存活的对象时，就需要依赖其他内存区域 (实际上大多数情况下就是老年代) 进行分配担保。在发生 Minor GC 之前，虚拟机必须先检查老年代最大可用的连续空间是否大于新生代所有对象总空间，如果这个条件成立，那这一次 Minor GC 可以确保是安全的。如果不成立，则虚拟机会先查看 - XX:HandlePromotionFailure 参数的设置值是否允许担保失败 (Handle Promotion Failure)；如果允许，那会继续检查老年代最大可用的连续空间是否大于历次晋升到老年代对象的平均大小，如果大于，将尝试进行一次 Minor GC，尽管这次 Minor GC 是有风险的；如果小于，或者-XX: HandlePromotionFailure设置不允许冒险，那这时就要改为进行一次 Full GC。

总结

本文介绍了 JVM 的垃圾收集机制，并用大量图片和动图来帮助大家理解，如有错误，欢迎指正。后续文章会继续介绍 JVM 中的各种垃圾收集器，包括最前沿的 ZGC 和 Shenandoah 收集器，是 JVM 领域的最新科技成果，敬请期待。

最后是参考文章：

• 《深入理解Java虚拟机》
• Minor GC vs Major GC vs Full GC
• How Does Garbage Collection Work in Java?
• Major GC和Full GC的区别是什么？触发条件呢？
• 面试题：JVM，GC垃圾回收机制

前言

Java 语言和 JVM 在不断迭代发展的同时，垃圾收集器也在不断地进化，从最初的的单线程收集器 Serial，到后来的并行收集器 Parallel 和并发收集器 CMS、G1，再到垃圾收集器最前沿成果——超低延迟的 Shenandoah 和 ZGC，还有不做垃圾收集的垃圾收集器 Epsilon (是的你没有看错)，正是有了这些垃圾收集器的存在，Java 开发者才得以从繁琐的手动管理中解放出来。下面将为大家一一介绍这些垃圾收集器，全文采用“总-分”结构，先总体认识一下所有的垃圾收集器，在逐个进行介绍。

一、垃圾收集器汇总

下图就是 HotSpot 虚拟机上的已商用的垃圾收集器的关系图 (此图并不包含 Shenandoah 和 ZGC，因为这两者目前都还处于实验阶段，且没有遵循经典的分代收集理论，另外的 Epsilon 也不是常规的垃圾收集器，因此也没出现在此图上)。

HotSpot 虚拟机的垃圾收集器

图中的连线表示两个垃圾收集器之间可以搭配使用，请注意，JDK 9 已不再支持 Serial + CMS 和 ParNew + Serial Old 的搭配组合。如果觉得数量太多不好记的话，可以把上图中的五个垃圾收集器分为以下三大类：

1. Serial 类：新生代版本为 Serial，老年代版本为 Serial Old，这两个都是单线程垃圾收集器。另外，ParNew 相比 Serial 只是增加了多线程并行收集的功能，并无其他太大差别。
2. Parallel 类：包括 Parallel Scavenge 和 Parallel Old，多线程并行垃圾收集器经典组合，这个组合更注重于提高程序的吞吐量。
3. 并发收集器：CMS 和 G1都可以并发进行垃圾收集，其中 CMS 只适用于老年代，而 G1 则横跨新生代和老年代。

并发 (concurrent)与并行 (parallel)：这里所说的并发与并行的概念和操作系统里的概念有所不同，这里的并发是指垃圾收集线程和用户线程可以同时执行，而并行是指多个垃圾收集线程同时执行，但用户线程必须暂停。

除了上图这些经典的垃圾收集器，还有一些目前尚处于试验阶段的黑科技收集器，这部分仅做了解即可，万一面试的时候扯到了，还能顺带装一波逼。OracleJDK 11 新加入了 ZGC 收集器(目前还处于实验阶段)，OpenJDK 12 中也加入了 其独有的 Shenandoah 收集器 (也处于实验阶段)，OracleJDK 和 OpenJDK 的区别这里就不细说了。这两款垃圾收集器都以超低延迟为卖点，也就是尽量缩短垃圾收集时用户线程的暂停 (Stop The World)的时间，这两款收集器都宣称可以把垃圾收集的停顿时间控制在 10 毫秒以内，比之前最牛X的G1的延迟还要短。最后还有适用于微服务领域的 Epsilon，下面就为大家一一介绍这些琳琅满目、五花八门的垃圾收集器。

二、垃圾收集器详解

2.1 新生代收集器

2.1.1 Serial 收集器

Serial 收集器是最基础、历史最悠久的垃圾收集器，在 JDK 1.3.1 之前是 HotSpot 虚拟机新生代收集器的唯一选择。既然如此，也不能指望它有多么强大的功能了，这是一款单线程收集器，不仅只有一个垃圾收集线程，更难受的是它在进行垃圾收集时必须暂停所有用户线程，也就是说垃圾收集时需要全程 “Stop The World”，如图：

Serial / Serial Old 搭配的垃圾收集示意图

可见 Serial 在进行垃圾收集是必须“Stop The World”，而且其单线程的收集效率并不高，可能造成用户程序的长时间停顿。上篇文章已经给大家介绍过了新生代和老年代的概念，接下来补充一下图中安全点的概念：

安全点 (safepoint)：安全点是代码指令中特定的位置，这些位置记录着栈和寄存器里那些位置是引用，这样收集器在扫描垃圾对象时就不需要一个不漏地从方法区等 GC Roots 开始查找。安全点位置一般选在方法调用、循环跳转和异常跳转的代码指令处，因为这些位置的代码可以“长时间运行”。

2.1.2 ParNew 收集器

ParNew 收集器实质上就是 Serial 收集器的多线程版本，这也是它的唯一优势，除了同时使用多线程进行垃圾收集之外，其他的行为包括 Serial 所有可用的控制参数 (比如 -XX:SurvivorRatio，-XX:PretenureSizeThreshold，-XX:HandlePromotionFailure等)，还垃圾收集算法、Stop The World、对象分配规则、回收策略等都与 Serial 收集器完全一致。这两个收集器的底层代码大部分也是相通的。

ParNew / Serial Old 搭配的垃圾收集示意图

可以使用 -XX:+/-UseParNewGC选项来强制指定或禁用 ParNew 收集器，ParNew 还有一个特点，就是在使用 -XX:UseConcMarkSweepGC 参数激活 CMS 收集器后，新生代会默认使用 ParNew 收集器。

2.1.3 Parallel Scavenge 收集器

Parallel Scavenge 收集器也是一款作用于新生代、基于标记-复制算法的多线程并行垃圾收集器，与 ParNew 有很多相似之处。相比 CMS、G1、Shenandoah 和ZGC 这些致力于降低停顿时间，也就是低延迟的收集器，Parallel Scavenge 是吞吐量 (throughput)优先的收集器，吞吐量是指 CPU 用于运行用户程序的时间与 CPU 总消耗时间的比值：

吞吐量计算表达式

低延迟和高吞吐量的收集器有着不同的适用场景，前者适用于与用户交互较多或需要保证服务器响应质量的场景，低延迟可以带来良好的用户体验，而高吞吐量可以让 CPU 把更多的时间用在运行用户程序上面，可以更快完成任务，适用于交互性不强的后台运算场景。Parallel Scavenge 提供了两个参数用于精确控制吞吐量，分别是控制最大垃圾收集停顿时间的 -XX:MaxGCPauseMillis参数和直接设置吞吐量大小的 -XX:GCTimeRatio。

Parallel Scavenge 还有一个比较特色的开关参数：-XX:+UseAdaptiveSizePolicy，激活这个参数后，会开启自适应策略，也就是无需我们手动设置新生代大小 (-Xmn)、Eden 与 Survivor 的比例 (-XX:SurvivorRatio)和直接晋升老年代对象大小（-XX:PretenureSizeThreshold)，虚拟机会根据系统运行状态并收集性能监控信息，动态调整这些参数以提供最合适的停顿时间或最大的吞吐量。

2.2 老年代收集器

2.2.1 Serial Old 收集器

这就是 Serial 的老年代版本，也是单线程收集器，使用标记-整理算法，是 Serial 的黄金搭档：

Serial / Serial Old 搭配的垃圾收集示意图

这个搭档主要用在客户端模式下，除此之外，Serial Old 还有两个用途，那就是和 JDK 5 及之前的 Parallel Scavenge搭配使用，以及作为 CMS 收集器失败之后的备胎。

2.2.2 Parallel Old 收集器

这个是 Parallel Scavenge 的老年代版本，但是直到 JDK 6 才正式提供，之前的 Parallel Scavenge 只能和单线程的 Serial Old 搭配使用，完全发挥不了其优势，Parallel Old 出现后，“吞吐量优先”收集器终于也有了黄金搭档：

Parallel Scavenge / Parallel Old 搭配的垃圾收集过程

2.2.3 CMS 收集器

CMS (Concurrent Mark Sweep) 收集器是一款致力于获取最短停顿时间的收集器，从它的名字中可以看出这款收集器有两个重要特点：一，这是一款可以并发进行垃圾收集的收集器；二，这款收集器是基于标记清除-算法的。它的运作过程相对于之前不能并发的垃圾收集器更加复杂，大体分为以下四个步骤：

1. 初始标记 (CMS initial mark)

这一步仅仅是标记一下与 GC Roots 直接关联的对象，虽然不是并发执行，但是速度很快，用户程序会有短暂的暂停。

2. 并发标记 (CMS concurrent mark)

这一步比较耗时，需要遍历所有与 GC Roots 有关联的对象，但是可以与用户线程并发执行，所以对用户程序影响不大。

3. 重新标记 (CMS remark)

由于并发标记过程中用户程序是不暂停的，所以有可能引起原来的标记对象产生变动，而重新标记的作用就是修正那些变动的标记记录，这一阶段虽然无法并发执行，但是工作量很小，所以持续时间也很短。

4. 并发清除 (CMS concurrent sweep)

这一阶段就是清除掉可回收的对象，回想上篇文章介绍的标记-清除算法，在清除掉垃圾对象后并不需要移动存活对象，所以这一阶段可以与用户线程并发执行。

CMS 垃圾收集过程

综上，CMS 收集器在运行过程中只需在初始标记阶段和重新标记阶段暂停用户程序，而且时间很短，其他阶段均可与用户程序并发执行，这就是它实现超短停顿的秘密所在。

CMS 的优势很明显，就是并发收集和低停顿，但也不是完美无缺的，它主要有以下三个明显缺点：

1. CMS 收集器对处理器资源，也就是 CPU 核心数非常敏感，这也是所有并发设计的程序的共同特点。虽然它并发特点带来了低停顿的优势，但是由于挤占了处理器资源，导致总吞吐量降低，程序运行总时间也会相应延长。
2. CMS 无法处理“浮动垃圾”，因为并发标记阶段和并发清除阶段用户程序是在继续执行的，自然会继续产生垃圾对象，但是这些垃圾对象产生在标记阶段之后，所以无法被标记出来，自然也就无法被清除，而这可能会引发停顿时间较长的 Full GC。
3. 空间碎片，既然 CMS 是基于标记-清除算法的，也就不能避免产生空间碎片了，空间碎片就是不连续的可用内存，这可能导致明明有剩余空间，但就是放不下新对象，从而提前触发 Full GC。

2.3 G1 收集器

Garbage First 收集器，简称 G1，可以说是垃圾收集器技术史上里程碑式的成果，它开创了收集器面向局部收集的设计思路和基于 Region 的内存布局结构。也是从 G1 开始，垃圾收集器，包括后来的 Shenandoah 和 ZGC 都不再局限于只回收新生代或只回收老年代，而是面向整个 Java 堆。

G1 收集器最大的特色就是可预测的停顿，用户可以通过 -XX:MaxPauseMillis 参数 (默认200毫秒)指定期望的最大停顿时间，但不能随意指定，要切合实际，然后 G1 会根据这一目标值筛选并回收那些回收价值最高的可回收对象，那么 G1 是怎样做到这一点的呢？关键就在于 G1 基于 Region 的内存布局，先来看一下 G1 和之前垃圾收集器的堆内存布局对比：

G1 之前各款垃圾收集器的堆内存布局

G1 收集器堆内存布局

由此可见，虽然 G1 仍然遵循分带收集理论，但是内存区域不再按照固定大小的新生代和老年代进行划分，而是把连续的 Java 对划分成多个大小相等的独立区域 (Region)，每一个 Region 都可以根据需要扮演新生代的 Eden 空间、Survivor 空间或老年代空间。收集器可以对扮演不同角色的 Region 采用不同的策略进行处理，这样无论是新创建的对象还是已经存活了一段时间的对象，抑或是熬过了多次收集的就对象都能获得很好的收集效果。Region 中还有一类特殊的 Humongous 区域，专门用来存放大对象，G1 认为只要大小超过一个 Region 容量一半的对象就可判定为大对象，每个 Region 的大小可以通过参数 -XX:G1HeapRedionSize 设定，取值范围为 1MB~32MB，且为 2 的 N 次幂，对于那些大小超过整个 Region 大小的超大对象，将会被存放在 N 个连续的 Humongous Region 中，G1 一般会把 Humongous Region 看做老年代。

在把内存分成 Region 管理之后，G1 就可以对这些 Region 各个击破了，其停顿时间之所以可控，是因为 G1 在垃圾收集时并不会把整个 Java 堆当做回收区域，而是只收集那些回收价值最高的 Region，保证能在指定最大停顿时间内回收完毕，回收价值是指回收所获得的空间大小及耗费时间的权衡结果。这样就保证了 G1 能在指定时间内获得尽可能高的回收效率。

G1 的回收过程大致可以分为以下四个步骤：

1. 初始标记 (initial marking)：仅仅标记直接与 GC Roots 关联的对象，停顿时间很短；
2. 并发标记 (Concurrent Marking)：从 GC Roots 开始对堆中对象进行可达性分析，耗时较长，但能与用户程序并发执行，所以不会停顿；
3. 最终标记 (Final Marking)：用户程序并发执行导致对象引用关系变化，修正变化的引用，此阶段会短暂地暂停用户程序；
4. 筛选回收 (Live Data Counting and Evacuation)：更新 Region 的统计数据，对各个 Region 的回收价值和成本进行排序，并根据用户所期望的停顿时间指定回收计划，可以自由选择任意多个 Region 构成回收集，然后把需要回收的 Region 中存货对象复制到空的 Region 中，在清理掉旧 Region 的全部空间，这里涉及存活对象的移动，必须暂停用户线程，是由多条收集器线程并行完成的。

G1 收集器运行过程

G1 和 CMS 都是以低停顿为目标的收集器，所以经常被拿来比较孰优孰劣，虽然 G1 相比 CMS 优势明显，但也并非全方位的碾压，G1相比 CMS 的优缺点如下：

• G1 优点：

  1. 可以指定最大停顿时间；

  2. 分 Region 管理内存，按受益动态确定回收区域；

  3. 不会产生内存碎片：G1 的内存布局并不是固定大小以及固定数量的分代区域划分，而是把连续的Java堆划分为多个大小相等的独立区域 (Region)，G1 从整体来看是基于“标记-整理”算法实现的收集器，但从局部 (两个Region 之间)上看又是基于“标记-复制”算法实现，不会像 CMS (“标记-清除”算法) 那样产生内存碎片。

• G1 缺点：

G1 需要记忆集 (具体来说是卡表)来记录新生代和老年代之间的引用关系，这种数据结构在 G1 中需要占用大量的内存，可能达到整个堆内存容量的 20% 甚至更多。而且 G1 中维护记忆集的成本较高，带来了更高的执行负载，影响效率。

按照《深入理解Java虚拟机》作者的说法，CMS 在小内存应用上的表现要优于 G1，而大内存应用上 G1 更有优势，大小内存的分水岭是6GB到8GB。

2.4 最前沿科技成果：低延迟垃圾收集器

之前最先进的 G1 收集器早在 JDK 7 上就已经发布了成熟版，而截至目前的2020年初，JDK 版本已经来到了 JDK 13，与此同时，垃圾收集器领域也早已有了更先进的黑科技，其中的代表者就是号称可以将停顿时间控制在10毫秒内低延迟收集器——Shenandoah 和 ZGC，它们最牛X的地方在于并发程度更高，连移动存活对象 (也就是标记-整理算法的整理阶段)都可以做到并发执行 (不过二者的实现原理有所区别)：

各种垃圾收集器并发程度对比，绿色表示并发，黄色表示非并发

由图可知，相比之前的收集器，Shenandoah 和 ZGC 在工作过程中几乎全程并发，只有在初始标记、最终标记这些阶段有短暂的暂停，而且这些停顿时间与堆容量和堆中对象数量没有正比例关系，这才可以将停顿时间控制在惊人的10毫秒以内。

2.4.1 Shenandoah 收集器

Shenandoah 是由 ReadHat 公司独立发展的新型垃圾收集器，并在2014年贡献给了 OpenJDK，并成为 OpenJDK 12 的正式特性之一，但是以 Oracle 公司的尿性，却不愿把它添加到 OracleJDK 中，这也导致了免费开源的 OpenJDK 反而比商业收费的 OracleJDK 功能更多，实属罕见。

Shenandoah 与 G1 有很多相似之处，比如都是基于 Region 的内存布局，都有用于存放大对象的 Humongous Region，默认回收策略也是优先处理回收价值最大的 Region。不过也有三个重大的区别：

1. 最最重要的区别，Shenandoah 支持并发的整理算法，G1 的整理阶段虽是多线程并行，但无法与用户程序并发执行；
2. 默认不使用分代收集理论；
3. 使用连接矩阵 (Connection Matrix)记录跨 Region 的引用关系，替换掉了 G1 中的记忆级 (Remembered Set)，内存和计算成本更低。

Shenandoah 收集器的工作原理相比 G1 要复杂不少，其运行流程示意图如下：

Shenandoah 收集器运行流程

可见 Shenandoah 的并发程度明显比 G1 更高，只需要在初始标记、最终标记、初始引用更新和最终引用更新这几个阶段进行短暂的“Stop The World”，其他阶段皆可与用户程序并发执行，其中最重要的并发标记、并发回收和并发引用更新详情如下：

• 并发标记( Concurrent Marking)

与G1一样，遍历对象图，标记出全部可达的对象，这个阶段是与用户线程一起并发的，时间长短取决于堆中存活对象的数量以及对象图的结构复杂程度。

• 并发回收( Concurrent Evacuation)

并发回收阶段是 Shenandoah 与之前 HotSpot 中其他收集器的核心差异。在这个阶段， Shenandoah 要把待回收 Region 里面的存活对象先复制一份到其他未被使用的 Region之中。复制对象这件事情如果将用户线程冻结起来再做那是相当简单的，但如果两者必须要同时并发进行的话，就变得复杂起来了。其困难点是在移动对象的同时，用户线程仍然可能不停对被移动的对象进行读写访问，移动对象是一次性的行为，但移动之后整个内存中所有指向该对象的引用都还是旧对象的地址，这是很难一瞬间全部改变过来的。对于并发回收阶段遇到的这些困难， Shenandoah 将会通过读屏障和被称为“ Brooks Pointers”的转发指针来解决。并发回收阶段运行的时间长短取决于回收集的大小。

Brooks Pointers 简要介绍：这是一种转发指针 (Forwarding Pointer)，原理就是在所有的对象上新添加一个指针，初始状态下该指针指向对象本身，而在垃圾回收过程中，如果该对象是存活对象，则需要将其从回收区域移动到目标区域 (其实就是在目标区域复制一个新对象，这就是标记-整理算法的整理阶段，之前的 G1 收集器在此阶段无法与用户程序并发执行)，然后把旧对象的转发指针指向新的对象，这样用户程序在并发执行的情况下，就不会访问到旧对象了。

• 并发引用更新( Concurrent Update Reference)

这个阶段是与用户线程一起并发的，时间长短取决于内存中涉及的引用数量的多少。并发引用更新与并发标记不同，它不再需要沿着对象图来搜索，只需要按照内存物理地址的顺序，线性地搜索出引用类型，把旧值改为新值即可。

Shenandoah 的高并发度让它实现了超低的停顿时间，但是更高的复杂度也伴随着更高的系统开销，这在一定程度上会影响吞吐量，下图是 Shenandoah 与之前各种收集器在停顿时间维度和系统开销维度上的对比：

Shenandoah 与之前各种收集器在停顿时间维度和系统开销维度上的对比

OracleJDK 并不支持 Shenandoah，如果你用的是 OpenJDK 12 或某些支持 Shenandoah 移植版的 JDK 的话，可以通过以下参数开启 Shenandoah：

-XX:+UnlockExperimentalVMOptions -XX:+UseShenandoahGC

2.4.2 ZGC 收集器

Z Garbage Collector，简称 ZGC，是 JDK 11 中新加入的尚在实验阶段的低延迟垃圾收集器。它和 Shenandoah 同属于超低延迟的垃圾收集器，但在吞吐量上比 Shenandoah 有更优秀的表现，甚至超过了 G1，接近了“吞吐量优先”的 Parallel 收集器组合，可以说近乎实现了“鱼与熊掌兼得”。

ZGC 的内存布局

与 Shenandoah 和 G1 一样，ZGC 也采用基于 Region 的堆内存布局，但与它们不同的是， ZGC 的 Region 具有动态性，也就是可以动态创建和销毁，容量大小也是动态的，有大、中、小三类容量:

ZGC 内存布局

• 小型 Region (Small Region)：容量固定为 2MB，用于放置小于 256KB 的小对象。

• 中型 Region (M edium Region)：容量固定为 32MB，用于放置大于等于 256KB 但小于 4MB 的对
  象。

• 大型 Region (Large Region)：容量不固定，可以动态变化，但必须为 2MB 的整数倍，用于放置 4MB 或以上的大对象。每个大型 Region 中只会存放一个大对象，这也预示着虽然名字叫作“大型 Region”，但它的实际容量完全有可能小于中型 Region，最小容量可低至 4MB。

与 Shenandoah 一样，ZGC 在工作过程中也几乎是全程与用户程序并发的，重点也是实现了标记-整理算法的整理阶段可以与用户程序并发执行。但是二者的实现方式不同，Shenandoah 是在对象身上添加转发指针的方法，而 ZGC 则是直接在指针上动手脚，也就是传说中的染色指针 (Colored Pointers)，这个指针就是 Java 对象的引用，例如：

Object o = new Object();

其中“o” 只是一个引用，也就是指针，指向存在堆上的对象实例，引用自身也是要占内存的，普通引用在32位机器占4个字节，在64位机器上，开启压缩指针 (-XX:+UseCompressedOops) 的话占4个字节，不开启的话占8个字节。ZGC 的染色指针结构如下 (不支持32位机器和压缩指针)：

染色指针结构示意图

得益于染色指针上标志位的支持，ZGC 也可以像 Shenandoah 那样，实现了在移动存活对象的过程中可以与用户程序并发执行，且效率更高。ZGC 还用到了很多其他的黑科技，原理过于复杂，就不在这里详述了。

在 JDK 11 及以上版本，可以通过以下参数开启 ZGC：

-XX:+UnlockExperimentalVMOptions -XX:+UseZGC

2.5 最奇葩的垃圾收集器——Epsilon

上面介绍的各种收集器，比如 G1、Shenandoah 和 ZGC 等都是越来越复杂，越来越先进， 而 JDK 11 新加入的 Epsilon 却是反其道而行，这款收集器不会做任何垃圾收集的操作，也许叫做“内存分配器”更加合适。虽然很奇葩，但是它还是有用武之地的，比如越来越火的微服务领域，如果系统运行时间很短，在堆内存耗尽之前就可以结束，那么垃圾收集也就没有任何意义了，这正是 Epsilon 的使用场景。

总结

本文为大家介绍了目前 HotSpot 虚拟机上的所有垃圾收集器，有的已经久经沙场，有的仍处于试验阶段，但有望在未来成为主流，在实际应用中，大家可以根据具体场景选择合适的垃圾收集器。

参考资料：

• 《深入理解Java虚拟机》周志明
• An Introduction to ZGC: A Scalable and Experimental Low-Latency JVM Garbage Collector
• 聊聊ShenandoahGC的Brooks Pointers
• https://wiki.openjdk.java.net/display/shenandoah/Main

虚拟机设计团队把类加载阶段中的 “通过一个类的全限定名来获取描述此类的二进制字节流(即字节码)” 这个动作放到Java虚拟机外部去实现，以便让应用程序自己决定如何去获取所需要的类。实现这个动作的代码模块称为 “类加载器”。

一般来说，Java 虚拟机使用 Java 类的方式如下：

1. Java 源程序（.java 文件）在经过 Java 编译器编译之后就被转换成字节码（.class 文件）。
2. 类加载器负责读取 Java 字节代码，并转换成 java.lang.Class类的一个实例。每个这样的实例用来表示一个 Java 类。通过此实例的 newInstance()方法就可以创建出该类的一个对象。

实际的情况可能更加复杂，比如 Java 字节代码可能是通过工具动态生成的，也可能是通过网络下载的。更详细的内容可以参考上一篇文章中讲类加载过程中的加载阶段时介绍的几个例子（JAR包、Applet、动态代理、JSP等）。

类加载器虽然只用于实现类的加载动作，但它在Java程序起到的作用却远大于类加载阶段。对于任意一个类，都需要由加载它的类加载器和这个类本身一同确立其在Java虚拟机中的唯一性，每一个类加载器，都拥有一个独立的类名称空间。通俗而言：比较两个类是否“相等”（这里所指的“相等”，包括类的Class对象的equals()方法、isAssignableFrom()方法、isInstance()方法的返回结果，也包括使用instanceof()关键字对做对象所属关系判定等情况），只有在这两个类时由同一个类加载器加载的前提下才有意义，否则，即使这两个类来源于同一个Class文件，被同一个虚拟机加载，只要加载它们的类加载器不同，那这两个类就必定不相等。

从jvm的角度来讲，只存在以下两种不同的类加载器：

• 启动类加载器（Bootstrap ClassLoader），这个类加载器用C++实现，是虚拟机自身的一部分；
• 所有其他类的加载器，这些类由Java实现，独立于虚拟机外部，并且全都继承自抽象类java.lang.ClassLoader。

从Java开发人员的角度看，类加载器可以划分得更细致一些：

• 启动类加载器（Bootstrap ClassLoader） 此类加载器负责将存放在 <JAVA_HOME>\lib 目录中的，或者被 -Xbootclasspath 参数所指定的路径中的，并且是虚拟机识别的（仅按照文件名识别，如 rt.jar，名字不符合的类库即使放在lib 目录中也不会被加载）类库加载到虚拟机内存中。 启动类加载器无法被 Java 程序直接引用，用户在编写自定义类加载器时，如果需要把加载请求委派给引导类加载器，直接使用null代替即可。
• 扩展类加载器（Extension ClassLoader） 这个类加载器是由ExtClassLoader（sun.misc.Launcher$ExtClassLoader）实现的。它负责将<Java_Home>/lib/ext或者被 java.ext.dir系统变量所指定路径中的所有类库加载到内存中，开发者可以直接使用扩展类加载器。
• 应用程序类加载器（Application ClassLoader） 这个类加载器是由 AppClassLoader（sun.misc.Launcher$AppClassLoader）实现的。由于这个类加载器是ClassLoader中的getSystemClassLoader()方法的返回值，因此一般称为系统类加载器。它负责加载用户类路径（ClassPath） 上所指定的类库，开发者可以直接使用这个类加载器，如果应用程序中没有自定义过自己的类加载器，一般情况下这个就是程序中默认的类加载器。

由开发人员开发的应用程序都是由这三种类加载器相互配合进行加载的，如果有必要，还可以加入自己定义的类加载器。这些类加载器的关系一般如下图所示：

上图展示的类加载器之间的层次关系，称为类加载器的双亲委派模型（Parents Delegation Model）。该模型要求除了顶层的启动类加载器外，其余的类加载器都应有自己的父类加载器，这里类加载器之间的父子关系一般通过组合（Composition） 关系来实现，而不是通过继承（Inheritance）的关系实现。

工作过程

如果一个类加载器收到了类加载的请求，它首先不会自己去尝试加载，而是把这个请求委派给父类加载器，每一个层次的加载器都是如此，依次递归，因此所有的加载请求最终都应该传送到顶层的启动类加载器中，只有当父加载器反馈自己无法完成此加载请求（它搜索范围中没有找到所需类）时，子加载器才会尝试自己加载。

优点

使用双亲委派模型来组织类加载器之间的关系，使得Java类随着它的类加载器一起具备了一种带有优先级的层次关系。例如类java.lang.Object，它存放再rt.jar中，无论哪个类加载器要加载这个类，最终都是委派给处于模型最顶端的启动类加载器进行加载，因此Object类在程序的各种类加载器环境中都是同一个类。

相反，如果没有双亲委派模型，由各个类加载器自行加载的话，如果用户编写了一个称为java.lang.Object的类，并放在程序的ClassPath中，那系统中将会出现多个不同的Object类，程序将变得一片混乱。如果开发者尝试编写一个与rt.jar类库中已有类重名的Java类，将会发现可以正常编译，但是永远无法被加载运行。

双亲委派模型的实现如下：

   protected synchronized Class<?> loadClass(String name,boolean resolve)throws ClassNotFoundException{       //check the class has been loaded or not       Class c = findLoadedClass(name);       if(c == null){           try{               if(parent != null){                   c = parent.loadClass(name,false);               }else{                   c = findBootstrapClassOrNull(name);               }           }catch(ClassNotFoundException e){               //if throws the exception ,the father can not complete the load           }           if(c == null){               c = findClass(name);           }       }       if(resolve){           resolveClass(c);       }       return c;   }

线程上下文类加载器

双亲委派模型并不能解决 Java 应用开发中会遇到的类加载器的全部问题。Java 提供了很多服务提供者接口（Service Provider Interface，SPI），允许第三方为这些接口提供实现。常见的 SPI 有 JDBC、JCE、JNDI、JAXP 和 JBI 等。这些 SPI 的接口由 Java 核心库来提供，如 JAXP 的 SPI 接口定义包含在 javax.xml.parsers包中。这些 SPI 的实现代码很可能是作为 Java 应用所依赖的 jar 包被包含进来，可以通过类路径（ClassPath）来找到，如实现了 JAXP SPI 的 Apache Xerces所包含的 jar 包。SPI 接口中的代码经常需要加载具体的实现类。如 JAXP 中的 javax.xml.parsers.DocumentBuilderFactory类中的 newInstance() 方法用来生成一个新的 DocumentBuilderFactory 的实例。这里的实例的真正的类是继承自 javax.xml.parsers.DocumentBuilderFactory，由 SPI 的实现所提供的。如在 Apache Xerces 中，实现的类是 org.apache.xerces.jaxp.DocumentBuilderFactoryImpl。而问题在于，SPI 的接口是Java 核心库的一部分，是由引导类加载器加载的，而SPI 实现的 Java 类一般是由系统类加载器加载的。引导类加载器是无法找到 SPI 的实现类的，因为它只加载 Java 的核心库。它也不能委派给系统类加载器，因为它是系统类加载器的祖先类加载器。也就是说，类加载器的双亲委派模型无法解决这个问题。

为了解决这个问题，Java设计团队只好引入了一个不太优雅的设计：线程上下文类加载器（Thread Context ClassLoader）。线程上下文类加载器是从 JDK 1.2 开始引入的。类 java.lang.Thread中的方法 getContextClassLoader()和 setContextClassLoader(ClassLoader cl)用来获取和设置线程的上下文类加载器。如果没有通过 setContextClassLoader(ClassLoader cl)方法进行设置的话，线程将继承其父线程的上下文类加载器。Java 应用运行的初始线程的上下文类加载器是应用程序类加载器。在线程中运行的代码可以通过此类加载器来加载类和资源。

有了线程上下文类加载器，就可以做一些“舞弊”的事情了，JNDI服务使用这个线程上下文类加载器去加载所需要的SPI代码，也就是父类加载器请求子类加载器去完成类加载器的动作，这种行为实际上就是打通了双亲委派模型的层次结构来逆向使用类加载器，已经违背了双亲委派模型的一般性原则。

追求程序动态性

这里所说的“动态性”指的是当前一些非常热门的名词：代码热替换（HotSwap）、模块热部署(Hot Deployment) 等。即希望应用程序能像计算机的外设一样，接上鼠标、键盘，不用重启就能立即使用，鼠标出了问题或需要升级就换个鼠标，不用停机或重启。

当前业界“事实上”的Java模块化标准是OSGi，而OSGi实现代码热部署的关键则是它自定义的类机载器的实现。关于OSGi的细节将在稍后的案例分析中详细讲解。

API

其中有如下三个比较重要的方法

在了解完上述内容后，我们可以容易地意识到自定义类加载器有以下两种方式：

• 采用双亲委派模型：继承ClassLoader类，只需重写其的findClass(String name)方法，而不需重写loadClass(String name)方法。
• 破坏双亲委派模型：继承ClassLoader类，需要整个重写实现了双亲委派模型逻辑的loadClass(String name)方法。

实例

下面我们来实现一个自定义类加载器，用来加载存储在文件系统上的 Java 字节代码。

   public class FileSystemClassLoader extends ClassLoader {           private String rootDir;           public FileSystemClassLoader(String rootDir) {           this.rootDir = rootDir;       }           @Override      protected Class<?> findClass(String name) throws ClassNotFoundException {           byte[] classData = getClassData(name);           if (classData == null) {               throw new ClassNotFoundException();           }           else {               return defineClass(name, classData, 0, classData.length);           }       }           private byte[] getClassData(String className) {           String path = classNameToPath(className);           try {               InputStream ins = new FileInputStream(path);               ByteArrayOutputStream baos = new ByteArrayOutputStream();               int bufferSize = 4096;               byte[] buffer = new byte[bufferSize];               int bytesNumRead = 0;               while ((bytesNumRead = ins.read(buffer)) != -1) {                   baos.write(buffer, 0, bytesNumRead);               }               return baos.toByteArray();           } catch (IOException e) {               e.printStackTrace();           }           return null;       }           private String classNameToPath(String className) {           return rootDir + File.separatorChar                   + className.replace('.', File.separatorChar) + ".class";       }    }

类 FileSystemClassLoader的 findClass()方法首先根据类的全名在硬盘上查找类的字节代码文件（.class 文件），然后读取该文件内容，最后通过 defineClass()方法来把这些字节代码转换成 java.lang.Class类的实例。

主流的Java Web服务器如Tomcat、Jetty、WebLogic、WebSphere等等，都实现了自己定义的类加载器（一般都不止一个）。因为一个功能健全的Web服务器，要解决以下问题：

• 部署在同一个服务器上的两个Web应用程序所使用的Java类库可以实现相互隔离。 两个不同的应用程序可能会依赖同一个第三方类库的不同版本，不能要求一个类库在一个服务器中只有一份，服务器应当保证两个应用程序的类库可以互相独立使用。
• 部署在同一个服务器上的两个Web应用程序所使用的Java类库可以相互共享。 例如，用户可能有5个使用Spring组织的应用程序部署在同一台服务器上，如果把5份Spring分别放在各个应用程序的隔离目录中，库在使用时都要被加载到服务器内存中，JVM的方法区就会有过度膨胀的风险。
• 服务器需要尽可能保证自身安全不受部署的Web应用程序影响。 很多Web服务器本身是用Java实现的，服务器使用的类库应该与应用程序的类库相互独立。
• 支持JSP应用的服务器，大多数需要支持代码热替换（HotSwap）功能。 JSP文件由于其纯文本存储的特性，运行时修改的概率远大于第三方类库或程序自身的Class文件，因此需要做到修改后无须重启。

鉴于上述问题，各种Web服务器都不约而同地提供了数个ClassPath路径供用户存放第三方类库，这些路径一般以“lib”或“classes”命名。以Tomcat为例，有3组目录（“/common/* ”、“/server/* ”和“/shared/* ”）可以存放Java类库，另外还可以加上Web应用程序自身的目录 “/WEB-INF/* ”，一共4组，把Java类库放置在这些目录中的含义分别如下：

• /common目录：类库可被Tomcat和所有的Web应用程序共同使用。
• /server目录：类库可被Tomcat使用，对所有的Web应用程序都不可见。
• /shared目录：类库可被所有的Web应用程序共同使用，但对Tomcat自己不可见。
• /WebApp/WEB-INF目录：类库仅仅可以被此Web应用程序使用，对Tomcat和其他Web应用程序都不可见。

为了支持这套目录结构，并对目录里的类库进行加载和隔离，Tomcat采用如下经典的双亲委派模型来实现了多个类加载器：

CommonClassLoader、CatalinaClassLoader、SharedClassLoader和WebappClassLoader是Tomcat自己定义的类加载器，它们分别加载 /common/*、/server/*、/shared/** 和 /WebApp/WEB-INF/* 中的Java类库。其中WebApp类加载器和JSP类加载器通常会存在多个实例，每一个Web应用程序对应一个WebApp类加载器，每一个JSP文件对应一个JSP类加载器。

CommonClassLoader能加载的类都可以被CatalinaClassLoader和SharedClassLoader使用，而CatalinaClassLoader和SharedClassLoader自己能加载的类则与对方相互隔离。WebAppClassLoader可以使用SharedClassLoader加载到的类，但各个WebAppClassLoader实例之间相互隔离。而JasperLoader的加载范围仅是这个JSP文件编译出来的那一个Class，它出现的目的就是被丢弃。当服务器检测到JSP文件被修改时，会替换掉目前的JasperLoader的实例，并通过再建立一个新的JSP类加载器来实现JSP文件的HotSwap功能。

特殊场景

前文提到过一个场景，如果有5个Web应用程序都是用Spring来进行组织和管理的话，可以把Spring放到Common或Shared目录下让这些程序共享。Spring要对用户程序的类进行管理，自然要能访问到用户程序的类，而用户程序放在 /WebApp/WEB-INF 目录中，这时就需要破坏双亲委派模型，使用线程上下文类加载器来完成这一工作了。

OSGi：类加载器的灵活运用

OSGi（Open Service Gateway Initiative）是OSGi联盟制定的一个基于Java语言的动态模块化规范，现在成为了Java“事实上”的模块化标准。它为开发人员提供了面向服务和基于组件的运行环境，并提供标准的方式用来管理软件的生命周期。OSGi 已经被实现和部署在很多产品上，在开源社区也得到了广泛的支持，其中最为著名的应用莫过于大家都很熟悉的Eclipse IDE。

OSGi 中的每个模块（bundle） 都包含 Java Package 和Class。模块可以声明它所依赖的需要导入（import） 的其它模块的 Java 包和类（通过 Import-Package），也可以声明导出（export） 自己的包和类，供其它模块使用（通过 Export-Package）。也就是说需要能够隐藏和共享一个模块中的某些 Java 包和类。这是通过 OSGi 特有的类加载器机制来实现的。

OSGi 中的每个模块都有对应的一个类加载器，它负责加载模块自己包含的 Java 包和类。当它需要加载 Java 核心库的类时（以 java开头的包和类），它会代理给父类加载器（通常是启动类加载器）来完成。当它需要加载所导入的 Java 类时，它会代理给导出此 Java 类的模块来完成加载。 模块也可以显式的声明某些 Java 包和类，必须由父类加载器来加载。只需要设置系统属性 org.osgi.framework.bootdelegation的值即可。

假设有两个模块 bundleA 和 bundleB，它们都有自己对应的类加载器 ClassLoaderA 和 ClassLoaderB。在 bundleA 中包含类 com.bundleA.Sample，并且该类被声明为导出的，也就是说可以被其它模块所使用的。bundleB 声明了导入 bundleA 提供的类 com.bundleA.Sample，并包含一个类 com.bundleB.NewSample继承自 com.bundleA.Sample。在 bundleB 启动的时候，其类加载器 classLoaderB 需要加载类 com.bundleB.NewSample，进而需要加载类 com.bundleA.Sample。由于 bundleB 声明了类 com.bundleA.Sample是导入的，classLoaderB 把加载类 com.bundleA.Sample的工作代理给导出该类的 bundleA 的类加载器 ClassLoaderA。ClassLoaderA 在其模块内部查找类 com.bundleA.Sample并定义它，所得到的类 com.bundleA.Sample实例就可以被所有声明导入了此类的模块使用。对于以 java开头的类，都是由父类加载器来加载的。如果声明了系统属性 org.osgi.framework.bootdelegation=com.example.core.*，那么对于包 com.example.core中的类，都是由父类加载器来完成的。 OSGi 模块的这种类加载器结构，使得一个类的不同版本可以共存在 Java 虚拟机中，带来了很大的灵活性。不过它的这种不同，也会给开发人员带来一些麻烦，尤其当模块需要使用第三方提供的库的时候。下面提供几条比较好的建议：

• 如果一个类库只有一个模块使用，把该类库的 jar 包放在模块中，在 Bundle-ClassPath中指明即可。
• 如果一个类库被多个模块共用，可以为这个类库单独的创建一个模块，把其它模块需要用到的 Java 包声明为导出的。其它模块声明导入这些类。
• 如果类库提供了 SPI 接口，并且利用线程上下文类加载器来加载 SPI 实现的 Java 类，有可能会找不到 Java 类。如果出现了 NoClassDefFoundError异常，首先检查当前线程的上下文类加载器是否正确。通过 Thread.currentThread().getContextClassLoader()就可以得到该类加载器。该类加载器应该是该模块对应的类加载器。如果不是的话，可以首先通过 class.getClassLoader()来得到模块对应的类加载器，再通过 Thread.currentThread().setContextClassLoader()来设置当前线程的上下文类加载器。

参考：

• 《深入理解Java虚拟机——JVM高级特性与最佳实践》－周志明
• 深入探讨 Java 类加载器－成富

From: https://crowhawk.github.io/2017/08/21/jvm_6/

在Class文件中描述的各种信息，最终都需要加载到虚拟机中之后才能运行和使用。而虚拟机中，而虚拟机如何加载这些Class文件？Class文件中的信息进入到虚拟机中会发生什么变化？本文将逐步解答这些问题。

类从被加载到虚拟机内存中开始，到卸载出内存为止，它的整个生命周期包括以下7个阶段：

• 加载（Loading）
• 验证（Verification）
• 准备（Preparation）
• 解析（Resolution）
• 初始化（Initialization）
• 使用（Using）
• 卸载（Unloading）

其中前五个阶段即为类加载的全过程。在后面会进行详细的介绍。而验证、准备、解析3个部分统称为连接（Linking）。这7个阶段的发生顺序如下图：

在上图中，加载、验证、准备、初始化和卸载这5个阶段的顺序是确定的，类的加载过程必须按照这种顺序按部就班地开始（开始而不是完成，这些阶段是互相交叉着进行的，在一个阶段执行过程中就会激活另一个阶段），而解析阶段则不一定：它在某些情况下可以在初始化阶段之后再开始，这是为了支持Java的运行时绑定（也称为动态绑定或晚期绑定）。

对于类加载过程的第一个阶段：加载，jvm规范中并没有进行强制约束其开始时机，可交由jvm的具体实现来自由把握。但是对于初始化阶段，jvm规范严格规定了有且只有下列5种情况必须对类进行**“初始化”**（很自然地，加载、验证、准备需要在此之前开始）：

• 遇到new、getstatic、putstatic、invokestatic这四条字节码指令时，如果类没有进行过初始化，则必须先触发其初始化。最常见的生成这4条指令的场景是：使用new关键字实例化对象的时候；读取或设置一个类的静态字段（被final修饰、已在编译期把结果放入常量池的静态字段除外）的时候；以及调用一个类的静态方法的时候。
• 使用 java.lang.reflect包的方法对类进行反射调用的时候，如果类没有进行初始化，则需要先触发其初始化。
• 当初始化一个类的时候，如果发现其父类还没有进行过初始化，则需要先触发其父类的初始化。
• 当虚拟机启动时，用户需要制定一个要执行的主类（包含main方法的那个类），虚拟机会先初始化这个主类；
• 当使用jdk1.7 的动态语言支持时，如果一个java.lang.invoke.MethodHandle实例最后的解析结果REF_getStatic, REF_putStatic, REF_invokeStatic 的方法句柄，并且这个方法句柄所对应的类没有进行过初始化，则需要先触发其初始化；

以上5种场景中的行为称为对一个类进行主动引用。除此之外，所有引用类的方式都不会触发初始化，称为被动引用。被动引用的常见例子包括：

• 通过子类引用父类的静态字段，不会导致子类初始化。
• 通过数组定义来引用类，不会触发此类的初始化，如SuperClass[] sca = new SuperClass[10];。
• 常量在编译阶段会存入调用类的常量池中，本质上并没有直接引用到定义常量的类，因此不会触发定义常量的类的初始化。

接口的加载过程和类加载过程略有不同，它们真正的区别在于在前文提到的5种需要开始初始化场景中的第3种：当一个类在初始化时，要求其父类全部都已经初始化过了，但是一个接口在初始化时，并不要求其父接口全部都完成了初始化，只有在真正使用到父接口的时候（如引用接口中定义的常量）才会初始化。

加载

加载是**类加载（Class Loading）**过程的一个阶段，两者不要混淆。虚拟机规范规定了在在加载阶段，jvm需要完成以下三件事情：

• 通过一个类的全限定名来获取定义此类的二进制字节流。
• 将这个字节流所代表的静态存储结构转化为方法区的运行时存储结构。
• 在内存中生成一个代表这个类的java.lang.Class对象，作为方法区这个类的各种数据的访问入口。

这三点要求不算具体，在jvm实现时灵活度很大。例如上面的第一条，它没有指明二进制字节流要从一个Class文件中获取，准确地说没有指明要从哪里获取、怎样获取。这也为许多Java技术提供了基础，例如：

• 从ZIP包读取，这很常见，最终成为日后JAR、EAR、WAR格式的基础。
• 从网络中获取，这种场景最典型的应用是Applet。
• 运行时计算生成，这种场景使用得最多得就是动态代理技术，在java.lang.reflect.Proxy中，就是用了ProxyGenerator.generateProxyClass的代理类的二进制字节流。
• 由其他文件生成，典型场景是JSP应用，即由JSP文件生成对应的Class类。
• 从数据库读取，这种场景相对少见，例如有些中间件服务器（如SAP Netweaver）可以选择把程序安装到数据库中来完成程序代码在集群间的分发。

非数组类的加载

相对于类加载过程的其他阶段，一个非数组类的加载阶段（准确地说，是加载阶段中获取类的二进制字节流的动作）是开发人员可控性最强的，因为加载阶段既可以使用系统提供的引导类加载器完成，也可以由用户自定义的类加载器完成，通过自定义类加载器去控制字节流的获取方式，即重写一个类加载器的loadClass()方法。关于类加载器的内容将在系列的下一篇文章中介绍。

数组类的加载

**数组类本身不通过类加载器创建，它是由jvm直接创建的。**但数组类的元素类型（Element Type，指的是数组去掉所有维度的类型）最终是要靠类加载器去创建，一个数据类C的创建过程遵循以下规则：

• 如果数组的组件类型（ComponentType，指的是数组去掉一个维度的类型）是引用类型，就递归采用本节中定义的加载过程去加载此组件类型，数组类将在加载该组件类型的类加载器的类名称空间上被标识（这很重要，在下一篇文章中会讲到，一个类必须与类加载器一起确定唯一性）。
• 如果数组的组件类型不是引用类型（例如int[]数组），Java虚拟机将会把数组类标记为与引导类加载器关联。
• 数组类的可见性与它的组件类型的可见性一致，如果组件类型不是引用类型，那数组类的可见性将默认为public。

加载阶段完成后，虚拟机外部的二进制字节流就按照虚拟机所需的格式存储在方法区之中，方法区的数据存储格式由虚拟机实现自行定义，虚拟机规范未规定此区域的具体数据结构。然后在内存中实例化一个java.lang.Class类的对象（并无明确规定是在Java 堆中，对于HotSpot虚拟机而言，Class对象比较特殊，它虽是对象，但存放在方法区里），这个对象将作为程序访问方法区中的这些类型数据的外部接口。

验证

验证是连接阶段的第一步，这一阶段的目的是确保输入的Class文件的字节流能正确地解析并存储于方法区之内，格式上符合描述一个Java类型信息的要求，并且不会危害虚拟机自身的安全。验证阶段是否严谨，直接决定了Java虚拟机是否能承受恶意代码的攻击。 从整体上看，验证阶段大致上会完成下面四个阶段的检验动作：文件格式验证、元数据验证、字节码验证、符号引用验证。

1. 文件格式验证

第一阶段要验证字节流是否符合Class文件格式的规范，并且能被当前版本的虚拟机处理。这一阶段可能包括下面这些验证点：

• 是否以魔数0xCAFEBABE开头。
• 主次版本号是否在当前虚拟机的处理范围之内
• 常量池的常量中是否有不被支持的常量类型（tag标志）。
• 指向常量的各种索引值中是否有指向不存在的常量或不符合类型的常量。
• Class文件中各个部分及文件本身是否有被删除的或附加的其他信息。 ……

这阶段的验证是基于二进制字节流进行的，只有通过了这个阶段的验证后，字节流才会进入方法区中进行存储，所以后面的3个验证阶段全部是基于方法区的存储结构进行的，不会再直接操作字节流。

2. 元数据验证

第二阶段是对字节码描述的信息（即类的元数据信息）进行语义分析，以保证其描述的信息符合Java语言规范的要求。例如下面这些验证点：

• 该类是否有父类（除了java.lang.Object之外，所有的类都应有父类）
• 该类的父类是否继承了不允许被继承的类（final修饰的类）
• 若此类不是抽象类，是否实现了其父类或接口之中要求实现的所有方法 ……

该阶段的主要目的是对类的元数据信息进行语义检验，保证不存在不符合Java语言规范的元数据信息。

3. 字节码验证

第三阶段的主要目的是进行数据流和控制流分析，确定程序语义是合法的、符合逻辑的。在第二阶段对元数据信息中的数据类型做完校验之后，这个阶段将对类的方法体进行校验分析，以保证被校验类的方法在运行时不会做出危害虚拟机安全的行为。例如：

• 保证任意时刻操作数栈的数据类型与指令代码序列都能配合工作。
• 保证跳转指令不会跳转到方法体以外的字节码指令上。
• 保证方法体中类型转换是有效的，例如子类对象可以赋值给父类数据类型，但父类对象赋值给子类数据类型是危险和不合法的。 ……

4. 符号引用验证

最后一个阶段的校验发生在虚拟机将符号引用转化为直接引用的时候，这个转化动作将在连接的第三阶段——解析阶段中发生。符号引用验证可以看做是对类自身以外（常量池中的各种符号引用）的信息进行匹配性校验，通常需要校验下列内容：

• 符号引用中通过字符串描述的全限定名是否能找到对应的类。
• 指定的类中是否存在符合描述符与简单名称描述的方法与字段。
• 符号引用中的类、字段、方法的访问性（private、protected、public、default）是否可被当前类访问。 ……

符号引用的目的是确保解析动作能正常执行。

对于jvm的类加载机制来说，验证阶段是一个非常重要但不是一定必要（因为对运行期没有影响）的阶段。如果所运行的全部代码都已经被反复验证过，那么在实施阶段就可以考虑使用-Xverify:none参数来关闭大部分的类验证措施，以缩短虚拟机类加载的时间。

准备

准备阶段的主要任务是如下两点：

• 为类变量分配内存
• 设置类变量初始值

这些变量所使用的内存都将在方法区中分配。

首先，在准备阶段进行内存分配的仅包括类变量（被static修饰的变量），而不包括实例变量，实例变量将会在对象实例化时随着对象一起分配在Java堆中。

其次，这里所说的初始值“通常情况”下是数据类型的零值，假设一个类变量的定义为：

public static int value = 123;

那变量value在准备阶段过后的初始值为0而不是123，因为这时候尚未开始执行任何Java方法，而把value赋值为123的putstatic指令是程序被编译后，存放于类构造器<clinit>()方法之中，所以把value赋值为123的动作在初始化阶段才会执行。 值得注意的是，如果类字段的字段属性中存在ConstantValue属性，那在准备阶段变量value就会被初始化为ConstantValue属性所指定的值，假设上面类变量value的定义变为：

public static final int value = 123;

编译时Javac将会为value生成ConstantValue属性，在准备阶段虚拟机就会根据ConstantValue的设置将value赋值为123。

解析

解析阶段是虚拟机将常量池内的符号引用替换为直接引用的过程。符号引用和直接引用的关联如下：

• 符号引用（Symbol References）： 符号引用以一组符号来描述所引用的目标，符号可以是任何形式的字面量，只要使用时能无歧义地定位到目标即可。符号引用与虚拟机实现的内存布局无关，引用的目标并不一定已经加载到内存中。各种虚拟机实现的内存布局可以各不相同，但是它们能接受的符号引用必须一致，因为符号引用的字面量形式明确定义在Java虚拟机规范的Class文件格式中。
• 直接引用（Direct References）： 直接引用可以是直接目标的指针、相对偏移量或是一个能间接定位到目标的句柄。直接引用是和虚拟机实现的内存布局有关的，同一个符号引用在不同虚拟机实例上翻译出来的直接引用一般不会相同。如果有了直接引用，那么引用的目标必定已经在内存中存在。

虚拟机规范并未规定解析动作发生的具体时间，仅要求在执行anewarray、checkcast、getfield、getstatic、instanceof、invokeinterface、invokespecial、invokestatic、invokevirtual、multianewarray、new、putfield和putstatic这13个用于操作符号引用的字节码指令之前，先对它们所使用的符号引用进行解析。所以虚拟机实现可以根据需要来判断到底是在类被加载器加载时就对常量池中的符号进行解析，还是等到一个符号引用将要被使用前才去解析它。

对同一个符号引用进行多次解析请求是很常见的，除 invokedynamic 指令外（ invokedynamic指令是用于动态语言支持的，它所对应的引用称为**“动态调用点限定符”，必须等到程序实际运行到这条指令的时候，解析动作才能进行）虚拟机实现可能会对第一次解析的结果进行缓存（将直接引用保存在运行时常量池中）**，无论是否真正执行了多次解析动作，虚拟机实现必须保证在同一个实体中，如果一个符号引用之前已经被成功解析过，后续的引用解析请求就应当一直成功，反之亦然。

解析动作主要针对以下7类符号引用

• 类或接口
• 字段
• 类方法（静态方法）
• 接口方法
• 方法类型
• 方法句柄
• 调用点限定符

其中后三种与java的动态语言支持息息相关。

初始化

类初始化阶段是“类加载过程”中最后一步，在之前的阶段，除了在加载阶段用户应用程序可以通过自定义类加载器参与之外，其它动作完全由虚拟机主导和控制，直到初始化阶段，才真正开始执行类中定义的Java程序代码（或者说是字节码）。

在准备阶段，变量已经赋过一次系统要求的初始值，而在初始化阶段，根据程序员通过程序制定的主观计划去初始化类变量和其它资源，简单说，初始化阶段即虚拟机执行类构造器<clinit>()方法的过程。

下面来详细讲解<clinit>()方法是怎么生成的，首先来了解此方法执行过程中可能会影响到程序运行行为的特点和细节：

• <clinit>()方法是由编译器自动收集类中所有类变量的赋值动作和静态语句块（static{} 块）中的语句合并产生的，编译器收集的顺序由语句在源文件中出现的顺序决定，特别注意的是，静态语句块只能访问到定义在它之前的类变量，定义在它之后的类变量只能赋值，不能访问。例如以下代码：

    public class Test {        static {            i = 0;  //  给变量复制可以正常编译通过            System.out.print(i);  // 这句编译器会提示“非法向前引用”          }        static int i = 1;    }

• <clinit>()方法与类的构造函数（或者说实例构造器<init>() 方法）不同，不需要显式的调用父类的()方法。虚拟机会自动保证在子类的<clinit>()方法运行之前，父类的<clinit>()方法已经执行结束。因此虚拟机中第一个执行<clinit>()方法的类肯定为java.lang.Object。
• 由于父类的<clinit>()方法先执行，也就意味着父类中定义的静态语句块要优于子类的变量赋值操作。例如以下代码：

    static class Parent {            public static int A = 1;            static {                A = 2;            }    }    static class Sub extends Parent {            public static int B = A;    }    public static void main(String[] args) {            System.out.println(Sub.B);//输出结果是父类中的静态变量值A，也就是2    }

• <clinit>()方法对于类或接口不是必须的，如果一个类中不包含静态语句块，也没有对类变量的赋值操作，编译器可以不为该类生成<clinit>()方法。
• 接口中不可以使用静态语句块，但仍然有类变量初始化的赋值操作，因此接口与类一样都会生成<clinit>()方法。但接口与类不同的是，执行接口的<clinit>()方法不需要先执行父接口的<clinit>()方法。只有当父接口中定义的变量使用时，父接口才会初始化。另外，接口的实现类在初始化时也一样不会执行接口的<clinit>()方法。
• 虚拟机会保证一个类的<clinit>()方法在多线程环境下被正确的加锁和同步，如果多个线程同时初始化一个类，只会有一个线程执行这个类的<clinit>()方法，其它线程都会阻塞等待，直到活动线程执行<clinit>()方法完毕。如果在一个类的<clinit>()方法中有耗时的操作，就可能造成多个进程阻塞，在实际过程中此种阻塞很隐蔽。

资料：

• 《深入理解Java虚拟机——JVM高级特性与最佳实践》－周志明

From: https://crowhawk.github.io/2017/08/21/jvm_5/

本文翻译自Sangmin Lee发表在Cubrid上的”Become a Java GC Expert”系列文章的第三篇《How to Tune Java Garbage Collection》,本文的作者是韩国人，写在JDK 1.8发布之前，虽然有些地方有些许过时，但整体内容还是非常有价值的。译者此前也看到有人翻译了本文，发现其中有许多错漏生硬和语焉不详之处，因此决定自己翻译一份，供大家分享。 本文系本人独立翻译，转载请注明出处。

本文是“成为Java GC专家”系列文章的第三篇，在系列的第一篇文章《理解Java GC》中，我们了解到了不同GC算法的执行过程、GC的工作原理、新生代和老年代的概念、JDK 7中你需要了解的5种GC类型以及每一种GC对性能的影响。

在系列的第二篇文章《如何监控Java GC》中笔者已经解释了JVM进行实时GC的原理、监控GC的方法以及可以使这一过程更加迅速高效的工具。

在第三篇文章中，笔者将基于实际生产环境中的案例，介绍几个GC优化的最佳参数设置。在此我们假设你已经理解了本系列前两篇文章的内容，因此为了更深入的理解本文所讲内容，我建议你在阅读本篇文章之前先仔细阅读这两篇文章。

或者更准确地说，GC优化对Java基础服务来说是必要的吗？答案是否定的，事实上GC优化对Java基础服务来说在有些场合是可以省去的，但前提是这些正在运行的Java系统，必须包含以下参数或行为：

• 内存大小已经通过 -Xms 和 -Xmx 参数指定过
• 运行在server模式下（使用 -server 参数）
• 系统中没有残留超时日志之类的错误日志

换句话说，如果你在运行时没有手动设置内存大小并且打印出了过多的超时日志，那你就需要对系统进行GC优化。

不过你需要时刻谨记一句话：GC tuning is the last task to be done.

现在来想一想GC优化的最根本原因，垃圾收集器的工作就是清除Java创建的对象，垃圾收集器需要清理的对象数量以及要执行的GC数量均取决于已创建的对象数量。因此，为了使你的系统在GC上表现良好，首先需要减少创建对象的数量。

俗话说“冰冻三尺非一日之寒”，我们在编码时要首先要把下面这些小细节做好，否则一些琐碎的不良代码累积起来将让GC的工作变得繁重而难于管理：

• 使用StringBuilder或StringBuffer来代替String
• 尽量少输出日志

尽管如此，仍然会有我们束手无策的情况。XML和JSON解析过程往往占用了最多的内存，即使我们已经尽可能地少用String、少输出日志，仍然会有大量的临时内存（大约10-100MB）被用来解析XML或JSON文件，但我们又很难弃用XML和JSON。在此，你只需要知道这一过程会占据大量内存即可。

如果在经过几次重复的优化后应用程序的内存用量情况有所改善，那么久可以启动GC优化了。

笔者总结了GC优化的两个目的：

1. 将进入老年代的对象数量降到最低
2. 减少Full GC的执行时间

除了可以在JDK 7及更高版本中使用的G1收集器以外，其他分代GC都是由Oracle JVM提供的。关于分代GC，就是对象在Eden区被创建，随后被转移到Survivor区，在此之后剩余的对象会被转入老年代。也有一些对象由于占用内存过大，在Eden区被创建后会直接被传入老年代。老年代GC相对来说会比新生代GC更耗时，因此，减少进入老年代的对象数量可以显著降低Full GC的频率。你可能会以为减少进入老年代的对象数量意味着把它们留在新生代，事实正好相反，新生代内存的大小是可以调节的。

Full GC的执行时间比Minor GC要长很多，因此，如果在Full GC上花费过多的时间（超过1s），将可能出现超时错误。

• 如果通过减小老年代内存来减少Full GC时间，可能会引起OutOfMemoryError或者导致Full GC的频率升高。
• 另外，如果通过增加老年代内存来降低Full GC的频率，Full GC的时间可能因此增加。

因此，你需要把老年代的大小设置成一个“合适”的值。

正如我在系列的第一篇文章《理解Java GC》末尾提到的，不要幻想着“如果有人用他设置的GC参数获取了不错的性能，我们为什么不复制他的参数设置呢？”，因为对于不用的Web服务，它们创建的对象大小和生命周期都不相同。

举一个简单的例子，如果一个任务的执行条件是A，B，C，D和E，另一个完全相同的任务执行条件只有A和B，那么哪一个任务执行速度更快呢？作为常识来讲，答案很明显是后者。

Java GC参数的设置也是这个道理，设置好几个参数并不会提升GC执行的速度，反而会使它变得更慢。GC优化的基本原则是将不同的GC参数应用到两个及以上的服务器上然后比较它们的性能，然后将那些被证明可以提高性能或减少GC执行时间的参数应用于最终的工作服务器上。

下面这张表展示了与内存大小相关且会影响GC性能的GC参数

表1：GC优化需要考虑的JVM参数

笔者在进行GC优化时最常用的参数是-Xms,-Xmx和-XX:NewRatio。-Xms和-Xmx参数通常是必须的，所以NewRatio的值将对GC性能产生重要的影响。

有些人可能会问如何设置永久代内存大小，你可以用-XX:PermSize和-XX:MaxPermSize参数来进行设置，但是要记住，只有当出现OutOfMemoryError错误时你才需要去设置永久代内存。

还有一个会影响GC性能的因素是垃圾收集器的类型,下表展示了关于GC类型的可选参数（基于JDK 6.0）：

表2：GC类型可选参数

除了G1收集器外，可以通过设置上表中每种类型第一行的参数来切换GC类型，最常见的非侵入式GC就是Serial GC，它针对客户端系统进行了特别的优化。

会影响GC性能的参数还有很多，但是上述的参数会带来最显著的效果，请切记，设置太多的参数并不一定会提升GC的性能。

GC优化的过程和大多数常见的提升性能的过程相似，下面是笔者使用的流程：

1.监控GC状态

你需要监控GC从而检查系统中运行的GC的各种状态，具体方法请查看系列的第二篇文章《如何监控Java GC》

2.分析监控结果后决定是否需要优化GC

在检查GC状态后，你需要分析监控结构并决定是否需要进行GC优化。如果分析结果显示运行GC的时间只有0.1-0.3秒，那么就不需要把时间浪费在GC优化上，但如果运行GC的时间达到1-3秒，甚至大于10秒，那么GC优化将是很有必要的。

但是，如果你已经分配了大约10GB内存给Java，并且这些内存无法省下，那么就无法进行GC优化了。在进行GC优化之前，你需要考虑为什么你需要分配这么大的内存空间，如果你分配了1GB或2GB大小的内存并且出现了OutOfMemoryError，那你就应该执行堆转储（heap dump） 来消除导致异常的原因。

注意：

堆转储（heap dump） 是一个用来检查Java内存中的对象和数据的内存文件。该文件可以通过执行JDK中的jmap命令来创建。在创建文件的过程中，所有Java程序都将暂停，因此，不要再系统执行过程中创建该文件。

你可以在互联网上搜索heap dump的详细说明。对于韩国读者，可以直接参考我去年发布的书：《The story of troubleshooting for Java developers and system operators》 (Sangmin Lee, Hanbit Media, 2011, 416 pages)

3.设置GC类型/内存大小

如果你决定要进行GC优化，那么你需要选择一个GC类型并且为它设置内存大小。此时如果你有多个服务器，请如上文提到的那样，在每台机器上设置不同的GC参数并分析它们的区别。

4.分析结果

在设置完GC参数后就可以开始收集数据，请在收集至少24小时后再进行结果分析。如果你足够幸运，你可能会找到系统的最佳GC参数。如若不然，你还需要分析输出日志并检查分配的内存，然后需要通过不断调整GC类型/内存大小来找到系统的最佳参数。

5.如果结果令人满意，将参数应用到所有服务器上并结束GC优化

如果GC优化的结果令人满意，就可以将参数应用到所有服务器上，并停止GC优化。

在下面的章节中，你将会看到上述每一步所做的具体工作。

在运行中的Web应用服务器（Web Application Server,WAS）上查看GC状态的最佳方式就是使用jstat命令。笔者在《如何监控Java GC》中已经介绍过了jstat命令，所以在本篇文章中我将着重关注数据部分。

下面的例子展示了某个还没有执行GC优化的JVM的状态（虽然它并不是运行服务器）。

$ jstat -gcutil 21719 1sS0    S1    E    O    P    YGC    YGCT    FGC    FGCT GCT48.66 0.00 48.10 49.70 77.45 3428 172.623 3 59.050 231.67348.66 0.00 48.10 49.70 77.45 3428 172.623 3 59.050 231.673

我们先看一下YGC（从应用程序启动到采样时发生 Young GC 的次数）和YGCT（从应用程序启动到采样时 Young GC 所用的时间(秒)），计算YGCT/YGC会得出，平均每次新生代的GC耗时50ms，这是一个很小的数字，通过这个结果可以看出，我们大可不必关注新生代GC对GC性能的影响。

现在来看一下FGC（ 从应用程序启动到采样时发生 Full GC 的次数）和FGCT（从应用程序启动到采样时 Full GC 所用的时间(秒)），计算FGCT/FGC会得出，平均每次老年代的GC耗时19.68s。有可能是执行了三次Full GC，每次耗时19.68s，也有可能是有两次只花了1s,另一次花了58s。不管是哪一种情况，GC优化都是很有必要的。

使用jstat命令可以很容易地查看GC状态，但是分析GC的最佳方式是加上-verbosegc参数来生成日志。在之前的文章中笔者已经解释了如何分析这些日志。HPJMeter是笔者最喜欢的用于分析-verbosegc生成的日志的工具，它简单易用，使用HPJmeter可以很容易地查看GC执行时间以及GC发生频率。

此外，如果GC执行时间满足下列所有条件，就没有必要进行GC优化了：

• Minor GC执行非常迅速（50ms以内）
• Minor GC没有频繁执行（大约10s执行一次）
• Full GC执行非常迅速（1s以内）
• Full GC没有频繁执行（大约10min执行一次）

括号中的数字并不是绝对的，它们也随着服务的状态而变化。有些服务可能要求一次Full GC在0.9s以内，而有些则会放得更宽一些。因此，对于不同的服务，需要按照不同的标准考虑是否需要执行GC优化。

当检查GC状态时，不能只查看Minor GC和Full GC的时间，还必须要关注GC执行的次数。如果新生代空间太小，Minor GC将会非常频繁地执行（有时每秒会执行一次，甚至更多）。此外，传入老年代的对象数目会上升，从而导致Full GC的频率升高。因此，在执行jstat命令时，请使用-gccapacity参数来查看具体占用了多少空间。

设置GC类型

Oracle JVM有5种垃圾收集器，但是在JDK 7以前的版本中，你只能在Parallel GC, Parallel Compacting GC 和CMS GC之中选择，至于具体选择哪个，则没有具体的原则和规则。

既然这样的话，我们如何来选择GC呢？最好的方法是把三种都用上，但是有一点必须明确——CMS GC通常比其他并行（Parallel）GC都要快（这是因为CMS GC是并发的GC），如果确实如此，那只选择CMS GC就可以了，不过CMS GC也不总是更快，当出现concurrent mode failure时，CMS GC就会比并行GC更慢了。

Concurrent mode failure

现在让我们来深入地了解一下concurrent mode failure。

并行GC和CMS GC的最大区别是并行GC采用“标记-整理”(Mark-Compact)算法而CMS GC采用“标记-清除”(Mark-Sweep)算法（具体内容可参照译者的文章《GC算法与内存分配策略》）,compact步骤就是通过移动内存来消除内存碎片，从而消除分配的内存之间的空白区域。

对于并行GC来说，无论何时执行Full GC，都会进行compact工作，这消耗了太多的时间。不过在执行完Full GC后，下次内存分配将会变得更快（因为直接顺序分配相邻的内存）。

相反，CMS GC没有compact的过程，因此CMS GC运行的速度更快。但是也是由于没有整理内存，在进行磁盘清理之前，内存中会有很多零碎的空白区域，这也导致没有足够的空间分配给大对象。例如，在老年代还有300MB可用空间，但是连一个10MB的对象都没有办法被顺序存储在老年代中，在这种情况下，会报出 “concurrent mode failure” 的 warning，然后系统执行compact操作。但是CMS GC在这种情况下执行的compact操作耗时要比并行GC高很多，并且这还会导致另一个问题，关于 “concurrent mode failure” 的详细说明，可用参考Oracle工程师撰写的《Understanding CMS GC Logs》。

综上所述，你需要根据你的系统情况为其选择一个最适合的GC类型。

每个系统都有最适合它的GC类型等着你去寻找，如果你有6台服务器，我建议你每两个服务器设置相同的参数，然后加上-verbosegc参数再分析结果。

设置内存大小

下面展示了内存大小、GC运行次数和GC运行时间之间的关系：

大内存空间

• 减少了GC的次数
• 提高了GC的运行时间

小内存空间

• 增多了GC的次数
• 降低了GC的运行时间

关于如何设置内存的大小，没有一个标准答案，如果服务器资源充足并且Full GC能在1s内完成，把内存设为10GB也是可以的，但是大部分服务器并不处在这种状态中，当内存设为10GB时，Full GC会耗时10-30s,具体的时间自然与对象的大小有关。

既然如此，我们该如何设置内存大小呢？ 通常我推荐设为500MB，这不是说你要通过-Xms500m和-Xmx500m参数来设置WAS内存。根据GC优化之前的状态，如果Full GC后还剩余300MB的空间，那么把内存设为1GB是一个不错的选择（300MB（默认程序占用）+ 500MB（老年代最小空间）+200MB（空闲内存））。这意味着你需要为老年代设置至少500MB空间，因此如果你有三个运行服务器，可以把它们的内存分别设置为1GB，1.5GB，2GB，然后检查结果。

理论上来说，GC执行速度应该遵循1GB> 1.5GB> 2GB，1GB内存时GC执行速度最快。然而，理论上的1GB内存Full GC消耗1s、2GB内存Full GC消耗2 s在现实里是无法保证的，实际的运行时间还依赖于服务器的性能和对象大小。因此，最好的方法是创建尽可能多的测量数据并监控它们。

在设置内存空间大小时，你还需要设置一个参数：NewRatio。NewRatio的值是新生代和老年代空间大小的比例。如果XX:NewRatio=1，则新生代空间:老年代空间=1:1，如果堆内存为1GB，则新生代:老年代=500MB:500MB。如果NewRatio等于2，则新生代:老年代=1:2，因此，NewRatio的值设置得越大，则老年代空间越大，新生代空间越小。

你可能会认为把NewRatio设为1会是最好的选择，然而事实并非如此，根据笔者的经验，当NewRatio设为2或3时，整个GC的状态表现得更好。

**完成GC优化最快地方法是什么？**答案是比较性能测试的结果。为了给每台服务器设置不同的参数并监控它们，最好查看的是一或两天后的数据。当通过性能测试来进行GC优化时，你需要在不同的测试时保证它们有相同的负载和运行环境。然而，即使是专业的性能测试人员，想精确地控制负载也很困难，并且需要大量的时间准备。因此，更加方便容易的方式是直接设置参数来运行，然后等待运行的结果（即使这需要消耗更多的时间）。

在设置了GC参数和-verbosegc参数后，可以使用tail命令确保日志被正确地生成。如果参数设置得不正确或日志未生成，那你的时间就被白白浪费了。如果日志收集没有问题的话，在收集一或两天数据后再检查结果。最简单的方法是把日志从服务器移到你的本地PC上，然后用HPJMeter分析数据。

在分析结果时，请关注下列几点（这个优先级是笔者根据自己的经验拟定的，我认为选取GC参数时应考虑的最重要的因素是Full GC的运行时间。）：

• 单次Full GC运行时间
• 单次Minor GC运行时间
• Full GC运行间隔
• Minor GC运行间隔
• 整个Full GC的时间
• 整个Minor GC的运行时间
• 整个GC的运行时间
• Full GC的执行次数
• Minor GC的执行次数

找到最佳的GC参数是件非常幸运的，然而在大多数时候，我们并不会如此幸运，在进行GC优化时一定要小心谨慎，因为当你试图一次完成所有的优化工作时，可能会出现OutOfMemoryError错误。

到目前为止，我们一直在从理论上介绍GC优化，现在是时候将这些理论付诸实践了，我们将通过几个例子来更深入地理解GC优化。

示例1

下面这个例子是针对Service S的优化，对于最近刚开发出来的Service S，执行Full GC需要消耗过多的时间。

现在看一下执行jstat -gcutil的结果

S0 S1 E O P YGC YGCT FGC FGCT GCT12.16 0.00 5.18 63.78 20.32 54 2.047 5 6.946 8.993

左边的Perm区的值对于最初的GC优化并不重要，而YGC参数的值更加对于这次优化更为重要。

平均执行一次Minor GC和Full GC消耗的时间如下表所示：

表3：Service S的Minor GC 和Full GC的平均执行时间

37ms对于Minor GC来说还不赖，但1.389s对于Full GC来说意味着当GC发生在数据库Timeout设置为1s的系统中时，可能会频繁出现超时现象。

首先，你需要检查开始GC优化前内存的使用情况。使用jstat -gccapacity命令可以检查内存用量情况。在笔者的服务器上查看到的结果如下：

NGCMN NGCMX NGC S0C S1C EC OGCMN OGCMX OGC OC PGCMN PGCMX PGC PC YGC FGC212992.0 212992.0 212992.0 21248.0 21248.0 170496.0 1884160.0 1884160.0 1884160.0 1884160.0 262144.0 262144.0 262144.0 262144.0 54 5

其中的关键值如下：

• 新生代内存用量：212,992 KB
• 老年代内存用量：1,884,160 KB

因此，除了永久代以外，被分配的内存空间加起来有2GB，并且新生代：老年代=1：9，为了得到比使用jstat更细致的结果，还需加上-verbosegc参数获取日志，并把三台服务器按照如下方式设置（除此以外没有使用任何其他参数）：

• NewRatio=2
• NewRatio=3
• NewRatio=4

一天后我得到了系统的GC log，幸运的是，在设置完NewRatio后系统没有发生任何Full GC。

**这是为什么呢？**这是因为大部分对象在创建后很快就被回收了，所有这些对象没有被传入老年代，而是在新生代就被销毁回收了。

在这样的情况下，就没有必要去改变其他的参数值了，只要选择一个最合适的NewRatio值即可。那么，**如何确定最佳的NewRatio值呢？**为此，我们分析一下每种NewRatio值下Minor GC的平均响应时间。

在每种参数下Minor GC的平均响应时间如下：

• NewRatio=2：45ms
• NewRatio=3：34ms
• NewRatio=4：30ms

我们可以根据GC时间的长短得出NewRatio=4是最佳的参数值（尽管NewRatio=4时新生代空间是最小的）。在设置完GC参数后，服务器没有发生Full GC。

为了说明这个问题，下面是服务执行一段时间后执行jstat –gcutil的结果:

S0 S1 E O P YGC YGCT FGC FGCT GCT8.61 0.00 30.67 24.62 22.38 2424 30.219 0 0.000 30.219

你可能会认为是服务器接收的请求少才使得GC发生的频率较低，实际上，虽然Full GC没有执行过，但Minor GC被执行了2424次。

示例2

这是一个Service A的例子。我们通过公司内部的应用性能管理系统（APM）发现JVM暂停了相当长的时间（超过8秒），因此我们进行了GC优化。我们努力寻找JVM暂停的原因，后来发现是因为Full GC执行时间过长，因此我们决定进行GC优化。

在GC优化的开始阶段，我们加上了-verbosegc参数，结果如下图所示：

图1：进行GC优化之前STW的时间

上图是由HPJMeter生成的图片之一。横坐标表示JVM执行的时间，纵坐标表示每次GC的时间。CMS为绿点，表示Full GC的结果，而Parallel Scavenge为蓝点，表示Minor GC的结果。

之前我说过CMS GC是最快的GC，但是上面的结果显示在一些时候CMS耗时达到了15s。 是什么导致了这一结果？ 请记住我之前说的：CMS在执行compact（整理）操作时会显著变慢。此外，服务的内存通过-Xms1g和=Xmx4g设置了，而分配的内存只有4GB。

因此笔者将GC类型从CMS GC改为了Parallel GC，把内存大小设为2GB，并把NewRatio设为3。在执行jstat -gcutil几小时后的结果如下：

S0 S1 E O P YGC YGCT FGC FGCT GCT0.00 30.48 3.31 26.54 37.01 226 11.131 4 11.758 22.890

Full GC的时间缩短了，变成了每次3s，跟15s比有了显著提升。但是3s依然不够快，为此笔者创建了以下6种情况：

• Case 1: -XX:+UseParallelGC -Xms1536m -Xmx1536m -XX:NewRatio=2
• Case 2: -XX:+UseParallelGC -Xms1536m -Xmx1536m -XX:NewRatio=3
• Case 3: -XX:+UseParallelGC -Xms1g -Xmx1g -XX:NewRatio=3
• Case 4: -XX:+UseParallelOldGC -Xms1536m -Xmx1536m -XX:NewRatio=2
• Case 5: -XX:+UseParallelOldGC -Xms1536m -Xmx1536m -XX:NewRatio=3
• Case 6: -XX:+UseParallelOldGC -Xms1g -Xmx1g -XX:NewRatio=3

**上面哪一种情况最快？**结果显示，内存空间越小，运行结果最少。下图展示了性能最好的Case 6的结果图，它的最慢响应时间只有1.7s，并且响应时间的平均值已经被控制到了1s以内。

图2：Case 6的持续时间图

基于上图的结果，按照Case 6调整了GC参数，但这却导致每晚都会发生OutOfMemoryError。很难解释发生异常的具体原因，简单地说，应该是批处理程序导致了内存泄漏，我们正在解决相关的问题。

如果只对GC日志做一些短时间的分析就将相关参数部署到所有服务器上来执行GC优化，这将是非常危险的。切记，只有当你同时仔细分析服务的执行情况和GC日志后，才能保证GC优化没有错误地执行。

在上文中，我们通过两个GC优化的例子来说明了GC优化是怎样执行的。正如上文中提到的，例子中设置的GC参数可以设置在相同的服务器之上，但前提是他们具有相同的CPU、操作系统、JDK版本并且运行着相同的服务。此外，不要把我使用的参数照搬到你的应用上，它们可能在你的机器上并不能起到同样良好的效果。

笔者没有执行heap dump并分析内存的详细内容，而是通过自己的经验进行GC优化。精确地分析内存可以得到更好的优化效果，不过这种分析一般只适用于内存使用量相对固定的场景。如果服务严重过载并占有了大量的内存，则建议你根据之前的经验进行GC优化。

笔者已经在一些服务上设置了G1 GC参数并进行了性能测试，但还没有应用于正式的生产环境。G1 GC的速度快于任何其他的GC类型，但是你必须要升级到JDK 7。此外，暂时还无法保证它的稳定性，没有人知道运行时是否会出现致命的错误，因此G1 GC暂时还不适合投入应用。

等未来JDK 7真正稳定了（这并不是说它现在不稳定），并且WAS针对JDK 7进行优化后，G1 GC最终能按照预期的那样来工作，等到那一天我们可能就不再需要GC优化了。

想了解关于GC优化的更多细节，请前往 Slideshare.com 查看相关资料。强烈推荐 Everything I Ever Learned About JVM Performance Tuning @Twitter,作者是Attila Szegedi, 一名Twitter工程师，请花些时间好好阅读它。

• From: https://crowhawk.github.io/2017/08/21/jvm_4/

如果说收集算法是内存回收的方法论，那么垃圾收集器就是内存回收的具体实现。 Java虚拟机规范中对垃圾收集器应该如何实现并没有任何规定，因此不同的厂商、版本的虚拟机所提供的垃圾收集器都可能会有很大差别，并且一般都会提供参数供用户根据自己的应用特点和要求组合出各个年代所使用的收集器。接下来讨论的收集器基于JDK1.7 Update 14 之后的HotSpot虚拟机（在此版本中正式提供了商用的G1收集器，之前G1仍处于实验状态），该虚拟机包含的所有收集器如下图所示：

上图展示了7种作用于不同分代的收集器，如果两个收集器之间存在连线，就说明它们可以搭配使用。虚拟机所处的区域，则表示它是属于新生代收集器还是老年代收集器。Hotspot实现了如此多的收集器，正是因为目前并无完美的收集器出现，只是选择对具体应用最适合的收集器。

并行和并发

并行（Parallel）：指多条垃圾收集线程并行工作，但此时用户线程仍然处于等待状态。
并发（Concurrent）：指用户线程与垃圾收集线程同时执行（但不一定是并行的，可能会交替执行），用户程序在继续运行。而垃圾收集程序运行在另一个CPU上。

吞吐量（Throughput）

吞吐量就是CPU用于运行用户代码的时间与CPU总消耗时间的比值，即

吞吐量 = 运行用户代码时间 /（运行用户代码时间 + 垃圾收集时间）。

假设虚拟机总共运行了100分钟，其中垃圾收集花掉1分钟，那吞吐量就是99%。

Minor GC 和 Full GC

新生代GC（Minor GC）：指发生在新生代的垃圾收集动作，因为Java对象大多都具备朝生夕灭的特性，所以Minor GC非常频繁，一般回收速度也比较快。具体原理见上一篇文章。
老年代GC（Major GC / Full GC）：指发生在老年代的GC，出现了Major GC，经常会伴随至少一次的Minor GC（但非绝对的，在Parallel Scavenge收集器的收集策略里就有直接进行Major GC的策略选择过程）。Major GC的速度一般会比Minor GC慢10倍以上。

Serial收集器

Serial（串行）收集器是最基本、发展历史最悠久的收集器，它是采用复制算法的新生代收集器，曾经（JDK 1.3.1之前）是虚拟机新生代收集的唯一选择。它是一个单线程收集器，只会使用一个CPU或一条收集线程去完成垃圾收集工作，更重要的是它在进行垃圾收集时，必须暂停其他所有的工作线程，直至Serial收集器收集结束为止（“Stop The World”）。这项工作是由虚拟机在后台自动发起和自动完成的，在用户不可见的情况下把用户正常工作的线程全部停掉，这对很多应用来说是难以接收的。

下图展示了Serial 收集器（老年代采用Serial Old收集器）的运行过程：

为了消除或减少工作线程因内存回收而导致的停顿，HotSpot虚拟机开发团队在JDK 1.3之后的Java发展历程中研发出了各种其他的优秀收集器，这些将在稍后介绍。但是这些收集器的诞生并不意味着Serial收集器已经“老而无用”，实际上到现在为止，它依然是HotSpot虚拟机运行在Client模式下的默认的新生代收集器。它也有着优于其他收集器的地方：简单而高效（与其他收集器的单线程相比），对于限定单个CPU的环境来说，Serial收集器由于没有线程交互的开销，专心做垃圾收集自然可以获得更高的单线程收集效率。

在用户的桌面应用场景中，分配给虚拟机管理的内存一般不会很大，收集几十兆甚至一两百兆的新生代（仅仅是新生代使用的内存，桌面应用基本不会再大了），停顿时间完全可以控制在几十毫秒最多一百毫秒以内，只要不频繁发生，这点停顿时间可以接收。所以，Serial收集器对于运行在Client模式下的虚拟机来说是一个很好的选择。

ParNew 收集器

ParNew收集器就是Serial收集器的多线程版本，它也是一个新生代收集器。除了使用多线程进行垃圾收集外，其余行为包括Serial收集器可用的所有控制参数、收集算法（复制算法）、Stop The World、对象分配规则、回收策略等与Serial收集器完全相同，两者共用了相当多的代码。

ParNew收集器的工作过程如下图（老年代采用Serial Old收集器）：

ParNew收集器除了使用多线程收集外，其他与Serial收集器相比并无太多创新之处，但它却是许多运行在Server模式下的虚拟机中首选的新生代收集器，其中有一个与性能无关的重要原因是，除了Serial收集器外，目前只有它能和CMS收集器（Concurrent Mark Sweep）配合工作，CMS收集器是JDK 1.5推出的一个具有划时代意义的收集器，具体内容将在稍后进行介绍。

ParNew 收集器在单CPU的环境中绝对不会有比Serial收集器有更好的效果，甚至由于存在线程交互的开销，该收集器在通过超线程技术实现的两个CPU的环境中都不能百分之百地保证可以超越。在多CPU环境下，随着CPU的数量增加，它对于GC时系统资源的有效利用是很有好处的。它默认开启的收集线程数与CPU的数量相同，在CPU非常多的情况下可使用 -XX:ParallerGCThreads 参数设置。

Parallel Scavenge 收集器

Parallel Scavenge收集器也是一个并行的多线程新生代收集器，它也使用复制算法。Parallel Scavenge收集器的特点是它的关注点与其他收集器不同，CMS等收集器的关注点是尽可能缩短垃圾收集时用户线程的停顿时间，而Parallel Scavenge收集器的目标是达到一个可控制的吞吐量（Throughput）。

停顿时间越短就越适合需要与用户交互的程序，良好的响应速度能提升用户体验。而高吞吐量则可以高效率地利用CPU时间，尽快完成程序的运算任务，主要适合在后台运算而不需要太多交互的任务。

Parallel Scavenge收集器除了会显而易见地提供可以精确控制吞吐量的参数，还提供了一个参数**-XX:+UseAdaptiveSizePolicy**，这是一个开关参数，打开参数后，就不需要手工指定新生代的大小（-Xmn）、Eden和Survivor区的比例（-XX:SurvivorRatio）、晋升老年代对象年龄（-XX:PretenureSizeThreshold）等细节参数了，虚拟机会根据当前系统的运行情况收集性能监控信息，动态调整这些参数以提供最合适的停顿时间或者最大的吞吐量，这种方式称为GC自适应的调节策略（GC Ergonomics）。自适应调节策略也是Parallel Scavenge收集器与ParNew收集器的一个重要区别。

另外值得注意的一点是，Parallel Scavenge收集器无法与CMS收集器配合使用，所以在JDK 1.6推出Parallel Old之前，如果新生代选择Parallel Scavenge收集器，老年代只有Serial Old收集器能与之配合使用。

Serial Old收集器

Serial Old 是 Serial收集器的老年代版本，它同样是一个单线程收集器，使用 “标记-整理”（Mark-Compact） 算法。

此收集器的主要意义也是在于给Client模式下的虚拟机使用。如果在Server模式下，它还有两大用途：

• 在JDK1.5 以及之前版本（Parallel Old诞生以前）中与Parallel Scavenge收集器搭配使用。
• 作为CMS收集器的后备预案，在并发收集发生Concurrent Mode Failure时使用。

它的工作流程与Serial收集器相同，这里再次给出Serial/Serial Old配合使用的工作流程图：

Parallel Old收集器

Parallel Old 收集器是 Parallel Scavenge 收集器的老年代版本，使用多线程和 “标记-整理” 算法。前面已经提到过，这个收集器是在JDK 1.6中才开始提供的，在此之前，如果新生代选择了Parallel Scavenge收集器，老年代除了Serial Old以外别无选择，所以在Parallel Old诞生以后，“吞吐量优先”收集器终于有了比较名副其实的应用组合，在注重吞吐量以及CPU资源敏感的场合，都可以优先考虑Parallel Scavenge加Parallel Old收集器。Parallel Old收集器的工作流程与Parallel Scavenge相同，这里给出Parallel Scavenge/Parallel Old收集器配合使用的流程图：

CMS收集器

CMS（Concurrent Mark Sweep）收集器是一种以获取最短回收停顿时间为目标的收集器，它非常符合那些集中在互联网站或者B/S系统的服务端上的Java应用，这些应用都非常重视服务的响应速度。从名字上（“Mark Sweep”）就可以看出它是基于 “标记-清除” 算法实现的。

CMS收集器工作的整个流程分为以下4个步骤：

初始标记（CMS initial mark）：仅仅只是标记一下GC Roots能直接关联到的对象，速度很快，需要“Stop The World”。
并发标记（CMS concurrent mark）：进行GC Roots Tracing的过程，在整个过程中耗时最长。
重新标记（CMS remark）：为了修正并发标记期间因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间一般会比初始标记阶段稍长一些，但远比并发标记的时间短。此阶段也需要“Stop The World”。
并发清除（CMS concurrent sweep）

由于整个过程中耗时最长的并发标记和并发清除过程收集器线程都可以与用户线程一起工作，所以，从总体上来说，CMS收集器的内存回收过程是与用户线程一起并发执行的。通过下图可以比较清楚地看到CMS收集器的运作步骤中并发和需要停顿的时间：

优点

CMS是一款优秀的收集器，它的主要优点在名字上已经体现出来了：并发收集、低停顿，因此CMS收集器也被称为并发低停顿收集器（Concurrent Low Pause Collector）。

缺点

对CPU资源非常敏感 其实，面向并发设计的程序都对CPU资源比较敏感。在并发阶段，它虽然不会导致用户线程停顿，但会因为占用了一部分线程（或者说CPU资源）而导致应用程序变慢，总吞吐量会降低。CMS默认启动的回收线程数是（CPU数量+3）/4，也就是当CPU在4个以上时，并发回收时垃圾收集线程不少于25%的CPU资源，并且随着CPU数量的增加而下降。但是当CPU不足4个时（比如2个），CMS对用户程序的影响就可能变得很大，如果本来CPU负载就比较大，还要分出一半的运算能力去执行收集器线程，就可能导致用户程序的执行速度忽然降低了50%，其实也让人无法接受。

无法处理浮动垃圾（Floating Garbage） 可能出现“Concurrent Mode Failure”失败而导致另一次Full GC的产生。由于CMS并发清理阶段用户线程还在运行着，伴随程序运行自然就还会有新的垃圾不断产生。这一部分垃圾出现在标记过程之后，CMS无法再当次收集中处理掉它们，只好留待下一次GC时再清理掉。这一部分垃圾就被称为“浮动垃圾”。也是由于在垃圾收集阶段用户线程还需要运行，那也就还需要预留有足够的内存空间给用户线程使用，因此CMS收集器不能像其他收集器那样等到老年代几乎完全被填满了再进行收集，需要预留一部分空间提供并发收集时的程序运作使用。

标记-清除算法导致的空间碎片 CMS是一款基于“标记-清除”算法实现的收集器，这意味着收集结束时会有大量空间碎片产生。空间碎片过多时，将会给大对象分配带来很大麻烦，往往出现老年代空间剩余，但无法找到足够大连续空间来分配当前对象。

G1（Garbage-First）收集器是当今收集器技术发展最前沿的成果之一，它是一款面向服务端应用的垃圾收集器，HotSpot开发团队赋予它的使命是（在比较长期的）未来可以替换掉JDK 1.5中发布的CMS收集器。与其他GC收集器相比，G1具备如下特点：

并行与并发 G1 能充分利用多CPU、多核环境下的硬件优势，使用多个CPU来缩短“Stop The World”停顿时间，部分其他收集器原本需要停顿Java线程执行的GC动作，G1收集器仍然可以通过并发的方式让Java程序继续执行。
分代收集 与其他收集器一样，分代概念在G1中依然得以保留。虽然G1可以不需要其他收集器配合就能独立管理整个GC堆，但它能够采用不同方式去处理新创建的对象和已存活一段时间、熬过多次GC的旧对象来获取更好的收集效果。
空间整合 G1从整体来看是基于 “标记-整理” 算法实现的收集器，从局部（两个Region之间）上来看是基于 “复制” 算法实现的。这意味着G1运行期间不会产生内存空间碎片，收集后能提供规整的可用内存。此特性有利于程序长时间运行，分配大对象时不会因为无法找到连续内存空间而提前触发下一次GC。
可预测的停顿 这是G1相对CMS的一大优势，降低停顿时间是G1和CMS共同的关注点，但G1除了降低停顿外，还能建立可预测的停顿时间模型，能让使用者明确指定在一个长度为M毫秒的时间片段内，消耗在GC上的时间不得超过N毫秒，这几乎已经是实时Java（RTSJ）的垃圾收集器的特征了。

横跨整个堆内存

在G1之前的其他收集器进行收集的范围都是整个新生代或者老生代，而G1不再是这样。G1在使用时，Java堆的内存布局与其他收集器有很大区别，它将整个Java堆划分为多个大小相等的独立区域（Region），虽然还保留新生代和老年代的概念，但新生代和老年代不再是物理隔离的了，而都是一部分Region（不需要连续）的集合。

建立可预测的时间模型

G1收集器之所以能建立可预测的停顿时间模型，是因为它可以有计划地避免在整个Java堆中进行全区域的垃圾收集。G1跟踪各个Region里面的垃圾堆积的价值大小（回收所获得的空间大小以及回收所需时间的经验值），在后台维护一个优先列表，每次根据允许的收集时间，优先回收价值最大的Region（这也就是Garbage-First名称的来由）。这种使用Region划分内存空间以及有优先级的区域回收方式，保证了G1收集器在有限的时间内可以获取尽可能高的收集效率。

避免全堆扫描——Remembered Set

G1把Java堆分为多个Region，就是“化整为零”。但是Region不可能是孤立的，一个对象分配在某个Region中，可以与整个Java堆任意的对象发生引用关系。在做可达性分析确定对象是否存活的时候，需要扫描整个Java堆才能保证准确性，这显然是对GC效率的极大伤害。

为了避免全堆扫描的发生，虚拟机为G1中每个Region维护了一个与之对应的Remembered Set。虚拟机发现程序在对Reference类型的数据进行写操作时，会产生一个Write Barrier暂时中断写操作，检查Reference引用的对象是否处于不同的Region之中（在分代的例子中就是检查是否老年代中的对象引用了新生代中的对象），如果是，便通过CardTable把相关引用信息记录到被引用对象所属的Region的Remembered Set之中。当进行内存回收时，在GC根节点的枚举范围中加入Remembered Set即可保证不对全堆扫描也不会有遗漏。

如果不计算维护Remembered Set的操作，G1收集器的运作大致可划分为以下几个步骤：

初始标记（Initial Marking） 仅仅只是标记一下GC Roots 能直接关联到的对象，并且修改TAMS（Nest Top Mark Start）的值，让下一阶段用户程序并发运行时，能在正确可以的Region中创建对象，此阶段需要停顿线程，但耗时很短。
并发标记（Concurrent Marking） 从GC Root 开始对堆中对象进行可达性分析，找到存活对象，此阶段耗时较长，但可与用户程序并发执行。
最终标记（Final Marking） 为了修正在并发标记期间因用户程序继续运作而导致标记产生变动的那一部分标记记录，虚拟机将这段时间对象变化记录在线程的Remembered Set Logs里面，最终标记阶段需要把Remembered Set Logs的数据合并到Remembered Set中，这阶段需要停顿线程，但是可并行执行。
筛选回收（Live Data Counting and Evacuation） 首先对各个Region中的回收价值和成本进行排序，根据用户所期望的GC 停顿是时间来制定回收计划。此阶段其实也可以做到与用户程序一起并发执行，但是因为只回收一部分Region，时间是用户可控制的，而且停顿用户线程将大幅度提高收集效率。

通过下图可以比较清楚地看到G1收集器的运作步骤中并发和需要停顿的阶段（Safepoint处）：

收集器串行、并行or并发新生代/老年代算法目标适用场景

Serial
串行
新生代
复制算法
响应速度优先
单CPU环境下的Client模式

Serial Old
串行
老年代
标记-整理
响应速度优先
单CPU环境下的Client模式、CMS的后备预案

ParNew
并行
新生代
复制算法
响应速度优先
多CPU环境时在Server模式下与CMS配合

Parallel Scavenge
并行
新生代
复制算法
吞吐量优先
在后台运算而不需要太多交互的任务

Parallel Old
并行
老年代
标记-整理
吞吐量优先
在后台运算而不需要太多交互的任务

CMS
并发
老年代
标记-清除
响应速度优先
集中在互联网站或B/S系统服务端上的Java应用

G1
并发
both
标记-整理+复制算法
响应速度优先
面向服务端应用，将来替换CMS

本文通过详细介绍HotSpot虚拟机的7种垃圾收集器回答了上一篇文章开头提出的三个问题中的第三个——“如何回收”，在下一篇文章中，我们将回答最后一个未被解答的问题——“什么时候回收”。

参考：

• 《深入理解 Java 虚拟机——JVM 高级特性与最佳实践》－周志明

From: https://crowhawk.github.io/2017/08/15/jvm_3/

说起垃圾收集（Garbage Collection, GC），想必大家都不陌生，它是 JVM 实现里非常重要的一环，JVM 成熟的内存动态分配与回收技术使 Java（当然还有其他运行在 JVM 上的语言，如 Scala 等）程序员在提升开发效率上获得了惊人的便利。理解 GC，对于理解 JVM 和 Java 语言有着非常重要的作用。并且当我们需要排查各种内存溢出、内存泄漏问题时，当垃圾收集称为系统达到更高并发量的瓶颈时，只有深入理解 GC 和内存分配，才能对这些 “自动化” 的技术实施必要的监控和调节。

在 Java 的运行时数据区中，程序计数器、虚拟机栈、本地方法栈三个区域都是线程私有的，随线程而生，随线程而灭，在方法结束或线程结束时，内存自然就跟着回收了，不需要过多考虑回收的问题。而Java 堆和方法区则不一样，一个接口中的多个实现类需要的内存可能不一样，一个方法中的多个分支需要的内存也可能不一样，我们只有在程序处于运行期间才能知道会创建哪些对象，这部分内存的分配和回收都是动态的，垃圾回收器关注的是这部分内存，后续讨论的 “内存” 分配回收也是指这一块，尤其需要注意。

GC 主要回答了以下三个问题：

• 哪些内存需要回收？
• 什么时候回收？
• 如何回收？

这三个问题的具体解决方案，也就是本文接下来要讲解的内容。

在堆里存放着 Java 世界中几乎所有的对象实例，垃圾收集器在对堆进行回收前，首要的就是确定这些对象中哪些还 “存活” 着，哪些已经“死去”（即不可能再被任何途径使用的对象）。

引用计数算法

引用计数算法是在 JVM 中被摒弃的一种对象存活判定算法，不过它也有一些知名的应用场景（如 Python、FlashPlayer），因此在这里也简单介绍一下。

用引用计数器判断对象是否存活的过程是这样的：给对象中添加一个引用计数器，每当有一个地方引用它时，计数器加 1；当引用失效时，计数器减 1；任何时刻计数器为 0 的对象就是不可能再被使用的。

引用计数算法的实现简单，判定效率也很高，大部分情况下是一个不错的算法。它没有被 JVM 采用的原因是它很难解决对象之间循环引用的问题。例如以下例子：

    /**     * testGC()方法执行后，objA 和 objB 会不会被 GC 呢？      */    public class ReferenceCountingGC {            public Object instance = null;            private static final int _1MB = 1024 * 1024;            /**         * 这个成员属性的唯一意义就是占点内存，以便在能在 GC 日志中看清楚是否有回收过         */        private byte[] bigSize = new byte[2 * _1MB];            public static void testGC() {ReferenceCountingGC objA = new ReferenceCountingGC();            ReferenceCountingGC objB = new ReferenceCountingGC();            objA.instance = objB;            objB.instance = objA;                objA = null;            objB = null;                // 假设在这行发生 GC，objA 和 objB 是否能被回收？            System.gc();}    }

在上面这段代码中，对象 objA 和对象 objB 都有字段 instance，赋值令 objA.instance = objB;、objB.instance = objA;，除此之外，这两个对象再无引用。如果 JVM 采用引用计数算法来管理内存，这两个对象不可能再被访问，但是他们互相引用着对方，导致它们引用计数不为 0，所以引用计数器无法通知 GC 收集器回收它们。

而事实上执行这段代码，objA 和 objB 是可以被回收的，下面一节将介绍 JVM 实际使用的存活判定算法。

可达性分析算法

在主流商用程序语言的实现中，都是通过可达性分析（tracing GC）来判定对象是否存活的。此算法的基本思路是：通过一系列的称为“GC Roots”的对象作为起点，从这些节点向下搜索，搜索所走过的路径称为引用链（Reference Chain），当一个对象到 GC Roots 没有任何引用链相连（用图论的话来说，就是 GC Roots 到这个对象不可达）时，则证明此对象时不可用的。用下图来加以说明：

![][1]

[1]: https://pic.yupoo.com/crowhawk/5d0246eb/0635cbe8.png)

上图中，对象 object 5、object 6、object 7 虽然互有关联，但是它们到 GC Roots 是不可达的，所以它们将会被判定为是可回收的对象。

可以看到，GC Roots 在对象图之外，是特别定义的 “起点”，不可能被对象图内的对象所引用。

准确地说，GC Roots 其实不是一组对象，而通常是一组特别管理的指向引用类型对象的指针，这些指针是 tracing GC 的 trace 的起点。它们不是对象图里的对象，对象也不可能引用到这些 “外部” 的指针，这也是 tracing GC 算法不会出现循环引用问题的基本保证。因此也容易得出，只有引用类型的变量才被认为是 Roots，值类型的变量永远不被认为是 Roots。只有深刻理解引用类型和值类型的内存分配和管理的不同，才能知道为什么 root 只能是引用类型。

在 Java 中，可作为 GC Roots 的对象包括以下几种：

虚拟机栈（栈帧中的局部变量表，Local Variable Table） 中引用的对象。
方法区中类静态属性 引用的对象。
方法区中常量 引用的对象。
本地方法栈中 JNI（即一般说的 Native 方法） 引用的对象。

看到这里你可能要问，选择这些对象的依据是什么呢？

可以概括得出，可作为 GC Roots 的节点主要在全局性的引用与执行上下文中。要明确的是，tracing gc 必须以当前存活的对象集为 Roots，因此必须选取确定存活的引用类型对象。GC 管理的区域是 Java 堆，虚拟机栈、方法区和本地方法栈不被 GC 所管理，因此选用这些区域内引用的对象作为 GC Roots，是不会被 GC 所回收的。其中虚拟机栈和本地方法栈都是线程私有的内存区域，只要线程没有终止，就能确保它们中引用的对象的存活。而方法区中类静态属性引用的对象是显然存活的。常量引用的对象在当前可能存活，因此，也可能是 GC roots 的一部分。

两次标记与 finalize()方法

即使在可达性分析算法中不可达的对象，也不是一定会死亡的，它们暂时都处于 “缓刑” 阶段，要真正宣告一个对象“死亡”，至少要经历两次标记过程：

如果对象在进行可达性分析后发现没有与 GC Roots 相连接的引用链，那它将会被第一次标记并且进行一次筛选，筛选的条件是此对象是否有必要执行 finaliza() 方法。当对象没有覆盖 finaliza() 方法，或者 finaliza() 方法已经被虚拟机调用过，虚拟机将这两种情况都视为“没有必要执行”。

如果这个对象被判定为有必要执行 finaliza() 方法，那么此对象将会放置在一个叫做 F-Queue 的队列中，并在稍后由一个虚拟机自动建立的、低优先级的 Finalizer 线程去执行它。这里所谓的 “执行” 是指虚拟机会触发此方法，但并不承诺会等待它运行结束，原因是：如果一个对象在 finaliza() 方法中执行缓慢，或者发生了死循环（更极端的情况），将很可能导致 F-Queue 队列中的其它对象永久处于等待，甚至导致整个内存回收系统崩溃。

finaliza() 方法是对象逃脱死亡命运的最后一次机会，稍后 GC 将对 F-Queue 队列中的对象进行第二次小规模的标记。如果对象想在 finaliza() 方法中成功拯救自己，只要重新与引用链上的任何一个对象建立关联即可，例如把自己（this 关键字）赋值给某个类变量或者对象的成员变量，这样在第二次标记时它将被移出 “即将回收” 的集合；如果对象这时候还没有逃脱，基本上它就真的被回收了。

值得注意的是，如果代码中有两段一模一样的代码段，执行结果却是一次逃脱成功，一次失败。这是因为任何一个对象的 finalize() 方法都只会被系统调用一次，如果对象面临下一次回收，它的 finalize() 方法不会再被执行，因此第二次逃脱行动失败。

需要说明的是，使用 finalize() 方法来 “拯救” 对象是不值得提倡的，因为它不是 C/C++ 中的析构函数，而是 Java 刚诞生时为了使 C/C++ 程序员更容易接受它所做的一个妥协。它的运行代价高昂，不确定性大，无法保证各个对象的调用顺序。finalize() 能做的工作，使用 try-finally 或者其它方法都更适合、及时，所以笔者建议大家可以忘掉此方法存在。

回收方法区

很多人认为方法区没有垃圾回收，Java 虚拟机规范中确实说过不要求，而且在方法区中进行垃圾收集的 “性价比” 较低：在堆中，尤其是新生代，常规应用进行一次垃圾收集可以回收 70%~95% 的空间，而方法区的效率远低于此。在 JDK 1.8 中，JVM 摒弃了永久代，用元空间来作为方法区的实现，下面介绍的将是元空间的垃圾回收。

元空间的内存管理由元空间虚拟机来完成。先前，对于类的元数据我们需要不同的垃圾回收器进行处理，现在只需要执行元空间虚拟机的 C++ 代码即可完成。在元空间中，类和其元数据的生命周期和其对应的类加载器是相同的。话句话说，只要类加载器存活，其加载的类的元数据也是存活的，因而不会被回收掉。

我们从行文到现在提到的元空间稍微有点不严谨。准确的来说，每一个类加载器的存储区域 都称作一个元空间，所有的元空间合在一起就是我们一直说的元空间。 当一个类加载器被垃圾回收器标记为不再存活，其对应的元空间会被回收。在元空间的回收过程中没有重定位和压缩等操作。但是元空间内的元数据会进行扫描来确定 Java 引用。

本节将介绍几种垃圾收集算法的思想及其发展过程，具体的实现将在稍后介绍。

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

标记－清除（Mark-Sweep） 算法是最基础的垃圾收集算法，后续的收集算法都是基于它的思路并对其不足进行改进而得到的。顾名思义，算法分成 “标记”、“清除” 两个阶段：首先标记出所有需要回收的对象，在标记完成后统一回收所有被标记的对象，标记过程在前一节讲述对象标记判定时已经讲过了。

标记－清除算法的不足主要有以下两点：

空间问题，标记清除之后会产生大量不连续的内存碎片，空间碎片太多可能会导致以后在程序运行过程中需要分配较大对象时，无法找到足够的连续内存而不得不触发另一次垃圾收集动作。
效率问题，因为内存碎片的存在，操作会变得更加费时，因为查找下一个可用空闲块已不再是一个简单操作。

标记－清除算法的执行过程如下图所示：

复制（Copying）算法

为了解决标记 - 清除算法的效率问题，一种称为 “复制”（Copying）的收集算法出现了，思想为：它将可用内存按容量分成大小相等的两块，每次只使用其中的一块。当这一块内存用完，就将还存活着的对象复制到另一块上面，然后再把已使用过的内存空间一次清理掉。

这样做使得每次都是对整个半区进行内存回收，内存分配时也就不用考虑内存碎片等复杂情况，只要移动堆顶指针，按顺序分配内存即可，实现简单，运行高效。只是这种算法的代价是将内存缩小为原来的一半，代价可能过高了。复制算法的执行过程如下图所示：

Minor GC 与复制算法

现在的商业虚拟机都使用复制算法来回收新生代。 新生代的 GC 又叫 “Minor GC”，IBM 公司的专门研究表明：新生代中的对象 98% 是 “朝生夕死” 的，所以 Minor GC 非常频繁，一般回收速度也比较快，同时 “朝生夕死” 的特性也使得 Minor GC 使用复制算法时不需要按照 1:1 的比例来划分新生代内存空间。

Minor GC 过程

事实上，新生代将内存分为一块较大的 Eden 空间和两块较小的 Survivor 空间（From Survivor 和 To Survivor），每次 Minor GC 都使用 Eden 和 From Survivor，当回收时，将 Eden 和 From Survivor 中还存活着的对象都一次性地复制到另外一块 To Survivor 空间上，最后清理掉 Eden 和刚使用的 Survivor 空间。一次 Minor GC 结束的时候，Eden空间和From Survivor空间都是空的，而To Survivor空间里面存储着存活的对象。在下次 MinorGC 的时候，两个 Survivor 空间交换他们的标签，现在是空的 “From” Survivor 标记成为 “To”，“To” Survivor 标记为 “From” 。因此，在 MinorGC 结束的时候，Eden 空间是空的，两个 Survivor 空间中的一个是空的，而另一个存储着存活的对象。

HotSpot 虚拟机默认的Eden : Survivor的比例是8 : 1，由于一共有两块 Survivor，所以每次新生代中可用内存空间为整个新生代容量的 90%（80%＋10%），只有 10% 的容量会被“浪费”。

分配担保

上文说的 98% 的对象可回收只是一般场景下的数据，我们没有办法保证每次回收都只有不多于 10% 的对象存活，当 Survivor 空间不够用时，需要依赖老年代内存进行分配担保（Handle Promotion）。如果另外一块 Survivor 上没有足够空间存放上一次新生代收集下来的存活对象，这些对象将直接通过分配担保机制进入老年代。

标记－整理（Mark-Compact）算法

复制算法在对象存活率较高时要进行较多的复制操作，效率将会变低。更关键的是：如果不想浪费 50% 的空间，就需要有额外的空间进行分配担保，以应对被使用的内存中所有对象都 100% 存活的极端情况，所以在老年代一般不能直接选用复制算法。

根据老年代的特点，标记－整理（Mark-Compact）算法被提出来，主要思想为：此算法的标记过程与标记－清除算法一样，但后续步骤不是直接对可回收对象进行清理，而是**让所有存活的对象都向一端移动，然后直接清理掉边界以外的内存。**具体示意图如下所示：

分代收集（Generational Collection）算法

当前商业虚拟机的垃圾收集都采用分代收集（Generational Collection）算法，此算法相较于前几种没有什么新的特征，主要思想为：根据对象存活周期的不同将内存划分为几块，一般是把 Java 堆分为新生代和老年代，这样就可以根据各个年代的特点采用最适合的收集算法：

新生代在新生代中，每次垃圾收集时都发现有大批对象死去，只有少量存活，那就选用复制算法，只需要付出少量存活对象的复制成本就可以完成收集。

老年代在老年代中，因为对象存活率高、没有额外空间对它进行分配担保，就必须使用 “标记 - 清除” 或 “标记 - 整理” 算法来进行回收。

前面两大节主要从理论上介绍了对象存活判定算法和垃圾收集算法，而在 HotSpot 虚拟机上实现这些算法时，必须对算法的执行效率有严格的考量，才能保证虚拟机高效运行。

枚举根节点

从可达性分析中从 GC Roots 节点找引用链这个操作为例，可作为 GC Roots 的节点主要在全局性的引用（例如常量或类静态属性）与执行上下文（例如栈帧中的局部变量表）中，现在很多应用仅仅方法区就有数百兆，如果要逐个检查这里面的引用，那么必然会消耗很多时间。

GC 停顿（”Stop The World”）

另外，可达性分析工作必须在一个能确保一致性的快照中进行——这里 “一致性” 的意思是指在整个分析期间整个执行系统看起来就像被冻结在某个时间点上，不可以出现分析过程中对象引用关系还在不断变化的情况，这是保证分析结果准确性的基础。这点是导致 GC 进行时必须停顿所有 Java 执行线程（Sun 将这件事情称为 “Stop The World” ）的其中一个重要原因，即使是在号称（几乎）不会发生停顿的 CMS 收集器中，枚举根节点时也是必须要停顿的。

准确式 GC 与 OopMap

由于目前的主流 Java 虚拟机使用的都是准确式 GC（即使用准确式内存管理，虚拟机可用知道内存中某个位置的数据具体是什么类型），所以当执行系统停顿下来后，并不需要一个不漏地检查完所有执行上下文和全局的引用位置，虚拟机应当是有办法直接得知哪些地方存放着对象引用。在 HotSpot 的实现中，是使用一组称为OopMap的数据结构来达到这个目的的，在类加载完成的时候，HotSpot 就把对象内什么偏移量上是什么类型的数据计算出来，在 JIT 编译过程中，也会在特定的位置记录下栈和寄存器中哪些位置是引用。这样，GC 在扫描时就可以直接得知这些信息了。

安全点（Safepoint）——进行 GC 时程序停顿的位置

在 OopMap 的协助下，HotSpot 可以快速且准确地完成 GC Roots 枚举，但一个很现实的问题随之而来：可能导致引用关系变化，或者说 OopMap 内容变化的指令非常多，如果为每一条指令都生成对应的 OopMap，那将会需要大量的额外空间，这样 GC 的空间成本将会变得很高。

为此，HotSpot 选择不为每条指令都生成 OopMap，而是只在 “特定的位置” 记录这些信息，这些位置便被称为安全点（Safepoint）。也就是说，程序执行时并非在所有地方都能停顿下来开始 GC，只有在到达安全点时才能暂停。Safepoint 的选定既不能太少以致于让 GC 等待时间太长，也不能过于频繁以致于过分增大运行时的负荷。所以，安全点的选定基本上是以程序 “是否具有让程序长时间执行的特征” 为标准进行选定的——因为每条指令执行的时间都非常短暂，程序不太可能因为指令流长度太长这个原因而过长时间运行，“长时间执行”的最明显特征就是指令序列复用，例如方法调用、循环跳转、异常跳转等，所以具有这些功能的指令才会产生 Safepoint。

对于 Sefepoint，另一个需要考虑的问题是如何在 GC 发生时让所有线程（这里不包括执行 JNI 调用的线程）都 “跑” 到最近的安全点上再停顿下来。这里有两种方案可供选择：

抢先式中断（Preemptive Suspension）抢先式中断不需要线程的执行代码主动去配合，在 GC 发生时，首先把所有线程全部中断，如果发现有线程中断的地方不在安全点上，就恢复线程，让它 “跑” 到安全点上。现在几乎没有虚拟机实现采用抢先式中断来暂停线程从而响应 GC 事件。
主动式中断（Voluntary Suspension） ： 主动式中断的思想是当 GC 需要中断线程的时候，不直接对线程操作，仅仅简单地设置一个标志，各个线程执行时主动去轮询这个标志，发现中断标志为真时就自己中断挂起。轮询标志的地方和安全点是重合的，另外再加上创建对象需要分配内存的地方。

安全区域（Safe Region）

Safepoint机制保证了程序执行时，在不太长的时间内就会遇到可进入 GC 的 Safepoint。但是，程序 “不执行” 的时候（如线程处于 Sleep 状态或 Blocked 状态），这时线程无法响应 JVM 的中断请求，“走到”安全的地方去中断挂起，这时候就需要**安全区域（Safe Region）**来解决。

安全区域是指 在一段代码片段之中，引用关系不会发生变化。在这个区域中的任意地方开始 GC 都是安全的。 我们也可以把 Safe Region 看做是被扩展了的 Safepoint。

在线程执行到 Safe Region 中的代码时，首先标识自己已经进入了 Safe Region，那样，当在这段时间里 JVM 要发起 GC 时，就不用管标识自己为 Safe Region 状态的线程了。在线程要离开 Safe Region 时，它要检查系统是否已经完成了根节点枚举（或者是整个 GC 过程），如果完成了，那线程就继续执行，否则它就必须等待直到收到可以安全离开 Safe Region 的信号为止。

Java 的自动内存管理最终可以归结为自动化地解决了两个问题：

给对象分配内存
回收分配给对象的内存

对象的内存分配通常是在堆上分配（除此以外还有可能经过 JIT 编译后被拆散为标量类型并间接地栈上分配），对象主要分配在新生代的 Eden 区上，如果启动了本地线程分配缓冲，将按线程优先在 TLAB 上分配。少数情况下也可能会直接分配在老年代中，分配的规则并不是固定的，实际取决于垃圾收集器的具体组合以及虚拟机中与内存相关的参数的设置。至于内存回收策略，在上文已经描述得很详尽了。

下面以使用 Serial/Serial Old 收集器（将在下一篇文章中讲解）为例，介绍内存分配的策略。

对象优先在 Eden 区分配

大多数情况下，对象在新生代的 Eden 区中分配。当 Eden 区没有足够空间进行分配时，虚拟机将发起一次 Minor GC。

大对象直接进入老年代

所谓的大对象是指，需要大量连续内存空间的 Java 对象，最典型的大对象就是很长的字符串以及数组。大对象对虚拟机的内存分配来说是一个坏消息（尤其是遇到朝生夕灭的“短命大对象”，写程序时应避免），经常出现大对象容易导致内存还有不少空间时就提前触发 GC 以获取足够的连续空间来安置它们。

虚拟机提供了一个 -XX:PretenureSizeThreshold 参数，令大于这个设置值的对象直接在老年代分配。这样做的目的是避免在 Eden 区及两个 Survivor 区之间发生大量的内存复制（新生代采用复制算法回收内存）。

长期存活的对象将进入老年代

既然虚拟机采用了分代收集的思想来管理内存，那么内存回收时就必须能识别哪些对象应放在新生代，哪些对象应放在老年代中。为了做到这点，虚拟机给每个对象定义了一个对象年龄（Age）计数器。如果对象在 Eden 出生并经过第一次 Minor GC 后仍然存活，并且能被 Survivor 容纳的话，将被移动到 Survivor 空间中，并且对象年龄设为 1。对象在 Survivor 区中每 “熬过” 一次 Minor GC，年龄就增加 1 岁，当它的年龄增加到一定程度（默认为 15 岁），就将会被晋升到老年代中。对象晋升老年代的年龄阈值，可以通过参数-XX:MaxTenuringThreshold设置。

动态对象年龄判定

为了能更好地适应不同程序的内存状况，虚拟机并不是永远地要求对象的年龄必须达到了MaxTenuringThreshold才能晋升老年代，如果在 Survivor 空间中相同年龄所有对象大小的总和大于 Survivor 空间的一半，年龄大于或等于该年龄的对象就可以直接进入老年代，无须等到MaxTenuringThreshold中要求的年龄。

空间分配担保

在发生 Minor GC 之前，虚拟机会先检查老年代最大可用的连续空间是否大于新生代所有对象总空间，如果这个条件成立，那么 Minor GC 可以确保是安全的。如果不成立，则虚拟机会查看HandlePromotionFailure设置值是否允许担保失败。如果允许，那么会继续检查老年代最大可用的连续空间是否大于历次晋升到老年代对象的平均大小，如果大于，将尝试着进行一次 Minor GC，尽管这次 Minor GC 是有风险的；如果小于，或者HandlePromotionFailure设置不允许冒险，那这时也要改为进行一次Full GC。

前面提到过，新生代使用复制收集算法，但为了内存利用率，只使用其中一个 Survivor 空间来作为轮换备份，因此当出现大量对象在 Minor GC 后仍然存活的情况（最极端的情况就是内存回收后新生代中所有对象都存活），就需要老年代进行分配担保，把 Survivor 无法容纳的对象直接进入老年代。 与生活中的贷款担保类似，老年代要进行这样的担保，前提是老年代本身还有容纳这些对象的剩余空间，一共有多少对象会活下来在实际完成内存回收之前是无法明确知道的，所以只好取之前每一次回收晋升到老年代对象容量的平均大小值作为经验值，与老年代的剩余空间进行比较，决定是否进行 Full GC 来让老年代腾出更多空间。

取平均值进行比较其实仍然是一种动态概率的手段，也就是说，如果某次 Minor GC 存活后的对象突增，远远高于平均值的话，依然会导致担保失败（Handle Promotion Failure）。如果出现了HandlePromotionFailure失败，那就只好在失败后重新发起一次 Full GC。虽然担保失败时绕的圈子是最大的，但大部分情况下都还是会将HandlePromotionFailure开关打开，避免 Full GC 过于频繁。

对于 Minor GC，其触发条件非常简单，当 Eden 区空间满时，就将触发一次 Minor GC。而 Full GC 则相对复杂，因此本节我们主要介绍 Full GC 的触发条件。

调用 System.gc()

此方法的调用是建议 JVM 进行 Full GC, 虽然只是建议而非一定, 但很多情况下它会触发 Full GC, 从而增加 Full GC 的频率, 也即增加了间歇性停顿的次数。因此强烈建议能不使用此方法就不要使用，让虚拟机自己去管理它的内存，可通过 -XX:+ DisableExplicitGC 来禁止 RMI 调用 System.gc()。

老年代空间不足

老年代空间不足的常见场景为前文所讲的大对象直接进入老年代、长期存活的对象进入老年代等，当执行 Full GC 后空间仍然不足，则抛出如下错误： Java.lang.OutOfMemoryError: Java heap space 为避免以上两种状况引起的 Full GC，调优时应尽量做到让对象在 Minor GC 阶段被回收、让对象在新生代多存活一段时间及不要创建过大的对象及数组。

空间分配担保失败

前文介绍过，使用复制算法的 Minor GC 需要老年代的内存空间作担保，如果出现了HandlePromotionFailure担保失败，则会触发 Full GC。

JDK 1.7 及以前的永久代空间不足

在 JDK 1.7 及以前，HotSpot 虚拟机中的方法区是用永久代实现的，永久代中存放的为一些 class 的信息、常量、静态变量等数据，当系统中要加载的类、反射的类和调用的方法较多时，Permanet Generation 可能会被占满，在未配置为采用 CMS GC 的情况下也会执行 Full GC。如果经过 Full GC 仍然回收不了，那么 JVM 会抛出如下错误信息： java.lang.OutOfMemoryError: PermGen space 为避免 PermGen 占满造成 Full GC 现象，可采用的方法为增大 PermGen 空间或转为使用 CMS GC。

在 JDK 1.8 中用元空间替换了永久代作为方法区的实现，元空间是本地内存，因此减少了一种 Full GC 触发的可能性。

Concurrent Mode Failure

执行 CMS GC 的过程中同时有对象要放入老年代，而此时老年代空间不足（有时候 “空间不足” 是 CMS GC 时当前的浮动垃圾过多导致暂时性的空间不足触发 Full GC），便会报 Concurrent Mode Failure 错误，并触发 Full GC。

本文简要地介绍了 HotSpot 虚拟机如何去发起内存回收的问题，也解答了文章开头提出的三个问题中的前两个——“哪些内存需要回收”和“何时回收”，同时对于第三个问题——“如何回收”，在原理层面作出了解答。在下一篇文章中，笔者将通过介绍几种具体的垃圾收集器，来更深入地回答第三个问题。

参考：

• 《深入理解 Java 虚拟机——JVM 高级特性与最佳实践》－周志明

From: https://crowhawk.github.io/2017/08/10/jvm_2/

JVM 载执行 Java 程序的过程中会把它所管理的内存划分为若干个不同的数据区域。这些区域都有各自的用途，以及创建和销毁的时间，有的区域随着虚拟机进程的启动而存在，有些区域则是依赖用户线程的启动和结束而建立和销毁。具体如下图所示：

Demo 图：

程序计数器（Program Counter Register）

程序计数器（Program Counter Register）是一块较小的内存空间，可以看作是当前线程所执行的字节码的行号指示器。在虚拟机概念模型中，字节码解释器工作时就是通过改变计数器的值来选取下一条需要执行的字节码指令，分支、循环、跳转、异常处理、线程恢复等基础功能都需要依赖这个计数器来完成。

程序计数器是一块 “线程私有” 的内存，如上文的图所示，每条线程都有一个独立的程序计数器，各条线程之间的计数器互不影响，独立存储。这样设计使得在多线程环境下，线程切换后能恢复到正确的执行位置。

如果线程正在执行的是一个Java 方法，这个计数器记录的是正在执行的虚拟机字节码指令的地址；若执行的是Native 方法，则计数器为空（Undefined）（因为对于 Native 方法而言，它的方法体并不是由 Java 字节码构成的，自然无法应用上述的 “字节码指令的地址” 的概念）。程序计数器也是唯一一个在 Java 虚拟机规范中没有规定任何OutOfMemoryError情况的内存区域。

Java 虚拟机栈（Java Virtual Machine Stacks）

Java 虚拟机栈（Java Virtual Machine Stacks）描述的是 Java 方法执行的内存模型：每个方法在执行的同时都会创建一个栈帧（Stack Frame），栈帧中存储着局部变量表、操作数栈、动态链接、方法出口等信息。每一个方法从调用直至执行完成的过程，会对应一个栈帧在虚拟机栈中入栈到出栈的过程。与程序计数器一样，Java 虚拟机栈也是线程私有的。

函数的调用有完美的嵌套关系——调用者的生命期总是长于被调用者的生命期，并且后者在前者的之内。这样，被调用者的局部信息所占空间的分配总是后于调用者的（后入），而其释放则总是先于调用者的（先出），所以正好可以满足栈的 LIFO 顺序，选用栈这种数据结构来实现调用栈是一种很自然的选择。

局部变量表中存放了编译期可知的各种：

基本数据类型（boolen、byte、char、short、int、 float、 long、double）
对象引用（reference 类型，它不等于对象本身，可能是一个指向对象起始地址的指针，也可能是指向一个代表对象的句柄或其他与此对象相关的位置）
returnAddress 类型（指向了一条字节码指令的地址）

其中 64 位长度的 long 和 double 类型的数据会占用 2 个局部变量空间（Slot），其余数据类型只占用 1 个。局部变量表所需的内存空间在编译期间完成分配，当进入一个方法时，这个方法需要在帧中分配多大的局部变量空间是完全确定的，在方法运行期间不会改变局部变量表的大小。

Java 虚拟机规范中对这个区域规定了两种异常状况：

StackOverflowError：线程请求的栈深度大于虚拟机所允许的深度，将会抛出此异常。
OutOfMemoryError：当可动态扩展的虚拟机栈在扩展时无法申请到足够的内存，就会抛出该异常。

本地方法栈（Native Method Stack）

本地方法栈（Native Method Stack） 与 Java 虚拟机栈作用很相似，它们的区别在于虚拟机栈为虚拟机执行 Java 方法（即字节码）服务，而本地方法栈则为虚拟机使用到的 Native 方法服务。

在虚拟机规范中对本地方法栈中使用的语言、方式和数据结构并无强制规定，因此具体的虚拟机可实现它。甚至有的虚拟机（Sun HotSpot 虚拟机）直接把本地方法栈和虚拟机栈合二为一。与虚拟机一样，本地方法栈会抛出 StackOverflowError 和 OutOfMemoryError 异常。

Java 堆（Heap）

对于大多数应用而言，Java 堆（Heap）是 Java 虚拟机所管理的内存中最大的一块，它被所有线程共享的，在虚拟机启动时创建。此内存区域唯一的目的是存放对象实例，几乎所有的对象实例都在这里分配内存，且每次分配的空间是不定长的。在 Heap 中分配一定的内存来保存对象实例，实际上只是保存对象实例的属性值，属性的类型和对象本身的类型标记等，并不保存对象的方法（方法是指令，保存在 Stack 中）, 在 Heap 中分配一定的内存保存对象实例和对象的序列化比较类似。对象实例在 Heap 中分配好以后，需要在 Stack 中保存一个 4 字节的 Heap 内存地址，用来定位该对象实例在 Heap 中的位置，便于找到该对象实例。

Java 虚拟机规范中描述道：所有的对象实例以及数组都要在堆上分配，但是随着 JIT 编译器的发展和逃逸分析技术逐渐成熟，栈上分配、标量替换优化技术将会导致一些微妙的变化发生，所有的对象都在堆上分配的定论也并不 “绝对” 了。

Java 堆是垃圾收集器管理的主要区域，因此也被称为 “GC 堆（Garbage Collected Heap）”。从内存回收的角度看内存空间可如下划分：

新生代（Young）： 新生成的对象优先存放在新生代中，新生代对象朝生夕死，存活率很低。在新生代中，常规应用进行一次垃圾收集一般可以回收 70% ~ 95% 的空间，回收效率很高。新生代又可细分为 Eden 空间、From Survivor 空间、To Survivor 空间，默认比例为 8:1:1。它们的具体作用将在下一篇文章讲解 GC 时介绍。
老年代（Tenured/Old）：在新生代中经历了多次（具体看虚拟机配置的阀值）GC 后仍然存活下来的对象会进入老年代中。老年代中的对象生命周期较长，存活率比较高，在老年代中进行 GC 的频率相对而言较低，而且回收的速度也比较慢。
永久代（Perm）：永久代存储类信息、常量、静态变量、即时编译器编译后的代码等数据，对这一区域而言，Java 虚拟机规范指出可以不进行垃圾收集，一般而言不会进行垃圾回收。

其中新生代和老年代组成了 Java 堆的全部内存区域，而永久代不属于堆空间，它在 JDK 1.8 以前被 Sun HotSpot 虚拟机用作方法区的实现，关于方法区的具体内容将在稍后介绍。

方法区（Method Area）

方法区（Method Area） 与 Java 堆一样，是各个线程共享的内存区域。 Object Class Data(类定义数据) 是存储在方法区的，此外，常量、静态变量、JIT 编译后的代码也存储在方法区。正因为方法区所存储的数据与堆有一种类比关系，所以它还被称为 Non-Heap。

JDK 1.8 以前的永久代（PermGen）

Java 虚拟机规范对方法区的限制非常宽松，除了和 Java 堆一样不需要连续的内存和可以选择固定大小或者可扩展外，还可以选择不实现垃圾收集，也就是说，Java 虚拟机规范只是规定了方法区的概念和它的作用，并没有规定如何去实现它。对于 JDK 1.8 之前的版本，HotSpot 虚拟机设计团队选择把 GC 分代收集扩展至方法区，即用永久代来实现方法区，这样 HotSpot 的垃圾收集器可以像管理 Java 堆一样管理这部分内存，能够省去专门为方法区编写内存管理代码的工作。对于其他的虚拟机（如Oracle JRockit、IBM J9等）来说是不存在永久代的概念的。

如果运行时有大量的类产生，可能会导致方法区被填满，直至溢出。常见的应用场景如：

• Spring 和 ORM 框架使用 CGLib 操纵字节码对类进行增强，增强的类越多，就需要越大的方法区来保证动态生成的 Class 可以加载入内存。
• 大量 JSP 或动态产生 JSP 文件的应用（JSP 第一次运行时需要编译为 Java 类）。
• 基于 OSGi 的应用（即使是同一个类文件，被不同的类加载器加载也会视为不同的类）。 ……

这些都会导致方法区溢出，报出 java.lang.OutOfMemoryError: PermGen space。

JDK 1.8 的元空间（Metaspace）

在 JDK 1.8 中，HotSpot 虚拟机设计团队为了促进HotSpot与JRockit的融合，修改了方法区的实现，移除了永久代，选择使用本地化的内存空间（而不是 JVM 的内存空间）存放类的元数据，这个空间叫做元空间（Metaspace）。

做了这个改动以后，java.lang.OutOfMemoryError: PermGen 的空间问题将不复存在，并且不再需要调整和监控这个内存空间。且虚拟机需要为方法区设计额外的 GC 策略：如果类元数据的空间占用达到参数 “MaxMetaspaceSize”设置的值，将会触发对死亡对象和类加载器的垃圾回收。 为了限制垃圾回收的频率和延迟，适当的监控和调优元空间是非常有必要的。元空间过多的垃圾收集可能表示类、类加载器内存泄漏或对你的应用程序来说空间太小了。

元空间的内存管理由元空间虚拟机来完成。先前，对于类的元数据我们需要不同的垃圾回收器进行处理，现在只需要执行元空间虚拟机的 C++ 代码即可完成。在元空间中，类和其元数据的生命周期和其对应的类加载器是相同的。话句话说，只要类加载器存活，其加载的类的元数据也是存活的，因而不会被回收掉。

我们从行文到现在提到的元空间稍微有点不严谨。准确的来说，每一个 类加载器的存储区域 都称作一个元空间，所有的元空间合在一起就是我们一直说的元空间。 当一个类加载器被垃圾回收器标记为不再存活，其对应的元空间会被回收。在元空间的回收过程中没有重定位和压缩等操作。但是元空间内的元数据会进行扫描来确定 Java 引用。

元空间虚拟机负责元空间的分配，其采用的形式为组块分配。组块的大小因类加载器的类型而异。在元空间虚拟机中存在一个全局的空闲组块列表。当一个类加载器需要组块时，它就会从这个全局的组块列表中获取并维持一个自己的组块列表。当一个类加载器不再存活，那么其持有的组块将会被释放，并返回给全局组块列表。类加载器持有的组块又会被分成多个块，每一个块存储一个单元的元信息。组块中的块是线性分配（指针碰撞分配形式）。组块分配自内存映射区域。这些全局的虚拟内存映射区域以链表形式连接，一旦某个虚拟内存映射区域清空，这部分内存就会返回给操作系统。

上图展示的是虚拟内存映射区域如何进行元组块的分配。类加载器 1 和 3 表明使用了反射或者为匿名类加载器，他们使用了特定大小组块。 而类加载器 2 和 4 根据其内部条目的数量使用小型或者中型的组块。

运行时常量池（Runtime Constant Pool）

运行时常量池（Runtime Constant Pool）是方法区的一部分。Class 文件中除了有类的版本、字段、方法、接口等描述信息外，还有一项信息是常量池（Constant Pool Table），用于存放编译期生成的各种字面量和符号引用，这部分内容将在类加载后进入方法区的运行时常量池存放。

Java 虚拟机对 Class 文件每一部分（自然包括常量池）的格式有严格规定，每一个字节用于存储那种数据都必须符合规范上的要求才会被虚拟机认可、装载和执行。但对于运行时常量池，Java 虚拟机规范没有做任何有关细节的要求，不同的提供商实现的虚拟机可以按照自己的需求来实现此内存区域。不过一般而言，除了保存 Class 文件中的描述符号引用外，还会把翻译出的直接引用也存储在运行时常量池中。

运行时常量池相对于 Class 文件常量池的另外一个重要特征是具备动态性，Java 语言并不要求常量一定只有编译器才能产生，也就是并非置入 Class 文件中的常量池的内容才能进入方法区运行时常量池，运行期间也可能将新的常量放入池中，此特性被开发人员利用得比较多的便是 String 类的 intern() 方法。

直接内存

直接内存（Direct Memory）并不是虚拟机运行时数据区的一部分，也不是 Java 虚拟机规范中定义的内存区域。但这部分内存也被频繁运用，而却可能导致 OutOfMemoryError 异常出现，所以这里放到一起讲解。

以NIO（New Input/Output） 类为例，NIO 引入了一种基于通道（Channel）与缓冲区（Buffer）的 I/O 方式，它可以使用 Native 函数库直接分配堆外内存，然后通过一个存储在 Java 堆中的 DirectByteBuffer 对象作为这块内存的引用进行操作。这样能避免在 Java 堆和 Native 堆中来回复制数据，在一些场景里显著提高性能。

本机直接内存的分配不会受到 Java 堆大小的限制，但是既然是内存，还是会受到本机总内存（包括 RAM 以及 SWAP 区或分页文件）大小以及处理器寻址空间的限制。服务器管理员在配置虚拟机参数时，会根据实际内存设置 - Xmx 等参数信息，但经常忽略直接内存，使得各个内存区域总和大于物理内存限制（包括物理的和操作系统的限制），从而导致动态扩展时出现 OutOfMemoryError 异常。

对象的创建

Java 的对象创建大致有如下四种方式：

1. new 关键字这应该是我们最常见和最常用最简单的创建对象的方式。
2. 使用 newInstance() 方法这里包括 Class 类的 newInstance() 方法和Constructor类的 newInstance() 方法（前者其实也是调用的后者）。
3. 使用 clone() 方法要使用 clone() 方法我们必须实现实现 Cloneable 接口，用 clone() 方法创建对象并不会调用任何构造函数。即我们所说的 浅拷贝。
4. 反序列化要实现反序列化我们需要让我们的类实现 Serializable 接口。当我们序列化和反序列化一个对象，JVM 会给我们创建一个单独的对象，在反序列化时，JVM 创建对象并不会调用任何构造函数。即我们所说的深拷贝。

上面的四种创建对象的方法除了第一种使用 new 指令之外，其他三种都是使用 invokespecial(构造函数的直接调用)。这里我们只说 new 创建对象的方式，关于 invokespecial 的内容将在后续文章中介绍。下面我们来看看当虚拟机遇到 new 指令的时候对象是如何创建的。

1. 类加载检查

虚拟机遇到一条 new 指令时，首先将去检查这个指令的参数是否能在常量池中定位到一个类的符号引用，并且检查这个符号引用代表的类是否已被加载、解析和初始化过的，如果没有，则必须先执行相应的类加载过程，关于类加载机制和类加载器的详细内容将在后续文章中介绍。

2. 分配内存

在类加载检查通过后，虚拟机就将为新生对象分配内存。对象所需内存的大小在类加载完成后便可完全确定（如何确定在下一节对象内存布局时再详细讲解），为对象分配空间的任务具体便等同于从 Java 堆中划出一块大小确定的内存空间，可以分如下两种情况讨论：

Java 堆中内存绝对规整所有用过的内存都被放在一边，空闲的内存被放在另一边，中间放着一个指针作为分界点的指示器，那所分配内存就仅仅是把那个指针向空闲空间那边挪动一段与对象大小相等的距离，这种分配方式称为 “指针碰撞”（Bump The Pointer）。
Java 堆中的内存不规整已被使用的内存和空闲的内存相互交错，那就没有办法简单的进行指针碰撞了，虚拟机就必须维护一个列表，记录哪些内存块是可用的，在分配的时候从列表中找到一块足够大的空间划分给对象实例，并更新列表上的记录，这种分配方式称为 “空闲列表”（Free List）。

选择哪种分配方式由 Java 堆是否规整决定，而 Java 堆是否规整又由所采用的垃圾收集器是否带有压缩整理功能决定。因此在使用 Serial、ParNew 等带 Compact 过程的收集器时，系统采用的分配算法是指针碰撞，而使用 CMS 这种基于 Mark-Sweep 算法的收集器时（说明一下，CMS 收集器可以通过 UseCMSCompactAtFullCollection 或 CMSFullGCsBeforeCompaction 来整理内存），就通常采用空闲列表。关于垃圾收集器的具体内容将在下一篇文章中介绍。

除如何划分可用空间之外，另外一个需要考虑的问题是对象创建在虚拟机中是非常频繁的行为，即使是仅仅修改一个指针所指向的位置，在并发情况下也并非线程安全的，可能出现正在给对象 A 分配内存，指针还没来得及修改，对象 B 又同时使用了原来的指针来分配内存。解决这个问题有如下两个方案：

对分配内存空间的动作进行同步实际上虚拟机是采用 CAS 配上失败重试的方式保证更新操作的原子性。
把内存分配的动作按照线程划分在不同的空间之中进行即每个线程在 Java 堆中预先分配一小块内存，称为本地线程分配缓冲（TLAB ，Thread Local Allocation Buffer），哪个线程要分配内存，就在哪个线程的 TLAB 上分配，只有 TLAB 用完，分配新的 TLAB 时才需要同步锁定。虚拟机是否使用 TLAB，可以通过 -XX:+/-UseTLAB 参数来设定。

3. 初始化

内存分配完成之后，虚拟机需要将分配到的内存空间都初始化为零值（不包括对象头），如果使用 TLAB 的话，这一个工作也可以提前至 TLAB 分配时进行。这步操作保证了对象的实例字段在 Java 代码中可以不赋初始值就直接使用。

4. 设置对象头

接下来，虚拟机要设置对象的信息（如这个对象是哪个类的实例、如何才能找到类的元数据信息、对象的哈希码、对象的 GC 分代年龄等信息）并存放在对象的对象头（Object Header） 中。根据虚拟机当前的运行状态的不同，如是否启用偏向锁等，对象头会有不同的设置方式。关于对象头的具体内容，在下一节再详细介绍。

5. 执行 <init> 方法

在上面工作都完成之后，在虚拟机的视角来看，一个新的对象已经产生了。但是在 Java 程序的视角看来，对象创建才刚刚开始——<init> 方法还没有执行，所有的字段都还为零值。所以一般来说（由字节码中是否跟随有 invokespecial 指令所决定），new 指令之后会接着执行 <init> 方法，把对象按照程序员的意愿进行初始化，这样一个真正可用的对象才算完全产生出来。

对象的内存布局

HotSpot 虚拟机中，对象在内存中存储的布局可以分为三块区域：对象头（Header）、实例数据（Instance Data）和对齐填充（Padding）。

1. 对象头

HotSpot 虚拟机的对象头包括两部分信息：

对象自身的运行时数据 “Mark Word” 如哈希码（HashCode）、GC 分代年龄、锁状态标志、线程持有的锁、偏向线程 ID、偏向时间戳等等，这部分数据的长度在 32 位和 64 位的虚拟机（暂不考虑开启压缩指针的场景）中分别为 32 个和 64 个 Bits，官方称它为 “Mark Word”。对象需要存储的运行时数据很多，其实已经超出了 32、64 位 Bitmap 结构所能记录的限度，但是对象头信息是与对象自身定义的数据无关的额外存储成本，考虑到虚拟机的空间效率，Mark Word 被设计成一个非固定的数据结构以便在极小的空间内存储尽量多的信息，它会根据对象的状态复用自己的存储空间。例如在 32 位的 HotSpot 虚拟机中对象未被锁定的状态下，Mark Word 的 32 个 Bits 空间中的 25Bits 用于存储对象哈希码（HashCode），4Bits 用于存储对象分代年龄，2Bits 用于存储锁标志位，1Bit 固定为 0，在其他状态（轻量级锁定、重量级锁定、GC 标记、可偏向）下对象的存储内容如下图所示：

类型指针类型指针即对象指向它的类元数据的指针，虚拟机通过这个指针来确定这个对象是哪个类的实例。并不是所有的虚拟机实现都必须在对象数据上保留类型指针，换句话说查找对象的元数据信息并不一定要经过对象本身，这点我们在下一节讨论。另外，如果对象是一个 Java 数组，那在对象头中还必须有一块用于记录数组长度的数据，因为虚拟机可以通过普通 Java 对象的元数据信息确定 Java 对象的大小，但是从数组的元数据中无法确定数组的大小。

2. 实例数据

实例数据是对象真正存储的有效信息，也既是我们在程序代码里面所定义的各种类型的字段内容，无论是从父类继承下来的，还是在子类中定义的都需要记录起来。这部分的存储顺序会受到虚拟机分配策略参数（FieldsAllocationStyle）和字段在 Java 源码中定义顺序的影响。HotSpot 虚拟机默认的分配策略为 longs/doubles、ints、shorts/chars、bytes/booleans、oops（Ordinary Object Pointers），从分配策略中可以看出，相同宽度的字段总是被分配到一起。在满足这个前提条件的情况下，在父类中定义的变量会出现在子类之前。如果 CompactFields 参数值为 true（默认为 true），那子类之中较窄的变量也可能会插入到父类变量的空隙之中。

3. 对齐填充

对齐填充并不是必然存在的，也没有特别的含义，它仅仅起着占位符的作用。由于 HotSpot VM 的自动内存管理系统要求对象起始地址必须是 8 字节的整数倍，换句话说就是对象的大小必须是 8 字节的整数倍。对象头部分正好似 8 字节的倍数（1 倍或者 2 倍），因此当对象实例数据部分没有对齐的话，就需要通过对齐填充来补全。

对象的访问定位

我们的 Java 程序需要通过栈上的对象引用（reference）数据（存储在栈上的局部变量表中）来操作堆上的具体对象。由于 reference 类型在 Java 虚拟机规范里面也只规定了是一个指向对象的引用，并没有定义这个引用的具体实现，对象访问方式也是取决于虚拟机实现而定的。主流的访问方式有使用句柄和直接指针两种。

1. 使用句柄访问

如果使用句柄访问的话，Java 堆中将会划分出一块内存来作为句柄池，reference 中存储的就是对象的句柄地址，而句柄中包含了对象实例数据与类型数据的各自的具体地址信息。如下图所示：

2. 使用直接指针访问

如果使用直接指针访问的话，Java 堆对象的布局中就必须考虑如何放置访问类型数据的相关信息，reference 中存储的直接就是对象地址，如下图所示：

这两种对象访问方式各有优势，下面分别来谈一谈：

句柄使用句柄访问的最大好处就是 reference 中存储的是稳定的句柄地址，在对象被移动（垃圾收集时移动对象是非常普遍的行为）时只会改变句柄中的实例数据指针，而 reference 本身不需要被修改。
直接指针使用直接指针来访问最大的好处就是速度更快，它节省了一次指针定位的时间开销，由于对象访问的在 Java 中非常频繁，因此这类开销积小成多也是一项 非常可观的执行成本。从上一部分讲解的对象内存布局可以看出，HotSpot 是使用直接指针进行对象访问的，不过在整个软件开发的范围来 看，各种语言、框架中使用句柄来访问的情况也十分常见。

参考：

• 《深入理解 Java 虚拟机——JVM 高级特性与最佳实践》－周志明

From: https://crowhawk.github.io/2017/08/09/jvm_1/

关于 JVM 中的 TLAB。

什么是 TLAB？

它是干什么的？咱们先抛开这个问题，一切的开始得从 new 对象到指针碰撞开始讲起。

new 对象与指针碰撞

new 对象怎么就出问题了呢？
Java 中我们要创建一个对象, 用关键字 new 就可以了。但是，在我们日常中，有很多生命周期很短的对象。比如：

    public void dome(){    User user=new user();        user.sayhi();    }

这种对象的作用域都不会逃逸出方法外，也就是说该对象的生命周期会随着方法的调用开始而开始，方法的调用结束而结束。
假设 JVM 所有的对象都放在堆内存中 (为什么用假设，因为 JVM 并不是这样) 一旦方法结束，没有了指向该对象的引用，该对象就需要被 GC 回收，如果存在很多这样的情况，对 GC 来说压力山大呀。

那么什么又是指针碰撞呢？

假设 JVM 虚拟机上，堆内存都是规整的。堆内存被一个指针一分为二。指针的左边都被塞满了对象，指针的右变是未使用的区域。每一次有新的对象创建，指针就会向右移动一个对象 size 的距离。这就被称为指针碰撞。

好，问题来了。如果我们多线程执行刚才那个 dome 方法，一个线程正在给 A 对象分配内存，指针还没有来的及修改，其它为 B 对象分配内存的线程，而且还是引用这之前的指针指向。这样就出现毛病了。
(要注意的是，上面两种情况解决方案不止一个，我今天主要是讲 TLAB，其他方案自行查询)

TLAB 的出现

我们现在已经搞清楚，我们出现了哪些问题。我在为大家介绍一下今天的主角。

TLAB 的全称是 Thread Local Allocation Buffer，即线程本地分配缓存区，这是一个线程专用的内存分配区域。

如果设置了虚拟机参数 -XX:UseTLAB，在线程初始化时，同时也会申请一块指定大小的内存，只给当前线程使用，这样每个线程都单独拥有一个空间，如果需要分配内存，就在自己的空间上分配，这样就不存在竞争的情况，可以大大提升分配效率。

TLAB 空间的内存非常小，缺省情况下仅占有整个 Eden 空间的 1%，也可以通过选项 - XX:TLABWasteTargetPercent 设置 TLAB 空间所占用 Eden 空间的百分比大小。

TLAB 的本质其实是三个指针管理的区域：start，top 和 end，每个线程都会从 Eden 分配一块空间，例如说 100KB，作为自己的 TLAB，其中 start 和 end 是占位用的，标识出 eden 里被这个 TLAB 所管理的区域，卡住 Eden 里的一块空间不让其它线程来这里分配。

TLAB 只是让每个线程有私有的分配指针，但底下存对象的内存空间还是给所有线程访问的，只是其它线程无法在这个区域分配而已。从这一点看，它被翻译为 线程私有分配区 更为合理一点
当一个 TLAB 用满（分配指针 top 撞上分配极限 end 了），就新申请一个 TLAB，而在老 TLAB 里的对象还留在原地什么都不用管——它们无法感知自己是否是曾经从 TLAB 分配出来的，而只关心自己是在 eden 里分配的。

TLAB 的缺点

事务总不是完美的，TLAB 也又自己的缺点。因为 TLAB 通常很小，所以放不下大对象。

1. TLAB 空间大小是固定的，但是这时候一个大对象，我 TLAB 剩余的空间已经容不下它了。(比如 100kb 的 TLAB，来了个 110KB 的对象)
2. TLAB 空间还剩一点点没有用到，有点舍不得。(比如 100kb 的 TLAB，装了 80KB，又来了个 30KB 的对象)
   所以 JVM 开发人员做了以下处理，设置了最大浪费空间。
   当剩余的空间小于最大浪费空间，那该 TLAB 属于的线程在重新向 Eden 区申请一个 TLAB 空间。进行对象创建，还是空间不够，那你这个对象太大了，去 Eden 区直接创建吧！
   当剩余的空间大于最大浪费空间，那这个大对象请你直接去 Eden 区创建，因为我 TLAB 没有使用完的空间还是放不下你。

当然，又会造成新的病垢。
3. Eden 空间够的时候，你再次申请 TLAB 没问题，我不够了，Heap 的 Eden 区要开始 GC。
4. TLAB 允许浪费空间，导致 Eden 区空间不连续，积少成多。以后还要人帮忙打理。

前序文章

• 高并发编程学习(1)——并发基础 - https://www.wmyskxz.com/2019/11/26/gao-bing-fa-bian-cheng-xue-xi-1-bing-fa-ji-chu/1

上一篇文章我们提到一个应用可以创建多个线程去执行不同的任务，如果这些任务之间有着某种关系，那么线程之间必须能够通信来协调完成工作。

生产者消费者问题（英语：Producer-consumer problem）就是典型的多线程同步案例，它也被称为有限缓冲问题（英语：Bounded-buffer problem）。该问题描述了共享固定大小缓冲区2的两个线程——即所谓的“生产者”和“消费者”——在实际运行时会发生的问题。生产者的主要作用是生成一定量的数据放到缓冲区中，然后重复此过程。与此同时，消费者也在缓冲区消耗这些数据。该问题的关键就是要保证生产者不会在缓冲区满时加入数据，消费者也不会在缓冲区中空时消耗数据。(摘自维基百科：生产者消费者问题3)

注意：生产者-消费者模式中的内存缓存区的主要功能是数据在多线程间的共享，此外，通过该缓冲区，可以缓解生产者和消费者的性能差；

准备基础代码：无通信的生产者消费者

我们来自己编写一个例子：一个生产者，一个消费者，并且让他们让他们使用同一个共享资源，并且我们期望的是生产者生产一条放到共享资源中，消费者就会对应地消费一条。

我们先来模拟一个简单的共享资源对象：

public class ShareResource {    private String name;    private String gender;    /**     * 模拟生产者向共享资源对象中存储数据     *     * @param name     * @param gender     */    public void push(String name, String gender) {        this.name = name;        this.gender = gender;    }    /**     * 模拟消费者从共享资源中取出数据     */    public void popup() {        System.out.println(this.name + "-" + this.gender);    }}

然后来编写我们的生产者，使用循环来交替地向共享资源中添加不同的数据：

public class Producer implements Runnable {    private ShareResource shareResource;    public Producer(ShareResource shareResource) {        this.shareResource = shareResource;    }    @Override    public void run() {        for (int i = 0; i < 50; i++) {            if (i % 2 == 0) {                shareResource.push("凤姐", "女");            } else {                shareResource.push("张三", "男");            }        }    }}

接着让我们的消费者不停地消费生产者产生的数据：

public class Consumer implements Runnable {    private ShareResource shareResource;    public Consumer(ShareResource shareResource) {        this.shareResource = shareResource;    }    @Override    public void run() {        for (int i = 0; i < 50; i++) {            shareResource.popup();        }    }}

然后我们写一段测试代码，来看看效果：

public static void main(String[] args) {    // 创建生产者和消费者的共享资源对象    ShareResource shareResource = new ShareResource();    // 启动生产者线程    new Thread(new Producer(shareResource)).start();    // 启动消费者线程    new Thread(new Consumer(shareResource)).start();}

我们运行发现出现了诡异的现象，所有的生产者都似乎消费到了同一条数据：

    张三-男      张三-男      ....以下全是张三-男....  

为什么会出现这样的情况呢？照理说，我的生产者在交替地向共享资源中生产数据，消费者也应该交替消费才对呀..我们大胆猜测一下，会不会是因为消费者是直接循环了 30 次打印共享资源中的数据，而此时生产者还没有来得及更新共享资源中的数据，消费者就已经连续打印了 30 次了，所以我们让消费者消费的时候以及生产者生产的时候都小睡个 10 ms 来缓解消费太快 or 生产太快带来的影响，也让现象更明显一些：

/** * 模拟生产者向共享资源对象中存储数据 * * @param name * @param gender */public void push(String name, String gender) {    try {        Thread.sleep(10);    } catch (InterruptedException ignored) {    }    this.name = name;    this.gender = gender;}/** * 模拟消费者从共享资源中取出数据 */public void popup() {    try {        Thread.sleep(10);    } catch (InterruptedException ignored) {    }    System.out.println(this.name + "-" + this.gender);}

再次运行代码，发现了出现了以下的几种情况：

• 重复消费：消费者连续地出现两次相同的消费情况（张三-男/ 张三-男）；
• 性别紊乱：消费者消费到了脏数据（张三-女/ 凤姐-男）；

分析出现问题的原因

• 重复消费：我们先来看看重复消费的问题，当生产者生产出一条数据的时候，消费者正确地消费了一条，但是当消费者再来共享资源中消费的时候，生产者还没有准备好新的一条数据，所以消费者就又消费到老数据了，这其中的根本原因是生产者和消费者的速率不一致。
• 性别紊乱：再来分析第二种情况。不同于上面的情况，消费者在消费第二条数据时，生产者也正在生产新的数据，但是尴尬的是，生产者只生产了一半儿（也就是该执行完 this.name = name），也就是还没有来得及给 gender 赋值就被消费者给取走消费了.. 造成这样情况的根本原因是没有保证生产者生产数据的原子性。

解决出现的问题

加锁解决性别紊乱

我们先来解决性别紊乱，也就是原子性的问题吧，上一篇文章里我们也提到了，对于这样的原子性操作，解决方法也很简单：加锁。稍微改造一下就好了：

/** * 模拟生产者向共享资源对象中存储数据 * * @param name * @param gender */synchronized public void push(String name, String gender) {    this.name = name;    try {        Thread.sleep(10);    } catch (InterruptedException ignored) {    }    this.gender = gender;}/** * 模拟消费者从共享资源中取出数据 */synchronized public void popup() {    try {        Thread.sleep(10);    } catch (InterruptedException ignored) {    }    System.out.println(this.name + "-" + this.gender);}

• 我们在方法前面都加上了 synchronized 关键字，来保证每一次读取和修改都只能是一个线程，这是因为当 synchronized 修饰在普通同步方法上时，它会自动锁住当前实例对象，也就是说这样改造之后读/ 写操作同时只能进行其一；
• 我把 push 方法小睡的代码改在了赋值 name 和 gender 的中间，以强化验证原子性操作是否成功，因为如果不是原子性的话，就很可能出现赋值 name 还没赋值给 gender 就被取走的情况，小睡一会儿是为了加强这种情况的出现概率（可以试着把 synchronized 去掉看看效果）；

运行代码后发现，并没有出现性别紊乱的现象了，但是重复消费仍然存在。

等待唤醒机制解决重复消费

我们期望的是 张三-男 和 凤姐-女 交替出现，而不是有重复消费的情况，所以我们的生产者和消费者之间需要一点沟通，最容易想到的解决方法是，我们新增加一个标志位，然后在消费者中使用 while 循环判断，不满足条件则不消费，条件满足则退出 while 循环，从而完成消费者的工作。

while (value != desire) {    Thread.sleep(10);}doSomething();

这样做的目的就是为了防止「过快的无效尝试」，这种方法看似能够实现所需的功能，但是却存在如下的问题：

1）难以确保及时性。在睡眠时，基本不消耗处理器的资源，但是如果睡得过久，就不能及时发现条件已经变化，也就是及时性难以保证；
2）难以降低开销。如果降低睡眠的时间，比如休眠 1 毫秒，这样消费者能够更加迅速地发现条件变化，但是却可能消耗更多的处理资源，造成了无端的浪费。

以上两个问题吗，看似矛盾难以调和，但是 Java 通过内置的等待/ 通知机制能够很好地解决这个矛盾并实现所需的功能。

等待/ 通知机制，是指一个线程 A 调用了对象 O 的 wait() 方法进入等待状态，而另一个线程 B 调用了对象 O 的 notifyAll() 方法，线程 A 收到通知后从对象 O 的 wait() 方法返回，进而执行后续操作。上述两个线程都是通过对象 O 来完成交互的，而对象上的 wait 和 notify/ notifyAll 的关系就如同开关信号一样，用来完成等待方和通知方之间的交互工作。

这里有一个比较奇怪的点是，为什么看起来像是线程之间操作的 wait 和 notify/ notifyAll 方法会是 Object 类中的方法，而不是 Thread 类中的方法呢？

• 简单来说：因为 synchronized 中的这把锁可以是任意对象，因为要满足任意对象都能够调用，所以属于 Object 类；
• 专业点说：因为这些方法在操作同步线程时，都必须要标识它们操作线程的锁，只有同一个锁上的被等待线程，可以被同一个锁上的 notify 唤醒，不可以对不同锁中的线程进行唤醒。也就是说，等待和唤醒必须是同一个锁。而锁可以是任意对象，所以可以被任意对象调用的方法是定义在 Object 类中。

好，简单介绍完等待/ 通知机制，我们开始改造吧：

public class ShareResource {    private String name;    private String gender;    // 新增加一个标志位，表示共享资源是否为空，默认为 true    privateboolean isEmpty = true;    /**     * 模拟生产者向共享资源对象中存储数据     *     * @param name     * @param gender     */    synchronized public void push(String name, String gender) {        try {            while (!isEmpty) {                // 当前共享资源不为空的时，则等待消费者来消费                // 使用同步锁对象来调用，表示当前线程释放同步锁，进入等待池，只能被其他线程所唤醒                this.wait();            }            // 开始生产            this.name = name;            Thread.sleep(10);            this.gender = gender;            // 生产结束            isEmpty = false;            // 生产结束唤醒一个消费者来消费            this.notify();        } catch (Exception ignored) {        }    }    /**     * 模拟消费者从共享资源中取出数据     */    synchronized public void popup() {        try {            while (isEmpty) {                // 为空则等着生产者进行生产                // 使用同步锁对象来调用，表示当前线程释放同步锁，进入等待池，只能被其他线程所唤醒                this.wait();            }            // 消费开始            Thread.sleep(10);            System.out.println(this.name + "-" + this.gender);            // 消费结束            isEmpty = true;            // 消费结束唤醒一个生产者去生产            this.notify();        } catch (InterruptedException ignored) {        }    }}

• 我们期望生产者生产一条，然后就去通知消费者消费一条，那么在生产和消费之前，都需要考虑当前是否需要生产 or 消费，所以我们新增了一个标志位来判断，如果不满足则等待；
• 被通知后仍然要检查条件，条件满足，则执行我们相应的生产 or 消费的逻辑，然后改变条件（这里是 isEmpty），并且通知所有等待在对象上的线程；
• 注意：上面的代码中通知使用的 notify() 方法，这是因为例子中写死了只有一个消费者和生产者，在实际情况中建议还是使用 notifyAll() 方法，这样多个消费和生产者逻辑也能够保证（可以自己试一下）；

小结

通过初始版本一步步地分析问题和解决问题，我们就差不多写出了我们经典生产者消费者的经典代码，但通常消费和生产的逻辑是写在各自的消费者和生产者代码里的，这里我为了方便阅读，把他们都抽离到了共享资源上，我们可以简单地再来回顾一下这个消费生产和等待通知的整个过程：

以上就是关于生产者生产一条数据，消费者消费一次的过程了，涉及的一些具体细节我们下面来说。

等待唤醒机制的替代：Lock 和 Condition

我们从上面的中看到了 wait() 和 notify() 方法，只能被同步监听锁对象来调用，否则就会报出 IllegalMonitorZStateException 的异常，那么现在问题来了，我们在上一篇提到的 Lock 机制根本就没有同步锁了，也就是没有自动获取锁和自动释放锁的概念，因为没有同步锁，也就意味着 Lock 机制不能调用 wait 和 notify 方法，我们怎么办呢？

好在 Java 5 中提供了 Lock 机制的同时也提供了用于 Lock 机制控制通信的 Condition 接口，如果大家理解了上面说到的 Object.wait() 和 Object.notify() 方法的话，那么就能很容易地理解 Condition 对象了。

它和 wait() 和 notify() 方法的作用是大致相同的，只不过后者是配合 synchronized 关键字使用的，而 Condition 是与重入锁相关联的。通过 Lock 接口（重入锁就实现了这一接口）的 newCondition() 方法可以生成一个与当前重入锁绑定的 Condition 实例。利用 Condition 对象，我们就可以让线程在合适的时间等待，或者在某一个特定的时刻得到通知，继续执行。

我们拿上面的生产者消费者来举例，修改成 Lock 和 Condition 代码如下：

public class ShareResource {    private String name;    private String gender;    // 新增加一个标志位，表示共享资源是否为空，默认为 true    privateboolean isEmpty = true;    private Lock lock = new ReentrantLock();    private Condition condition = lock.newCondition();    /**     * 模拟生产者向共享资源对象中存储数据     *     * @param name     * @param gender     */    public void push(String name, String gender) {        lock.lock();        try {            while (!isEmpty) {                // 当前共享资源不为空的时，则等待消费者来消费                condition.await();            }            // 开始生产            this.name = name;            Thread.sleep(10);            this.gender = gender;            // 生产结束            isEmpty = false;            // 生产结束唤醒消费者来消费            condition.signalAll();        } catch (Exception ignored) {        } finally {            lock.unlock();        }    }    /**     * 模拟消费者从共享资源中取出数据     */    public void popup() {        lock.lock();        try {            while (isEmpty) {                // 为空则等着生产者进行生产                condition.await();            }            // 消费开始            Thread.sleep(10);            System.out.println(this.name + "-" + this.gender);            // 消费结束            isEmpty = true;            // 消费结束唤醒生产者去生产            condition.signalAll();        } catch (InterruptedException ignored) {        } finally {            lock.unlock();        }    }}

在 JDK 内部，重入锁和 Condition 对象被广泛地使用，以 ArrayBlockingQueue 为例，它的 put() 方法实现如下：

** Main lock guarding all access */final ReentrantLock lock;/** Condition for waiting takes */privatefinal Condition notEmpty;/** Condition for waiting puts */privatefinal Condition notFull;// 构造函数，初始化锁以及对应的 Condition 对象public ArrayBlockingQueue(int capacity, boolean fair) {    if (capacity <= 0)        thrownew IllegalArgumentException();    this.items = new Object[capacity];    lock = new ReentrantLock(fair);    notEmpty = lock.newCondition();    notFull =  lock.newCondition();}public void put(E e) throws InterruptedException {    checkNotNull(e);    final ReentrantLock lock = this.lock;    lock.lockInterruptibly();    try {        while (count == items.length)            // 等待队列有足够的空间            notFull.await();        enqueue(e);    } finally {        lock.unlock();    }}private void enqueue(E x) {    // assert lock.getHoldCount() == 1;    // assert items[putIndex] == null;    final Object[] items = this.items;    items[putIndex] = x;    if (++putIndex == items.length)        putIndex = 0;    count++;    // 通知需要 take() 的线程，队列已有数据    notEmpty.signal();}

同理，对应的 take() 方法实现如下：

public E take() throws InterruptedException {    final ReentrantLock lock = this.lock;    lock.lockInterruptibly();    try {        while (count == 0)            // 如果队列为空，则消费者队列要等待一个非空的信号            notEmpty.await();        return dequeue();    } finally {        lock.unlock();    }}

允许多个线程同时访问：信号量(Semaphore)

以下内容摘录 or 改编自 《实战 Java 高并发程序设计》 3.1.3 节的内容

信号量为多线程协作提供了更为强大的控制方法。广义上说，信号量是对锁的扩展，无论是内部锁 synchronized 还是重入锁 ReentrantLock，一次都只允许一个线程访问一个资源，而信号量却可以指定多个线程，同时访问某一个资源。信号量主要提供了以下构造函数：

public Semaphore(int permits)public Semaphore(int permits, boolean fair)        // 第二个参数可以指定是否公平

在构造信号量对象时，必须要指定信号量的准入数，即同时能申请多少个许可。当每个线程每次只申请一个许可时，这就相当于指定了同时有多少个线程可以访问某一个资源。信号量的主要逻辑如下：

public void acquire()public void acquireUninterruptibly()public boolean tryAcquire()public boolean tryAcquire(long timeout, TimeUnit unit)public void release()

• acquire() 方法尝试获得一个准入的许可。若无法获得，则线程会等待，直到有线程释放一个许可或者当前线程被中断。
• acquireUninterruptibly() 方法和 acquire() 方法类似，但是不响应中断。
• tryAcquire() 尝试获得一个许可，如果成功则返回 true，失败则返回 false，它不会进行等待，立即返回。
• release() 用于在线程访问资源结束后，释放一个许可，以使其他等待许可的线程可以进行资源访问。

在 JDK 的官方 Javadoc 中，就有一个有关信号量使用的简单实例，有兴趣的读者可以自行去翻阅一下，这里给出一个更傻瓜化的例子：

public class SemapDemo implements Runnable {    final Semaphore semaphore = new Semaphore(5);    @Override    public void run() {        try {            semaphore.acquire();            // 模拟耗时操作            Thread.sleep(2000);            System.out.println(Thread.currentThread().getId() + ":done!");            semaphore.release();        } catch (InterruptedException ignore) {        }    }    public static void main(String[] args) {        ExecutorService executorService = Executors.newFixedThreadPool(20);        final SemapDemo demo = new SemapDemo();        for (int i = 0; i < 20; i++) {            executorService.submit(demo);        }    }}

执行程序，就会发现系统以 5 个线程为单位，依次输出带有线程 ID 的提示文本。

在实现上，Semaphore 借助了线程同步框架 AQS（AbstractQueuedSynchornizer），同样借助了 AQS 来实现的是 Java 中可重入锁的实现。AQS 的强大之处在于，你仅仅需要继承它，然后使用它提供的 api 就可以实现任意复杂的线程同步方案，AQS 为我们做了大部分的同步工作，所以这里不细说，之后再来详细探究一下...

我等着你：Thread.join()

如果一个线程 A 执行了 thread.join() 方法，其含义是：当前线程 A 等待 thread 线程终止之后才从 thread.join() 返回。线程 Thread 除了提供 join() 方法之外，还提供了 join(long millis) 和 join(long millis, int nanos) 两个具备超时特性的方法。这两个超时方法表示，如果线程 Thread 在给定的超时时间里没有终止，那么将会从该超时方法中返回。

在下面的代码中，我们创建了 10 个线程，编号 0 ~ 9，每个线程调用前一个线程的 join() 方法，也就是线程 0 结束了，线程 1 才能从 join() 方法中返回，而线程 0 需要等待 main 线程结束。

public class Join {    public static void main(String[] args) throws InterruptedException {        Thread previous = Thread.currentThread();        for (int i = 0; i < 10; i++) {            // 每个线程拥有前一个线程的引用，需要等待前一个线程终止，才能从等待中返回            Thread thread = new Thread(new Domino(previous), String.valueOf(i));            thread.start();            previous = thread;        }        TimeUnit.SECONDS.sleep(5);        System.out.println(Thread.currentThread().getName() + " terminate. ");    }    staticclass Domino implements Runnable {        private Thread thread;        public Domino(Thread thread) {            this.thread = thread;        }        @Override        public void run() {            try {                thread.join();            } catch (InterruptedException ignore) {            }            System.out.println(Thread.currentThread().getName() + " terminate. ");        }    }}

运行程序，可以看到下列输出：

main terminate.0 terminate.1 terminate.2 terminate.3 terminate.4 terminate.5 terminate.6 terminate.7 terminate.8 terminate.9 terminate.

说明每个线程终止的前提都是前驱线程的终止，每个线程等待前驱线程结束后，才从 join() 方法中返回，这里涉及了等待/ 通知机制，在 JDK 的源码中，我们可以看到 join() 的方法如下：

public final synchronized void join(long millis)    throws InterruptedException {    long base = System.currentTimeMillis();    long now = 0;    if (millis < 0) {        thrownew IllegalArgumentException("timeout value is negative");    }    if (millis == 0) {        // 条件不满足则继续等待        while (isAlive()) {            wait(0);        }        // 条件符合则返回    } else {        while (isAlive()) {            long delay = millis - now;            if (delay <= 0) {                break;            }            wait(delay);            now = System.currentTimeMillis() - base;        }    }}

当线程终止时，会调用线程自身的 notifyAll() 方法，会通知所有等待在该线程对象上的线程。可以看到 join() 方法的逻辑结构跟我们上面写的生产者消费者类似，即加锁、循环和处理逻辑三个步骤。

保证可见性：volatile 关键字

我们先从一个有趣的例子入手：

private static boolean isOver = false;public static void main(String[] args) throws InterruptedException {    Thread thread = new Thread(() -> {        while (!isOver) {        }        System.out.println("线程已感知到 isOver 置为 true，线程正常返回!");    });    thread.start();    Thread.sleep(500);    isOver = true;    System.out.println("isOver 已置为 true");}

我们开启了一个主线程和一个子线程，我们期望子线程能够感知到 isOver 变量的变化以结束掉死循环正常返回，但是运行程序却发现并不是像我们期望的那样发生，子线程一直处在了死循环的状态！

为什么会这样呢？

Java 内存模型

关于这一点，我们有几点需要说明，首先需要搞懂 Java 的内存模型：

Java 虚拟机规范中试图定义一种 Java 内存模型（Java Memory Model, JMM）来屏蔽掉各层硬件和操作系统的内存访问差异，以实现让 Java 程序在各种平台下都能达到一致的内存访问效果。

Java 内存模型规定了所有的变量都存储在主内存（Main Memory）中。每条线程还有自己的工作内存（Working Memory），线程的工作内存中保存了被该线程使用到的变量的主内存副本拷贝，线程对变量的所有操作（读取、赋值等）都必须在主内存中进行，而不能直接读写主内存中的变量。不同的线程之间也无法直接访问对方工作内存中的变量，线程间的变量值的传递均需要通过主内存来完成，线程、主内存、工作内存三者的关系如上图。

那么不同的线程之间是如何通信的呢？

在共享内存的并发模型里，线程之间共享程序的公共状态，线程之间通过写-读内存中的公共状态来隐式进行通信，典型的共享内存通信方式就是通过共享对象进行通信。

例如上图线程 A 与 线程 B 之间如果要通信的话，那么就必须经历下面两个步骤：

1. 首先，线程 A 把本地内存 A 更新过的共享变量刷新到主内存中去
2. 然后，线程 B 到主内存中去读取线程 A 之前更新过的共享变量
   

在消息传递的并发模型里，线程之间没有公共状态，线程之间必须通过明确的发送消息来显式进行通信，在 Java 中典型的消息传递方式就是 wait() 和 notify()。

说回刚才出现的问题，就很容易理解了：每个线程都有独占的内存区域，如操作栈、本地变量表等。线程本地保存了引用变量在堆内存中的副本，线程对变量的所有操作都在本地内存区域中进行，执行结束后再同步到堆内存中去。也就是说，我们在主线程中修改的 isOver 的值并没有被子线程读取到（没有被刷入主内存），也就造成了子线程对于 isOver 变量不可见。

解决方法也很简单，只需要在 isOver 变量前加入 volatile 关键字就可以了，这是因为加入了 volatile 修饰的变量允许直接与主内存交互，进行读写操作，保证可见性。

指令重排/ happen-before 原则

再从另一个有趣的例子中入手，这是在高并发场景下会存在的问题：

class LazyInitDemo {    private static TransationService service = null;    public static TransationService getTransationService(){        if (service == null) {            synchronized (this) {                if (service == null) {                    service = new TransationService();                }            }        }    }}

这是一个典型的双重检查锁定思想，这段代码也是一个典型的双重检查锁定（Double-checked Locking）问题。在高并发的情况下，该对象引用在没有同步的情况下进行读写操作，导致用户可能会获取未构造完成的对象。

这是因为指令优化的结果。计算机不会根据代码顺序按部就班地执行相关指令，我们来举一个借书的例子：假如你要去还书并且想要借一个《高并发编程学习》系列丛书，而你的室友恰好也要还书，并且还想让你帮忙借一本《Java 从入门到放弃》。

这件事乍一看有两件事：你的事和你室友的事。先办完你的事，再开始处理你室友的事情是属于单线程的死板行为，此时你会潜意识地进行**「优化」**，例如你可以把你要还的书和你室友需要还的书一起还了，再一起把想要借的书借出来，这其实就相当于合并数据进行存取的操作过程了。

我们知道一条指令的执行是可以分成很多步骤的，简单地说，可以分为：

• 取值 IF
• 译码和去寄存器操作数 ID
• 执行或者有效地址计算 EX
• 存储器访问 MEM
• 写回 WB

由于每一个步骤可能使用不同的硬件完成，因此，聪明的工程师就发明了流水线技术来执行指令，如下图所示：

可以看到，当第 2 条指令执行时，第 1 条执行其实并没有执行完，确切地说第一条指令还没有开始执行，只是刚刚完成了取值操作而已。这样的好处非常明显，假如这里每一个步骤都需要花费 1 毫秒，那么指令 2 等待指令 1 完全执行后再执行，则需要等待 5 毫秒，而使用流水线指令，指令 2 只需要等待 1 毫秒就可以执行了。如此大的性能提升，当然让人眼红。

回到最初的问题，我们分析一下：对于 Java 编译器来说，初始化 TransactionService 实例和将对象地址写到 service 字段并非原子操作，且这两个阶段的执行顺序是未定义的。加入某个线程执行 new TransactionService() 时，构造方法还未被调用，编译器仅仅为该对象分配了内存空间并设为默认值，此时若另一个线程调用 getTransactionService() 方法，由于 service != null，但是此时 service 对象还没有被赋予真正的有效值，从而无法取到正确的 service 单例对象。

对于此问题，一种较为简单的解决方案就是用 volatile 关键字修饰目标属性（适用于 JDK5 及以上版本），这样 service 就限制了编译器对它的相关读写操作，对它的读写操作进行指令重排，确定对象实例化之后才返回引用。

另外指令重排也有自己的规则，并非所有的指令都可以随意改变执行位置，下面列举一下基本的原则：

• 程序次序规则：一个线程内，按照代码顺序，书写在前面的操作先行发生于书写在后面的操作；
• 锁定规则：一个 unLock 操作先行发生于后面对同一个锁的 lock 操作；
• volatile 变量规则：对一个变量的写操作先行发生于后面对这个变量的读操作；
• 传递规则：如果操作 A 先行发生于操作 B，而操作 B 又先行发生于操作 C，则可以得出操作 A 先行发生于操作 C；
• 线程启动规则：Thread 对象的 start() 方法先行发生于此线程的每个一个动作；
• 线程中断规则：对线程 interrupt() 方法的调用先行发生于被中断线程的代码检测到中断事件的发生；
• 线程终结规则：线程中所有的操作都先行发生于线程的终止检测，我们可以通过 Thread.join() 方法结束、Thread.isAlive() 的返回值手段检测到线程已经终止执行；
• 对象终结规则：一个对象的初始化完成先行发生于他的 finalize() 方法的开始；

volatile 不保证原子性

volatile 解决的是多线程共享变量的可见性问题，类似于 synchronized，但不具备 synchronized 的互斥性。所以对 volatile 变量的操作并非都具有原子性，例如我们用下面的例子来说明：

public class VolatileNotAtomic {    private staticvolatilelong count = 0L;    private staticfinalint NUMBER = 10000;    public static void main(String[] args) {        Thread subtractThread = new SubstractThread();        subtractThread.start();        for (int i = 0; i < NUMBER; i++) {            count++;        }        // 等待减法线程结束        while (subtractThread.isAlive()) {        }        System.out.println("count 最后的值为: " + count);    }    private static class SubstractThread extends Thread {        @Override        public void run() {            for (int i = 0; i < NUMBER; i++) {                count--;            }        }    }}

多次执行后，发现结果基本都不为 0。只有在 count++ 和 count-- 两处都进行加锁时，才能正确的返回 0，了解 Java 的童鞋都应该知道这 count++ 和 count-- 都不是一个原子操作，这里就不作说明了。

volatile 的使用优化

在了解一点吧，注明的并发编程大师 Doug lea 在 JDK 7 的并发包里新增一个队列集合类 LinkedTransferQueue，它在使用 volatile 变量时，用一种追加字节的方式来优化对列出队和入队的性能，具体的可以看一下下列的链接，这里就不具体说明了。

• 追加字节方式来优化队列性能？- https://my.oschina.net/u/3694754/blog/29906524

保证原子性：synchronized

Java 中任何一个对象都有一个唯一与之关联的锁，这样的锁作为该对象的一系列标志位存储在对象信息的头部。Java 对象头里的 Mark Word 里默认的存放的对象的 Hashcode/ 分代年龄和锁标记位。32 为 JVM Mark Word 默认存储结构如下：

Java SE 1.6 中，锁一共有 4 种状态，级别从低到高依次是：无锁状态、偏向锁状态、轻量级锁状态和重量级锁状态，这几个状态会随着竞争情况逐渐升级。锁可以升级但不能降级，意味着偏向锁升级成轻量级锁后不能降级成偏向锁。这种锁升级却不能降级的策略，目的是为了提高获得锁和释放锁的效率。

偏向锁

HotSpot 的作者经过研究发现，大多数情况下，锁不仅不存在多线程竞争，而且总是由同一线程多次获得，为了让线程获得锁的代价更低而引入了偏向锁。

• 偏向锁的获取：当一个线程访问同步块并获取锁时，会在对象头和栈帧中的锁记录里存储锁偏向的线程 ID，以后该线程在进入和退出同步块时不需要进行 CAS 操作来加锁和解锁，只需简单地测试一下对象头的 Mark Word 里是否存储着指向当前线程的偏向锁。如果测试成功，表示线程已经获得了锁。如果测试失败，则需要再测试一下 Mark Word 中偏向锁的标识是否设置成 1（表示当前是偏向锁），如果没有设置，则使用 CAS 竞争锁；如果设置了，则尝试使用 CAS 将对象头的偏向锁指向当前线程。

• 偏向锁的撤销：偏向锁使用了一种等到竞争出现才释放锁的机制，所以当其他线程尝试竞争偏向锁时，持有偏向锁的线程才会释放锁。

下图线程 1 展示了偏向锁获取的过程，线程 2 展示了偏向锁撤销的过程。

轻量级锁和自旋锁

如果偏向锁失败，虚拟机并不会立即挂起线程。它还会使用一种称为轻量级锁的优化手段。

线程在执行同步块之前，JVM 会先在当前线程的栈桢中创建用于存储锁记录的空间，并将对象头中的 Mark Word 复制到锁记录中，官方称为 Displaced Mark Word。然后线程尝试使用 CAS 将对象头中的 Mark Word 替换为指向锁记录的指针。如果成功，当前线程获得锁，如果失败，表示其他线程竞争锁，当前线程便尝试使用自旋（自己执行几个空循环再进行尝试）来获取锁。

轻量级解锁时，会使用原子的 CAS 操作将 Displaced Mark Word 替换回到对象头，如果成功，则表示没有竞争发生。如果失败，表示当前锁存在竞争，锁就会膨胀成重量级锁。下图是两个线程同时争夺锁，导致锁膨胀的流程图。

几种锁的比较

下图就简单概括了一下几种锁的比较：

每人一支笔：ThreadLocal

除了控制资源的访问外，我们还可以通过增加资源来保证所有对象的线程安全。比如，让 100 个人填写个人信息表，如果只有一支笔，那么大家就得挨个写，对于管理人员来说，必须保证大家不会去哄抢这仅存的一支笔，否则，谁也填不完。从另外一个角度出发，我们可以干脆就准备 100 支笔，那么所有人都可以各自为营，很快就能完成表格的填写工作。

如果说锁是使用第一种思路，那么 ThreadLocal 就是使用第二种思路了。

当使用 ThreadLocal 维护变量时，其为每个使用该变量的线程提供独立的变量副本，所以每一个线程都可以独立的改变自己的副本，而不会影响其他线程对应的副本。

ThreadLocal 内部实现机制：

1. 每个线程内部都会维护一个类似 HashMap 的对象，称为 ThreadLocalMap，里边会包含若干了 Entry（K-V 键值对），相应的线程被称为这些 Entry 的属主线程；

2. Entry 的 Key 是一个 ThreadLocal 实例，Value 是一个线程特有对象。Entry 的作用即是：为其属主线程建立起一个 ThreadLocal 实例与一个线程特有对象之间的对应关系；

3. Entry 对 Key 的引用是弱引用；Entry 对 Value 的引用是强引用。

ThreadLodal 的副作用

为了让线程安全地共享某个变量，JDK 开出了 ThreadLocal 这副药方，但「是药三分毒」，ThreadLocal 也有一定的副作用。主要问题是「产生脏数据」和「内存泄漏」。这两个问题通常是在线程池中使用 ThreadLocal 引发的，因为线程池有 「线程复用」 和 「内存常驻」 两个特点。

脏数据

线程复用会产生脏数据。由于线程池会重用 Thread 对象，那么与 Thread 绑定的类的静态属性 ThreadLocal 变量也会被重用。如果在实现的线程 run() 方法中不显式地 remove() 清理与线程相关的 ThreadLocal 信息，那么倘若下一个线程不调用 set() 设置初始值，就可能 get() 到重用的线程信息，包括 ThreadLocal 所关联的线程对象的 value 值。

为了方便理解，用一段简要代码来模拟，如下所示：

public class DirtyDataInThreadLocal {    public static ThreadLocal<String> threadLocal = new ThreadLocal<>();    public static void main(String[] args) {        // 使用固定大小为 1 的线程池，说明上一个的线程属性会被下一个线程属性复用        ExecutorService pool = Executors.newFixedThreadPool(1);        for (int i = 0; i < 2; i++) {            Mythread mythread = new Mythread();            pool.execute(mythread);        }    }    private static class Mythread extends Thread {        private static boolean flag = true;        @Override        public void run() {            if (flag) {                // 第 1 个线程 set 后，并没有进行 remove                // 而第二个线程由于某种原因没有进行 set 操作                threadLocal.set(this.getName() + ", session info.");                flag = false;            }            System.out.println(this.getName() + " 线程是 " + threadLocal.get());        }    }}

执行结果：

Thread-0 线程是 Thread-0, session info.Thread-1 线程是 Thread-0, session info.

内存泄漏

在源码注释中提示使用 static 关键字来修饰 ThreadLocal。在此场景下，寄希望于 ThreadLocal 对象失去引用后，触发弱引用机制来回首 Entry 的 Value 就变得不现实了。在上面的例子中，如果不进行 remove() 操作，那么这个线程执行完成后，通过 ThreadLocal 对象持有的 String 对象是不会被释放的。

以上两个问题的解决办法很简单，就是在每次使用完 ThreadLocal 时，必须要及时调用 remove() 方法清理。

1. 《Java 零基础入门教程》 - http://study.163.com/course/courseMain.htm?courseId=10031080285
2. 《Java 并发编程的艺术》
3. 《码出高效 Java 开发手册》 - 杨冠宝（孤尽） 高海慧（鸣莎）著
4. Java 面试知识点解析(二)——高并发编程篇 - https://www.wmyskxz.com/2018/05/10/java-mian-shi-zhi-shi-dian-jie-xi-er-gao-bing-fa-bian-cheng-pian/6
5. 让你彻底理解 Synchronized - https://www.jianshu.com/p/d53bf830fa097
6. 《Offer 来了 - Java 面试核心知识点精讲》 - 王磊 编著
7. 《实战 Java 高并发程序设计》 - 葛一鸣 郭超 编著

原文始发于微信公众号（我没有三颗心脏）：高并发编程学习(2)——线程通信详解