fullTryAcquireShared详细解读
程序员文章站
2024-03-24 22:01:04
...
fullTryAcquireShared是ReentrantReadWriteLock类设计很巧妙的一个方法,由Doug Lea大神贡献,写这篇文章前天fastjson爆出了FastJson 拒绝服务攻击漏洞,fastjson算是json处理一个不错的库了,自开源依赖也经过了不少版本迭代,然而还是存在一些未知的漏洞,写代码容易,但写出好的代码需要不断修行,好了下面直接入主题:
final int fullTryAcquireShared(Thread current) {
/*
* This code is in part redundant with that in
* tryAcquireShared but is simpler overall by not
* complicating tryAcquireShared with interactions between
* retries and lazily reading hold counts.
*/
HoldCounter rh = null;
for (;;) {
int c = getState();
//如果没有if的判断直接进入readerShouldBlock分支,如果获取写锁后再获取读锁但是在
//该线程试图获取读锁之前有其他线程试图获取写锁,最终也会死锁!!!
if (exclusiveCount(c) != 0) {
if (getExclusiveOwnerThread() != current)
return -1;
//如果没有上面的判断获取到写锁的线程将进入睡眠但是没有唤醒它的条件,
//也就是传说中的死锁状态
// else we hold the exclusive lock; blocking here
// would cause deadlock.
} else if (readerShouldBlock()) {
// Make sure we're not acquiring read lock reentrantly
if (firstReader == current) {
// assert firstReaderHoldCount > 0;
} else {
if (rh == null) {
rh = cachedHoldCounter;
if (rh == null || rh.tid != getThreadId(current)) {
rh = readHolds.get();
if (rh.count == 0)
readHolds.remove();
}
}
if (rh.count == 0)
return -1;
}
}
if (sharedCount(c) == MAX_COUNT)
throw new Error("Maximum lock count exceeded");
if (compareAndSetState(c, c + SHARED_UNIT)) {
if (sharedCount(c) == 0) {
firstReader = current;
firstReaderHoldCount = 1;
} else if (firstReader == current) {
firstReaderHoldCount++;
} else {
if (rh == null)
rh = cachedHoldCounter;
if (rh == null || rh.tid != getThreadId(current))
rh = readHolds.get();
else if (rh.count == 0)
readHolds.set(rh);
rh.count++;
cachedHoldCounter = rh; // cache for release
}
return 1;
}
}
}
上面的代码如果改成下面这种形式:
final int fullTryAcquireShared(Thread current) {
/*
* This code is in part redundant with that in
* tryAcquireShared but is simpler overall by not
* complicating tryAcquireShared with interactions between
* retries and lazily reading hold counts.
*/
HoldCounter rh = null;
for (;;) {
int c = getState();
//如果没有if的判断直接进入readerShouldBlock分支,如果获取写锁后再获取读锁但是在
//该线程试图获取读锁之前有其他线程试图获取写锁,最终也会死锁!!!,获取直接去掉
//if (exclusiveCount(c) != 0)判断分支都有可能导致死锁,比如常见的写锁降级、其他线程获取写锁,且其他线程获取写锁在同步队列排队早于获取读锁线程
if (exclusiveCount(c) != 0) {
return -1;
} else if (readerShouldBlock()) {
// Make sure we're not acquiring read lock reentrantly
if (firstReader == current) {
// assert firstReaderHoldCount > 0;
} else {
if (rh == null) {
rh = cachedHoldCounter;
if (rh == null || rh.tid != getThreadId(current)) {
rh = readHolds.get();
if (rh.count == 0)
readHolds.remove();
}
}
if (rh.count == 0)
return -1;
}
}
if (sharedCount(c) == MAX_COUNT)
throw new Error("Maximum lock count exceeded");
if (compareAndSetState(c, c + SHARED_UNIT)) {
if (sharedCount(c) == 0) {
firstReader = current;
firstReaderHoldCount = 1;
} else if (firstReader == current) {
firstReaderHoldCount++;
} else {
if (rh == null)
rh = cachedHoldCounter;
if (rh == null || rh.tid != getThreadId(current))
rh = readHolds.get();
else if (rh.count == 0)
readHolds.set(rh);
rh.count++;
cachedHoldCounter = rh; // cache for release
}
return 1;
}
}
}
针对上面的验证笔者重写了ReentrantReadWriteLock来验证上面的理论,感兴趣的也可以试下!