Java 线程管理中的锁
Monitor 概念
Java 对象头
Mark Word:
Monitor (锁)
Monitor 被翻译为监视器或管程
每个 Java 对象都可以关联一个 Monitor 对象，如果使用 synchronized 给对象上锁（重量级）之后，该对象头的Mark Word 中就被设置指向 Monitor 对象的指针
Monitor 结构：
- 刚开始 Monitor 中 Owner 为 null
- 当 Thread-2 执行 synchronized(obj) 就会将 Monitor 的所有者 Owner 置为 Thread-2，Monitor中只能有一个 Owner
- 在 Thread-2 上锁的过程中，如果 Thread-3，Thread-4，Thread-5 也来执行 synchronized(obj)，就会进入 EntryList BLOCKED
- Thread-2 执行完同步代码块的内容，然后唤醒 EntryList 中等待的线程来竞争锁，竞争的时是非公平的
- 图中 WaitSet 中的 Thread-0，Thread-1 是之前获得过锁，但条件不满足进入 WAITING 状态的线程（与wait-notify有关）
注意：
- synchronized 必须是进入同一个对象的 monitor 才有上述的效果
- 不加 synchronized 的对象不会关联监视器，不遵从以上规则
一个锁对象中的 MarkWord 会指向一个 Monitor 对象，不同的锁对象关联不同的 Monitor
synchronized 原理
1. 轻量级锁
对象中轻量级锁的 MarkWord 结构：
轻量级锁的使用场景：如果一个对象虽然有多线程要加锁，但加锁的时间是错开的（也就是没有竞争），那么可以使用轻量级锁来优化。
轻量级锁对使用者是透明的，即语法仍然是 synchronized
假设有两个方法同步块，利用同一个对象加锁：
static final Object obj = new Object();
public static void method1() {
synchronized( obj ) {
// 同步块 A
method2();
}
}
public static void method2() {
synchronized( obj ) {
// 同步块 B
}
}
轻量级锁的加锁解锁流程：
- 创建锁记录（Lock Record，LR）对象，每个线程都的栈帧都会包含一个锁记录的结构，内部可以存储锁定对象的 Mark Word
01 表示没有锁（或者偏向锁），从上面MarkWord结构可知
-
让锁记录中 Object reference 指向锁对象，并尝试用 cas 替换 Object 的 Mark Word，将 Mark Word 的值存入锁记录
cas ：取出 MarkWord值，然后尝试修改该值，写回时比较当前MarkWord值是否和当初取出的值相同，如果相同则将修改的值写入
- 如果 cas 替换成功，对象头中存储了锁记录地址和状态 00 ，表示由该线程给对象加锁，这时图示如下
- 如果 cas 失败，有两种情况
- 如果是其它线程已经持有了该 Object 的轻量级锁，这时表明有竞争，进入锁膨胀过程
- 如果是自己执行了 synchronized 锁重入，那么再添加一条 Lock Record 作为重入的计数
- 当退出 synchronized 代码块（解锁时）如果有取值为 null 的锁记录，表示有重入，这时重置锁记录，表示重入计数减一
- 当退出 synchronized 代码块（解锁时）锁记录的值不为 null，这时使用 cas 将 Mark Word 的值恢复给对象头
- 成功，则解锁成功
- 失败，说明轻量级锁进行了锁膨胀或已经升级为重量级锁，进入重量级锁解锁流程
2. 锁膨胀——轻量级锁膨胀为重量级锁
如果在尝试加轻量级锁的过程中，CAS 操作无法成功，这时一种情况就是有其它线程为此对象加上了轻量级锁（有竞争），这时需要进行锁膨胀，将轻量级锁变为重量级锁。
- 当 Thread-1 进行轻量级加锁时，Thread-0 已经对该对象加了轻量级锁：
-
这时 Thread-1 加轻量级锁失败，进入锁膨胀流程
-
即为 Object 对象申请 Monitor 锁，创建一个Monitor对象管理多线程，让 Object 指向重量级锁（Monitor对象）地址
-
然后 Thread-1 自己进入 Monitor 的 EntryList BLOCKED
-
- 当 Thread-0 退出同步块解锁时，使用 cas 将 Mark Word 的值恢复给对象头，失败，因为现在MarkWord已经变为Monitor地址了。
- 这时会进入重量级解锁流程，即按照 Monitor 地址找到 Monitor 对象，设置 Owner 为 null，唤醒 EntryList 中 BLOCKED 线程
3. 自旋优化
重量级锁竞争的时候，还可以使用自旋来进行优化，如果当前线程自旋成功（即这时候持锁线程已经退出了同步块，释放了锁），这时当前线程就可以避免阻塞。因为阻塞会发生上下文切换，避免阻塞，上下文切换也会避免，减少了上下文切换的次数，优化了性能
自旋重试成功的一种情况：（这里多核CPU下才有意义）
自旋重试失败的一种情况：
- 自旋会占用 CPU 时间，单核 CPU 自旋就是浪费，多核 CPU 自旋才能发挥优势。
- 在 Java 6 之后自旋锁是自适应的，比如对象刚刚的一次自旋操作成功过，那么认为这次自旋成功的可能性会高，就多自旋几次；反之，就少自旋甚至不自旋，总之，比较智能。
- Java 7 之后不能控制是否开启自旋功能
4. 偏向锁
自JDK15起，偏向锁已被废弃，JDK20被移除，可以在JDK8中将其关闭以提高性能
偏向状态
轻量级锁在没有竞争时（就自己这个线程），每次重入仍然需要执行 CAS 操作。
Java 6 中引入了偏向锁来做进一步优化：只有第一次使用 CAS 将线程 ID 设置到对象的 Mark Word 头，之后发现这个线程 ID 是自己的就表示没有竞争，不用重新 CAS。以后只要不发生竞争，这个对象就归该线程所有
对象头格式：（延迟几秒后，MarkWord 最后三位是101）
一个对象创建时：
- 如果开启了偏向锁（默认开启），那么对象创建后，markword 值为 0x05 即最后 3 位为 101，这时它的 thread、epoch、age 都为 0
- 偏向锁是默认是延迟的，不会在程序启动时立即生效，如果想避免延迟，可以加 VM 参数
-XX:BiasedLockingStartupDelay=0来禁用延迟 - 如果没有开启偏向锁，那么对象创建后，markword 值为 0x01 即最后 3 位为 001，这时它的 hashcode、age 都为 0，第一次用到 hashcode 时才会赋值
hashCode：正常状态对象一开始是没有 hashCode 的，第一次调用才生成；生成 hasCode 后，偏向锁就被禁止使用了，因为偏向锁无法存下 hashCode ，偏向锁被撤销了
偏向锁撤销的情况
-
撤销 - 调用对象 hashCode
-
调用了对象的 hashCode，但偏向锁的对象 MarkWord 中存储的是线程 id，如果调用 hashCode 会导致偏向锁被撤销
-
轻量级锁会在锁记录中记录 hashCode
-
重量级锁会在 Monitor 中记录 hashCode
-
-
撤销 - 其它线程使用对象
当有其它线程使用偏向锁对象时，会将偏向锁升级为轻量级锁
-
调用 wait/notify：只有重量级锁才有 wait/notify操作，会被升级为重量级锁
批量重偏向
如果对象虽然被多个线程访问，但没有竞争（线程交替访问锁对象），这时有一个原本偏向 T1 的偏向锁，T2 在访问T1的偏向锁时会将偏向锁撤销，升级为轻量级锁。随后轻量级锁被释放，再访问锁对象时，又会产生一个偏向 T1 的偏向锁，反复多次这种流程会耗费性能
所以希望在偏向了线程 T1 的对象仍有机会重新偏向 T2，重偏向会重置对象的 Thread ID
当撤销偏向锁（加锁，解锁次数）阈值超过 20 次后，jvm 会这样觉得，我是不是偏向错了呢，于是会在给这些对象加锁时重新偏向至加锁线程
批量撤销
当撤销偏向锁阈值超过 40 次后，jvm 会这样觉得，自己确实偏向错了，根本就不该偏向。于是整个类的所有对象都会变为不可偏向的，新建的对象也是不可偏向的
5. 锁消除
JIT 即时编译器，会优化代码，把不会被共享的锁对象的同步代码块中的加锁操作消除
-XX:-EliminateLocks ：vm option 指令，禁止锁消除优化
锁粗化：对相同对象多次加锁，导致线程发生多次重入，可以使用锁粗化方式来优化，这不同于之前讲的细分锁的粒度。
wait notify 原理
- Owner 线程发现条件不满足，调用 wait 方法，即可进入 WaitSet 变为 WAITING 状态
- BLOCKED 和 WAITING 的线程都处于阻塞状态，不占用 CPU 时间片
- BLOCKED 线程会在 Owner 线程释放锁时唤醒
- WAITING 线程会在 Owner 线程调用 notify 或 notifyAll 时唤醒，但唤醒后并不意味者立刻获得锁，仍需进入EntryList 重新竞争
waiting 状态的线程是获得锁后又放弃锁进入的状态，而 blocked 状态是还没获得锁的，他俩都是阻塞状态
API 介绍
obj.wait()让进入 object 监视器的线程到 waitSet 等待obj.notify()在 object 上正在 waitSet 等待的线程中挑一个唤醒obj.notifyAll()让 object 上正在 waitSet 等待的线程全部唤醒
以上方法的调用必须是先获得锁（成为 Owner以后）；测试：
@Slf4j(topic = "c.d4_wait_notify")
public class d4_wait_notify {
final static Object obj = new Object();
public static void main(String[] args) throws InterruptedException {
new Thread(() -> {
synchronized (obj) {
log.debug("执行....");
try {
obj.wait(); // 让线程在obj上一直等待下去
} catch (InterruptedException e) {
e.printStackTrace();
}
log.debug("其它代码....");
}
}, "t1").start();
new Thread(() -> {
synchronized (obj) {
log.debug("执行....");
try {
obj.wait(); // 让线程在obj上一直等待下去
} catch (InterruptedException e) {
e.printStackTrace();
}
log.debug("其它代码....");
}
}, "t2").start();
// 主线程两秒后执行
Thread.sleep(2000);
log.debug("唤醒 obj 上其它线程");
synchronized (obj) {
obj.notify(); // 唤醒obj上一个线程
// obj.notifyAll(); // 唤醒obj上所有等待线程
}
}
}
结果：
15:18:02 [t1] c.d4_wait_notify - 执行....
15:18:02 [t2] c.d4_wait_notify - 执行....
15:18:04 [main] c.d4_wait_notify - 唤醒 obj 上其它线程
15:18:04 [t1] c.d4_wait_notify - 其它代码....
wait() 方法会释放对象的锁，进入 WaitSet 等待区，从而让其他线程就机会获取对象的锁。无限制等待，直到 notify 为止
wait(long n) 有时限的等待, 到 n 毫秒后结束等待，或是被 notify
wait notify 的正确使用方式
sleep(long n) 和 wait(long n) 的区别
- sleep 是 Thread 方法，而 wait 是 Object 的方法
- sleep 不需要强制和 synchronized 配合使用，但 wait 需要和 synchronized 一起用
- sleep 在睡眠的同时，不会释放对象锁的，其他线程想用锁只能在EntryList里阻塞等待；但 wait 在等待的时候会释放对象锁，当前线程会进入 WaitList 等待，其他 EntryList里等待的线程会被唤醒一个获得释放的锁
- 它们状态都是 TIMED_WAITING
当有多个线程进入 waitList ，我们要选择其中一个唤醒，可以为每个线程设置一个标志 flag，然后唤醒所有线程；唤醒后，每个线程检查自己的 flag条件，如果 flag 不满足，则一直 wait 等待：
synchronized(lock) {
while(条件不成立) {
lock.wait();
}
// 干活
}
//另一个线程
synchronized(lock) {
lock.notifyAll();
}
同步模式之保护性暂停
1. 定义
即 Guarded Suspension，用在一个线程等待另一个线程的执行结果
要点：
- 有一个结果需要从一个线程传递到另一个线程，让他们关联同一个 GuardedObject
- 如果有结果不断从一个线程到另一个线程那么可以使用消息队列（见生产者/消费者）
- JDK 中，join 的实现、Future 的实现，采用的就是此模式
- 因为要等待另一方的结果，因此归类到同步模式
2. 实现：
@Slf4j(topic = "c.d6_GuardedObject")
public class d6_GuardedObject {
private Object response;
private final Object lock = new Object();
public Object get() {
synchronized (lock) {
// 条件不满足则等待
while (response == null) {
log.debug("等待 response ");
try {
lock.wait();
} catch (InterruptedException e) {
e.printStackTrace();
}
}
return response;
}
}
public void complete(Object response) {
synchronized (lock) {
// 条件满足，通知等待线程
this.response = response;
lock.notifyAll();
}
}
public static void main(String[] args) {
d6_GuardedObject guardedObject = new d6_GuardedObject();
new Thread(()->{
Object myResponse = guardedObject.get();
log.debug("myResponse: {}", myResponse);
}, "t1").start();
new Thread(()->{
try {
Thread.sleep(1000);
} catch (InterruptedException e) {
throw new RuntimeException(e);
}
guardedObject.complete("等待结束...");
}, "t2").start();
}
}
15:55:48 [t1] c.d6_GuardedObject - 等待 response
15:55:49 [t1] c.d6_GuardedObject - myResponse: 等待结束...
3. 带有时间限制的实现：
@Slf4j(topic = "c.d7_CuardedObjectV2")
public class d7_CuardedObjectV2 {
private Object response;
private final Object lock = new Object();
public Object get(long millis) {
synchronized (lock) {
// 1) 记录最初时间
long begin = System.currentTimeMillis();
// 2) 已经经历的时间
long timePassed = 0;
while (response == null) {
// 4) 假设 millis 是 1000，结果在 400 时唤醒了，那么还有 600 要等
long waitTime = millis - timePassed;
log.debug("waitTime: {}", waitTime);
if (waitTime <= 0) {
log.debug("break...");
break;
}
try {
lock.wait(waitTime);
} catch (InterruptedException e) {
e.printStackTrace();
}
// 3) 如果提前被唤醒，这时已经经历的时间假设为 400
timePassed = System.currentTimeMillis() - begin;
log.debug("timePassed: {}, object is null {}",
timePassed, response == null);
}
return response;
}
}
public void complete(Object response) {
synchronized (lock) {
// 条件满足，通知等待线程
this.response = response;
log.debug("notify...");
lock.notifyAll();
}
}
public static void main(String[] args) {
d7_CuardedObjectV2 v2 = new d7_CuardedObjectV2();
new Thread(() -> {
try {
Thread.sleep(1000);
} catch (InterruptedException e) {
throw new RuntimeException(e);
}
v2.complete(null);
try {
Thread.sleep(1000);
} catch (InterruptedException e) {
throw new RuntimeException(e);
}
v2.complete(Arrays.asList("a", "b", "c"));
}).start();
Object response = v2.get(2500);
if (response != null) {
log.debug("get response: [{}] lines", ((List<String>) response).size());
} else {
log.debug("can't get response");
}
}
}
16:45:02 [main] c.d7_CuardedObjectV2 - waitTime: 2500
16:45:03 [Thread-0] c.d7_CuardedObjectV2 - notify...
16:45:03 [main] c.d7_CuardedObjectV2 - timePassed: 1012, object is null true
16:45:03 [main] c.d7_CuardedObjectV2 - waitTime: 1488
16:45:04 [Thread-0] c.d7_CuardedObjectV2 - notify...
16:45:04 [main] c.d7_CuardedObjectV2 - timePassed: 2014, object is null false
16:45:04 [main] c.d7_CuardedObjectV2 - get response: [3] lines
Join 原理
是调用者轮询检查线程 alive 状态
t1.join();
// 等价于下面的代码
synchronized (t1) {
// 调用者线程进入 t1 的 waitSet 等待, 直到 t1 运行结束
while (t1.isAlive()) {
t1.wait(0);
}
}
join 源码：其实也是用wait实现的带有时间限制的保护性暂停
public final void join(long millis) throws InterruptedException {
// ... millis 非法异常判断
synchronized (this) {
if (millis > 0) {
if (isAlive()) {
final long startTime = System.nanoTime(); // 记录最初时间
long delay = millis;
do {
wait(delay);
} while (isAlive() && (delay = millis -
NANOSECONDS.toMillis(System.nanoTime() - startTime)) > 0);
// passTime = System.nanoTime() - startTime ： 获取已经经历过的时间
// delay = millis - passTime ：更新剩余该等待的时间
}
} else {
while (isAlive()) {
wait(0);
}
}
}
}
Park & Unpark
它们是 LockSupport 类中的方法
// 暂停当前线程
LockSupport.park();
// 恢复某个线程的运行
LockSupport.unpark(暂停线程对象)
特点
与 Object 的 wait & notify 相比
- wait，notify 和 notifyAll 必须配合 Object Monitor 一起使用，而 park，unpark 不必
- park & unpark 是以指定线程为单位来【阻塞】和【唤醒】线程，而 notify 只能随机唤醒一个等待线程，notifyAll是唤醒所有等待线程，就不那么【精确】
- park & unpark 可以先 unpark，而 wait & notify 不能先 notify
原理
每个线程都有自己的一个 Parker 对象，由三部分组成 _counter ， _cond 和 _mutex 打个比喻
-
线程就像一个旅人，Parker 就像他随身携带的背包，条件变量就好比背包中的帐篷。_counter 就好比背包中的备用干粮（0 为耗尽，1 为充足）
-
调用 park 就是要看需不需要停下来歇息
-
如果备用干粮耗尽，那么钻进帐篷歇息
-
如果备用干粮充足，那么不需停留，继续前进
-
-
调用 unpark，就好比令干粮充足
- 如果这时线程还在帐篷，就唤醒让他继续前进
- 如果这时线程还在运行，那么下次他调用 park 时，仅是消耗掉备用干粮，不需停留继续前进
- 因为背包空间有限，多次调用 unpark 仅会补充一份备用干粮
调用 park
- 当前线程调用 Unsafe.park() 方法
- 检查 _counter ，本情况为 0，这时，获得 _mutex 互斥锁
- 线程进入 _cond 条件变量阻塞
- 设置 _counter = 0
调用 unpark:
- 调用 Unsafe.unpark(Thread_0) 方法，设置 _counter 为 1
- 唤醒 _cond 条件变量中的 Thread_0
- Thread_0 恢复运行
- 设置 _counter 为 0
先调用 unpark 再调用 park:
- 调用 Unsafe.unpark(Thread_0) 方法，设置 _counter 为 1
- 唤醒 _cond 条件变量中的 Thread_0
- Thread_0 恢复运行
- 设置 _counter 为 0
线程状态转换
假设有线程 Thread t
NEW --> RUNNABLE
情况 1 NEW --> RUNNABLE
当调用 t.start() 方法时，由 NEW --> RUNNABLE
RUNNABLE <–> WAITING：-> wait(), join(), park()
情况 2 RUNNABLE <–> WAITING
t 线程用 synchronized(obj) 获取了对象锁后
-
调用 obj.wait() 方法时，t 线程从 RUNNABLE --> WAITING
-
调用 obj.notify() ， obj.notifyAll() ， t.interrupt() 时
-
竞争锁成功，t 线程从 WAITING --> RUNNABLE
-
竞争锁失败，t 线程从 WAITING --> BLOCKED
-
情况 3 RUNNABLE <–> WAITING
- 当前线程调用 t.join() 方法时，当前线程从 RUNNABLE --> WAITING
- 注意是当前线程在t 线程对象的监视器上等待
- t 线程运行结束，或调用了当前线程的 interrupt() 时，当前线程从 WAITING --> RUNNABLE
情况 4 RUNNABLE <–> WAITING
- 当前线程调用 LockSupport.park() 方法会让当前线程从 RUNNABLE --> WAITING
- 调用 LockSupport.unpark(目标线程) 或调用了线程 的 interrupt() ，会让目标线程从 WAITING -->RUNNABLE
RUNNABLE <–> TIMED_WAITING：-> wait(n), join(n), sleep(n)
情况 5 RUNNABLE <–> TIMED_WAITING
t 线程用 synchronized(obj) 获取了对象锁后
- 调用 obj.wait(long n) 方法时，t 线程从 RUNNABLE --> TIMED_WAITING
- t 线程等待时间超过了 n 毫秒，或调用 obj.notify() ， obj.notifyAll() ， t.interrupt() 时
- 竞争锁成功，t 线程从 TIMED_WAITING --> RUNNABLE
- 竞争锁失败，t 线程从 TIMED_WAITING --> BLOCKED
情况 6 RUNNABLE <–> TIMED_WAITING
- 当前线程调用 t.join(long n) 方法时，当前线程从 RUNNABLE --> TIMED_WAITING
- 注意是当前线程在t 线程对象的监视器上等待
- 当前线程等待时间超过了 n 毫秒，或t 线程运行结束，或调用了当前线程的 interrupt() 时，当前线程从 TIMED_WAITING --> RUNNABLE
情况 7 RUNNABLE <–> TIMED_WAITING
- 当前线程调用 Thread.sleep(long n) ，当前线程从 RUNNABLE --> TIMED_WAITING
- 当前线程等待时间超过了 n 毫秒，当前线程从 TIMED_WAITING --> RUNNABLE
情况 8 RUNNABLE <–> TIMED_WAITING
- 当前线程调用 LockSupport.parkNanos(long nanos) 或 LockSupport.parkUntil(long millis) 时，当前线程从 RUNNABLE --> TIMED_WAITING
- 调用 LockSupport.unpark(目标线程) 或调用了线程 的 interrupt() ，或是等待超时，会让目标线程从TIMED_WAITING–> RUNNABLE
RUNNABLE <–> BLOCKED
情况 9 RUNNABLE <–> BLOCKED
t 线程用 synchronized(obj) 获取了对象锁时如果竞争失败，从 RUNNABLE --> BLOCKED
- 持 obj 锁线程的同步代码块执行完毕，会唤醒该对象上所有 BLOCKED 的线程重新竞争，如果其中 t 线程竞争成功，从 BLOCKED --> RUNNABLE ，其它失败的线程仍然 BLOCKED
RUNNABLE <–> TERMINATED
情况 10 RUNNABLE <–> TERMINATED
当前线程所有代码运行完毕，进入TERMINATED
活跃性
死锁
有这样的情况：一个线程需要同时获取多把锁，这时就容易发生死锁
t1 线程 获得 A对象 锁，接下来想获取 B对象的锁 t2 线程 获得 B对象 锁
定位死锁
检测死锁可以使用 jconsole工具，或者使用 jps 定位进程 id，再用 jstack 定位死锁：
jstack定位死锁：
t1 等待的锁对象被 t2 锁住了；t1锁住的对象被 t2等待
stack也会提示找到的死锁：
- 避免死锁要注意加锁顺序
- 另外如果由于某个线程进入了死循环，导致其它线程一直等待，对于这种情况 linux 下可以通过 top 先定位到 CPU 占用高的 Java 进程，再利用 top -Hp 进程id 来定位是哪个线程，最后再用 jstack 排查
活锁
活锁出现在两个线程互相改变对方的结束条件，最后谁也无法结束，例如：
死锁是无法继续运行下去，活锁是一直运行下去
import lombok.extern.slf4j.Slf4j;
@Slf4j(topic = "c.d9_TestLiveLock")
public class d9_TestLiveLock {
static volatile int count = 10;
static final Object lock = new Object();
public static void main(String[] args) {
new Thread(() -> {
// 期望减到 0 退出循环
while (count > 0) {
try {
Thread.sleep(200);
} catch (InterruptedException e) {
throw new RuntimeException(e);
}
count--;
log.debug("count: {}", count);
}
}, "t1").start();
new Thread(() -> {
// 期望超过 20 退出循环
while (count < 20) {
try {
Thread.sleep(200);
} catch (InterruptedException e) {
throw new RuntimeException(e);
}
count++;
log.debug("count: {}", count);
}
}, "t2").start();
}
}
饥饿
很多教程中把饥饿定义为，一个线程由于优先级太低，始终得不到 CPU 调度执行，也不能够结束，饥饿的情况不易演示，讲读写锁时会涉及饥饿问题
的一个线程饥饿的例子，可以使用顺序加锁的方式解决之前的死锁问题
线程1锁住了A，线程2锁住了B，死锁发生：
顺序加锁来避免死锁的解决方案：
必须先获得锁对象A才能获得锁对象B，这样就不会出现，线程2在获取A的时候就会阻塞而一直等待线程1释放
ReentrantLock（可重入锁）
相对于 synchronized 它具备如下特点
- 可中断
- 可以设置超时时间
- 可以设置为公平锁（避免饥饿）
- 支持多个条件变量
与 synchronized 一样，都支持可重入
基本语法
// 获取锁
reentrantLock.lock();
try {
// 临界区
} finally {
// 释放锁
reentrantLock.unlock();
}
可重入
可重入是指同一个线程如果首次获得了这把锁，那么因为它是这把锁的拥有者，因此有权利再次获取这把锁
如果是不可重入锁，那么第二次获得锁时，自己也会被锁挡住
对一个锁对象反复加锁的示例：
@Slf4j(topic = "c.d10_ReentrantLock")
public class d10_ReentrantLock {
private static ReentrantLock lock = new ReentrantLock();
public static void main(String[] args) {
lock.lock();
try {
log.debug("enter main");
method1();
}finally {
lock.unlock();
}
}
public static void method1(){
lock.lock();
try {
log.debug("enter method1");
method2();
}finally {
lock.unlock();
}
}
public static void method2(){
lock.lock();
try {
log.debug("enter method2");
}finally {
lock.unlock();
}
}
}
输出：
19:45:30 [main] c.d10_ReentrantLock - enter main
19:45:30 [main] c.d10_ReentrantLock - enter method1
19:45:30 [main] c.d10_ReentrantLock - enter method2
可打断
可以用让其他线程调用 interrupt 方法打断当前的锁
需要使用 lockInterruptibly 方法进行加锁才可被打断：
@Slf4j(topic = "c.d11_TestLockInterrupt")
public class d11_TestLockInterrupt {
private static ReentrantLock lock = new ReentrantLock();
public static void main(String[] args) throws InterruptedException {
Thread t1 = new Thread(()->{
try {
log.debug("尝试获得锁");
// lockInterruptibly：
// 如果没有竞争，此方法会获取lock对象的锁
// 如果有竞争，则进去阻塞队列，可以被其他线程用interrupt方法打断
lock.lockInterruptibly();
}catch (InterruptedException e){
e.printStackTrace();
log.debug("没有获得锁，返回");
return;
}
try {
log.debug("获取到锁");
}finally {
lock.unlock();
}
}, "t1");
lock.lock(); // 主线程先获取锁，t1等待
t1.start();
Thread.sleep(1000);
log.debug("打断 t1");
t1.interrupt();
}
}
19:53:49 [t1] c.d11_TestLockInterrupt - 尝试获得锁
19:53:50 [main] c.d11_TestLockInterrupt - 打断 t1
19:53:50 [t1] c.d11_TestLockInterrupt - 没有获得锁，返回
java.lang.InterruptedException at ... ...
锁超时
可打断是被动的，等待其他线程打断。锁超时是主动的打断，避免无限时的等待下去
使用 tryLock 方法实现 没获得到锁就立刻失败：
ReentrantLock lock = new ReentrantLock();
Thread t1 = new Thread(() -> {
log.debug("启动...");
if (!lock.tryLock()) { // trylock尝试获取锁
log.debug("获取立刻失败，返回");
return;
}
try {
log.debug("获得了锁");
} finally {
lock.unlock();
}
}, "t1");
lock.lock();
log.debug("获得了锁");
t1.start();
try {
Thread.sleep(2000);
} finally {
lock.unlock();
}
超时失败实现：
lock.tryLock(1, TimeUnit.SECONDS)
公平锁
ReentrantLock 默认是不公平的。根据构造参数可以设置为公平锁：
ReentrantLock lock = new ReentrantLock(true);
条件变量
synchronized 中也有条件变量，就是我们讲原理时那个 waitSet 休息室，当条件不满足时进入 waitSet 等待
ReentrantLock 的条件变量比 synchronized 强大之处在于，它是支持多个条件变量的，不同在于：
- synchronized 是那些不满足条件的线程都在一间休息室等消息
- 而 ReentrantLock 支持多间休息室，有专门等烟的休息室、专门等早餐的休息室、唤醒时也是按休息室来唤醒
使用要点：
- await 前需要获得锁
- await 执行后，会释放锁，进入 conditionObject 等待
- await 的线程被唤醒（或打断、或超时）取重新竞争 lock 锁
竞争 lock 锁成功后，从 await 后继续执行
使用方式：
通过 lock.newCondtition() 的方法创建一个新的条件变量对象：
@Slf4j(topic = "c.d12_TestConditionLock")
public class d12_TestConditionLock {
static ReentrantLock lock = new ReentrantLock();
public static void main(String[] args) throws InterruptedException {
Condition condition1 = lock.newCondition();
Condition condition2 = lock.newCondition();
lock.lock();
// 进入条件1（休息室1）等待
condition1.await();
// 叫醒休息室1中的线程：
condition1.signal();
condition1.signalAll();
}
}
本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。 如若内容造成侵权/违法违规/事实不符，请联系我的编程经验分享网邮箱：veading@qq.com进行投诉反馈，一经查实，立即删除！