锁降级需显式调用tryConvertToReadLock且必须用原写锁stamp，失败时须先unlockWrite再readLock并重读字段；其价值在于写锁修正状态后转读锁支持并发只读计算，避免全程持写锁阻塞读请求。
锁降级不是“自动转换”，必须显式调用 tryConvertToReadLock
StampedLock 的写锁到读锁降级，不能像 ReentrantReadWriteLock 那样在持有写锁后直接调用 readLock()。它要求你**必须用原始写锁 stamp 尝试转换**，且仅当当前无其他读线程时才成功。一旦失败（返回 0L），你就得手动释放写锁、再获取读锁——这会引入窗口期，数据可能被修改。
典型错误是忽略返回值，直接把写锁 stamp 当作读锁 stamp 传给 unlockRead()，结果抛出 IllegalMonitorStateException 或静默失效。
-
tryConvertToReadLock(stamp)成功返回非零 stamp，表示已切换为读锁状态，可安全继续读操作 - 返回
0L表示有其他读线程正在竞争，此时应：unlockWrite(stamp)→readLock()→ 重新读取关键字段 - 降级后仍需配对
unlockRead(newStamp)，不能复用原写锁 stamp
为什么要在复杂计算中用锁降级，而不是全程持写锁
写锁独占，长期持有会阻塞所有读线程，尤其在业务逻辑含 IO、远程调用或耗时计算时，吞吐量会断崖下跌。锁降级的本质是：**用一次写锁完成数据修正 + 状态标记，再以读锁支撑后续只读计算，让其他线程能并发读取中间结果**。
例如缓存预热场景：先写锁更新 version 和 data，然后降级为读锁，再遍历 data 做校验、聚合、序列化——这些只读步骤不再阻塞新请求。
- 全程写锁：100ms 计算期间，所有读请求排队，P99 延迟飙升
- 写+降级读：前 5ms 写，后 95ms 读锁共享，读请求可并发进入
- 注意：降级后的读锁仍会阻塞新写锁，但不会阻塞其他读锁或乐观读
降级失败时的重试逻辑必须包裹完整读路径
很多人只重试“获取读锁”动作，却忘了重读关键字段。因为写锁释放到读锁获取之间存在竞态窗口，validate() 或字段值可能已变。
正确模式是把整个只读计算逻辑包进重试块，确保数据一致性边界清晰：
long stamp = lock.writeLock();
try {
// 步骤1：原子更新核心状态
this.version++;
this.data = computeNewData();
// 步骤2：尝试降级
long readStamp = lock.tryConvertToReadLock(stamp);
if (readStamp != 0L) {
stamp = readStamp; // 成功，继续用该 stamp
} else {
lock.unlockWrite(stamp); // 必须先释放写锁
stamp = lock.readLock(); // 再抢读锁
}
// 步骤3：所有只读计算都放在这里（含字段重读）
int size = this.data.size(); // 不是之前写入时的局部变量！
double avg = computeAvg(this.data);
return buildResult(size, avg, this.version);
} finally {
lock.unlock(stamp); // 自动识别是读锁还是写锁
}
容易被忽略的三个硬约束
StampedLock 的降级能力很脆，以下三点不满足就大概率失效或出错：
- 写锁期间**不能嵌套调用
tryOptimisticRead()**：会破坏 stamp 版本链，validate()永远失败 - 降级前后读取的字段必须是
final或volatile，否则 JIT 可能重排序，导致看到部分更新的脏值 -
unlock(stamp)是安全的，但若你手动拆成unlockWrite()/unlockRead()，必须严格匹配 stamp 类型，混用必抛异常
真正难的不是写对降级代码，而是判断“这个业务是否值得降级”——如果只读计算本身很快（
