什么是opportunistic locks？它与pessimistic locks有什么区别？

二者存在本质差异，你看到Windows文件系统层面对机会锁的描述和悲观锁相似，只是特定场景下的实现表象，核心逻辑完全不同：

核心差异点 #

• 锁抢占时机完全不同
  悲观锁是预先抢占机制：操作数据前必须先主动申请并持有锁，加锁成功前不允许其他方修改对应数据，从操作起始就独占资源权限。
  机会锁是先操作后校验机制：操作前不会主动加锁抢占资源，默认假设不会发生并发冲突，直接执行读写逻辑，仅在提交修改的最后阶段校验数据是否被其他方修改，校验失败才回滚操作。
• 性能开销分布不同
  悲观锁的开销集中在操作前：每次操作都要走锁申请、持有、释放的流程，并发量高时会出现大量线程阻塞等待锁的情况，即使没有冲突也会产生固定的锁调度开销。
  机会锁的开销集中在冲突发生后：只有真的出现并发修改冲突时才需要回滚重试，低冲突场景下没有任何锁相关开销，性能远高于悲观锁；但高冲突场景下大量回滚会导致性能骤降。
• 适用场景不同
  悲观锁适合写多读少、并发冲突概率极高的场景，比如高频次的库存扣减业务。
  机会锁适合读多写少、并发冲突概率低的场景，这也是MongoDB WiredTiger存储引擎选择该机制的核心原因：大部分文档读写不会出现并发修改，能大幅提升整体吞吐量，仅在偶发冲突时返回写入冲突让客户端重试即可。
• 实现逻辑不同
  悲观锁通常依赖互斥量、读写锁等操作系统原生锁原语实现，操作全程持有锁标识。
  机会锁通常通过数据版本号、时间戳比对实现，不需要全程持有锁，WiredTiger的文档级多版本并发控制（MVCC）就是机会锁的典型实现。

补充：你看到的Windows文件系统机会锁看起来类似悲观锁，是因为其实现中检测到冲突后会暂时阻塞新的写入方，等待持有缓存的旧客户端作废缓存，这个流程只是冲突后的处理逻辑，本质还是遵循「先假设无冲突，冲突后再处理」的核心逻辑，和悲观锁操作前就预先占锁的逻辑有本质区别。

内容的提问来源于stack exchange，提问作者Vaibhav