04.071-reentrantlock简介、可重入、可打断、锁超时、解决哲学家吃饭、公平锁、条件变量、

原创已于 2024-12-16 16:16:44 修改 · 687 阅读

21 ·

CC 4.0 BY-SA版权

文章标签：

#java

于 2024-12-13 14:51:20 首次发布

java.jdk.juc 专栏收录该内容

89 篇文章

订阅专栏

这个可重入的搞完就下一章了，

明天终于周五了，这周终于双休了，感觉要累死了。

567内容不多， 8 就结束了，终于juc结束了，可以写简历上了，

然后先看 db高级，这个有用点，然后写简历，

再看一致性啥的那些，看有没有吧，有就写简历，

没有可以先看设计模式 jvm spring springmvc 啥的，写简历，

java synchronized 和 reentrantlock

在 Java 中，synchronized 和 ReentrantLock 都是用于线程同步的工具，它们的作用是保证多线程环境中共享资源的访问是互斥的，避免出现数据竞争的情况。虽然它们都能提供同步功能，但在实现和使用上有一些差异。下面是它们之间的比较和特点。

1. synchronized

synchronized 是 Java 中的一种关键字，用于控制对代码块或方法的访问，以确保同一时刻只有一个线程能执行该部分代码。

特点：

简洁：synchronized 语法简单，直接在方法或代码块前加上 synchronized 关键字即可。
隐式锁：它是对对象进行加锁，每个对象（包括类）都有一个隐式的锁。当多个线程尝试访问同一 synchronized 方法或代码块时，会进入竞争锁的状态。
自动释放锁：当 synchronized 块或方法执行完毕，锁会自动释放，无需手动解锁。
无法中断：如果一个线程已经获得了锁，其他线程只能等待，无法强行中断。

2. ReentrantLock

ReentrantLock 是 Java 5 引入的 java.util.concurrent.locks 包中的一个类，提供了比 synchronized 更加灵活和强大的锁机制。

特点：

显式锁：与 synchronized 不同，ReentrantLock 是一个显式的锁，需要通过 lock() 和 unlock() 方法进行加锁和解锁。
可中断：可以通过 lockInterruptibly() 方法在等待锁时能够响应中断。
公平锁和非公平锁：可以选择是否使用公平锁，公平锁会让线程按照请求锁的顺序来获取锁，非公平锁则没有这种约束。ReentrantLock 默认是非公平的。
锁重入：ReentrantLock 是可重入的，这意味着同一线程可以多次获得同一把锁，而不会发生死锁。
条件变量：ReentrantLock 可以与 Condition 一起使用，提供了类似于传统的线程等待/通知机制的功能，能够更加灵活地控制线程的执行。

3. 主要区别

特性	`synchronized`	`ReentrantLock`
锁的类型	隐式锁，锁是对象的监视器（monitor）	显式锁，需要手动加锁和释放锁
可中断性	无法中断，线程只能等待锁的释放	可以中断，通过 `lockInterruptibly()` 方法
公平性	不提供公平锁机制	支持公平锁（通过构造函数参数设置）
锁重入性	允许锁重入	允许锁重入
性能	性能较差，尤其是在锁竞争激烈时	性能更优，支持更多的高级操作
锁释放	锁释放由 JVM 自动管理	必须手动释放锁（通过 `unlock()`）
条件变量	不支持条件变量	支持条件变量（`Condition` 类）

4. 使用场景

synchronized 适合用在简单的多线程同步场景中，尤其是在代码逻辑较简单且没有复杂的锁管理需求时。
ReentrantLock 适合用于更复杂的场景，如需要响应中断、尝试锁定、实现公平锁、使用条件变量等功能的场合。它的灵活性使得它在一些高级并发控制中更加优越。

5. 总结

对于简单的同步任务，synchronized 足够用了，简洁且易于理解。
对于复杂的并发控制，ReentrantLock 提供了更多的灵活性和功能，尤其是在锁管理和线程协调方面。

为什么会性能更优

ReentrantLock 相比 synchronized 提供了更高的性能，主要原因在于以下几个方面：

1. 锁管理的灵活性

synchronized 是 Java 的内置机制，它由 JVM 和操作系统的线程管理器负责处理。在锁竞争激烈的情况下，JVM 的 synchronized 锁可能会导致线程的上下文切换和阻塞，这样就增加了性能开销。
ReentrantLock 提供了更多的锁管理操作，允许程序员显式地控制锁的获取与释放。它的锁实现是在用户级别进行的，不完全依赖于操作系统，因此在高并发场景下能更高效地管理锁资源，避免不必要的上下文切换。

2. 更好的竞争控制（自旋锁）

ReentrantLock 通常会在锁竞争发生时采用自旋锁机制，也就是说，当线程发现锁已经被其他线程持有时，它会在一定时间内反复尝试获取锁（自旋），而不是立即进入阻塞状态。这样，如果锁竞争非常短暂，自旋操作能够避免进入阻塞，减少线程切换的开销。
相比之下，synchronized 在锁竞争时，线程通常会进入阻塞状态，导致线程切换开销增加，性能较低。

3. 支持中断

ReentrantLock 提供了 lockInterruptibly() 方法，允许线程在等待锁的时候响应中断。这使得程序可以灵活地处理线程的中断，避免因等待锁而导致的长时间阻塞。特别是在高并发和资源紧张的场景中，这种中断支持可以帮助程序更好地处理资源争用，提高系统的整体响应性。
synchronized 无法响应中断，线程一旦获取锁，会一直持有锁直到执行完同步代码块，这可能导致在高并发情况下，锁持有者阻塞其他线程，进而影响性能。

4. 公平锁和非公平锁

ReentrantLock 支持公平锁（通过构造函数 new ReentrantLock(true) 创建），公平锁可以按照线程请求锁的顺序来分配锁。虽然公平锁会带来一些额外的性能开销，但在某些高并发场景下，它能避免饥饿（某些线程长时间无法获取锁），使系统表现得更加稳定。
synchronized 并没有显式的公平锁机制，可能导致某些线程一直无法获得锁（即饥饿问题），从而降低整体系统性能，尤其是在锁竞争非常激烈时。

5. 条件变量（Condition）支持

ReentrantLock 提供了 Condition 对象，它允许线程在某些条件下挂起和被唤醒，从而实现更加灵活和高效的线程协调机制。Condition 提供了 await() 和 signal() 方法，可以用来实现复杂的线程协作逻辑（例如生产者-消费者模型），且不会产生不必要的线程阻塞。
synchronized 只能通过 wait() 和 notify() 来进行线程的协调，功能相对简单和有限，且容易出现死锁等问题，导致性能下降。

6. 锁的重入特性

ReentrantLock 是可重入的，也就是说，同一线程可以多次获取同一个锁。synchronized 也是可重入的，但 ReentrantLock 提供了更多的控制（如获取锁的次数，允许调试等）。
如果程序需要频繁地在不同方法间获取同一把锁，那么 ReentrantLock 能够提供更加明确和可控的重入特性，有助于提高性能，避免因不必要的锁释放和重新获取导致的额外开销。

7. 锁释放与性能开销

在 ReentrantLock 中，锁的释放是显式的，通过调用 unlock() 方法。开发人员可以精确控制何时释放锁，这使得 ReentrantLock 能够在性能关键的代码段中减少锁的持有时间，从而减少锁竞争。
而 synchronized 锁的释放是隐式的，JVM 会在同步代码块执行完毕时自动释放锁，但没有办法精准控制锁的持有时间，这可能导致锁的持有时间过长，影响性能。

8. 避免不必要的上下文切换

在高并发的情况下，ReentrantLock 的自旋锁和更高效的线程调度能避免频繁的上下文切换。线程上下文切换是昂贵的操作，它涉及保存和加载线程的上下文（如寄存器、堆栈等），而 ReentrantLock 提供了在短期锁定的情况下减少这种开销的能力。
synchronized 在锁竞争中更容易导致线程被挂起（尤其是当锁竞争激烈时），从而增加上下文切换的开销。

总结

ReentrantLock 在性能上的优势主要体现在：

更灵活的锁管理和线程协调；
高效的锁竞争控制（包括自旋锁和中断支持）；
可定制的公平性策略；
支持条件变量、精确的锁释放控制等高级功能。

这些优势使得 ReentrantLock 在高并发、复杂同步需求的场景中表现得更为高效，而 synchronized 则在简单的同步需求下更加简洁和易用。

简单来说，reentrantlock 和 synchronized 的每个区别，都是性能提高的解决方案结果。

reentrantlock 就是为了解决 synchronized 短板，而出现的产物。

公平锁真的公平吗

公平锁（Fair Lock）并不总是“绝对公平”，尽管它尽力保证按请求锁的顺序来分配锁，但它仍然存在一些细节上的限制和开销，因此不能保证在所有情况下都“完美公平”。以下是关于公平锁的一些重要细节和考虑：

1. 公平锁的定义

公平锁是指锁的获取顺序按照线程请求锁的顺序进行，即先来先得，避免了线程饥饿的问题。在使用公平锁时，新的线程会在队列的末尾排队等待锁，保证了请求锁的线程按顺序获得锁。
在 Java 中，ReentrantLock 提供了一个构造方法允许设置公平性：new ReentrantLock(true) 表示公平锁。

2. 公平性保证的实现

公平锁是通过队列来实现的，所有请求锁的线程都会被排队，只有前面的线程释放了锁，后面的线程才可以获取锁。
公平锁的实现是通过 AQS（AbstractQueuedSynchronizer，抽象队列同步器）来管理线程队列的。在公平锁模式下，ReentrantLock 会确保一个线程释放锁后，队列中的第一个等待线程能够获得锁。

3. 公平锁的开销和影响

公平锁虽然能避免线程饥饿问题，但会引入一定的性能开销。因为每次线程获取锁之前，都需要进行排队和选择，系统需要管理等待队列，并且可能增加上下文切换的频率。
在高竞争的环境下，公平锁可能会因为线程竞争和排队的机制引起额外的延迟，这在某些场景下可能反而比非公平锁（ReentrantLock 的默认模式）更低效。

4. 不完全的公平性

公平锁虽然在设计上保证了按请求顺序分配锁，但并不意味着每次获取锁的线程都是“公平的”。比如：
- 如果某个线程在队列中排队时被操作系统的调度策略抢占，可能导致其他线程提前执行，造成调度的不完全公平。
- 在实际的多线程环境中，线程的切换、上下文切换和操作系统调度策略可能会影响公平性的严格程度。
因此，公平锁在多核、复杂的系统中可能无法完全保证“绝对的公平”，它依赖于 JVM 的实现和操作系统的调度行为。

5. 性能权衡

在高并发的情况下，使用公平锁通常会引入更多的系统开销，因为每次请求锁的线程都需要等待队列中的前一个线程释放锁。
非公平锁（默认情况下，ReentrantLock 是非公平的）则允许当前请求锁的线程直接获得锁，甚至在队列中有其他线程等待的情况下，这能显著减少线程的等待时间，因此在某些高并发的应用场景下，非公平锁的性能会更好。
但非公平锁可能会导致某些线程长时间无法获取锁，尤其在锁竞争非常激烈时，可能出现“线程饥饿”的问题。

6. 公平锁的适用场景

适用场景：公平锁适合用于要求线程公平轮流获取资源的场景，尤其是当线程持有锁的时间较长或者资源有限，且保证顺序性和防止线程饥饿是必要的。
不适用场景：如果锁的竞争非常激烈，且线程持有锁的时间非常短，使用公平锁可能带来不必要的性能开销，反而降低了系统的吞吐量。

总结

尽管公平锁在设计上尽量保证按顺序分配锁，避免了线程饥饿的情况，但在高并发环境下，它的实际公平性可能受操作系统调度、上下文切换等因素的影响，导致在某些情况下不如预期的“公平”。此外，公平锁的引入会带来一定的性能开销，因此在选择是否使用公平锁时，需要根据实际场景做出权衡。在一些对性能要求非常高的场景，非公平锁可能会更适合。

可重入锁的条件变量

可重入锁的条件变量功能就是，不满足x条件，可以去 y里等。其中 x 是自变量，y是因变量。可以自由配置。

可打断有啥意义

“可打断”是指在多线程编程中，某些操作或方法可以在执行过程中被中断，打断操作可以让线程在执行阻塞操作时响应外部的中断信号并提前结束当前操作。这个机制对于提高系统的响应性和灵活性具有重要意义。

在 Java 等语言中，可打断性常见于线程的阻塞操作（如 sleep、wait、join，以及一些锁相关操作）。在这些操作中，线程会进入一个阻塞状态，直到某个条件满足或者超时结束，而“可打断”则是指在这些操作的过程中，线程可以响应外部的中断信号，提前终止等待。

可打断性的意义：

1. 提高系统响应性

当线程正在进行某些长时间的阻塞操作时（比如 Thread.sleep() 或等待一个锁），系统可以通过中断机制来打断这些操作，从而尽早恢复线程的执行，避免线程长时间处于不必要的等待状态。
比如，在处理请求或处理任务时，可能会遇到某些突发情况，比如接收到取消任务的请求，或者某些任务需要超时处理。可打断的机制可以让线程及时中止当前操作，转而处理这些紧急情况。

2. 避免线程饥饿

在没有可打断机制的情况下，某些线程可能因为等待某个资源而进入阻塞状态，甚至可能长时间无法获得资源，从而出现“线程饥饿”的情况。通过引入中断，系统可以在一定条件下终止阻塞，避免线程长时间无所事事。

3. 灵活控制任务的执行

在很多场景下，线程会执行一些可能需要很长时间的任务（例如网络请求、文件操作或计算密集型任务）。如果任务执行过程中某些条件发生变化（如需要取消任务、超时或重新分配资源等），使用可打断机制可以让线程灵活地响应这些变化，及时停止任务并处理新的需求。
举个例子，在处理用户请求时，如果一个请求需要执行某些耗时操作，而用户在中途取消请求，那么可以通过中断线程来停止当前操作。

4. 避免死锁

在使用多线程时，可能会因为资源竞争导致死锁。如果某个线程长时间阻塞等待资源而无法获取，可以通过中断机制来打破死锁状态，从而让系统恢复正常运行。
举例来说，如果线程 A 在等待线程 B 释放锁，但由于某种原因，线程 B 一直阻塞，而线程 A 也被迫长时间等待，这时如果线程 A 可以被中断，就可以释放它所持有的资源，避免死锁的发生。

5. 资源清理与恢复

当线程在执行某些资源密集型操作时（如磁盘 I/O 或数据库操作），如果操作无法按预期完成（比如超时、外部中断等），通过可打断机制，可以触发相应的清理工作，释放资源，并使线程能够恢复或执行其他任务。

可打断操作的常见示例：

Thread.sleep()
- Thread.sleep() 是一个常见的阻塞操作，它会让当前线程在指定的时间内休眠。虽然线程在休眠时不会消耗 CPU 资源，但如果线程被中断，则会抛出 InterruptedException 异常，可以让线程提前结束休眠并进行其他处理。
Object.wait() 和 Object.notify()
- 在多线程同步中，wait() 会使当前线程进入等待状态，直到其他线程调用 notify() 或 notifyAll() 唤醒。可打断性意味着如果等待的线程在此期间收到中断信号，则会抛出 InterruptedException，提前结束等待。
Thread.join()
- join() 方法会让当前线程等待指定的线程执行完成。在这段等待期间，如果目标线程被中断，调用线程可以提前结束等待。
ReentrantLock 的 lockInterruptibly()
- ReentrantLock 提供了 lockInterruptibly() 方法，使得锁获取操作支持中断。使用这个方法时，如果线程在尝试获取锁时被中断，会抛出 InterruptedException，让线程能够响应中断信号并放弃继续等待锁的操作。

public class InterruptExample {
    public static void main(String[] args) throws InterruptedException {
        Thread thread = new Thread(() -> {
            try {
                // 模拟长时间阻塞操作
                for (int i = 0; i < 10; i++) {
                    System.out.println("Thread running: " + i);
                    Thread.sleep(1000); // 线程休眠1秒
                }
            } catch (InterruptedException e) {
                System.out.println("Thread was interrupted during sleep");
            }
        });

        thread.start();

        // 主线程在2秒后中断子线程
        Thread.sleep(2000);
        thread.interrupt(); // 发送中断信号
        thread.join(); // 等待子线程终止
    }
}