StampedLock通过戳记机制和乐观读模式提升高并发性能，支持写锁、悲观读锁和乐观读三种模式，其中乐观读在读操作快且冲突少时显著减少竞争；示例中distanceFromOrigin先尝试乐观读并校验戳记，失败则降级为悲观读，确保数据一致性；写锁由move方法展示，需独占获取并用try-finally保证释放；因不支持锁重入，禁止同一线程重复获取写锁；锁升级必须先释放读锁再申请写锁，避免死锁；适用于读多写少场景如缓存、状态标志等，关键在于正确使用戳记校验与资源管理。
在高并发场景下，传统的 ReentrantReadWriteLock 虽然能分离读写锁，提升读多写少的性能，但在存在写线程饥饿或读锁长时间占用时，仍可能成为性能瓶颈。Java 8 引入的 StampedLock 提供了一种更高效、灵活的读写控制机制，通过“戳记（stamp）”机制和乐观读模式，显著提升了并发性能。
StampedLock 的核心特性
与传统读写锁不同，StampedLock 返回一个 long 类型的戳记（stamp），用于标识锁的状态和操作合法性。主要特性包括：
- 支持三种模式：写锁、悲观读锁、乐观读
- 乐观读不阻塞写操作：适用于读操作极快且冲突较少的场景
- 无重入性：同一个线程获取写锁后不能再次获取，需自行管理避免死锁
- 基于戳记校验：每次读取后需验证戳记是否被修改，确保数据一致性
使用乐观读提升读性能
在大多数情况下，共享数据被频繁读取但很少修改。StampedLock 的乐观读模式允许读线程在不加锁的情况下访问数据，仅在最后校验数据是否被写线程修改过。
示例代码：
class Point {
private double x, y;
private final StampedLock sl = new StampedLock();
// 使用乐观读
public double distanceFromOrigin() {
long stamp = sl.tryOptimisticRead(); // 尝试乐观读
double currentX = x, currentY = y;
// 检查期间是否有写操作发生
if (!sl.validate(stamp)) {
stamp = sl.readLock(); // 升级为悲观读锁
try {
currentX = x;
currentY = y;
} finally {
sl.unlockRead(stamp);
}
}
return Math.sqrt(currentX * currentX + currentY * currentY);
}
}
立即学习“Java免费学习笔记（深入）”；
上述代码中，先尝试用乐观读获取戳记，读取数据后调用 validate 校验。若校验失败，说明数据可能已被修改，此时降级为悲观读锁重新读取。
写锁的获取与释放
写锁是独占的，获取时会阻塞其他所有读写操作。StampedLock 提供了阻塞和超时两种方式获取写锁。
示例：添加坐标修改方法
public void move(double deltaX, double deltaY) {
long stamp = sl.writeLock();
try {
x += deltaX;
y += deltaY;
} finally {
sl.unlockWrite(stamp);
}
}
写锁操作必须保证原子性，使用 try-finally 确保锁最终被释放。注意：写锁不可重入，同一线程重复获取会导致死锁。
处理锁升级与降级
StampedLock 不支持直接锁升级（如从读锁升级为写锁），否则可能引发死锁。正确的做法是释放当前锁后重新申请。
错误示例（禁止）：// 读锁未释放时申请写锁 → 可能死锁
正确做法：
public void conditionalMove(double newX, double newY) {
long stamp = sl.readLock();
try {
if (x == 0.0 && y == 0.0) {
sl.unlockRead(stamp); // 先释放读锁
stamp = sl.writeLock(); // 再获取写锁
try {
x = newX;
y = newY;
} finally {
sl.unlockWrite(stamp);
}
}
} finally {
if (sl.getReadHoldCount() > 0) { // 防止重复释放
sl.unlockRead(stamp);
}
}
}
StampedLock 在读多写少、读操作轻量的场景中表现优异，尤其适合高频查询、低频更新的数据结构，如缓存坐标、状态标志等。合理使用乐观读可大幅减少锁竞争，提升吞吐量。
基本上就这些。关键是理解戳记机制和校验流程，避免误用锁升级，同时注意异常安全和锁释放。实践中建议结合具体业务场景权衡是否使用乐观读。不复杂但容易忽略细节。
