4.4 解决之前的线程不安全问题
这里用到的机制，我们马上会给大家解释。
static class Counter { public int count = 0; synchronized void increase() { count++; } } public static void main(String[] args) throws InterruptedException { final Counter counter = new Counter(); Thread t1 = new Thread(() -> { for (int i = 0; i < 50000; i++) { counter.increase(); } }); Thread t2 = new Thread(() -> { for (int i = 0; i < 50000; i++) { counter.increase(); } }); t1.start(); t2.start(); t1.join(); t2.join(); System.out.println(counter.count); }
5. synchronized[ˈsɪŋkrənaɪzd] 关键字-监视器锁monitor lock
所以加锁，是要明确执行对哪个对象加锁的。
如果两个线程针对同一个对象加锁，会产生阻塞等待(锁竞争/锁冲突)
如果两个线程针对不同对象加锁，不会阻塞等待(不会锁竞争/锁冲突)
无论这个对象是个啥对象，原则就一条，锁对象相同，就会产生锁竞争(产生阻塞等待)，锁对象不同就不会产生锁竞争(不会阻塞等待)
5.1 synchronized 的特性
1)互斥
synchronized 会起到互斥效果, 某个线程执行到某个对象的 synchronized 中时, 其他线程如果也执行到 同一个对象 synchronized 就会阻塞等待.
- 进入 synchronized 修饰的代码块, 相当于 加锁
- 退出 synchronized 修饰的代码块, 相当于 解锁
synchronized用的锁是存在Java对象头里的。
可以粗略理解成, 每个对象在内存中存储的时候, 都存有一块内存表示当前的 “锁定” 状态(类似于厕 所的 “有人/无人”).
如果当前是 “无人” 状态, 那么就可以使用, 使用时需要设为 “有人” 状态.
如果当前是 “有人” 状态, 那么其他人无法使用, 只能排队
一个线程先上了锁，其他线程只能等待这个线程释放。
理解 “阻塞等待”.
针对每一把锁, 操作系统内部都维护了一个等待队列. 当这个锁被某个线程占有的时候, 其他线程尝 试进行加锁, 就加不上了, 就会阻塞等待, 一直等到之前的线程解锁之后, 由操作系统唤醒一个新的 线程, 再来获取到这个锁.
注意:
- 上一个线程解锁之后, 下一个线程并不是立即就能获取到锁. 而是要靠操作系统来 “唤醒”. 这 也就是操作系统线程调度的一部分工作.
- 假设有 A B C 三个线程, 线程 A 先获取到锁, 然后 B 尝试获取锁, 然后 C 再尝试获取锁, 此时 B 和 C 都在阻塞队列中排队等待. 但是当 A 释放锁之后, 虽然 B 比 C 先来的, 但是 B 不一定就能 获取到锁, 而是和 C 重新竞争, 并不遵守先来后到的规则.
synchronized的底层是使用操作系统的mutex lock实现的.
2)刷新内存
synchronized 的工作过程:
- 获得互斥锁
- 从主内存拷贝变量的最新副本到工作的内存
- 执行代码
- 将更改后的共享变量的值刷新到主内存
- 释放互斥锁
所以 synchronized 也能保证内存可见性. 具体代码参见后面 volatile 部分.
3)可重入
synchronized 同步块对同一条线程来说是可重入的，不会出现自己把自己锁死的问题；
理解 “把自己锁死”
一个线程没有释放锁, 然后又尝试再次加锁.
// 第一次加锁, 加锁成功 lock(); // 第二次加锁, 锁已经被占用, 阻塞等待. lock();
按照之前对于锁的设定, 第二次加锁的时候, 就会阻塞等待. 直到第一次的锁被释放, 才能获取到第 二个锁. 但是释放第一个锁也是由该线程来完成, 结果这个线程已经躺平了, 啥都不想干了, 也就无 法进行解锁操作. 这时候就会 死锁.
这样的锁称为 不可重入锁
Java 中的 synchronized 是 可重入锁, 因此没有上面的问题.
代码示例
在下面的代码中,
- increase 和 increase2 两个方法都加了 synchronized, 此处的 synchronized 都是针对 this 当前 对象加锁的.
- 在调用 increase2 的时候, 先加了一次锁, 执行到 increase 的时候, 又加了一次锁. (上个锁还没释 放, 相当于连续加两次锁)
这个代码是完全没问题的. 因为 synchronized 是可重入锁.
static class Counter { public int count = 0; synchronized void increase() { count++; } synchronized void increase2() { increase(); } }
在可重入锁的内部, 包含了 “线程持有者” 和 “计数器” 两个信息.
- 如果某个线程加锁的时候, 发现锁已经被人占用, 但是恰好占用的正是自己, 那么仍然可以继续获取 到锁, 并让计数器自增.
- 解锁的时候计数器递减为 0 的时候, 才真正释放锁. (才能被别的线程获取到)
如果允许二次加锁，这个锁就是可重入的。
如果不允许二次加锁，那么就会阻塞等待，就是不可重入的。这个情况会导致线程"僵住了"，即死锁了。
因为在Java里面这种代码是很容易出现的。
为了避免不小心就死锁，Java就把synchronized设定成可重入的了。
但是c++，Python，操作系统原生的锁，都是不可重入的
5.2 synchronized 使用示例
synchronized 本质上要修改指定对象的 “对象头”. 从使用角度来看, synchronized 也势必要搭配一个具 体的对象来使用.
1)直接修饰普通方法: 锁的 SynchronizedDemo 对象
public class SynchronizedDemo { public synchronized void methond() { } }
直接把synchronized修饰到方法上，此时相当于针对this加锁。
t1执行add，就加上锁了，针对count这个对象加上锁了。
t2执行add的时候，也尝试对count加锁，但是由于count已经被t1给占用了。因此这里的加锁操作就回阻塞。
2)修饰静态方法: 锁的 SynchronizedDemo 类的对象
public class SynchronizedDemo { public synchronized static void method() { } }
3)修饰代码块: 手动指定锁哪个对象.
锁当前对象
public class SynchronizedDemo { public void method() { synchronized (this) { } } }
锁内对象
public class SynchronizedDemo { public void method() { synchronized (SynchronizedDemo.class) { } } }
我们重点要理解，synchronized 锁的是什么. 两个线程竞争同一把锁, 才会产生阻塞等待.
两个线程分别尝试获取两把不同的锁, 不会产生竞争.
5.3 Java 标准库中的线程安全类
Java 标准库中很多都是线程不安全的. 这些类可能会涉及到多线程修改共享数据, 又没有任何加锁措施.
- ArrayList
- LinkedList
- HashMap
- TreeMap
- HashSet
- TreeSet
- StringBuilder
但是还有一些是线程安全的. 使用了一些锁机制来控制.
- Vector (不推荐使用)
- HashTable (不推荐使用)
- ConcurrentHashMap
- StringBuffer
StringBuffer 的核心方法都带有 synchronized .
还有的虽然没有加锁, 但是不涉及 “修改”, 仍然是线程安全的
- String
那么强行加锁之后，线程就会变得安全，为什么不全部加锁呢？
答：因为加锁这个操作是有副作用的，有额外的时间开销，所以我们的API没有给所有的线程都强制加锁。
5.4死锁代码演示
死锁代码演示：
public class ThreadDemo15 { public static void main(String[] args) { Object locker1 = new Object(); Object locker2 = new Object(); Thread t1 = new Thread(()->{ synchronized (locker1) { try { Thread.sleep(1000); } catch (InterruptedException e) { e.printStackTrace(); } synchronized (locker2) { System.out.println("t1 把 locker1 和 locker2 都拿到了"); } } }); Thread t2 = new Thread(()->{ synchronized (locker2) { try { Thread.sleep(1000); } catch (InterruptedException e) { e.printStackTrace(); } synchronized (locker1) { System.out.println("t2 把 locker1 和 locker2 都拿到了"); } } }); t1.start(); t2.start(); } }
这里没有输出出结果就是因为死锁问题，t1和t2都获取不到所需的对象。(因为t1和t2所需要的对象都在对方手上，而他们需要获取到各自所需要的对象才会释放手上的，因为导致僵持住了)
小tips：shift + F6可以一键给所有变量改名。
5.5如何避免死锁？
死锁的四个必要条件：
1.互斥使用
线程1拿到了锁，线程2就得等着。(锁的基本特性)
2.不可抢占
线程1拿到锁之后，必须是线程1主动释放。不能是线程2把锁强行获取到。
3.请求与保持
线程1拿到锁A之后，再尝试获取锁B，A这把锁还是保持的。(不会因为获取锁B就把锁A释放了)
4.循环等待
线程1尝试获取锁A和锁B，线程2尝试获取锁B和锁A。
线程1在获取B的时候在等待线程2释放B；线程2在获取A的时候在等待线程1释放A。
这里四个条件，实际上就是一个条件，前面三个条件都是锁的基本特性，循环等待是这四个条件里唯一一个和代码结构相关的。也是咱们程序猿可以控制的。
那么我们如何避免死锁呢？
办法：给锁编号，然后指定一个固定的顺序(比如从小到大)来加锁。任意线程加多把锁的时候，都让线程遵守上述顺序，此时循环等待自然破除。
这里我们改了一下顺序把t2拿锁的顺序从先拿locker2再拿locker1，改为了和t1一样的顺序，即都是先拿小的，locker1，再拿locker2，就完美的解决了死锁问题。
改前代码运行结果：
改后代码运行结果：
6. volatile[ˈvɒlətaɪl] 关键字
用来解决一个读一个写可能造成的问题。
volatile 能保证内存可见性
volatile 修饰的变量, 能够保证 “内存可见性”.
代码在写入 volatile 修饰的变量的时候,
- 改变线程工作内存中volatile变量副本的值
- 将改变后的副本的值从工作内存刷新到主内存
代码在读取 volatile 修饰的变量的时候,
- 从主内存中读取volatile变量的最新值到线程的工作内存中
- 从工作内存中读取volatile变量的副本
前面我们讨论内存可见性时说了, 直接访问工作内存(实际是 CPU 的寄存器或者 CPU 的缓存), 速度 非常快, 但是可能出现数据不一致的情况.
加上 volatile , 强制读写内存. 速度是慢了, 但是数据变的更准确了.
代码示例
在这个代码中
- 创建两个线程 t1 和 t2
- t1 中包含一个循环, 这个循环以 flag == 0 为循环条件.
- t2 中从键盘读入一个整数, 并把这个整数赋值给 flag.
- 预期当用户输入非 0 的值的时候, t1 线程结束.
static class Counter { public int flag = 0; } public static void main(String[] args) { Counter counter = new Counter(); Thread t1 = new Thread(() -> { while (counter.flag == 0) { // do nothing } System.out.println("循环结束!"); }); Thread t2 = new Thread(() -> { Scanner scanner = new Scanner(System.in); System.out.println("输入一个整数:"); counter.flag = scanner.nextInt(); }); t1.start(); t2.start(); } // 执行效果 // 当用户输入非0值时, t1 线程循环不会结束. (这显然是一个 bug)
我们预期输入一个值，使得t2线程结束，而输入的值导致flag改变，进而使得t1里面的flag ！=0结束循环，至此打印t1 循环结束，从而导致程序结束。
实际运行结果图：
那么为什么这里和我们预期结果不一样呢，t2输入值改变了flag使其不为0，但是线程t1仍然没有结束。
那么这个情况就叫做线程可见性问题。
下面就为大家讲解这个问题是如何出现的：
这里使用汇编来理解，大概就是两步操作：
1.load，把内存中的falg的值，读取到寄存器里。
2.cmp，把寄存器的值和0进行比较。根据比较结果，决定下一步往哪个方向执行(条件跳转指令)
上述是个循环，这个循环速度极快，一秒钟执行上百万次以上
循环这么多次，在t2真正修改之前，load得到的结果都是一样的。
另一方面，load操作和cmp操作相比，速度慢非常非常多。
由于load执行速度太慢(相比于cmp来说)，在加上反复 load 得到的结果都一样，JVM就做出了一个非常大胆的决定~~~ 不再真正的重复load了，判定好像没人改flag值，那干脆就只读取一次就好了。(编译器优化的一种方式)
t1 读的是自己工作内存中的内容.
当 t2 对 flag 变量进行修改, 此时 t1 感知不到 flag 的变化.
如果给 flag 加上 volatile
static class Counter { public volatile int flag = 0; } // 执行效果 // 当用户输入非0值时, t1 线程循环能够立即结束.
我们加上volatile
加上了volatile之后，我们编译器就知道了flag这个操作不能随便乱改，因此编译器再次运行的结果就是正确的。
我们从JMM的角度来重新描述内存可见性问题：
Java 程序里，主内存，每个线程都有自己的工作内存(t1 的 和 t2的 工作内存不是一个东西)
t1 线程进行读取的时候，知识读取了工作内存的值
t2 线程进行修改的时候，先修改的工作内存的值，然后再把工作内存的内容同步到主内存中。
但是由于编译器优化，导致 t1 没有重新的从主内存同步数据到工作内存，读取到的结果就是"修改之前"的结果。
主内存 --> 内存
工作内存 --> CPU寄存器
工作内存可能不只是 CPU寄存器 可能还有 CPU缓存(cache)
volatile 不保证原子性
volatile 和 synchronized 有着本质的区别. synchronized 能够保证原子性, volatile 保证的是内存可见性.
代码示例
这个是最初的演示线程安全的代码.
- 给 increase 方法去掉 synchronized
- 给 count 加上 volatile 关键字.
static class Counter { volatile public int count = 0; void increase() { count++; } } public static void main(String[] args) throws InterruptedException { final Counter counter = new Counter(); Thread t1 = new Thread(() -> { for (int i = 0; i < 50000; i++) { counter.increase(); } }); Thread t2 = new Thread(() -> { for (int i = 0; i < 50000; i++) { counter.increase(); } }); t1.start(); t2.start(); t1.join(); t2.join(); System.out.println(counter.count); }]
此时可以看到, 最终 count 的值仍然无法保证是 100000.
synchronized 也能保证内存可见性 (存疑)
synchronized 既能保证原子性, 也能保证内存可见性. (要保存两个性质的话建议把synchronized 和 volatile 都用上)
对上面的代码进行调整:
- 去掉 flag 的 volatile
- 给 t1 的循环内部加上 synchronized, 并借助 counter 对象加锁.
static class Counter { public int flag = 0; } public static void main(String[] args) { Counter counter = new Counter(); Thread t1 = new Thread(() -> { while (true) { synchronized (counter) { if (counter.flag != 0) { break; } } // do nothing } System.out.println("循环结束!"); }); Thread t2 = new Thread(() -> { Scanner scanner = new Scanner(System.in); System.out.println("输入一个整数:"); counter.flag = scanner.nextInt(); }); t1.start(); t2.start(); }
7. 总结-保证线程安全的思路
- 使用没有共享资源的模型
- 适用共享资源只读，不写的模型
- 不需要写共享资源的模型
- 使用不可变对象
- 直面线程安全（重点）
- 保证原子性
- 保证顺序性
- 保证可见性
8. 对比线程和进程
8.1 线程的优点
- 创建一个新线程的代价要比创建一个新进程小得多
- 与进程之间的切换相比，线程之间的切换需要操作系统做的工作要少很多
- 线程占用的资源要比进程少很多
- 能充分利用多处理器的可并行数量
- 在等待慢速I/O操作结束的同时，程序可执行其他的计算任务
- 计算密集型应用，为了能在多处理器系统上运行，将计算分解到多个线程中实现
- I/O密集型应用，为了提高性能，将I/O操作重叠。线程可以同时等待不同的I/O操作。
8.2 进程与线程的区别
- 进程是系统进行资源分配和调度的一个独立单位，线程是程序执行的最小单位。
- 进程有自己的内存地址空间，线程只独享指令流执行的必要资源，如寄存器和栈。
- 由于同一进程的各线程间共享内存和文件资源，可以不通过内核进行直接通信。
- 线程的创建、切换及终止效率更高
感谢各位读者的阅读，本文章有任何错误都可以在评论区发表你们的意见，我会对文章进行改正的。如果本文章对你有帮助请动一动你们敏捷的小手点一点赞，你的每一次鼓励都是作者创作的动力哦！😘
