悲观锁乐观锁

悲观锁与乐观锁

面试题

​ 悲观锁（Pessimistic Lock），每次去操作数据的时候都会认为别人会修改这个数据，所以每次操作数据的时候都会上锁。这样别人想拿到这个数据就会阻塞直到拿到锁。悲观锁是一种思想，很多技术中都使用到了悲观锁。

​ 传统的RDBMS（关系型数据库管理系统）中就用到了这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁（比如通过select…for update添加排他锁）。

​ Java中的synchronized和ReentrantLock也是悲观锁思想的实现，当一个线程得到锁的时候，其他需要锁的线程（访问同一个资源的其他线程）就得阻塞等待挂起。

​ 乐观锁(Optimistic Lock)，每次操作数据的时候都认为别人不会修改这条数据，所以不会上锁（乐观锁实际上没有锁），但是在更新数据的时候会判断一下在此期间别人有没有修改过这个数据，可以使用版本号、时间戳、CAS算法等机制。乐观锁适用于读多写少的场景，这样能提高吞吐量。

​ 乐观锁也是一种思想，CAS算法是乐观锁的一种实现方式，CAS就是Compare And Swap比较并交换。CAS有三个操作数，内存值V（变量地址指向的值、主存中值），旧的预期值A（原来的值，从主存中拉到工作内存的值），要修改的新值B（修改后的值）。只有当内存值V和预期值A相同时，才会将内存值V修改为新值B，否则什么也不做。

​ Java中的原子类操作就是基于CAS的，当多个线程尝试使用CAS来更新同一个变量时，只有一个线程能成功更新变量的值，其他线程都会失败。失败的线程并不会被挂起，而是会被告知竞争失败了，可以重新尝试（retry）。

​ ES也是使用乐观锁来进行并发控制保证数据一致性的，不需要进行加锁或者解锁的操作。当我们GET一条文档的时候，返回结果中会有一个字段叫做“_version”，在更新这条数据编写更新语句的时候带上这个版本号，只有更新语句中的版本号和ES服务器中这个文档的版本号相同才能更新成功，否则ES就会抛出版本冲突异常（version_conflict_engine_exception）。

​ 那么悲观锁和乐观锁各有优缺点，应用场景不同。乐观锁适用于读多写少的场景，也就是冲突真的很少发生的时候，这样就省去了锁的开销，提高了系统的吞吐量。但是如果是多写的场景，一般会经常产生冲突，这就导致上层应用不断retry（重试），反倒是降低了性能，所以一般写多读少的场景使用悲观锁比较合适。

参考：https://blog.csdn.net/qq_34337272/article/details/81072874