阿里一道Java并发面试题 (详细分析篇)

说明

前天分享了一篇关于阿里的“Java常见疑惑和陷阱”的文章，有人说这个很早就有了，可能我才注意到，看完以后发现内容很是不错，有几个我也是须要停顿下想一想，若是后续有机会我录制一个视频把这个ppt里面的全部内容，根据个人理解和知道的给你们分享一遍。

若是你以前尚未看过建议好好看一遍：Java常见疑惑和陷阱，若是你须要获取完整ppt，能够在公号对话框回复： “PPT” 便可获取完整文件，只要你发现你看到里面知识点的时候，你须要思考一会，那么就表示你还不太熟悉，你应该去补补相关的基础知识了。

题目

我我的一直认为： 网络、并发相关的知识，相对其余一些编程知识点更难一些，主要是很差调试而且涉及内容太多 ！

因此今天就取一篇并发相关的内容分享下，我相信你们认真看完会有收获的。

你们能够先看看这个问题，看看这个是否有问题呢？ 那里有问题呢？

若是你在这个问题上面停留超过5s的话，那么表示你对这块某些知识还有点模糊，须要再巩固下，下面咱们一块儿来分析下！

结论

多线程并发的同时进行set、get操做，A线程调用set方法，B线程并不必定能对这个改变可见！！！

分析

这个类很是简单，里面有一个属性，有2个方法：get、set方法，一个用来设置属性值，一个用来获取属性值，在设置属性方法上面加了synchronized。

隐式信息： 多线程并发的同时进行set、get操做，A线程调用set方法，B线程能够里面感知到吗？？？

说到这里，问题就变成了synchronized在刚刚说的上下文下面可否保证可见性！！！

关键词synchronized的用法

• 指定加锁对象:对给定对象加锁，进入同步代码前须要得到给定对象的锁。
• 直接做用于实例方法:至关于对当前实例加锁，进入同步代码前要得到当前实例的锁。
• 直接做用于静态方法:至关于对当前类加锁，进入同步代码前要得到当前类的锁。

synchronized它的工做就是对须要同步的代码加锁，使得每一次只有一个线程能够进入同步块（实际上是一种悲观策略）从而保证线程之间得安全性。

从这里咱们能够知道，咱们须要分析的属于第二类状况，也就是说多个线程若是同时进行set方法的时候，因为存在锁，因此会一个一个进行set操做，而且是线程安全的，可是get方法并无加锁，表示假如A线程在进行set的同时B线程能够进行get操做。而且能够多个线程同时进行get操做，可是同一时间最多只能有一个set操做。

Java 内存模型 happens-before原则

JSR-133 内存模型使用 happens-before 的概念来阐述操做之间的内存可见性。在 JMM 中，若是一个操做执行的结果须要对另外一个操做可见，那么这两个操做之间必需要存在 happens-before 关系。这里提到的两个操做既能够是在一个线程以内，也能够是在不一样线程之间。

与程序员密切相关的 happens-before 规则以下：

• 程序顺序规则：一个线程中的每一个操做，happens-before 于该线程中的任意后续操做。
• 监视器锁规则：对一个监视器的解锁，happens-before 于随后对这个监视器的加锁。
• volatile 变量规则：对一个 volatile 域的写，happens-before 于任意后续对这个 volatile 域的读。
• 传递性：若是 A happens-before B，且 B happens-before C，那么 A happens-before C。

注意，两个操做之间具备 happens-before 关系，并不意味着前一个操做必需要在后一个操做以前执行！happens-before 仅仅要求前一个操做（执行的结果）对后一个操做可见，且前一个操做按顺序排在第二个操做以前（the first is visible to and ordered before the second）。

其中有监视器锁规则：对一个监视器的解锁，happens-before 于随后对这个监视器的加锁。 这一条，仅仅只是针对synchronized的set方法，而对于get并无这方面的说明。

其实在这种上下文下面一个synchronized的set方法，一个普通的get方法，a线程调用set方法，b线程并不必定能对这个改变可见！

更多Java内存模型内存欢迎查看：深刻理解 Java 内存模型，写的很是详细，建议多读几遍！！！

volatile

volatile可见性

前面happens-before原则就提到：volatile 变量规则：对一个 volatile 域的写，happens-before 于任意后续对这个 volatile 域的读。 volatile从而保证了多线程下的可见性！！！

volatile 禁止内存重排序

下面是 JMM 针对编译器制定的 volatile 重排序规则表：

为了实现 volatile 的内存语义，编译器在生成字节码时，会在指令序列中插入内存屏障来禁止特定类型的处理器重排序。

下面是基于保守策略的 JMM 内存屏障插入策略：

• 在每一个 volatile 写操做的前面插入一个 StoreStore 屏障。
• 在每一个 volatile 写操做的后面插入一个 StoreLoad 屏障。
• 在每一个 volatile 读操做的后面插入一个 LoadLoad 屏障。
• 在每一个 volatile 读操做的后面插入一个 LoadStore 屏障。

下面是保守策略下，volatile 写操做 插入内存屏障后生成的指令序列示意图：

下面是在保守策略下，volatile 读操做 插入内存屏障后生成的指令序列示意图：

上述 volatile 写操做和 volatile 读操做的内存屏障插入策略很是保守。在实际执行时，只要不改变 volatile 写-读的内存语义，编译器能够根据具体状况省略没必要要的屏障。

更多Java内存模型内存欢迎查看：深刻理解 Java 内存模型，写的很是详细，建议多读几遍！！！

双重检查锁实现单例中就须要用到这个特性！！！

模拟

经过上面的分析，其实这个题目涉及到的内容都提到了，而且进行了解答。

虽然你知道的缘由，可是想模拟并非一件容易的事情！，下面咱们来模拟看看效果：

public class ThreadSafeCache {
    int result;

    public int getResult() {
        return result;
    }

    public synchronized void setResult(int result) {
        this.result = result;
    }

    public static void main(String[] args) {
        ThreadSafeCache threadSafeCache = new ThreadSafeCache();

        for (int i = 0; i < 8; i++) {
            new Thread(() -> {
                int x = 0;
                while (threadSafeCache.getResult() < 100) {
                    x++;
                }
                System.out.println(x);
            }).start();
        }

        try {
            Thread.sleep(1000);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }

        threadSafeCache.setResult(200);
    }
}
复制代码

效果：

程序会一直卡在这边不动，表示set修改的200，get方法并不可见！！！

添加volatile 关键词观察效果

其实例子中synchronized关键字能够去掉，仅仅用volatile便可。

效果：

代码很快正常结束了！

结论： 多线程并发的同时进行set、get操做，A线程调用set方法，B线程并不必定能对这个改变可见！！！，上面的代码中，若是对get方法也加synchronized也是可见的，仍是happens-before的监视器锁规则：对一个监视器的解锁，happens-before 于随后对这个监视器的加锁。，只是volatile比synchronized更轻量级，因此本例直接用volatile。可是对于符合非原子操做i++这里仍是不行的仍是须要synchronized。

更多Java内存模型内存欢迎查看：深刻理解 Java 内存模型，写的很是详细，建议多读几遍！！！

建议好好看看Java常见疑惑和陷阱，里面有不少很优秀的东西，若是你须要获取完整ppt，能够在公号对话框回复： “PPT” 便可获取完整文件！

---

若是读完以为有收获的话，欢迎点赞、关注、加公众号【匠心零度】，查阅更多精彩历史！！！

)