并发编程之——写锁源码分析
1.前言
Java 中的读写锁实现是 ReentrantReadWriteLock ，是一种锁分离策略。能有效提高读比写多的场景下的程序性能。
关于如何使用参见 并发编程之 Java 三把锁。
由于读写锁较为复杂，故分为篇文章进行源码分析，今天先说较为简单的写锁。
2. 写锁介绍
不论是读锁还是写锁，都是基于 AQS 的，而 AQS 留给子类实现的就是 tryAcquire 或者 tryAcquireShared 方法，前者是写锁的实现，后者是读锁的实现，从名字上可以看出，一个是独占锁，一个是共享锁。
今天看的就是 tryAcquire 和 tryRelease 的实现，获取和释放。
3. tryAcquire 实现
源码加注释如下：
// 如果有读锁，此时是获取不到写锁的。当有写锁时，判断重入次数。
// 当写锁空闲，读锁空闲，公平模式下，如果队列中有等待的，不会抢锁。非公平模式下，必抢锁。
protected final boolean tryAcquire(int acquires) {
// 写
Thread current = Thread.currentThread();
int c = getState();
// 用 state & 65535 得到低 16 位的值。
int w = exclusiveCount(c);
if (c != 0) {
// (Note: if c != 0 and w == 0 then shared count != 0)
// 如果 state 不是0，且低16位是0，说明了什么？说明写锁是空闲的，读锁被霸占了。那么也不能拿锁，返回 fasle。
// 如果低 16 位不是0，说明写锁被霸占了，并且，如果持有锁的不是当前线程，那么这次拿锁是失败的。返回 fasle。
// 总之，当有读锁，就不能获取写锁。当有写锁，就必须是重入锁。
if (w == 0 || current != getExclusiveOwnerThread())
return false;
// 到这一步了，只会是写重入锁。如果写重入次数超过最大值 65535，就会溢出。
if (w + exclusiveCount(acquires) > MAX_COUNT)
throw new Error("Maximum lock count exceeded");
// Reentrant acquire
// 将 state + 1
setState(c + acquires);
return true;
}
// 当 state 是 0 的时候，那么就可以获取锁了。
// writerShouldBlock 判断是否需要锁。非公平情况下，返回 false。公平情况下，根据 hasQueuedPredecessors 结果判断。
// 当队列中有锁等待了，就返回 false 了。
// 当是非公平锁的时候，或者队列中没有等待节点的时候，尝试用 CAS 修改 state。
if (writerShouldBlock() ||
!compareAndSetState(c, c + acquires))
return false;
// 修改成功 state 后，修改锁的持有线程。
setExclusiveOwnerThread(current);
详解的逻辑都写在注释里了，可以对照源码查看，这里再次总结这个方法的逻辑。
-
首先判断锁是否空闲。
-
如果空闲，则根据公平与否判断是否应该获取锁，当
writerShouldBlock返回结果是false的时候，就使用 CAS 修改 state 变量，获取锁。成功之后修改 AQS 持有线程。 -
如果不是空闲的，则判断写锁是否是空闲的，这里有 2 种情况：
3.1 如果写锁空闲，但
state不是0，说明有读锁，那么就不能获取锁。3.2 如果写锁不空闲，判断持有 AQS 锁的线程是不是当前线程，如果不是，不能获取，反之，可以获取重入锁。
4. tryRelease 实现
代码加注释如下：
protected final boolean tryRelease(int releases) {
// 是否持有当前锁
if (!isHeldExclusively())
throw new IllegalMonitorStateException();
// 计算 state 值
int nextc = getState() - releases;
// 计算写锁的状态，如果是0，说明是否成功。
boolean free = exclusiveCount(nextc) == 0;
// 释放成功，设置持有锁的线程为 null。
if (free)
setExclusiveOwnerThread(null);
// 设置 state
setState(nextc);
return free;
}
这里还是很简单的，只是有一个地方需要注意：
// 计算写锁的状态，如果是0，说明是否成功。
boolean free = exclusiveCount(nextc) == 0;
这里计算的只是 state 变量的低 16 的值，而不是整个 state 的值。虽然写的时候，必然是串行的，但这里计算的仍然是低 16 位的。
5. 总结
写锁在获取锁的时候，有几个地方需要注意：当有读锁的时候，是不能获取写锁的。写锁可以重入，但不能超过 65535 次。写锁状态设置在 state 变量的低 16 位。
同时，在获取锁的时候，也会根据公平与否决定此次释放需要获取锁。
如果是非公平的，直接尝试CAS 修改 state ，获取锁。
如果是公平的，则根据 hasQueuedPredecessors 方法的返回值判断，也就是如果队列中有等待的线程，则依据公平策略，放弃此次获取锁的操作。反之，直接获取锁。
