每日三个JAVA经典面试题(十四)

1.乐观锁一定就是好的吗？

乐观锁是一种在多线程环境中管理对共享资源访问的策略，它基于这样的假设：冲突发生的概率低，因此在实际更新资源之前不会尝试加锁。这种策略在某些场景下非常有效，特别是当资源竞争不频繁，读操作远多于写操作时。然而，乐观锁并非在所有情况下都是最佳选择，它的适用性取决于具体的应用场景。下面是一些乐观锁可能不是最佳选择的情况：

高冲突环境

在高竞争的环境中，尝试提交更新的线程可能经常因为检测到冲突而失败，这会导致大量的重试操作，从而增加了CPU的负担，可能导致性能问题。在这种情况下，悲观锁可能是更好的选择，因为它通过阻塞的方式减少了重试次数，尽管可能引入了线程阻塞和上下文切换的开销。

ABA问题

乐观锁通常使用版本号或时间戳来检测数据在读取和写入期间是否发生了变化。然而，如果数据在这两个操作之间被改变了两次——先从A变成B，然后又从B变回A——乐观锁可能无法正确检测到这种改变（称为ABA问题）。虽然可以通过使用版本号来避免这个问题，但这增加了实现的复杂性。

开销问题

虽然乐观锁避免了线程阻塞，但它需要额外的机制来检查数据是否被修改过，比如版本号的管理。在数据频繁更新的场景中，维护这些额外的机制可能导致显著的开销。

应用场景

• 读多写少：当应用程序的读操作远多于写操作时，乐观锁通常能提供更好的性能。
• 低冲突：在低冲突环境下，即数据并发修改的概率较低时，乐观锁是一个有效的策略。
• 无阻塞需求：对于不能容忍线程阻塞的实时系统，乐观锁提供了一种可能的解决方案。

总的来说，乐观锁在特定的应用场景下可以提供显著的性能优势，但它不是万能的。选择使用乐观锁还是悲观锁，或者是其他的并发控制机制，应该基于对应用程序的具体需求、资源访问模式和预期的工作负载进行仔细的考虑和分析。

2.请尽可能详尽地对比下 Synchronized 和 ReentrantLock 的异同。Synchronized和ReentrantLock都是Java中用于管理同步的工具，它们提供了机制来确保多线程环境中对共享资源的安全访问。尽管它们的目标相同，但在实现和功能上存在一些差异。

相同点

1. 互斥性：都能保证同一时刻只有一个线程执行同步代码块或同步方法，实现线程之间的互斥。
2. 可重入性：都支持可重入，即线程可以重复获取已经持有的锁。这对于防止死锁和实现递归同步代码块非常重要。

不同点

设计和使用

• Synchronized：是Java语言的关键字，提供了一种隐式的锁机制，不需要显式地创建锁对象。它可以修饰方法或代码块。
• ReentrantLock：是java.util.concurrent.locks包中的一个类，提供了显式的锁机制，需要显式地创建锁对象、锁定(lock())和解锁(unlock())。

功能和灵活性

• 等待可中断：ReentrantLock提供了一种能够响应中断的锁获取操作，即如果一个线程正在等待锁，但是被中断了，它能够放弃等待。Synchronized不支持中断等待。
• 尝试非阻塞获取锁：ReentrantLock提供了tryLock()方法，允许尝试获取锁而不是无限期等待，它还可以带有超时参数。Synchronized不提供这样的功能。
• 公平性选择：ReentrantLock允许选择公平锁或非公平锁（通过构造函数指定），而synchronized只能实现非公平锁。

性能

• 在JDK早期版本中，ReentrantLock性能普遍优于synchronized。但随着JVM的发展，特别是在JDK 6及之后的版本中，synchronized的性能得到了显著提升，二者的性能差异已经不再显著。
• 在具体性能表现上，它们的性能差异通常取决于具体的应用场景和JVM实现。在某些情况下，ReentrantLock的高级功能可能导致比synchronized更高的CPU开销。

锁状态查询

• ReentrantLock提供了方法来查询锁的状态，比如查询是否被锁定(isLocked())，是否被当前线程持有(isHeldByCurrentThread())等，而synchronized没有提供直接的方法来查询锁的状态。

总结

Synchronized是Java语言层面的同步机制，使用方便，代码更加简洁；而ReentrantLock提供了更多的高级功能和灵活性。选择使用哪一种，应根据具体的应用场景和需求来决定。如果需要高级的同步控制功能，比如可中断的锁获取、公平锁、锁投票等，ReentrantLock可能是更好的选择。如果同步逻辑简单，优先考虑使用synchronized，因为它使代码更简洁，且现代JVM对synchronized进行了大量优化。

3.ReentrantLock 是如何实现可重入性的？

ReentrantLock是Java中的一个同步锁，它位于java.util.concurrent.locks包下。它的可重入性意味着同一个线程可以多次获得同一个锁，而不会导致死锁。ReentrantLock是通过维护一个持有锁的线程和持有次数的计数器来实现可重入性的。

实现原理

当一个线程首次获得锁时，JVM记录锁的持有者，并将持有次数设为1。如果同一个线程再次尝试获得这个锁，JVM会检查锁的持有者是否是当前线程。如果是，持有次数就增加，而不是阻塞线程。每次成功的锁获取操作都需要相应的锁释放操作。当线程完成所有的锁区域代码后，它会调用unlock()方法释放锁。每调用一次unlock()方法，持有次数就减一。当持有次数为零时，锁被完全释放，其他线程就可以获取锁。

关键特性

• 锁的拥有者：ReentrantLock内部维护了一个指向当前持有锁的线程的引用，这使得锁能够识别出当前尝试获取锁的线程是否为已经持有该锁的线程。

• 状态变量：ReentrantLock使用状态变量来跟踪锁被重入的次数。当线程首次获得锁时，状态变量被设置为1。每次线程重入这个锁时，状态变量就增加。每当线程退出同步代码块并释放锁时，状态变量就减少。当状态变量回到零时，锁被释放。

• 公平性：ReentrantLock提供了选择公平性或非公平性锁的机制。对于公平锁，等待时间最长的线程会优先获得锁，这保证了获取锁的顺序，但可能会降低性能。对于非公平锁，尝试获取锁的线程可能会插队成功，这虽然提高了响应时间，但减少了公平性。