在开发中有些业务我们可能会使用到乐观锁或者悲观锁，但是具体使用场景需要结合具体业务需求和并发情况进行选择。下面用代码来简单实现两种锁

一、乐观锁

概念： 乐观锁从字面上来看就知道它是比较乐观的，它认为数据一般不会产生冲突，因此开始执行方法的时候一般不加锁，只有当数据进行提交更新时，才会真正对数据是否产生冲突进行监测，再加锁更新数据。如果监测时发生冲突，就返回给用户错误信息，由用户来决定如何去做。

代码示例：

public class OptimisticLockExample {private int version;public void optimisticLockTest() {int v = version;// 假设一些其他操作可能会改变version值// 执行一些其他操作...version++;// 更新数据前监测version是否因为其他操作修改了if (v == version - 1) {// 版本号未被其他线程改变，操作成功// 更新业务逻辑代码...} else {// 被改动了，抛出异常throw new OptimisticLockException("版本号已被其他线程改变，操作失败");}}
}

乐观锁通常是基于版本号的，需要对数据库表进行设计，增加版本号字段，一般都会使用CAS(compare-and-swap)算法实现。但不一定使用CAS算法，这里是一个简单的Java乐观锁示例，optimisticLockTest()方法先保存当前版本号为 v ，然后执行一些其他操作，假设这些操作可能会改变version值。然后比较 v 和当前版本号-1的值，如果相等则说明版本号未被其他线程改变，操作成功；否则抛出OptimisticLockException异常，表示版本号已被其他线程改变，操作失败。

适用场景： 乐观锁适用于读多写少的场景，如缓存更新、统计分析等。因为乐观锁不需要加锁，可以提高并发性能。

二、悲观锁

概念： 悲观锁它总是会假设当前情况是最坏的情况，在每次去拿数据的时候，都会认为数据会被别人改变，所以在拿数据的时候一开始就加锁，确保同一时刻只有一个线程能够访问和修改数据，其他线程需要等待当前线程释放锁之后才能进行访问和修改。

代码示例：

public class PessimisticLockExample {private Lock lock = new ReentrantLock();public void pessimisticLockTest() {// 获取锁lock.lock();try {// 执行共享资源操作..} finally {lock.unlock();}}
}

Java里面synchronized(同步锁)和ReentrantLock(重入锁)等独占锁就是悲观锁思想的实现，上述代码使用的是ReentrantLock(重入锁)，在对共享资源进行操作时，先通过lock()方法获取锁，操作完成后再通过unlock()方法释放锁。这种方式能够保证同一时刻只有一个线程能够对资源进行操作。

适用场景： 悲观锁适用于写多读少的场景，如银行转账、库存更新等。因为悲观锁需要加锁，可以保证数据的一致性和完整性，但是也会降低并发性能。

三、总结

乐观锁通常是通过CAS算法来实现，也可以使用版本号或时间戳等方式。而悲观锁通常是通过synchronized关键字或者ReentrantLock来实现的。当多个线程同时更新同一条数据时，如果使用乐观锁，可能会发生更新冲突，需要进行重试或者回滚操作；而如果使用悲观锁，则可以保证同一时刻只有一个线程能够更新数据，不会出现更新冲突。总之，乐观锁和悲观锁各有优缺点，具体使用场景需要结合具体业务需求和并发情况进行选择。