为什么 Java StampedLock 比 ReentrantReadWriteLock 更快

Question

StampedLock 与其他锁的比较表明，随着争用的增加， StampedLock是最快的。然而，这篇文章和其他各种文章都没有列出为什么它更快。它似乎使用与其他类型的锁相同的 CAS 语义？谁能解释为什么随着争用的增加它速度最快？
例如，在下面的代码中，writeLock 不仅会阻塞其他 writeLock，还会阻塞 readLock。目前我不关心optimisticReadLocks 等。只是简单的 writeLock .. 有什么优点以及它比 ReentrantLock 更快（而且它甚至没有可重入性）。

    public static void main(String[]args)throws Exception{
    StampedLock lk = new StampedLock();

    new Thread(() -> {
        long stamp = lk.writeLock();
        try {
            out.println("locked.. sleeping");
            TimeUnit.SECONDS.sleep(5);
            lk.unlock(stamp);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }).start();

    new Thread(() -> {
        long stamp = lk.writeLock();
        try {
            out.println("locked.. sleeping");
            TimeUnit.SECONDS.sleep(5);
            lk.unlock(stamp);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }).start();

}

Answer 1

需要明确的是，当争用加剧时，StampedLock 的读取速度要快得多。写入速度稍快一些，但不如读取速度快。我会解释原因。

大多数时候，使用读写锁，写入次数会少得多。然而，尽管如此，每次你获得一个readLock()on时，ReentrantReadWriteLock你都必须增加读者计数。这会强制使用此锁的所有核心上的缓存失效。

在严重争用的情况下，这可能会导致读取速度显着减慢。读取应该很快，在执行操作时readLock()我们不必更新变量，这是违反直觉的。

如果我们有一个印章或者版本怎么办？每次读取迭代仅更新一次。

这对我们来说是，在争用的情况下，如果只有一个线程更新标记值（假设在写入之后），则所有读取线程在想要读取锁时都将执行缓存命中。这会禁止缓存失效并允许锁以比 RRWL 更合适的方式执行。

使用 a 的模式StampedLock类似于使用时的无锁算法tryOptimisticRead（如 CAS）

1. 获得邮票
2. 读取一个值
3. 邮票有变化吗？
   • 是的，重试或发出阻塞读取
   • 不，我们很好，我们继续吧。