17370845950

悲观锁假设冲突频繁发生，通过synchronized、ReentrantLock或数据库行锁实现，适合写多场景；乐观锁假设冲突少，采用版本号或CAS机制，适用于读多写少场景，提升并发性能。

在Java中处理多线程环境下的数据并发控制时，乐观锁和悲观锁是两种常见的策略。它们适用于不同的业务场景，理解其原理和实现方式对提升系统性能和数据一致性至关重要。

悲观锁：假设冲突总会发生

悲观锁认为在并发操作中，数据被修改的可能性很高，因此在整个操作过程中都会锁定资源，防止其他线程访问。

在Java中，悲观锁的实现主要依赖于同步机制：

• synchronized关键字：修饰方法或代码块，确保同一时刻只有一个线程可以执行该段代码。
• ReentrantLock：显式锁，提供比synchronized更灵活的控制，如尝试获取锁、超时获取等。
• 数据库层面的行锁：在使用JDBC或ORM框架（如MyBatis、Hibernate）时，通过SELECT ... FOR UPDATE语句对记录加锁，属于数据库悲观锁的应用。

示例代码（使用ReentrantLock）：

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实现分布式锁，扩展悲观/乐观思想。

基本上就这些，根据实际业务权衡一致性与性能，选择合适的并发控制方式即可。