说明
前天分享了一篇关于阿里的 "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" 即可获取完整文件!
来源: https://www.cnblogs.com/jiangxinlingdu/p/10842321.html