共享问题
小故事
老王（操作系统）有一个功能强大的算盘（CPU），现在想把它租出去，赚一点外快
小南、小女（线程）来使用这个算盘来进行一些计算，并按照时间给老王支付费用
但小南不能一天24小时使用算盘，他经常要小憩一会（sleep），又或是去吃饭上厕所（阻塞 io 操作），有时还需要一根烟，没烟时思路全无（wait）这些情况统称为（阻塞）
在这些时候，算盘没利用起来（不能收钱了），老王觉得有点不划算
另外，小女也想用用算盘，如果总是小南占着算盘，让小女觉得不公平
于是，老王灵机一动，想了个办法 [ 让他们每人用一会，轮流使用算盘 ]（分时系统）
这样，当小南阻塞的时候，算盘可以分给小女使用，不会浪费，反之亦然
最近执行的计算比较复杂，需要存储一些中间结果，而学生们的脑容量（工作内存）不够，所以老王申请了一个笔记本（主存），把一些中间结果先记在本上
计算流程是这样的
但是由于分时系统，有一天还是发生了事故
小南刚读取了初始值 0 做了个 +1 运算，还没来得及写回结果
老王说 [ 小南，你的时间到了，该别人了，记住结果走吧 ]，于是小南念叨着 [ 结果是1，结果是1…] 不甘心地到一边待着去了（上下文切换）
老王说 [ 小女，该你了 ]，小女看到了笔记本上还写着 0 做了一个 -1 运算，将结果 -1 写入笔记本
这时小女的时间也用完了，老王又叫醒了小南：[小南，把你上次的题目算完吧]，小南将他脑海中的结果 1 写入了笔记本
小南和小女都觉得自己没做错，但笔记本里的结果是 1 而不是 0
Java的体现
两个线程对初始值为 0 的静态变量一个做自增，一个做自减，各做 5000 次，结果是 0 吗？
static int counter = 0; public static void main(String[] args) throws InterruptedException { Thread t1 = new Thread(() -> { for (int i = 0; i < 5000; i++) { counter++; } }, "t1"); Thread t2 = new Thread(() -> { for (int i = 0; i < 5000; i++) { counter--; } }, "t2"); t1.start(); t2.start(); t1.join(); t2.join(); log.debug("{}",counter); }
问题分析
以上的结果可能是正数、负数、零。为什么呢？因为 Java 中对静态变量的自增，自减并不是原子操作，要彻底理解，必须从字节码来进行分析
例如对于 i++ 而言（i 为静态变量），实际会产生如下的 JVM 字节码指令：
getstatic i // 获取静态变量i的值 iconst_1 // 准备常量1 iadd // 自增 putstatic i // 将修改后的值存入静态变量i
而对应 i-- 也是类似：
getstatic i // 获取静态变量i的值 iconst_1 // 准备常量1 isub // 自减 putstatic i // 将修改后的值存入静态变量i
而 Java 的内存模型如下，完成静态变量的自增，自减需要在主存和工作内存中进行数据交换：
如果是单线程以上 8 行代码是顺序执行（不会交错）没有问题：
但多线程下这 8 行代码可能交错运行：
出现负数的情况：
出现正数的情况：
临界区 Critical Section
一个程序运行多个线程本身是没有问题的
问题出在多个线程访问共享资源
- 多个线程读共享资源其实也没有问题
- 在多个线程对共享资源读写操作时发生指令交错，就会出现问题
一段代码块内如果存在对共享资源的多线程读写操作，称这段代码块为临界区
例如，下面代码中的临界区
static int counter = 0; static void increment() // 临界区 { counter++; } static void decrement() // 临界区 { counter--; }
竞态条件 Race Condition
多个线程在临界区内执行，由于代码的执行序列不同而导致结果无法预测，称之为发生了竞态条件
synchronized 解决方案
为了避免临界区的竞态条件发生，有多种手段可以达到目的。
- 阻塞式的解决方案：synchronized，Lock
- 非阻塞式的解决方案：原子变量
目前使用阻塞式的解决方案：synchronized，来解决上述问题，即俗称的【对象锁】，它采用互斥的方式让同一时刻至多只有一个线程能持有【对象锁】，其它线程再想获取这个【对象锁】时就会阻塞住。这样就能保证拥有锁的线程可以安全的执行临界区内的代码，不用担心线程上下文切换
synchronized
语法
synchronized(对象) // 线程1， 线程2(blocked) { 临界区 }
解决
static int counter = 0; static final Object room = new Object(); public static void main(String[] args) throws InterruptedException { Thread t1 = new Thread(() -> { for (int i = 0; i < 5000; i++) { synchronized (room) { counter++; } } }, "t1"); Thread t2 = new Thread(() -> { for (int i = 0; i < 5000; i++) { synchronized (room) { counter--; } } }, "t2"); t1.start(); t2.start(); t1.join(); t2.join(); log.debug("{}",counter); }
你可以做这样的类比：
- synchronized(对象) 中的对象，可以想象为一个房间（room），有唯一入口（门）房间只能一次进入一人进行计算，线程 t1，t2 想象成两个人
- 当线程 t1 执行到 synchronized(room) 时就好比 t1 进入了这个房间，并锁住了门拿走了钥匙，在门内执行count++ 代码
- 这时候如果 t2 也运行到了 synchronized(room) 时，它发现门被锁住了，只能在门外等待，发生了上下文切换，阻塞住了
- 这中间即使 t1 的 cpu 时间片不幸用完，被踢出了门外（不要错误理解为锁住了对象就能一直执行下去哦），这时门还是锁住的，t1 仍拿着钥匙，t2 线程还在阻塞状态进不来，只有下次轮到 t1 自己再次获得时间片时才能开门进入
- 当 t1 执行完 synchronized{} 块内的代码，这时候才会从 obj 房间出来并解开门上的锁，唤醒 t2 线程把钥匙给他。t2 线程这时才可以进入 obj 房间，锁住了门拿上钥匙，执行它的 count-- 代码
用图来表示
思考
synchronized 实际是用对象锁保证了临界区内代码的原子性，临界区内的代码对外是不可分割的，不会被线程切换所打断。
为了加深理解，请思考下面的问题
1.如果把 synchronized(obj) 放在 for 循环的外面，如何理解？
其实很好回答，就是相当于保证了整个for循环的原子性。
2.如果 t1 synchronized(obj1) 而 t2 synchronized(obj2) 会怎样运作？
相当于没有作用，因为想要保护共享资源，需要让多个资源保护同一把锁
3.如果 t1 synchronized(obj) 而 t2 没有加会怎么样？如何理解？
由于线程2没有加锁，根据上图所示，第一次上下文切换的时候，就不会出现获取锁被阻塞的情况，所以就会直接写入，导致出现问题。
面向对象的改进
把需要保护的共享变量放入一个类
class Room { int value = 0; public void increment() { synchronized (this) { value++; } } public void decrement() { synchronized (this) { value--; } } public int get() { synchronized (this) { return value; } } } @Slf4j public class Test1 { public static void main(String[] args) throws InterruptedException { Room room = new Room(); Thread t1 = new Thread(() -> { for (int j = 0; j < 5000; j++) { room.increment(); } }, "t1"); Thread t2 = new Thread(() -> { for (int j = 0; j < 5000; j++) { room.decrement(); } }, "t2"); t1.start(); t2.start(); t1.join(); t2.join(); log.debug("count: {}" , room.get()); } }
这里其实需要关注的是为什么get方法也上锁了，其实是为了保证获取值是一个准确的结果，而不是一个中间的结果，需要加锁。
方法上的synchronized
class Test{ public synchronized void test() { } } 等价于 class Test{ public void test() { synchronized(this) { // 实际上是对 对象实例上锁，而不是对象本身 } } } class Test{ public synchronized static void test() { } } 等价于 class Test{ public static void test() { synchronized(Test.class) { } } }
所谓的线程八锁
其实就是考察 synchronized 锁住的是哪个对象
情况1：
class Number{ public synchronized void a() { log.debug("1"); } public synchronized void b() { log.debug("2"); } } public static void main(String[] args) { Number n1 = new Number(); new Thread(()->{ n1.a(); }).start(); new Thread(()->{ n1.b(); }).start(); }
先1后2 或者 先2后1 原因是因为 同一个对象实例，都是同一把锁，谁先抢到锁谁先输出
情况2：
class Number{ public synchronized void a() { sleep(1); log.debug("1"); } public synchronized void b() { log.debug("2"); } } public static void main(String[] args) { Number n1 = new Number(); new Thread(()->{ n1.a(); }).start(); new Thread(()->{ n1.b(); }).start(); }
1s后1 2 或者 2 1s后 1 情况与情况1一致
情况3：
class Number{ public synchronized void a() { sleep(1); log.debug("1"); } public synchronized void b() { log.debug("2"); } public void c() { log.debug("3"); } } public static void main(String[] args) { Number n1 = new Number(); new Thread(()->{ n1.a(); }).start(); new Thread(()->{ n1.b(); }).start(); new Thread(()->{ n1.c(); }).start(); }
先 3 1s后 1 2 或者 2 3 1s 后 1 或者 3 2 1s 后 1 这个总体上还是和情况1一致
情况4：
class Number{ public synchronized void a() { sleep(1); log.debug("1"); } public synchronized void b() { log.debug("2"); } } public static void main(String[] args) { Number n1 = new Number(); Number n2 = new Number(); new Thread(()->{ n1.a(); }).start(); new Thread(()->{ n2.b(); }).start(); }
2 1s 后 1 之所以会出现这样的情况是因为，因为 synchronized（this）锁住的是 实例对象，而main中有两个不一样的实例，那么其实就相当于没加锁，所以自然是这个执行顺序
剑指JUC原理-4.共享资源和线程安全性（下）:https://developer.aliyun.com/article/1413596
