Java中的重重“锁”事，java常见的算法面试题-CSDN博客

本文链接：https://blog.csdn.net/m0_56175058/article/details/136894099

但如果是不可重入锁的话，管理员只允许每一个锁与每个顾客的一个取票票据绑定。那么顾客就不能在取完一个票后继续取票，因为锁还未归还给管理员，另外一个票据还无法与锁绑定。此时，就会发生死锁。

Java中的重重“锁”事

不可重入锁：在主流程中已经获得了锁，如果想要在子流程中再次获取该锁，是无法获取的，并且会发生死锁，因为子流程一直在等待主流程释放锁，而主流程因为子流程没有执行完，并不会释放锁。

我们可以想象一下如果 synchronized 是非可重入锁的话会怎么样：

public class Test {

public synchronized void firstStep(){

}

public synchronized void secondStep(){

}

复制代码

对于这个示例，如果在 firstStep 方法中调用 secondStep 方法的话，就会发生死锁。这样，我们在编写代码的时候，发生死锁的几率就会很大，因为这两个方法的锁都是同一个对象。

共享锁 VS 独占锁

=============================================================================

共享锁是对于同一个锁，可以有多个线程同时获得锁；

独占锁则是每次只有一个线程可以获得锁，其他线程需要获得该锁，则需要等待获得锁的线程释放锁才有机会。

在 ReentrantReadWriteLock 中则同时使用了共享锁和独占锁。其中，共享锁用于读操作、独占锁用于写操作。

因为读操作是使用共享锁，所以可以支持高效的并发读操作。而对于读写、写写、写读操作，为了数据的一致性，都是必须互斥的。因为读锁和写锁的分离，相比于一般的互斥锁，有较大的性能提升。

我们直接看 ReentrantReadWriteLock 中是如何通过AQS来实现读锁和写锁共存的：

public class ReentrantReadWriteLock

implements ReadWriteLock, java.io.Serializable {

private static final long serialVersionUID = -6992448646407690164L;

/** Inner class providing readlock */

private final ReentrantReadWriteLock.ReadLock readerLock;

/** Inner class providing writelock */

private final ReentrantReadWriteLock.WriteLock writerLock;

/** Performs all synchronization mechanics */

final Sync sync;

/**

Creates a new {@code ReentrantReadWriteLock} with
default (nonfair) ordering properties.

public ReentrantReadWriteLock() {

this(false);

}

/**

Creates a new {@code ReentrantReadWriteLock} with
the given fairness policy.
@param fair {@code true} if this lock should use a fair ordering policy

public ReentrantReadWriteLock(boolean fair) {

sync = fair ? new FairSync() : new NonfairSync();

readerLock = new ReadLock(this);

writerLock = new WriteLock(this);

}

复制代码

我们可以看到类中里面存在一个 ReadLock 和一个 WriteLock ，而这两个类实现了 Lock 接口，也就是真正的锁是由这两个类来实现的。

Java中的重重“锁”事

我们可以看到这两个类里面都有 Sync 类成员，该类则继承了AQS。 Sync 类才是真正的锁。

在 ReentrantReadWriteLock 中将锁的状态切分为了两种状态，其中高16位表示读锁的个数，低16位表示写锁的个数。

Java中的重重“锁”事

我们直接看写锁的加锁代码：

final boolean tryWriteLock() {

Thread current = Thread.currentThread(); // 获取当前线程

int c = getState(); // 获取锁的状态

if (c != 0) { // 判断是否存在线程获取了锁

int w = exclusiveCount©; // 获取占有独占锁的线程数量

if (w == 0 || current != getExclusiveOwnerThread()) // 存在读锁或者占有独占锁的线程不是当前线程，则失败

return false;

if (w == MAX_COUNT) // 如果可重入的独占锁数量饱和，则失败

throw new Error(“Maximum lock count exceeded”);

}

if (!compareAndSetState(c, c + 1)) // 设置写锁的状态。因为写锁是低16位，所以直接加1即可

return false;

setExclusiveOwnerThread(current); // 设置当前占有独占锁的线程

return true; // 成功

}

复制代码

如果存在读锁、或者当前线程不等于独占锁的线程，则返回失败
如果锁的数量已经饱和，返回失败。读锁和写锁最大可重入的锁数量均为65535
如果上面皆为失败，则使用CAS设置写锁的状态，设置独占锁的线程为当前线程。

写锁除了是独占锁这个条件之外，还添加了一个判断是否存在读锁的条件，如果存在读锁，则加锁失败。这是为了保证写锁期间的修改，对于正在运行的读锁的线程来说必须是可见的。如果允许在读锁期间，写锁也可以被获取，那么在当前正在运行的读线程就无法感知到写线程的操作，从而造成读写不一致的情况。

我们接着来看读锁的加锁代码：

final boolean tryReadLock() {

Thread current = Thread.currentThread(); \ 获取当前线程

for (;😉 { \ 无限循环

int c = getState(); \ 获取当前锁状态

if (exclusiveCount© != 0 && \ 如果存在写锁并且占用写锁的线程不是当前线程，则返回失败

getExclusiveOwnerThread() != current)

return false;

int r = sharedCount©; \ 获取共享锁的数量

if (r == MAX_COUNT) \ 确定锁的数量未饱和

throw new Error(“Maximum lock count exceeded”);

if (compareAndSetState(c, c + SHARED_UNIT)) { // 后面就是添加读锁的个数

if (r == 0) {

firstReader = current;

firstReaderHoldCount = 1;

} else if (firstReader == current) {

firstReaderHoldCount++;

} else {

HoldCounter rh = cachedHoldCounter;

if (rh == null || rh.tid != getThreadId(current))

cachedHoldCounter = rh = readHolds.get();

else if (rh.count == 0)

readHolds.set(rh);

rh.count++;

}

return true;

}

复制代码

如果其他线程中已经持有了写锁，那么当前线程获取读锁失败
如果读锁的数量已经饱和，那么获取读锁失败
增加读锁的状态、成功获取读锁。

每次读锁的释放都会减少读状态。只有读读的状态是共享的，只有存在着写锁相关的操作，那么就都是互斥的。

无锁 VS 偏向锁 VS 轻量级锁 VS 重量级锁

============================================================================================

要理解Java中的锁对象，那么Java对象头结构就必须得了解清楚。

Java的对象头包括两部分内容：

Mark Word : 默认存储对象的HashCode，分代年龄和锁标志位信息。但是会根据对象的锁状态，从而改变这部分的内容。如下图所示。
Klass Point : 指向类型的指针，用于确定该对象是属于哪个类的实例

Java中的重重“锁”事

锁的级别目前有四级：有低至高分别是：无锁 -> 偏向锁 -> 轻量级锁 -> 重量级锁

锁只能升级，不能降级。也就是不能从轻量级锁变为偏向锁状态等等，但是只要对象释放了锁，那么就会恢复到无锁状态，到时候就又要从无锁状态开始，慢慢升级。

无锁

=====================================================================

无锁就是没有对资源进行锁定，所有的线程都可以对资源进行访问和修改，但是只有一个线程可以成功。

其实CAS就是无锁的一样实现方式，但是无锁并不能替代锁，因为无锁的弊端也是很明显的，我们只有在某些场景下才能使用无锁。

偏向锁

======================================================================

偏向锁的目的是消除数据在无竞争情况下的同步原语，进一步提高程序的运行性能。

偏向锁就是在无竞争的情况下把整个同步都消除掉，连CAS操作都不去做了。偏向锁会偏向于第一个获得它的线程，如果在接下来的执行过程中，该锁一直没有被其他的线程获取，则持有偏向锁的线程将永远不需要再进行同步。

如果锁总是由同一个线程获得，不存在多线程竞争，那么偏向锁的效果将会非常明显，因为它消除了获取锁的代价。

当锁对象第一次被线程获取的时候，虚拟机将会把对象头中的标志位设置为01，把偏向模式设置为1，表示进入偏向模式。同时使用CAS操作把获取到这个锁的线程的ID记录在对象的Mark Word之中。如果CAS操作成功，持有偏向锁的线程以后每次进入这个锁相关的同步块时，虚拟机都可以不再进行任何同步操作（例如加锁，解锁及对Mark Word的更新操作等）

一旦出现另外一个线程去尝试获取这个锁的情况，偏向锁模式就马上宣告结束。根据锁对象目前是否处于被锁定的状态决定是否撤销偏向，撤销后标志位恢复到未锁定或者轻量级锁定的状态，后续的同步操作就按照轻量级锁那样去执行。

假设一个对象刚开始实例化的时候，还没有任何线程持有该对象的锁，此时它是可以被偏向的。如果此时有一个线程来获取该对象的锁，它会偏向该线程，设置对象为偏向模式，并用CAS操作去设置对象的Mark Word，将Thread Id设置为获取该对象锁的线程的ID。如果该线程下次再来获取该对象的锁时就无需再进行CAS操作了，直接对比Mark Word中的Thread ID即可。

如果有第二个线程来获取该对象的锁，因为偏向锁不会主动释放，所以第二个线程是可以看得到该锁的偏向模型，此时它会检测第一个线程是否还存活，如果已经死去了，则设置对象为无锁状态，重新进入偏向模式。

如果检测到第一个线程依然存活，则会去检测该线程的操作栈，检测该线程是否依然需要持有偏向锁，如果不需要，则设置对象为无锁状态，重新进入偏向模式。

如果检测到第一个线程依然存活，并且检测到该线程依然需要持有偏向锁，则会将该偏向锁升级为轻量级锁。

如果在轻量级锁期间，第一个线程持有锁，第二个线程自旋等待获取锁，一个新的第三个线程也来获取该锁，此时就会出现对象锁的竞争，则会将该轻量级锁升级为重量级锁，重量级锁会将除了使用该锁的线程之外，都阻塞等待，防止CPU资源浪费。

小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数初中级Java工程师，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年最新Java开发全套学习资料》送给大家，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。