ReentrantLock介绍及使用
ReentrantLock
同Synchronized
一样可以实现线程锁的功能,同样具有可重入性,除此之外还可以实现公平锁&非公平锁,其底层是基于AQS
框架实现的。
主要方法:
lock()
: 加锁lockInterruptibly()
: 加锁,支持中断tryLock()
:tryLock(long timeout, TimeUnit unit)
:unlock()
: 解锁newCondition()
: 初始化Condition
条件,如在A线程中使用condition.await()
中断执行并释放锁,B线程中可以通过condition.signal/condition.signalAll
来通知A线程恢复执行。getHoldCount()
: 返回当前state
的值,默认是0isHeldByCurrentThread()
: 当前线程是否是锁的持有者isLocked()
: 是否有锁isFair()
: 是否是公平锁getOwner()
: 获取持有当前锁的线程,如果没有返回null
hasQueuedThreads()
:getQueueLength()
:getQueuedThreads()
:hasWaiters()
: 在Condition Queue
中是否有Node
,只能在互斥锁中调用,否则会抛异常。getWaitQueueLength()
:getWaitingThreads(Condition condition)
:
通过一个例子来看下ReentrantLock
的基本用法:
lock
加锁unlock
解锁:
//初始化 ReentrantLock
ReentrantLock reentrantLock = new ReentrantLock();
//lock加锁 unlock解锁
MyRunnable runnable = new MyRunnable(reentrantLock);
Thread threadA = new Thread(runnable,"threadA");
Thread threadB = new Thread(runnable,"threadB");
threadA.start();
threadB.start();
static class MyRunnable implements Runnable {
private ReentrantLock reentrantLock;
MyRunnable(ReentrantLock reentrantLock) {
this.reentrantLock = reentrantLock;
}
@Override
public void run() {
try {
reentrantLock.lock();
for (int i = 0; i < 5; i++) {
System.out.println(Thread.currentThread().getName() + "," + i);
}
} catch (Exception e) {
e.printStackTrace();
} finally {
reentrantLock.unlock();
}
}
}
输出结果:
threadA,0
threadA,1
threadA,2
threadA,3
threadA,4
threadB,0
threadB,1
threadB,2
threadB,3
threadB,4
通过结果可以说明ReentrantLock
可以保证多线程访问共享资源的顺序性。
- condition:
await、signal/signalAll
通知
//condition:await、signal/signalAll通知
Condition condition = reentrantLock.newCondition();
ThreadC threadC = new ThreadC(reentrantLock, condition);
threadC.start();
Thread.sleep(2000);
ThreadD threadD = new ThreadD(reentrantLock, condition);
threadD.start();
static class ThreadC extends Thread {
private ReentrantLock reentrantLock;
private Condition condition;
ThreadC(ReentrantLock reentrantLock, Condition condition) {
this.reentrantLock = reentrantLock;
this.condition = condition;
setName("ThreadC");
}
@Override
public void run() {
System.out.println(Thread.currentThread().getName() + ": 开始运行");
try {
reentrantLock.lock();
System.out.println(Thread.currentThread().getName() + ": 通过condition.await中断运行并放弃锁");
condition.await();
System.out.println(Thread.currentThread().getName() + ": 重新获取锁,恢复执行");
} catch (Exception e) {
e.printStackTrace();
} finally {
reentrantLock.unlock();
System.out.println(Thread.currentThread().getName() + ": 释放锁");
}
}
}
static class ThreadD extends Thread {
private ReentrantLock reentrantLock;
private Condition condition;
ThreadD(ReentrantLock reentrantLock, Condition condition) {
this.reentrantLock = reentrantLock;
this.condition = condition;
setName("ThreadD");
}
@Override
public void run() {
System.out.println(Thread.currentThread().getName() + ": 开始运行");
try {
reentrantLock.lock();
System.out.println(Thread.currentThread().getName() + ": 通过condition.signal去唤醒ThreadC");
condition.signal();
} catch (Exception e) {
e.printStackTrace();
} finally {
reentrantLock.unlock();
System.out.println(Thread.currentThread().getName() + ": 释放锁");
}
}
}
执行结果:
ThreadC: 开始运行
ThreadC: 通过condition.await中断运行并放弃锁
ThreadD: 开始运行
ThreadD: 通过condition.signal去唤醒ThreadC
ThreadD: 释放锁
ThreadC: 重新获取锁,恢复执行
ThreadC: 释放锁
ReentrantLock源码分析
public interface Lock {
void lock();
void lockInterruptibly() throws InterruptedException;
boolean tryLock();
boolean tryLock(long timeout, TimeUnit unit) throws InterruptedException;
void unlock();
Condition newCondition();
}
Lock
提供了一种无条件的、可轮询的、定时的、可中断的锁获取操作。所有加锁和解锁方法都是显式的。
ReentrantLock
实现了Lock
接口,并提供了与Synchronized
相同的互斥性与可见性。同时当锁不可用时ReentrantLock
提供了更高的灵活性。
公平锁及非公平锁
ReentrantLock
中有一个静态内部类Sync
并且继承了AbstractQueuedSynchronizer(AQS)
,所以ReentrantLock
的底层是基于AQS
同步器框架实现的,默认使用的是非公平锁,如果需要使用公平锁,初始化时需要传入参数true
,即ReentrantLock reentrantLock = new ReentrantLock(true)
, 对应的源码:
//默认实现是非公平锁
public ReentrantLock() {
sync = new NonfairSync();
}
//传入true 初始化的是FairSync公平锁,否则是NonfairSync非公平锁
public ReentrantLock(boolean fair) {
sync = fair ? new FairSync() : new NonfairSync();
}
那么公平锁FairSync
及非公平锁NonfairSync
内部又是怎么实现的呢?继续往下看:
//抽象类Sync,继承自AQS,默认实现的是非公平锁方法
abstract static class Sync extends AbstractQueuedSynchronizer {
private static final long serialVersionUID = -5179523762034025860L;
//抽象方法 在子类中实现
abstract void lock();
//非公平锁
final boolean nonfairTryAcquire(int acquires) {
final Thread current = Thread.currentThread();
int c = getState();
//state为0 表示还没有加锁
if (c == 0) {
//非公平锁直接通过CAS再次获取锁 如果成功 直接设置当前线程为独占锁
if (compareAndSetState(0, acquires)) {
setExclusiveOwnerThread(current);
return true;
}
}
else if (current == getExclusiveOwnerThread()) {
//如果当前state不为0 说明已经有线程持有锁 如果持有锁的是当前线程,那么直接对state进行加1 所以ReentrantLock也有可重入性
int nextc = c + acquires;
if (nextc < 0) // overflow
throw new Error("Maximum lock count exceeded");
setState(nextc);
return true;
}
return false;
}
//释放锁
protected final boolean tryRelease(int releases) {
int c = getState() - releases;
if (Thread.currentThread() != getExclusiveOwnerThread())
throw new IllegalMonitorStateException();
boolean free = false;
if (c == 0) {
free = true;
setExclusiveOwnerThread(null);
}
setState(c);
return free;
}
//是否是互斥锁
protected final boolean isHeldExclusively() {
return getExclusiveOwnerThread() == Thread.currentThread();
}
final ConditionObject newCondition() {
return new ConditionObject();
}
final Thread getOwner() {
return getState() == 0 ? null : getExclusiveOwnerThread();
}
final int getHoldCount() {
return isHeldExclusively() ? getState() : 0;
}
final boolean isLocked() {
return getState() != 0;
}
private void readObject(java.io.ObjectInputStream s)
throws java.io.IOException, ClassNotFoundException {
s.defaultReadObject();
setState(0); // reset to unlocked state
}
}
//1、非公平锁实现,继承自Sync
static final class NonfairSync extends Sync {
private static final long serialVersionUID = 7316153563782823691L;
final void lock() {
//非公平锁直接通过CAS尝试获取锁
if (compareAndSetState(0, 1))
setExclusiveOwnerThread(Thread.currentThread());
else
//调用AQS中的acquire()方法,acquire()方法又会调用到tryAcquire()方法
acquire(1);
}
protected final boolean tryAcquire(int acquires) {
//调用抽象父类Sync中的方法,见上面Sync类中nonfairTryAcquire方法注释
return nonfairTryAcquire(acquires);
}
}
//2、公平锁实现,继承自Sync
static final class FairSync extends Sync {
private static final long serialVersionUID = -3000897897090466540L;
final void lock() {
//不同于非公平锁,这里并不会通过CAS去尝试获取锁 而是直接调用FairSync类中重写的tryAcquire方法
acquire(1);
}
protected final boolean tryAcquire(int acquires) {
final Thread current = Thread.currentThread();
int c = getState();
if (c == 0) {
//不同于非公平锁,除非没有等待节点Node或者在队列中的第一个,否则不会尝试获取锁而是加入到等待队列中(在父类AQS中实现)
if (!hasQueuedPredecessors() &&
compareAndSetState(0, acquires)) {
setExclusiveOwnerThread(current);
return true;
}
}
else if (current == getExclusiveOwnerThread()) {
int nextc = c + acquires;
if (nextc < 0)
throw new Error("Maximum lock count exceeded");
setState(nextc);
return true;
}
return false;
}
}
公平锁和非公平锁都继承了Sync
,通过代码对比,可以看出有2个地方的实现不一样:
1、在调用lock()
方法时,公平锁不会通过CAS
直接尝试获取锁,而非公平锁会直接通过CAS
尝试获取锁,如果成功,那么会直接获取锁返回(比等待队列中的线程优先获取到锁,从而导致非公平性)。
2、当非公平锁获取锁失败后,和公平锁一样都会进入tryAcquire
方法中,如果此时之前的锁释放了(state==0
),非公平锁会再次执行一次CAS
尝试获取锁,而公平锁会判断队列中是否有线程在等待,没有的话才会尝试去获取锁,否则直接加入到等待队列中。如果非公平锁/公平锁尝试获取锁失败,那么都会进入阻塞队列中等待唤醒。此外,如果当前state
不为0(已经有线程持有锁),判断持有锁的是不是当前线程,如果是,那么直接对state
进行加1 所以ReentrantLock
具有可重入性。
性能对比:非公平锁有更好的性能,吞吐量比较大,同时,非公平锁可能会导致在阻塞队列中的线程一直处于饥饿状态。
Synchronized浅析 & ReentrantLock对比
Synchronized浅析:
Synchronized
是基于Jvm
层面的互斥锁,底层通过monitor
指令来实现加锁和解锁,可以把monitor
当成一把锁,锁里面包含了计数器
和线程指针
,当计数器为0时,表示锁没有被任何线程持有,当计数器大于0时表示锁已经被某个线程持有,线程指针指的即使持有当前锁的线程,当同一线程多次申请该锁时,计数器会进行叠加(可重入性),这里跟AQS
中的state
概念是类似的。
PS:Synchronized
在1.5之前属于重量级锁,线程的阻塞和唤醒需要CPU
从用户态转为内核态,频繁的阻塞和唤醒对CPU
来说是一件耗性能的工作,从而影响到并发性能。JDK1.6
后对其做了一系列的优化,主要包括:自旋锁、偏向锁、轻量级锁、重量级锁、锁消除、锁粗化等,通过一系列锁优化技术在特定场景下可以大大提高并发性能。
自旋锁:
自旋锁是指当一个线程获取锁时,如果已经被其他线程获取锁,当前线程将循环等待(执行无实际意义的循环),不断判断锁是否能够成功获取,直到成功才会退出循环。
优点:旋锁可以减少不必要用户态与内核态之间的来回切换,提高了性能。线程状态一直处于用户态。
缺点:
- 自旋锁是不公平的,若多个线程自旋,无法满足等待最长时间的线程最先获取锁,即存在线程饥饿的问题
- 如果某个线程持有锁的时间过长,会导致其他自旋等待的线程循环等待,过度消耗CPU做无用功。
Synchronized、ReentrantLock对比:
对比 | Synchronized | ReentrantLock |
---|---|---|
实现原理 | Jvm 层面的内置互斥锁,底层通过monitorenter 和monitorexit 两个字节码指令来实现加锁解锁操作的 |
应用层互斥锁 |
是否需要手动释放锁 | 否(自动释放) | 是(需要手动释放锁) |
其他 | 修饰普通方法、成员变量为对象锁,不同对象的锁互相不影响;修饰static 静态方法为类锁。不可中断,不支持定时 |
Lock 锁可以中断,支持定时 |
通过对比我们看到,ReentrantLock
的功能相比于Synchronized
来说,功能更强大,如:可以实现公平锁、可以中断、支持定时等功能,但是是否能认为ReentrantLock
可以完全替代Synchronized
呢?答案是否认的,可以看到ReentrantLock
在使用时需要手动释放锁,这里就好像一颗定时炸弹,一旦开发者忘记了释放锁,就会导致后续的所有线程都不能再获取锁。ReentrantLock
在某种程度上可以认为是Synchronized
的一种补充,两者各有优缺点。