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

题目

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

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

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

若是你在这个问题上面停留超过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线程并必定能对这个改变可见！

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 写-读的内存语义，编译器能够根据具体状况省略没必要要的屏障。

模拟

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

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

publicclassThreadSafeCache{intresult;publicintgetResult(){returnresult;    }publicsynchronizedvoidsetResult(intresult){this.result = result;    }publicstaticvoidmain(String[] args){        ThreadSafeCache threadSafeCache =newThreadSafeCache();for(inti =0; i <8; i++) {newThread(() -> {intx =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便可。

效果：

代码很快正常结束了！

加架构群:705127209 领取资料，里面会分享一些资深架构师录制的视频录像：有Spring，MyBatis，Netty源码分析，高并发、高性能、分布式、微服务架构的原理，JVM性能优化这些成为架构师必备的资料

结论：

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