Skip to content

Commit 029713f

Browse files
SnailclimbSnailclimb
authored
Merge pull request Snailclimb#2554 from 1020325258/java-concurrent
[docs update]增加ReentrantLock相关内容
2 parents e196417 + 5357847 commit 029713f

File tree

1 file changed

+87
-1
lines changed

1 file changed

+87
-1
lines changed

‎docs/java/concurrent/java-concurrent-questions-02.md‎

Lines changed: 87 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -646,16 +646,102 @@ public class SynchronizedDemo {
646646

647647
相比`synchronized`，`ReentrantLock`增加了一些高级功能。主要来说主要有三点：
648648

649-
- **等待可中断** : `ReentrantLock`提供了一种能够中断等待锁的线程的机制，通过 `lock.lockInterruptibly()` 来实现这个机制。也就是说正在等待的线程可以选择放弃等待，改为处理其他事情。
649+
- **等待可中断** : `ReentrantLock`提供了一种能够中断等待锁的线程的机制，通过 `lock.lockInterruptibly()` 来实现这个机制。也就是说当前线程在等待获取锁的过程中，如果其他线程中断当前线程「 `interrupt()` 」，当前线程就会抛出 `InterruptedException` 异常，可以捕捉该异常进行相应处理。
650650
- **可实现公平锁** : `ReentrantLock`可以指定是公平锁还是非公平锁。而`synchronized`只能是非公平锁。所谓的公平锁就是先等待的线程先获得锁。`ReentrantLock`默认情况是非公平的，可以通过 `ReentrantLock`类的`ReentrantLock(boolean fair)`构造方法来指定是否是公平的。
651651
- **可实现选择性通知（锁可以绑定多个条件）**: `synchronized`关键字与`wait()`和`notify()`/`notifyAll()`方法相结合可以实现等待/通知机制。`ReentrantLock`类当然也可以实现，但是需要借助于`Condition`接口与`newCondition()`方法。
652+
- **支持超时** ：`ReentrantLock` 提供了 `tryLock(timeout)` 的方法，可以指定等待获取锁的最长等待时间，如果超过了等待时间，就会获取锁失败，不会一直等待。
652653

653654
如果你想使用上述功能，那么选择 `ReentrantLock` 是一个不错的选择。
654655

655656
关于 `Condition`接口的补充：
656657

657658
> `Condition`是 JDK1.5 之后才有的，它具有很好的灵活性，比如可以实现多路通知功能也就是在一个`Lock`对象中可以创建多个`Condition`实例（即对象监视器），**线程对象可以注册在指定的`Condition`中，从而可以有选择性的进行线程通知，在调度线程上更加灵活。 在使用`notify()/notifyAll()`方法进行通知时，被通知的线程是由 JVM 选择的，用`ReentrantLock`类结合`Condition`实例可以实现“选择性通知”** ，这个功能非常重要，而且是 `Condition` 接口默认提供的。而`synchronized`关键字就相当于整个 `Lock` 对象中只有一个`Condition`实例，所有的线程都注册在它一个身上。如果执行`notifyAll()`方法的话就会通知所有处于等待状态的线程，这样会造成很大的效率问题。而`Condition`实例的`signalAll()`方法，只会唤醒注册在该`Condition`实例中的所有等待线程。
658659
660+
关于 **等待可中断** 的补充：
661+
662+
> `lockInterruptibly()` 会让获取锁的线程在阻塞等待的过程中可以响应中断，即当前线程在获取锁的时候，发现锁被其他线程持有，就会阻塞等待
663+
>
664+
> 在阻塞等待的过程中，如果其他线程中断当前线程 「 `interrupt()` 」，就会抛出 `InterruptedException` 异常，可以捕获该异常，做一些处理操作
665+
>
666+
> 为了更好理解这个方法，借用 Stack Overflow 上的一个案例，可以更好地理解 `lockInterruptibly()` 可以响应中断：
667+
>
668+
> ```JAVA
669+
> public class MyRentrantlock {
670+
> Thread t = new Thread() {
671+
> @Override
672+
> public void run() {
673+
> ReentrantLock r = new ReentrantLock();
674+
> // 1.1、第一次尝试获取锁，可以获取成功
675+
> r.lock();
676+
>
677+
> // 1.2、此时锁的重入次数为 1
678+
> System.out.println("lock() : lock count :" + r.getHoldCount());
679+
>
680+
> // 2、中断当前线程，通过 Thread.currentThread().isInterrupted() 可以看到当前线程的中断状态为 true
681+
> interrupt();
682+
> System.out.println("Current thread is intrupted");
683+
>
684+
> // 3.1、尝试获取锁，可以成功获取
685+
> r.tryLock();
686+
> // 3.2、此时锁的重入次数为 2
687+
> System.out.println("tryLock() on intrupted thread lock count :" + r.getHoldCount());
688+
> try {
689+
> // 4、打印线程的中断状态为 true，那么调用 lockInterruptibly() 方法就会抛出 InterruptedException 异常
690+
> System.out.println("Current Thread isInterrupted:" + Thread.currentThread().isInterrupted());
691+
> r.lockInterruptibly();
692+
> System.out.println("lockInterruptibly() --NOt executable statement" + r.getHoldCount());
693+
> } catch (InterruptedException e) {
694+
> r.lock();
695+
> System.out.println("Error");
696+
> } finally {
697+
> r.unlock();
698+
> }
699+
>
700+
> // 5、打印锁的重入次数，可以发现 lockInterruptibly() 方法并没有成功获取到锁
701+
> System.out.println("lockInterruptibly() not able to Acqurie lock: lock count :" + r.getHoldCount());
702+
>
703+
> r.unlock();
704+
> System.out.println("lock count :" + r.getHoldCount());
705+
> r.unlock();
706+
> System.out.println("lock count :" + r.getHoldCount());
707+
> }
708+
> };
709+
> public static void main(String str[]) {
710+
> MyRentrantlock m = new MyRentrantlock();
711+
> m.t.start();
712+
> }
713+
> }
714+
> ```
715+
>
716+
> 输出：
717+
>
718+
> ```BASH
719+
> lock() : lock count :1
720+
> Current thread is intrupted
721+
> tryLock() on intrupted thread lock count :2
722+
> Current Thread isInterrupted:true
723+
> Error
724+
> lockInterruptibly() not able to Acqurie lock: lock count :2
725+
> lock count :1
726+
> lock count :0
727+
> ```
728+
729+
关于 **支持超时** 的补充：
730+
731+
> **为什么需要 `tryLock(timeout)` 这个功能呢？**
732+
>
733+
> 假设这样一种场景：有一个加载缓存数据的任务在某个时间点多个线程同时要来执行，为了并发安全，通过锁来控制只有一个线程可以执行该任务。
734+
>
735+
> 假设大量线程同时来执行该任务，由于需要穿行执行，因此大量线程都进入阻塞队列等待获取锁
736+
>
737+
> 当第一个线程拿到锁，执行完任务之后，此时后边的线程都不需要执行该任务了，但是由于没有这个超时功能，导致后边的线程还需要在队列中阻塞等待获取锁，再一个个进入同步代码块，发现任务已经执行过了，不需要自己再执行了，之后再退出释放锁，退出同步代码块。
738+
>
739+
> 因此就需要一个支持超时的功能，`tryLock(timeout)` 的作用就是 **将大量线程的串行操作转为并行操作** ，当大量线程等待时间已经超过了指定的超时时间，直接返回 false，表示获取锁失败，不需要大量的线程串行排队等待获取锁。
740+
>
741+
> ![image-20241208153800259](https://11laile-note-img.oss-cn-beijing.aliyuncs.com/image-20241208153800259.png)
742+
>
743+
> 这里 `tryLock(timeout)` 的情况只是举一个特殊的情况，其实是参考了分布式环境下，更新 Redis 缓存时会出现这种情况，但是在分布式环境下肯定不会使用 synchronized ，因此这里主要是举个例子说一下 tryLock(timeout) 的作用！
744+
659745
### 可中断锁和不可中断锁有什么区别？
660746
661747
- **可中断锁**：获取锁的过程中可以被中断，不需要一直等到获取锁之后 才能进行其他逻辑处理。`ReentrantLock` 就属于是可中断锁。

0 commit comments

Comments
 (0)