Java多线程与锁

article/2025/10/20 21:33:33

前文中，我们已经了解了什么是线程，线程间常用通信方式，线程池以及其相关特性，可以看出锁在多线程环境中充当着重要作用，不管是线程间的数据通信，还是线程间的等待和唤醒，都依赖于锁，那么锁又有哪些特征以及分类呢？下面我们一起详细看下。

公平锁/非公平锁

公平锁：多个线程按照申请锁的顺序来获取锁。
非公平锁：多个线程获取锁的顺序不等于申请锁的顺序，可能造成饥饿现象，即某个线程长时间获取不到锁

我们前文提到的Semaphore信号量就支持公平锁和非公平锁两种形式，可以通过下面构造函数指定使用公平锁还是非公平锁

public Semaphore(int permits, boolean fair)

fair为true时是公平锁，反之为非公平锁，默认构造的Semaphore是非公平锁。

ReentrantLock也支持公平锁和非公平锁两种形式，默认实现是非公平锁，可以通过

public ReentrantLock(boolean fair)

来创建公平锁实现的ReentrantLock对象。

独占锁/共享锁

独占锁：该锁单次只能被一个线程持有，该线程释放后，下个线程才能获取
共享锁：该锁同时可以被多个线程持有

Semaphore其内部实现就是共享锁，ReentrantLock内部实现是独占锁，ReentrantReadWriteLock其内部读锁是共享锁，写锁是独占锁。

乐观锁/悲观锁

乐观锁：乐观锁是对于数据冲突保持一种乐观态度，操作数据时不会对操作的数据进行加锁（这使得多个任务可以并行的对数据进行操作），只有到数据提交的时候才通过一种机制来验证数据是否存在冲突(一般实现方式是通过加版本号然后进行版本号的对比方式实现)，如果存在冲突则提交失败。其本身不存在真实存在的锁对象。
悲观锁：悲观锁是基于一种悲观的态度类来防止一切数据冲突，它是以一种预防的姿态在修改数据之前把数据锁住，然后再对数据进行读写，在它释放锁之前任何人都不能对其数据进行操作，直到前面一个人把锁释放后下一个人数据加锁才可对数据进行加锁，然后才可以对数据进行操作。

一般情况下，乐观锁通过CAS实现，CAS全称为Compare And Swap，译为对比替换，CAS工作如下图所示：

CAS.drawio

首先比较旧址V1与现在内存中的值事否相等，如果相等则把新值V2写入，如果不等则重新从V同步值到V1，重新计算V2后，再进行V和V1的比较。

从上述逻辑可以看出CAS可以保证变量的原子性，但是普通的CAS也有ABA的问题，所谓ABA问题，指的是先将值修改至A，再将值修改为B，最后再改为A，以银行转账为例，现在银行卡里有100元，此时有A，B，C三方需要对银行卡进行操作，其中A 转出100，B 转出 100 ，C转入100，按CAS实现该逻辑：

账户余额100，此时A 转出 100，由于网络阻塞，A转出卡住
账户余额100，B转出100，网络顺畅，转出完成
此时余额0，随后C转入100，网络顺畅，转出完成
此时余额100，A唤醒，执行执行转出100，执行完成
此时余额为0

C转入的100没了，重复扣款了，ABA问题的解决方案就是加上版本号。比如AtomicStampedReference，其就是解决了ABA问题的原子引用类。

比较典型的悲观锁实现有synchronized，Lock等。

可重入锁/非可重入锁

可重入锁：当前线程获得锁后，可在不释放该锁的情况下，再次获取这把锁
非可重入锁：当前线程获得锁后，必须释放锁后才能再次获取

ReentrantLock，synchronized都是可重入锁，可重入锁的好处是可以一定程度上避免死锁，NonReentrantLock是非可重入锁的实现。

自旋锁/适应性自旋锁

阻塞或唤醒一个Java线程需要操作系统切换CPU状态来完成，这种状态转换需要耗费处理器时间。如果同步代码块中的内容过于简单，状态转换消耗的时间有可能比用户代码执行的时间还要长。

所以我们可以让当前线程等待一下，进而使得线程进入自旋状态，如果在自旋完成后前面锁定同步资源的线程已经释放了锁，那么当前线程就可以不必阻塞而是直接获取同步资源，从而避免切换线程的开销。这就是自旋锁。

而在JDK1.6 中，又引入了适应性自旋锁的，自适应的改变在于自旋的时间(次数)不再固定，而是由前一次在同一个锁上的自旋时间及锁的持有者状态决定。

锁升级过程

锁升级指的是锁状态从无锁->偏向锁->轻量级锁->重量级锁这一变化过程，锁升级是仅对synchronized而言，synchronized在操作同步资源之前需要给同步资源先加锁，这把锁就是存在Java对象头里的(Java对象头相关知识参见Java对象一节的描述)Mark Word内，通常情况下我们可以将其称之为Monitor锁或对象锁。

synchronized依赖Monitor锁完成线程同步，而Monitor锁底层依赖于Mutex Lock(互斥锁)实现，大家都知道互斥锁是悲观锁，进而对于使用synchronized而言，阻塞或唤醒线程所需系统切换CPU的时间往往比用户代码执行时间还长，为了优化这一现象，JDK 1.6中，在synchronized引入了偏向锁和轻量级锁，进而造就了锁升级过程。

锁升级过程从无锁到重量级锁，其级别依此升高，各个锁状态说明如下：