目录
1.ReentrantLock
1.1整体结构
- 可重入锁针对同一个线程可以对同一个对象重复获取锁;支持公平和非公平获取锁(tryLock只有非公平性,而lock都有)
- ReentrantLock 类本身是不继承 AQS 的,实现了 Lock 接口
public class ReentrantLock implements Lock, java.io.Serializable {...}
public interface Lock {
// 获得锁方法,获取不到锁的线程会到同步队列中阻塞排队
void lock();
// 获取可中断的锁
void lockInterruptibly() throws InterruptedException;
// 尝试获得锁,如果锁空闲,立马返回 true,否则返回 false
boolean tryLock();
// 带有超时等待时间的锁,如果超时时间到了,仍然没有获得锁,返回 false
boolean tryLock(long time, TimeUnit unit) throws InterruptedException;
// 释放锁
void unlock();
// 得到新的 Condition
Condition newCondition();
}
- Sync 继承了 AbstractQueuedSynchronizer ,所以 Sync 就具有了锁的框架,Sync 只实现了 AQS 预留的几个方法,还有一些交给子类 NonfairSync 和 FairSync 去实现了,NonfairSync 是非公平锁,FairSync 是公平锁
// 同步器 Sync 的两个子类锁
static final class FairSync extends Sync {...}
static final class NonfairSync extends Sync {...}
1.2ReentrantLock 构造器
// 无参数构造器,相当于 ReentrantLock(false),默认是非公平的
public ReentrantLock() {
sync = new NonfairSync();
}
public ReentrantLock(boolean fair) {
sync = fair ? new FairSync() : new NonfairSync();
}
默认是非公平的获取锁
1.3释放锁的源码分析
- ReentrantLock的sync类实现的尝试释放锁
// 释放锁方法,非公平和公平锁都使用
protected final boolean tryRelease(int releases) {
// 当前同步器的状态减去释放的个数,releases 一般为 1
int c = getState() - releases;
// 当前线程根本都不持有锁,报错
if (Thread.currentThread() != getExclusiveOwnerThread())
throw new IllegalMonitorStateException();
boolean free = false;
// 如果 c 为 0,表示当前线程持有的锁都释放了
if (c == 0) {
free = true;
setExclusiveOwnerThread(null);
}
// 如果 c 不为 0,那么就是可重入锁,并且锁没有释放完,用 state 减去 releases 即可,无需做其他操作
setState(c);
return free;
}
更新锁的状态,如果状态为0说明当前线程可以直接释放掉锁(因为是可重入的所以需要判断)
- AQS实现了release方法,该方法底层实际使用的是子类sync实现的tryRelease方法
// 释放锁
public void unlock() {
sync.release(1); //调用AQS的方法
}
// AQS的release方法
public final boolean release(int arg) {
if (tryRelease(arg)) {
Node h = head;
if (h != null && h.waitStatus != 0)// 还没有一次入队enq方法就为null
unparkSuccessor(h); // 判断无效节点,然后才进行释放LockSupport.unpark(s.thread);
return true;
}
return false;
}
unlock方法调用sync的release方法,而release方法是sync继承AQS的,并且底层需要的tryRelease方法还是sync这个子类来实现的。
1.4公平锁源码分析——FairSync类
- FairSync 公平锁只实现了 lock 和 tryAcquire 两个方法
// acquire 是 AQS 的方法,表示先尝试获得锁,失败之后进入同步队列阻塞等待
final void lock() {
acquire(1);
}
AQS的acquire默认就是公平的获取锁
// tryAcquire是AQS默认要让子类去实现的方法
protected final boolean tryAcquire(int acquires) {
final Thread current = Thread.currentThread();
int c = getState();
if (c == 0) {
// hasQueuedPredecessors 是实现公平的关键
// 会判断当前执行线程是不是属于同步队列的头节点的下一个节点
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;
}
public final boolean hasQueuedPredecessors() {
Node t = tail;
Node h = head;
Node s;
// (s = h.next) == null就是为了赋值而已,一定为false的
// 判断头节点的next是否正在运行
return h != t &&
((s = h.next) == null || s.thread != Thread.currentThread());
}
跟nonfairTryAcquire非公平的获取锁,只多了一个是否是队列头节点的下一个节点的判断
先获取锁的状态,如果s=0并且是队列头节点的下一个节点那么就可以获取锁,如果s不为零需要进行可重入,要将锁的状态进行累加
1.5非公平锁源码解析——NonfairSync类
- NonfairSync 底层实现了 lock 和 tryAcquire 两个方法
// 加锁
final void lock() {
// cas 给 state 赋值
if (compareAndSetState(0, 1))
// cas 赋值成功,代表拿到当前锁,记录拿到锁的线程
setExclusiveOwnerThread(Thread.currentThread());
else
// acquire 是抽象类AQS的方法,
// 但是tryAcquire需要子类进行重写
acquire(1);
}
// 直接使用的是 Sync.nonfairTryAcquire 方法
protected final boolean tryAcquire(int acquires) {
return nonfairTryAcquire(acquires);
}
// 尝试获得非公平锁
final boolean nonfairTryAcquire(int acquires) {
final Thread current = Thread.currentThread();
int c = getState();
// 同步器的状态是 0,表示同步器的锁没有人持有
if (c == 0) {
// 当前线程持有锁
if (compareAndSetState(0, acquires)) {
// 标记当前持有锁的线程是谁
setExclusiveOwnerThread(current);
return true;
}
}
// 如果当前线程已经持有锁了,同一个线程可以对同一个资源重复加锁,代码实现的是可重入锁
else if (current == getExclusiveOwnerThread()) {
// 当前线程持有锁的数量 + acquires
int nextc = c + acquires;
// int 是有最大值的,<0 表示持有锁的数量超过了 int 的最大值
if (nextc < 0) // overflow
throw new Error("Maximum lock count exceeded");
setState(nextc);
return true;
}
//否则线程进入同步队列
return false;
}
同步状态是0说明可以直接获取锁,通过cas操作设置状态,线程获取互斥锁
大于0先要判断是不是可冲入,如果当前线程可冲入那么就需要状态累加
其他情况,获取不到锁并且线程进入同步队列
ps:整个过程和公平获取锁大致相同,根本的区别就是公平锁加了判断(node是否前面还有节点)
1.6加锁和尝试加锁——ReentrantLock类
//支持公平和非公平获取锁——FairSync类
public void lock() {
sync.lock();
}
// 无参构造器——NonfairSync类
// 只支持非公平获取锁
public boolean tryLock() {
return sync.nonfairTryAcquire(1);
}
// timeout 为超时的时间,在时间内,仍没有得到锁,会返回 false
// 调用了sync继承AQS的tryAcquireNanos方法,该方法底层还是调用了tryAcquire是sync子类实现的方法可以实现公平和非公平获取锁
public boolean tryLock(long timeout, TimeUnit unit)
throws InterruptedException {
return sync.tryAcquireNanos(1, unit.toNanos(timeout));
}
lock:根据构造器决定公平和非公平获取锁,两个sync类都实现了对应的lock方法
tryLock:只支持非公平获取锁,sync类实现了该nonfairTryAcquire方法
带超时的tryLock:支持公平和非公平获取锁,sync继承了AQS的该方法,此方法底层用到了sync两个子类实现的tryAcquire
1.7公平和非公平问题;
- 当第一个线程抢占了锁没在同步队列放节点,然后接着几个线程抢占那么就会放入同步队列,有时候第一个线程会出现连续进行抢占的;
- 在非公平情况下,第一个线程因为没在同步队列,只要尝试获取锁成功那么,在释放后先唤醒同步队列的第一个节点,尽管如此第一个线程还是可以继续抢占的,这样可以充分利用cpu,但会出现饥饿的情况;
- 在公平情况下,第一个线程如果抢占了第二次尝试获取,是不会成功的因为加了判断--当前线程是不是等于同步队列的头节点的下一个节点的线程,所有绝对的公平应该是按照尝试获取锁的时间来判断的,可以避免饥饿;
- 扩展:不管如何,同步队列是可以保证完全公平的释放节点的;