悲观锁假设冲突频繁发生，通过synchronized、ReentrantLock或数据库行锁实现，适合写多场景；乐观锁假设冲突少，采用版本号或CAS机制，适用于读多写少场景，提升并发性能。
在Java中处理多线程环境下的数据并发控制时，乐观锁和悲观锁是两种常见的策略。它们适用于不同的业务场景，理解其原理和实现方式对提升系统性能和数据一致性至关重要。
悲观锁：假设冲突总会发生
悲观锁认为在并发操作中，数据被修改的可能性很高，因此在整个操作过程中都会锁定资源，防止其他线程访问。
在Java中，悲观锁的实现主要依赖于同步机制：
- synchronized关键字：修饰方法或代码块，确保同一时刻只有一个线程可以执行该段代码。
- ReentrantLock：显式锁，提供比synchronized更灵活的控制，如尝试获取锁、超时获取等。
- 数据库层面的行锁：在使用JDBC或ORM框架（如MyBatis、Hibernate）时，通过red">SELECT ... FOR UPDATE语句对记录加锁，属于数据库悲观锁的应用。
示例代码（使用ReentrantLock）：
立即学习“Java免费学习笔记（深入）”；
private final ReentrantLock lock = new ReentrantLock();
public void updateData() {
lock.lock();
try {
// 操作共享资源
} finally {
lock.unlock();
}
}
这种方式适合写操作频繁、冲突概率高的场景，但可能影响并发性能。
乐观锁：假设冲突很少发生
乐观锁认为大多数情况下不会发生冲突，因此不加锁。只有在更新数据时才检查是否被其他线程修改过，若已被修改则放弃或重试。
常见实现方式是基于版本号或CAS（Compare and Swap）机制：
- 版本号机制：在数据表中增加一个version字段，每次更新时判断当前version是否与读取时一致，一致则更新并version+1，否则失败。
- CAS操作：Java中的AtomicInteger、AtomicReference等类底层使用Unsafe提供的CAS指令实现无锁并发控制。
- 数据库实现：UPDATE语句中加入version条件，例如：UPDATE table SET value=?, version=version+1 WHERE id=? AND version=?。
示例代码（使用AtomicInteger）：
private AtomicInteger counter = new AtomicInteger(0);
public void increment() {
int oldValue, newValue;
do {
oldValue = counter.get();
newValue = oldValue + 1;
} while (!counter.compareAndSet(oldValue, newValue));
}
乐观锁适用于读多写少的场景，能有效提高吞吐量，但高并发写入时可能导致大量重试。
选择建议与注意事项
悲观锁适合临界区大、写操作频繁的场景，能保证强一致性；乐观锁适合冲突少、响应要求高的系统，减少线程阻塞。
- 使用悲观锁要注意避免死锁，确保锁的粒度合理，及时释放锁。
- 乐观锁需配合重试机制（如Spring的@Retryable），避免无限循环。
- 在分布式环境下，可结合Redis或Zookeeper实现分布式锁，扩展悲观/乐观思想。
基本上就这些，根据实际业务权衡一致性与性能，选择合适的并发控制方式即可。
