CFSDN坚持开源创造价值，我们致力于搭建一个资源共享平台，让每一个IT人在这里找到属于你的精彩世界.

这篇CFSDN的博客文章Java 重入锁和读写锁的具体使用由作者收集整理，如果你对这篇文章有兴趣，记得点赞哟.

重入锁

重入锁 ReentrantLock，顾名思义，就是支持重进入的锁，它表示该锁能够支持一个线程对资源的重复加锁。除此之外，该锁还支持获取锁时的公平和非公平性选择 。

所谓不支持重进入，可以考虑如下场景：当一个线程调用 lock() 方法获取锁之后，如果再次调用 lock() 方法，则该线程将会被自己阻塞，原因是在调用 tryAcquire(int acquires) 方法时会返回 false，从而导致线程阻塞 。

synchronize 关键字隐式的支持重进入，比如一个 synchronize 修饰的递归方法，在方法执行时，执行线程在获取锁之后仍能连续多次地获得该锁。ReentrantLock 虽然不能像 synchronize 关键字一样支持隐式的重进入，但在调用 lock() 方法时，已经获得锁的线程，能够再次调用 lock() 方法获取锁而不被阻塞 。

1. 实现重进入

重进入特性的实现需要解决以下两个问题:

线程再次获取锁 锁需要去识别获取锁的线程是否为当前占据锁的线程，如果是，则再次成功获取 。

锁的最终释放 线程重复 n 次获取锁，随后在第 n 次释放该锁后，其他线程能获取到锁。实现此功能，理应考虑使用计数 。

ReentrantLock 通过组合自定义同步器来实现锁的获取与释放，以非公平锁实现为例，获取同步状态的代码如下所示，主要是增加了再次获取同步状态的处理逻辑 。

1. final boolean nonfairTryAcquire(int acquires) {
2. final Thread current = Thread.currentThread();
3. int c = getState();
4. if (c == 0) {
5. if (compareAndSetState(0, acquires)) {
6. setExclusiveOwnerThread(current);
7. return true;
8. }
9. }
10. // 判断当前线程是否为获取锁的线程
11. else if (current == getExclusiveOwnerThread()) {
12. // 将同步值进行增加，并返回 true
13. int nextc = c + acquires;
14. if (nextc < 0)
15. throw new Error("Maximum lock count exceeded");
16. setState(nextc);
17. return true;
18. }
19. return false;
20. }

考虑到成功获取锁的线程再次获取锁，只是增加同步状态值，这也就要求 ReentrantLock 在释放同步状态时减少同步状态值，该方法代码如下:

1. protected final boolean tryRelease(int releases) {
2. // 减少状态值
3. int c = getState() - releases;
4. if (Thread.currentThread() != getExclusiveOwnerThread())
5. throw new IllegalMonitorStateException();
6. boolean free = false;
7. // 当同步状态为0，将占有线程设为null，并返回true，表示释放成功
8. if (c == 0) {
9. free = true;
10. setExclusiveOwnerThread(null);
11. }
12. setState(c);
13. return free;
14. }

2. 公平与非公平获取锁的区别

如果一个锁是公平的，那么锁的获取顺序就应该符合请求的绝对时间顺序，也即 FIFO。回顾上一节，非公平锁只要 CAS 设置同步状态成功，即表示当前线程获取了锁，而公平锁则不同，代码如下:

1. protected final boolean tryAcquire(int acquires) {
2. final Thread current = Thread.currentThread();
3. int c = getState();
4. if (c == 0) {
5. /*
6. * 唯一不同的就是判断条件多了 hasQueuedPredecessors()
7. * 该方法用来判断当前节点是否有前驱节点
8. * 如果该方法返回 true，表示有线程比当前线程更早请求获取锁
9. * 因此需要等待前驱线程释放锁之后才能继续获取锁
10. */
11. if (!hasQueuedPredecessors() && compareAndSetState(0, acquires)) {
12. setExclusiveOwnerThread(current);
13. return true;
14. }
15. }
16. else if (current == getExclusiveOwnerThread()) {
17. int nextc = c + acquires;
18. if (nextc < 0)
19. throw new Error("Maximum lock count exceeded");
20. setState(nextc);
21. return true;
22. }
23. return false;
24. }

读写锁

之前提到的锁基本都是排它锁，同一时刻只允许一个线程访问，而读写锁在同一时刻可以允许多个线程访问，但在写线程访问时，所有的读线程和其他写线程均被阻塞。读写锁维护了一对锁，一个读锁和一个写锁，通过分离读锁和写锁，使得并发性相比一般的排它锁有了很大提升 。

1. 接口示例

下面通过缓存示例说明读写锁的使用方式 。

1. public class Cache {
2.  
3. static Map<String, Object> map = new HashMap<>();
4. static ReentrantReadWriteLock rwl = new ReentrantReadWriteLock();
5. static Lock r = rwl.readLock();
6. static Lock w = rwl.writeLock();
7.  
8. /**
9. * 获取一个 key 对应的 value
10. */
11. public static Object get(String key) {
12. r.lock();
13. try {
14. return map.get(key);
15. } finally {
16. r.unlock();
17. }
18. }
19.  
20. /**
21. * 设置 key 对应的 value，并返回旧的 value
22. */
23. public static Object put(String key, Object value) {
24. w.lock();
25. try {
26. return map.put(key, value);
27. } finally {
28. w.unlock();
29. }
30. }
31.  
32. /**
33. * 清空所有的内容
34. */
35. public static void clear() {
36. w.lock();
37. try {
38. map.clear();
39. } finally {
40. w.unlock();
41. }
42. }
43. }

2. 读写状态的设计

读写锁同样依赖自定义同步器来实现功能，而读写状态就是其同步器状态。读写锁的自定义同步器需要在同步状态（一个整型变量）上维护多个读线程和一个写线程的状态，为此需要读写锁将变量切分成两部分，高 16 位表示读，低 16 位表示写 。

上图表示一个线程已经获取了写锁，且重进入了两次，同时也连续两次获取了读锁。通过位运算可以迅速确定读和写各自的状态，假设当前同步状态值为 S，则:

• 写状态等于 S & 0x0000FFFF（将高 16 位全部抹去）
• 读状态等于 S >>> 16（无符号右移 16 位）
• 当写状态增加 1 时，等于 S + 1
• 当读状态增加 1 时，等于 S + (1<<6)，也就是 S + 0x00010000

根据状态的划分能得出一个结论：S 不等于 0 时，当写状态（S & 0x0000FFFF）等于 0 时，则读状态（S >>> 16）大于 0，即读锁已被获取 。

3. 写锁的获取与释放

写锁是一个支持重进入的排它锁。如果当前线程已经获取了写锁，则增加写状态。如果当前线程在获取写锁时，读锁已被获取，或者该线程不是获取写锁的线程，则当前线程进入等待状态，获取写锁的代码如下:

1. protected final boolean tryAcquire(int acquires) {
2. Thread current = Thread.currentThread();
3. int c = getState();
4. // exclusiveCount 方法会用 c & 0x0000FFFF，即得出写状态个数
5. int w = exclusiveCount(c);
6. if (c != 0) {
7. // 根据上面提到的推论，c 不等于 0，而 w 等于 0，证明存在读锁
8. // 当前线程也不是获取了写锁的线程
9. if (w == 0 || current != getExclusiveOwnerThread())
10. return false;
11. if (w + exclusiveCount(acquires) > MAX_COUNT)
12. throw new Error("Maximum lock count exceeded");
13. setState(c + acquires);
14. return true;
15. }
16. if (writerShouldBlock() || !compareAndSetState(c, c + acquires))
17. return false;
18. setExclusiveOwnerThread(current);
19. return true;
20. }

写锁的每次释放均会减少写状态，当写状态为 0 时表示写锁已被释放，从而等待的读写线程能够继续访问读写锁，同时前次写线程的修改对后续读写线程可见 。

4. 读锁的获取与释放

读锁是一个支持重进入的共享锁，它能被多个线程同时获取，在没有其他写线程访问时，读锁总能被成功获取，这里对获取读锁的代码做了简化:

1. protected final int tryAcquireShared(int unused) {
2.  
3. for(;;) {
4. int c = getState();
5. int nextc = c + (1<<16);
6. if(nextc < c) {
7. throw new Error("Maximum lock count exceeded");
8. }
9. // 如果其他线程已经获取写锁，则读取获取失败
10. if(exclusiveCount(c) != 0 && owner != Thread.currentThread()) {
11. return -1;
12. }
13. if(compareAndSetState(c, nextc)) {
14. return 1;
15. }
16. }
17. }

读锁的每次释放均减少读状态，减少的值是 1<<16 。

5. 锁降级

锁降级指的是写锁降级成为读锁。如果当前线程拥有写锁，然后将其释放，最后再获取读锁，这种分段完成的过程不能称之为锁降级。锁降级是指把持住写锁，再获取读锁，随后释放写锁的过程 。

1. public void processData() {
2. readLock.lock();
3. if(!update) {
4. // 必须先释放读锁
5. readLock.unlock();
6. // 锁降级从写锁获取到开始
7. writeLock.lock();
8. try {
9. if(!update) {
10. // 准备数据的流程（略）
11. update = true;
12. }
13. readLock.lock();
14. } finally {
15. writeLock.unlock();
16. }
17. }
18. try {
19. // 使用数据的流程（略）
20. } finally {
21. readLock.unlock();
22. }
23. }

上例中，当数据发生变更，则 update（使用 volatile 修饰）被设置为 false，此时所有访问 processData 方法的线程都能感知到变化，但只有一个线程能获取到写锁，其余线程会被阻塞在写锁的 lock 方法上。当前线程获取写锁完成数据准备之后，再次获取读锁，随后释放写锁，完成锁降级 。

到此这篇关于Java 重入锁和读写锁的具体使用的文章就介绍到这了,更多相关Java 重入锁和读写锁内容请搜索我以前的文章或继续浏览下面的相关文章希望大家以后多多支持我！ 。

原文链接：https://juejin.cn/post/6938036777919709191 。

最后此篇关于Java 重入锁和读写锁的具体使用的文章就讲到这里了,如果你想了解更多关于Java 重入锁和读写锁的具体使用的内容请搜索CFSDN的文章或继续浏览相关文章，希望大家以后支持我的博客！ 。