Java 中的乐观锁与悲观锁在实现原理、性能表现及适用场景上有何区别？请分别说明它们的使用条件与典型应用。

回答思路

1. 【回答框架 1】悲观锁基于冲突预防，假设数据总是被并发修改，访问前先加锁（如数据库行锁、synchronized），阻塞其他事务直到释放，保证严格串行化。
2. 【回答框架 2】乐观锁基于冲突检测，假设冲突很少，读取时不加锁，提交时校验版本号（version）或时间戳，若版本不一致则更新失败并重试，如CAS（Compare And Swap）机制。
3. 【回答框架 3】两者核心区别在于加锁时机与冲突处理方式：悲观锁以锁换安全，代价是阻塞与死锁风险，适合写多读少、冲突率高、事务时间短的场景；乐观锁以重试换并发，代价是增加ABA问题与重试开销，适合读多写少、冲突率低、对实时性要求不严的场景。
4. 【回答框架 4】选择依据：若业务对数据一致性要求极高且并发冲突频繁，用悲观锁；若冲突率低且希望最大化并发吞吐，用乐观锁。实际中常搭配使用，如数据库乐观锁用于更新操作，分布式锁用于跨进程互斥。
5. 【回答框架 5】实现层面需注意：悲观锁要控制锁粒度与持有时间，避免死锁；乐观锁需处理版本字段更新与失败重试逻辑，并考虑ABA问题的解决方案（如版本号递增或带标记的引用）。
6. 【关键点 1】悲观锁假设冲突频繁，先加锁后访问，通过阻塞保证互斥。
7. 【关键点 2】乐观锁假设冲突少，不加锁，通过版本号或CAS在提交时校验冲突。
8. 【关键点 3】乐观锁适用于读多写少的场景，悲观锁适用于写多冲突频繁且需要强一致的场景。
9. 【关键点 4】乐观锁需处理ABA问题，悲观锁需防范死锁与锁持有过长。
10. 【关键点 5】实际系统常灵活组合两种策略，如乐观锁控制更新，悲观锁控制临界资源互斥。
11. 【易错点 1】将乐观锁的版本校验误认为能完全保证业务幂等，实际上还需结合唯一标识、状态记录或唯一约束。
12. 【易错点 2】忽视ABA问题，盲目使用CAS或版本号不递增，导致并发更新丢失。
13. 【易错点 3】认为乐观锁一定比悲观锁高性能，未考虑冲突率高时的重试开销与CPU空转。