目录
从上一篇【JavaEE初阶系列】—— 一万字让你了解线程类方法属性以及线程状态和线程安全问题!-CSDN博客
我们知道线程安全的原因,怎么引起了线程安全问题。接下来我将会讲述如何解决线程安全问题。
上一篇最后讲了,导致count加起来结果不是1w的原因是 count++不是原子性,因为在count++的过程中会经历三个步骤,导致了在多线程的情况下,操作系统,线程的调度顺序是随机的(抢占式执行),所以我们需要加锁。
💻synchronized 的特性
🖥️互斥及使用示例
🚩锁修饰代码块
synchronized在使用的时候,要搭配一个代码块{} ,进入{ 就会加锁,出了} 就会解锁。在已经加锁的状态下,另一个线程尝试同样加这个锁,就会产生“所冲突/锁竞争",后一个线程就会阻塞等待,一直等到前一个线程解锁为止。
()中需要表示一个用来加锁的对象,这个对象是啥不重要,重要的是通过这个对象来区分俩个线程是否在竞争同一个锁。如果俩个线程是在针对同一个对象加锁,就会有锁竞争,如果不是针对同一个对象加锁,就不会有锁竞争,仍然是并发执行。
你可以将锁想想成一个女生A,一个男生喜欢这个女生A,然后追到手了,就相当于给女生A枷锁了,如果另一个男生B也想追这个女生A,他就必须得阻塞等待,只有等男生A和女生A分手后,他才有机会。但是如果男生B追其他的女生,就不会受到男生A和女生A的影响。
如果按照这样的编程方式,俩个线程是针对同一个对象加锁的,就会有锁竞争。但是线程t2会阻塞等待,等到t1线程结束了之后,t2线程才会开始。
public class Test {
public static int count=0;
public static void main(String[] args) throws InterruptedException {
Object object=new Object();
Thread t1=new Thread(()->{
for (int i = 0; i <5000 ; i++) {
synchronized (object){
count++;
}
}
});
Thread t2=new Thread(()->{
for (int i = 0; i < 5000; i++) {
synchronized (object) {
count++;
}
}
});
t1.start();
t2.start();
t1.join();
t2.join();
System.out.println(count);
}
}
记住:
- 锁对象到底用哪个对象,是无所谓的,对象是谁,不重要,重要的是俩线程加锁的对象,是否是同一个对象。
- 这里的意义/规则,有且只有一个。当俩个线程同时尝试对一个对象加锁,此时就会出现"锁冲突/锁竞争",一旦竞争出现,一个线程能够拿到锁,继续执行代码,一个线程拿不到锁,就只能阻塞等待,等待前一个线程释放锁之后,它才会有机会拿到锁,继续执行。 (并发执行 =》串行执行》
🚩锁修饰实例方法/静态方法
🎈锁修饰实例方法
class Counter{
public int count;
synchronized public void increase(){
count++;
}
public void increase1(){
synchronized (this){
count++;
}
}
}
以上俩种写法都是可以的,只是上面的写法是下面写法的简化版。此时用的是this锁对象了。
🎈锁修饰静态方法
synchronized public static void increase(){
count++;
}
public void increase1(){
synchronized (Counter.class){
count++;
}
}
public static void main(String[] args) throws InterruptedException {
Object object=new Object();
Counter counter=new Counter();
Thread t1=new Thread(()->{
for (int i = 0; i <5000 ; i++) {
counter.increase();
}
});
Thread t2=new Thread(()->{
for (int i = 0; i <5000 ; i++) {
counter.increase();
}
});
t1.start();
t2.start();
t1.join();
t2.join();
System.out.println(counter.count);
}
🚩总结
锁可以修饰代码块,也可以修饰实例方法和静态方法。其实根本都是对count进行加锁。
代码块中的锁对象可以是任意类型的对象,但多个线程共享的锁对象必须是同一个(因为对同一个变量进行修改)
代码块,实例方法,静态方法的锁是不同的
- 代码块的锁是自己定义的任意类型的对象。
- 实例方法就是调用该方法的当前对象,也就是this指向的对象。
- 静态方法不需要创建对象就可以直接用"类名.方法名()"方式调用。java中静态方法的锁是该方法所在类的class对象,class对象在装载该类的时候自动创建,该对象可以直接用"类名.class"的方式获取。
- 可以粗略理解成, 每个对象在内存中存储的时候, 都存有一块内存表示当前的 "锁定" 状态(类似于厕所的 "有人/无人").
- 如果当前是 "无人" 状态, 那么就可以使用, 使用时需要设为 "有人" 状态.
- 如果当前是 "有人" 状态, 那么其他人无法使用, 只能排队.
理解阻塞等待:
针对每一把锁,操作系统内部维护了一个等待队列,当这个锁被某个线程占有的时候,其他线程尝试对其加锁的时候,就加不上了,就会阻塞等待,一直等到之前的线程解锁之后,由操作系统唤醒一个新的线程,再来获取这个锁。
注意:上一个线程解锁之后, 下一个线程并不是立即就能获取到锁. 而是要靠操作系统来 "唤醒". 这也就是操作系统线程调度的一部分工作.假设有 A B C 三个线程, 线程 A 先获取到锁, 然后 B 尝试获取锁, 然后 C 再尝试获取锁, 此时 B 和 C 都在阻塞队列中排队等待. 但是当 A 释放锁之后, 虽然 B 比 C 先来的, 但是 B 不一定就能获取到锁, 而是和 C 重新竞争, 并不遵守先来后到的规则.
🖥️可重入
理解 "把自己锁死"
- 一个线程没有释放锁, 然后又尝试再次加锁
可重入锁的意义之一在于防止死锁
🚩死锁的现象
public static void main(String[] args) {
Object object=new Object();
Thread t=new Thread(()->{
synchronized (object){
synchronized (object){
}//(2)
}//(1)
});
}
一个锁对象object,一个线程t,第一次加锁,假设能够加锁成功,此时的object就属于"被锁定"状态,再进行第二次加锁的时候,很明显,object已经是锁定的状态了,第二次加锁操作,原则上来说,是应该要"阻塞等待"的,应该是等待到,锁被释放了之后,才能加锁成功.
但是实际上,一旦第二次加锁的时候阻塞了,就会出现死锁的现象。(线程卡死了)
如果第二次想要加锁成功的话,就需要第一次的加锁释放锁,第一次加锁要想释放锁,就需要执行完完}(1)的位置。要执行到(1) 就需要让第二次加锁能够成功,代码才能成功执行。由于第二次加锁导致了代码阻塞住了,当前没有办法执行到}(1),也就无法释放锁了。
public class Test3 {
public static void main(String[] args) throws InterruptedException {
Object object=new Object();
Thread t=new Thread(()->{
synchronized (object){
synchronized (object){
System.out.println("synchronized设计成可重入锁");
}
}
});
t.start();
t.join();
}
}
但是有一个问题:
上述代码中,synchronized是可重入锁,没有因为第二次加锁而死锁,但是当代码执行到}(2),此时,锁是否应该释放呢? ——不能释放
不管加锁多少层,N层,都是在最外层才能释放锁。
这就引入了计数器,锁对象中,不光要记录谁拿了锁,还要记录,锁被加了几次
- 没加锁一次,计数器+1
- 每解锁一次,计数器就-1
出了最后一个大括号,恰好就减成0了,才真正的释放锁。
public class Test3 { public static int count=0; public static void main(String[] args) throws InterruptedException { Object object=new Object(); Thread t=new Thread(()->{ synchronized (object){ count++; synchronized (object){ System.out.println("synchronized设计成可重入锁"); count++;//加锁++ } count--;//解锁-- synchronized (object){ count++;//加锁++ } count--;//解锁-- } count--; }); t.start(); t.join(); System.out.println(count); } }
通过加锁+1,解锁-1的操作,我们最后出了大括号之后,恰好就减成0了。
🚩死锁
🎈一个线程一把锁
- 一个线程,针对一把锁,连续加锁两次,如果是不可重入锁,就会出现死锁现象,被synchronized修饰就是可重入锁。
🎈俩个线程俩把锁
- 俩个线程,俩把锁。(此时无论是不是可重入锁,都会死锁)就相当于 {车钥匙锁家里了,家钥匙锁车里了}
线程t1获取锁A,t2线程获取锁B
线程t1获取锁B,t2线程获取锁A
public class Test4 {
private static Object locker1=new Object();
private static Object locker2=new Object();
public static void main(String[] args) throws InterruptedException {
Thread t1=new Thread(()->{
synchronized (locker1){
try {
Thread.sleep(1000);
} catch (InterruptedException e) {
throw new RuntimeException(e);
}
synchronized (locker2){
System.out.println("t1加锁成功");
}
}
});
Thread t2=new Thread(()->{
synchronized (locker2){
try {
Thread.sleep(1000);
} catch (InterruptedException e) {
throw new RuntimeException(e);
}
synchronized (locker1){
System.out.println("t2加锁成功");
}
}
});
t1.start();
t2.start();
}
}
此时就产生了死锁效果。如果线程1没有sleep的话,是不会出现死锁现象的。这是为什么呢?因为t1.start()的时候,并发执行,首先加locker1的锁,然后没有sleep,此时t2线程就进行了,然后t1线程加锁locker2的基本上同时加锁t2线程locker2.并没有出现t1线程获取locker2锁同时,然后t2线程获取locker1锁.因为中间没有sleep。
🎈哲学家吃饭(M个线程N个锁)
哲学家相当于线程,筷子相当于锁,同一时刻,五个哲学家发现,他们的右手边都没有筷子,与时只能拿起左手的筷子,此时,五个哲学家发现,他们的右手边都没有筷子,只能阻塞等待,等待过程中,,不会放下左手的筷子。这就造成了严重的死锁现象了。
🚩死锁的成因
死锁的成因涉及到四个必要条件。
- 1.互斥使用(锁的基本特性):当一个线程持有一把锁之后,另一个线程想要拥有这把锁,就需要阻塞等待(适用于 串行执行 二线程一把锁)
- 2.不可抢占(锁的基本特征):当锁已经被线程1拿到之后,线程2只能等线程1主动释放,不能强行抢占。(男生A和女生A已经在一起了,男生B不能强行让女生A和他在一起,除非等女生A真的不喜欢男生A了,才会和男生B在一起,也适用于 串行执行)
- 3.请求保持(代码结构):一个线程尝试获取多把锁。(先拿到锁1之后,再尝试获取锁2,获取的时候,锁1不会释放 嵌套执行)
- 4.循环等待/环路等待(代码结构): 等待的依赖关系,形成环了。
解决死锁,核心就是破坏上述的必要条件,只要破坏一个,死锁就形成不了了。
- 1和2破坏不了(synchronized自带特性,你无法干预)
- 对于3来说,调整代码结构,避免编写”锁前套“逻辑
- 对于4来说,可以预定加锁的顺序,就可以避免循环等待
针对锁进行编号,比如约定,加多把锁的时候,先加编号小的锁,后加编号大的锁。(所有的线程都要遵守这个规则)此时循环等待就破除了,上述系统就不会再出现死锁了。
滑稽1先拿上编号最小的1,然后滑稽2拿上2筷子,滑稽3拿上3筷子,滑稽4拿上4筷子,此时滑稽5拿不了1筷子,只能等待,所以此时滑稽4就可以拿到5筷子,等滑稽4吃完了后,放下,4,5筷子之后,滑稽3就可以拿到4筷子了,以此类推,滑稽1吃完后,滑稽5就可以同时拿到1和5筷子了。
此时就解决了死锁的问题了。
synchronized使用规则上,并不复杂,抓住一个原则:两个线程针对同一个对象加锁,就会产生锁竞争。
其实锁还有个特性是:刷新内存 后面讲到volatile 即可明白。
今天报考六级了。