在学习蚂蚁金服实现的Raft算法实现sofa-jraft项目中第一次接触到这个锁。jraft使用StampedLock来实现对于raft group 的路由信息的线程安全。

StampedLock是Java 8中引入的新的锁机制，它支持三种模式的访问控制，分别是读模式、写模式和乐观读模式，它可以在高并发的情况下提供更好的性能和吞吐量。

在StampedLock中，每个线程都需要获取一个戳（stamp）来进行读或写操作，这个戳是一个64位的数字，其中高16位代表一个版本号，低48位代表一个序号。线程可以使用tryOptimisticRead()方法来获取一个乐观读锁，这种方式不会阻塞线程，只是获取一个戳，如果获取到的戳发生了变化，就意味着有其他线程已经修改了共享资源，这时候需要重新获取锁。

StampedLock还支持读锁和写锁。读锁是共享锁，多个线程可以同时持有读锁，并发地读取共享资源，而写锁是独占锁，只有一个线程可以持有写锁，其他线程需要等待写锁释放才能继续执行。

StampedLock的优势在于，对于读多写少的场景，使用乐观读锁可以避免大量线程阻塞，提高系统的吞吐量；对于写操作比较频繁的场景，使用StampedLock可以减少锁的竞争，提高系统的性能。

API

StampedLock有三种锁的获取方式：

1. 读锁（readLock()）：多个线程可以同时持有读锁，只要没有线程持有写锁。读锁是乐观的且不可重入的。通过调用tryOptimisticRead()方法获取读锁，如果锁可用，会返回一个非零的标记（stamp）。
2. 写锁（writeLock()）：只有一个线程可以持有写锁，它排除所有的读锁和写锁。写锁是悲观的且可重入的。通过调用writeLock()方法获取写锁。
3. 乐观读锁（Optimistic Read Lock）：乐观读锁是一种特殊的读锁，它允许其他线程在获取读锁之前修改共享数据，但在验证阶段检测到数据被修改时，需要重新获取锁。乐观读锁的获取方式是调用tryOptimisticRead()方法，如果锁可用，会返回一个非零的标记（stamp）。

下面是一个简单的StampedLock的使用示例：

import java.util.concurrent.locks.StampedLock;

public class Point {
    private double x;
    private double y;
    private final StampedLock lock = new StampedLock();

    public void setPoint(double x, double y) {
        long stamp = lock.writeLock();
        try {
            this.x = x;
            this.y = y;
        } finally {
            lock.unlockWrite(stamp);
        }
    }

    public double distanceFromOrigin() {
        long stamp = lock.tryOptimisticRead();
        double currentX = x;
        double currentY = y;
        if (!lock.validate(stamp)) {
            stamp = lock.readLock();
            try {
                currentX = x;
                currentY = y;
            } finally {
                lock.unlockRead(stamp);
            }
        }
        return Math.sqrt(currentX * currentX + currentY * currentY);
    }
}

在上述示例中，setPoint()方法使用写锁来更新坐标。写锁是排他锁，当一个线程获取写锁时，其他线程无法获取读锁或写锁。

distanceFromOrigin()方法使用乐观读锁尝试获取点的当前坐标，并计算点到原点的距离。如果乐观读锁验证失败（即期间有写操作），则通过获取悲观读锁来重新读取坐标。

这个例子展示了StampedLock的乐观读锁和悲观写锁的使用方式，通过合理地选择锁的模式，可以提供更高的并发性能，并且允许读操作和写操作同时进行，而不会相互阻塞。

校验是否有写操作 是如何判断的

StampedLock的写锁有一个版本号，读锁没有版本号。因此，StampedLock可以通过判断当前读锁的版本号是否等于写锁的版本号来检查是否存在写锁。如果版本号相同，说明当前存在写锁，反之，则没有写锁。需要注意的是，在使用StampedLock时，如果读锁和写锁是在不同的线程中获取的，那么在判断是否存在写锁时可能存在一定的延迟，因为写锁的版本号可能已经变化，但是读锁的版本号还没有更新。因此，在这种情况下，可能会出现一定的误判。