JAVA：【基础八】乐观锁、悲观锁

目录

定义

悲观锁

悲观锁详细分为：【共享锁】和【排它锁】

乐观锁

可以使用【版本号机制】或【CAS算法】实现

版本号机制：

CAS算法机制：

定义

悲观锁

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

乐观锁 ：

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

悲观锁

悲观锁详细分为：【共享锁】和【排它锁】

• 共享锁【shared locks】又称为读锁，简称 S 锁。顾名思义，共享锁就是多个事务对于同一数据可以共享一把锁，都能访问到数据，但是只能读不能修改。
• 排他锁【exclusive locks】又称为写锁，简称 X 锁。顾名思义，排他锁就是不能与其他锁并存，如果一个事务获取了一个数据行的排他锁，其他事务就不能再获取该行的其他锁，包括共享锁和排他锁。获取排他锁的事务可以对数据行读取和修改。

乐观锁

可以使用【版本号机制】或【CAS算法】实现

版本号机制：

• 在数据表中加上一个数据版本号version字段，表示数据被修改的次数，如id=1，name="张三"，version=1
• 收到【线程1】和【线程2】查询“张三”的操作；
• 查询完成后，【线程1】优先执行以下sql

  • # mysql书写方式 其中#{version} = 1, id = 1
    update table 
        set name = '李四' , version=#{version} + 1 
    where 
        id = #{id} and version=#{version}

• 【线程1】执行完update操作并提交，此时数据变为：id=1，name="张三"，version =2；
• 此时【线程2】也开始执行上面同样的update语句，但此时sql中给version赋的值是1，固更新失败

CAS算法机制：

• 具有原子性特性，其机制类似于GIT提交
• CAS有3个操作数，内存值V，旧的预期值A，要修改的新值B
• 当且仅当预期值A和内存值V相同时，将内存值V修改为B，否则就不更新
• 多线程因为需要对比，所以会存在【自旋】问题，即反复进行对比
• CAS存在【ABA问题】
  • 数据由A，变为B，又变为A。这样从结果来看，就不知道数据发生过改变
  • 可使用【AtomicStampedReference】来解决：使用版本戳的记录每次改变后的版本号，这样的话就不会存在 ABA问题了
• CAS 必须借助 【volatile】 才能读取到共享变量的最新值来实现【比较并交换】的效果
• 原子类：Atomic