如何理解ReentrantReadWriteLock的“不公平”模式?
ReentrantReadWriteLock具有公平和不公平(默认)模式,但是文档对我来说很难理解。
我怎么理解?如果有一些代码示例对其进行演示,那就太好了。
如果我有一个写线程,而有许多读线程,哪种模式更好?如果我使用非公平模式,写线程是否有机会获得锁?
回答:
是指当准备好通过新线程获取锁时,该锁不能保证谁获得了该锁的公平性(假设当时有多个线程在请求该锁)。换句话说,可以想象一个线程可能会连续饿死,因为其他线程总是设法任意获得锁而不是锁。
模式的行为更像是先到先服务,在这种情况下,线程被保证达到一定程度的公平性,即它们将以公平的方式获得锁(例如,在线程开始等待很长时间之后)。
回答:
这是一个演示锁公平性的示例程序(以先到先得的方式请求对公平锁的写锁请求)。比较FAIR = true
( 按顺序提供FAIR =
false线程)与( 不按顺序提供线程)的结果。
import java.util.concurrent.locks.ReentrantReadWriteLock;public class FairLocking {
public static final boolean FAIR = true;
private static final int NUM_THREADS = 3;
private static volatile int expectedIndex = 0;
public static void main(String[] args) throws InterruptedException {
ReentrantReadWriteLock.WriteLock lock = new ReentrantReadWriteLock(FAIR).writeLock();
// we grab the lock to start to make sure the threads don't start until we're ready
lock.lock();
for (int i = 0; i < NUM_THREADS; i++) {
new Thread(new ExampleRunnable(i, lock)).start();
// a cheap way to make sure that runnable 0 requests the first lock
// before runnable 1
Thread.sleep(10);
}
// let the threads go
lock.unlock();
}
private static class ExampleRunnable implements Runnable {
private final int index;
private final ReentrantReadWriteLock.WriteLock writeLock;
public ExampleRunnable(int index, ReentrantReadWriteLock.WriteLock writeLock) {
this.index = index;
this.writeLock = writeLock;
}
public void run() {
while(true) {
writeLock.lock();
try {
// this sleep is a cheap way to make sure the previous thread loops
// around before another thread grabs the lock, does its work,
// loops around and requests the lock again ahead of it.
Thread.sleep(10);
} catch (InterruptedException e) {
//ignored
}
if (index != expectedIndex) {
System.out.printf("Unexpected thread obtained lock! " +
"Expected: %d Actual: %d%n", expectedIndex, index);
System.exit(0);
}
expectedIndex = (expectedIndex+1) % NUM_THREADS;
writeLock.unlock();
}
}
}
}
回答:
关于您的更新,使用非公平锁定,并不是说线程获得锁的可能性很小,而是线程要稍等一会儿的可能性很小。
现在,通常随着饥饿期的增加,实际发生的时间长度的可能性会降低……就像连续10次翻转硬币“头”比连续9次翻转硬币“头”的可能性较小。
但是,如果用于多个等待线程的选择算法是非随机的,例如“具有字母名字的线程始终获得锁定”,那么您可能会遇到真正的问题,因为随着线程数量的增加,概率并不一定会降低更饿了…如果将一枚硬币称重为“正面”,则连续10个正面的可能性实际上与9个连续正面的可能性差不多。
我相信在非公平锁定的实现中,会使用某种“公平”的硬币。因此,问题实际上变成了公平性(以及 延迟
)与吞吐量之间的关系。使用非公平锁定通常可以提高吞吐量,但要以偶尔出现的锁定请求延迟时间为代价。哪种更适合您取决于您自己的要求。
以上是 如何理解ReentrantReadWriteLock的“不公平”模式? 的全部内容, 来源链接: utcz.com/qa/414471.html