mirror of
https://github.com/Snailclimb/JavaGuide
synced 2025-06-16 18:10:13 +08:00
fix:修正标点符号
This commit is contained in:
parent
25de0a492c
commit
2a6783d0e4
@ -265,7 +265,7 @@ Java 使用的线程调度是抢占式的。也就是说,JVM 本身不负责
|
|||||||
|
|
||||||
## ⭐️死锁
|
## ⭐️死锁
|
||||||
|
|
||||||
### 什么是线程死锁?
|
### 什么是线程死锁?
|
||||||
|
|
||||||
线程死锁描述的是这样一种情况:多个线程同时被阻塞,它们中的一个或者全部都在等待某个资源被释放。由于线程被无限期地阻塞,因此程序不可能正常终止。
|
线程死锁描述的是这样一种情况:多个线程同时被阻塞,它们中的一个或者全部都在等待某个资源被释放。由于线程被无限期地阻塞,因此程序不可能正常终止。
|
||||||
|
|
||||||
@ -323,14 +323,14 @@ Thread[线程 1,5,main]waiting get resource2
|
|||||||
Thread[线程 2,5,main]waiting get resource1
|
Thread[线程 2,5,main]waiting get resource1
|
||||||
```
|
```
|
||||||
|
|
||||||
线程 A 通过 `synchronized (resource1)` 获得 `resource1` 的监视器锁,然后通过`Thread.sleep(1000);`让线程 A 休眠 1s 为的是让线程 B 得到执行然后获取到 resource2 的监视器锁。线程 A 和线程 B 休眠结束了都开始企图请求获取对方的资源,然后这两个线程就会陷入互相等待的状态,这也就产生了死锁。
|
线程 A 通过 `synchronized (resource1)` 获得 `resource1` 的监视器锁,然后通过 `Thread.sleep(1000);` 让线程 A 休眠 1s,为的是让线程 B 得到执行然后获取到 resource2 的监视器锁。线程 A 和线程 B 休眠结束了都开始企图请求获取对方的资源,然后这两个线程就会陷入互相等待的状态,这也就产生了死锁。
|
||||||
|
|
||||||
上面的例子符合产生死锁的四个必要条件:
|
上面的例子符合产生死锁的四个必要条件:
|
||||||
|
|
||||||
1. 互斥条件:该资源任意一个时刻只由一个线程占用。
|
1. 互斥条件:该资源任意一个时刻只由一个线程占用。
|
||||||
2. 请求与保持条件:一个线程因请求资源而阻塞时,对已获得的资源保持不放。
|
2. 请求与保持条件:一个线程因请求资源而阻塞时,对已获得的资源保持不放。
|
||||||
3. 不剥夺条件:线程已获得的资源在未使用完之前不能被其他线程强行剥夺,只有自己使用完毕后才释放资源。
|
3. 不剥夺条件:线程已获得的资源在未使用完之前不能被其他线程强行剥夺,只有自己使用完毕后才释放资源。
|
||||||
4. 循环等待条件:若干线程之间形成一种头尾相接的循环等待资源关系。
|
4. 循环等待条件:若干线程之间形成一种头尾相接的循环等待资源关系。
|
||||||
|
|
||||||
### 如何检测死锁?
|
### 如何检测死锁?
|
||||||
|
|
||||||
|
Loading…
x
Reference in New Issue
Block a user