并发面试高频考点：乐观锁与悲观锁深度解析
在多线程环境下，如何保证数据的一致性？这通常是面试官考察并发能力的经典切入点。核心就在于对'锁'的理解——悲观锁与乐观锁。
悲观锁：先占为敬
悲观锁的哲学是'防患于未然'。它假设最坏的情况会发生，即任何时刻资源都可能被其他线程修改。因此，在执行操作前必须先锁定资源，确保独占访问。
- 实现方式：依赖数据库的行锁/表锁，或编程语言层面的同步机制（如 Java 中的
synchronized）。 - 适用场景：写多读少、竞争激烈的环境。
- 代价：线程容易阻塞等待，高并发下可能成为性能瓶颈，甚至引发死锁。
乐观锁：后发制人
乐观锁则相反，它假设冲突很少发生。读取数据时不加锁，只在更新时检查数据是否被他人改动过。如果冲突了，再重试或回滚。
- 核心机制：通常借助版本号（Version）或时间戳（Timestamp）来实现。
- 版本号：更新前比对版本号，不一致则放弃并重试。
- 时间戳：比对最后修改时间，确保当前数据未被覆盖。
- 优势：无锁开销，并发吞吐量更高。
- 注意：需要妥善处理冲突重试逻辑，否则可能导致活锁或无限重试。
总结与选型建议
没有绝对更好的锁，只有更合适的选择。
- 若业务场景冲突概率高（如库存扣减），优先选悲观锁，保证强一致性。
- 若读多写少且冲突少（如配置中心），乐观锁能显著提升性能。
- 实际架构中，两者常结合使用，根据具体模块特性灵活切换。
