乐观锁和悲观锁的区别

悲观锁

总是假设最坏的情况，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会阻塞直到它拿到锁（共享资源每次只给一个线程使用，其它线程阻塞，用完后再把资源转让给其它线程）。传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。在Java中，synchronized从偏向锁、轻量级锁到重量级锁，全是悲观锁。JDK提供的Lock实现类全是悲观锁。

乐观锁

总是假设最好的情况，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下，在此期间有没有别人去更新这个数据，可以使用版本号机制和CAS算法实现。乐观锁适用于多读的应用类型，这样可以提高吞吐量。

优点

乐观锁是一种并发类型的锁，其本身并不对数据进行加锁，而是通过循环重试、CAS算法实现锁的功能，其不对数据加锁的机制就意味着允许多个线程同时读取数据，但是只有最先修改的线程可以修改数据，这种方式大大提高了数据库操作数据的性能。

缺点

但是在并发量特别大的时候会有很多进程回滚重试，从而引起很多的CPU资源浪费

实现方式：版本号机制、CAS算法

版本号机制：

使用version来标记每次操作
每次操作之前检查version
如果当前version是我拿到的version那么表示没有其他线程修改过该数据，因此可以正确修改数据，并把version+1，表示这个数据我已经修改过了
如果version错误表示已经有其他操作修改了原始数据
这种实现方式因为需要我们读取version字段，因此要在表中添加对应的version字段

特点：吞吐量比较多，如果线程比较多那么需要大量的轮询，占用大量的CPU时间
适合读多写少

在表中一定要有一个表示version的字段

CAS算法：

是操作系统来实现的，CPU级别的指令

在Mybatis-plus中怎么实现乐观锁

首先引入插件：

// Spring Boot 方式
@Configuration
@MapperScan("按需修改")
public class MybatisPlusConfig {
    /**
     * 旧版
     */
    @Bean
    public OptimisticLockerInterceptor optimisticLockerInterceptor() {
        return new OptimisticLockerInterceptor();
    }

    /**
     * 新版
     */
    @Bean
    public MybatisPlusInterceptor mybatisPlusInterceptor() {
        MybatisPlusInterceptor mybatisPlusInterceptor = new MybatisPlusInterceptor();
        //表示添加对乐观锁的支持，分页插件的添加方式亦如是
        mybatisPlusInterceptor.addInnerInterceptor(new OptimisticLockerInnerInterceptor());
        return mybatisPlusInterceptor;
    }
}

在实体类的字段上加上@Version注解，表示数据库中对应的字段用于表示版本号

支持的数据类型只有:int,Integer,long,Long,Date,Timestamp,LocalDateTime
整数类型下 
newVersion = oldVersion + 1
newVersion 会回写到 
entity 中
仅支持 
updateById(id) 与 
update(entity, wrapper) 方法
在 update(entity, wrapper) 方法下, wrapper 不能复用!!!

模拟多线程：

乐观锁和悲观锁的比较

1、乐观锁并未真正加锁（不是真正的锁），效率高。一旦锁的粒度掌握不好，更新失败的概率就会比较高，容易发生业务失败。
2、悲观并发控制实际上是“先取锁再访问”的保守策略，为数据处理的安全提供了保证，但是需要依赖数据库的加锁机制
3、悲观锁阻塞事务，乐观锁回滚重试，它们各有优缺点，不要认为一种一定好于另一种。像乐观锁适用于写比较少的情况下，即冲突真的很少发生的时候，这样可以省去锁的开销，加大了系统的整个吞吐量。但如果经常产生冲突，上层应用会不断的进行重试，这样反倒是降低了性能，所以这种情况下用悲观锁就比较合适。