为什么会使用到数据库级别的锁？

你可能会有这么一个疑问：现在的程序已经提供了很完善的锁机制来保证多线程的安全问题，还需要用到数据库级别的锁吗？我觉得还是需要的，为什么呢？理由很简单，我们再编程中使用的大部分锁都是单机，尤其是现在分布式集群的流行，这种单机的锁机制就保证不了线程安全了，这个时候，你可能又会想到使用redis的setNX分布式锁或者zookeeper的强一致性来保证线程安全，但是这里我们需要考虑到一个问题，那就是成本问题，有的时候使用redis分布式锁以及zookeeper会增加维护的成本，结合实际出发，再说没有百分百安全的程序，所以再数据库层加锁，也能将安全再提升一级，所以还是有必要的。

什么是悲观锁

悲观锁，正如其名，具有强烈的独占和排他特性。它指的是对数据被外界（包括本系统当前的其他事务，以及来自外部系统的事务处理）修改持保守态度，因此，在整个数据处理过程中，将数据处于锁定状态。悲观锁的实现，往往依靠数据库提供的锁机制（也只有数据库层提供的锁机制才能真正保证数据访问的排他性，否则，即使在本系统中实现了加锁机制，也无法保证外部系统不会修改数据）。

通俗的讲：开启一个事务之后开启悲观锁，这时候数据库将会锁着你需要查询的某条数据或者某张表，其他事务中的查询将会处于阻塞状态，开启悲观锁事务里面操作不会被阻塞，这点有点类似java中的互斥锁（其中的可重入锁），那什么时候锁记录？什么时候锁整张表呢？接着往下看。

mysql悲观锁如何使用？

1.在查询后加：for update

2.需要先开启事务，否者悲观锁无效

3.执行完查询之后一定要接上update语句，否者其他事物会一直处于阻塞状态，直到第一个事务抛出异常为止。

我们看一个例子，假如用户现在有100块钱，买充电器需要100，买耳机也需要100，这时候用户同时买下这两款商品，会发生什么事情呢？

我们分别说一下正常情况和加了悲观锁的情况，这里暂时不讨论程序锁的问题，如果想了解程序中的锁，请参考：java并发编程之synchronized、java并发编程之ReentrantReadWriteLock读写锁等等。

我在数据库新建了一张表：

 表比较简单，我们只需要关注用户id和用户余额，我们等会会用到，我们现在就来模拟一下同时扣款100元，会发生什么情况，直接上代码

单元测试代码：

 @Resource
    private IUserWalletService userWalletService;

@Test
    void deductMoney() throws InterruptedException {
        //需要扣除的金额
        BigDecimal meney = BigDecimal.valueOf(100l);

        //新建第一个线程t1
        Thread t1 = new Thread(() ->{
            //线程1：让用户1扣除100元
            userWalletService.deductMoney(1, meney);
        });
        //新建第一个线程t2
        Thread t2 = new Thread(() ->{
            //线程2：让用户1扣除100元
            userWalletService.deductMoney(1, meney);
        });
        //启动线程1
        t1.start();
        //启动线程1
        t2.start();
        //让线程同步
        t1.join();
        t2.join();
        System.out.println("执行完毕");

    }

service代码：

private UserWalletMapper userWalletMapper;


    UserWalletServiceImpl(UserWalletMapper userWalletMapper){
        this.userWalletMapper = userWalletMapper;
    }

    @Override
    @Transactional
    public void deductMoney(int userId, BigDecimal money) {
        //获取线程名
        String threadName = Thread.currentThread().getName();
        //查询当前用户钱包信息
        UserWallet userWallet = userWalletMapper.getWalletByUserId(userId);
        log.info("线程：{}，用户id：{}，钱包余额：{}",threadName,userId,userWallet.getBalance());
        //判断当前用户是否存在
        if(null == userWallet){
            log.info("线程：{}，用户id：{}，不存在",threadName,userId);
            return ;
        }
        //判断用户的金额是否足够扣除
        if(userWallet.getBalance().subtract(money).compareTo(BigDecimal.ZERO) < 0){
            log.info("线程：{}，用户id：{}，余额不足",threadName,userId);
            return ;
        }
        //修改余额
        userWallet.setBalance(userWallet.getBalance().subtract(money));
        //扣钱，修改数据库
        userWalletMapper.update(userWallet,new UpdateWrapper<UserWallet>().lambda().eq(UserWallet::getUId,userId));
        //获取用户扣款之后的余额
        UserWallet wallet = userWalletMapper.selectOne(new QueryWrapper<UserWallet>().lambda().eq(UserWallet::getUId,userId));
        log.info("线程：{}，用户id：{}，扣钱之后余额：{}",threadName,userId,wallet.getBalance());
    }

mapper代码：

/**
     * 通过用户id查询用户钱包新消息
     * @param userId
     * @return
     */
    UserWallet getWalletByUserId(int userId);

与mapper对应的xml代码：

<!-- 通用查询映射结果 -->
    <resultMap id="BaseResultMap" type="com.aspect.entity.UserWallet">
        <id column="id" property="id" />
        <result column="balance" property="balance" />
        <result column="u_id" property="uId" />
        <result column="version" property="version" />
    </resultMap>

    <!-- 通用查询结果列 -->
    <sql id="Base_Column_List">
        id, balance, u_id, version
    </sql>


    <select id="getWalletByUserId" resultType="com.aspect.entity.UserWallet">
        select <include refid="Base_Column_List" /> from user_wallet  where u_id =#{userId}

    </select>

实体类：

package com.aspect.entity;

import java.math.BigDecimal;

import com.baomidou.mybatisplus.annotation.IdType;
import com.baomidou.mybatisplus.extension.activerecord.Model;
import com.baomidou.mybatisplus.annotation.TableId;

import java.io.Serializable;

import lombok.Data;
import lombok.EqualsAndHashCode;
import lombok.experimental.Accessors;

/**
 * <p>
 *
 * </p>
 *
 * @author yaomaoyang
 * @since 2020-01-10
 */
@Data
@EqualsAndHashCode(callSuper = false)
@Accessors(chain = true)
public class UserWallet extends Model<UserWallet> {

    private static final long serialVersionUID = 1L;

    @TableId(value = "id", type = IdType.AUTO)
    private Long id;

    private BigDecimal balance;

    private Long uId;

    private Long version;


    @Override
    protected Serializable pkVal() {
        return this.id;
    }

}

userWalletMapper.update、userWalletMapper.selectOne属于mybatis-plus语法。

好了，正常的写法应该是这样的吧，那到底会不会出现问题呢？我们先再数据库给用户id为1的一个初始化数据：100元

好了，准备工作已经做完，我们运行deductMoney()

预期结果：第一次扣钱成功，第二次提示余额不足

实际结果：

结果却不是我们想要的，如果这要是出现在我们的生产环境，那是要背大锅的，那如何解决呢？肯定有人想到了：互斥锁，这个肯定能解决，那如果有两个服务呢？其实也能解决，感兴趣的可以自行研究，文章开头已经说了解决方向，还有什么方式能解决呢？我们的mysql悲观锁就应该要登场了。

使用悲观锁优化代码：

之前的代码不动，只需要修改一处代码即可，那就是查询用户钱包信息的sql语句：

<select id="getWalletByUserId" resultType="com.aspect.entity.UserWallet">
        select <include refid="Base_Column_List" /> 
        
        from user_wallet  where u_id =#{userId} 

        for update

    </select>

我们将用户的余额重新修改为100，然后再运行单元测试代码：

 发现没有，线程2与线程3居然串行化了，并且也变成了我们预期的结果，虽然悲观锁可以实现线程的安全，但是弊端也很明显，那就是效率会很慢，有时候用的不好，会导致系统崩溃。

我们再来说说悲观锁锁住的到底是什么？

一共有两种
1.锁定指定行：查询对象为主键、字段有索引
2.锁定整张表：其他

查询对象为主键这个我就不演示了，这里我来展示一下另外一种情况，需求如下：
同时扣除用户id：1与用户id：2 的账户100元。

在数据库新增一条用户id等于2的数据，初始金额100

u_id字段我们暂时还没有加索引，所以是一个普通字段，为了让你们看的清楚，我们再改造一下代码：

单元测试代码

 @Test
    void deductMoney2() throws InterruptedException {
        //需要扣除的金额
        BigDecimal meney = BigDecimal.valueOf(100l);

        //新建第一个线程t1
        Thread t1 = new Thread(() ->{
            //线程1：让用户1扣除100元
            userWalletService.deductMoney(1, meney);
        });
        //新建第一个线程t2
        Thread t2 = new Thread(() ->{
            //线程2：让用户1扣除100元
            userWalletService.deductMoney(2, meney);
        });
        //启动线程1
        t1.start();
        //启动线程1
        t2.start();
        //让线程同步
        t1.join();
        t2.join();
        System.out.println("执行完毕");

    }

与第一个单元测试的差别仅仅只是修改了一个线程的用户id，接着再service中让程序休眠1秒，这样我们可以更直观的看结果

@Override
    @Transactional
    public void deductMoney(int userId, BigDecimal money) {
        //获取线程名
        String threadName = Thread.currentThread().getName();
        //查询当前用户钱包信息
        UserWallet userWallet = userWalletMapper.getWalletByUserId(userId);
        log.info("线程：{}，用户id：{}，钱包信息：{}", threadName, userId, userWallet);
         try {
            //休眠一秒
            log.info("线程：{}，用户id：{}，休眠开始", threadName, userId);
            TimeUnit.SECONDS.sleep(1);
            log.info("线程：{}，用户id：{}，休眠结束", threadName, userId);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        //判断当前用户是否存在
        if (null == userWallet) {
            log.info("线程：{}，用户id：{}，不存在", threadName, userId);
            return;
        }
        //判断用户的金额是否足够扣除
        if (userWallet.getBalance().subtract(money).compareTo(BigDecimal.ZERO) < 0) {
            log.info("线程：{}，用户id：{}，余额不足", threadName, userId);
            return;
        }
        //修改余额
        userWallet.setBalance(userWallet.getBalance().subtract(money));
        //扣钱，修改数据库

       
        userWalletMapper.update(userWallet,new UpdateWrapper<UserWallet>().lambda().eq(UserWallet::getUId,userId));
        //获取用户扣款之后的余额
        UserWallet wallet = userWalletMapper.selectOne(new QueryWrapper<UserWallet>().lambda().eq(UserWallet::getUId, userId));
        log.info("线程：{}，用户id：{}，扣钱之后余额：{}", threadName, userId, wallet.getBalance());
    }

运行单元测试

发现没有，程序先扣除了用户id等于2的金额，然后再扣除用户id等于1的金额，两个完全不相干的用户居然阻塞了？这就是我们刚刚说的普通字段悲观锁 锁定的整张表 ，我们希望的是同个用户的操作互斥，不同用户的操作并行，该如何实现呢？加入索引即可

我们再执行一次刚刚的单元测试：

此时，不同的用户扣钱操作就变成了并行，提高了一点点效率，主键也能保证并行，这里就不做演示了，你需要注意一点那就是mysql的悲观锁需要配合事务一起使用，否则无效 。

那在数据库层面有没有比读写锁更快的一种锁呢？答案肯定是有的，就是接下来需要说到的乐观锁。

乐观锁

乐观锁机制采取了更加宽松的加锁机制。悲观锁大多数情况下依靠数据库的锁机制实现，以保证操作最大程度的独占性。但随之而来的就是数据库 性能的大量开销，特别是对长事务而言，这样的开销往往无法承受。相对悲观锁而言，乐观锁更倾向于开发运用。

简单来说，就是在修改时做一个版本判断，符合要求则修改，否则不修改，修改的同时改变版本号。

这种方式严格来说不算锁，java程序中也有这样类似的操作，有一个专业术语：CAS（Compare and Swap），比如：Atomic的原子类操作都是无锁，实现机制就和乐观锁很相像，比较和赋值，这里就不多说了，感兴趣的可以自行百度。

那应该如何改造之前的代码？

第一步：删除sql中的 for update 悲观锁

 <select id="getWalletByUserId" resultType="com.aspect.entity.UserWallet">
        select <include refid="Base_Column_List" />
        from user_wallet  where u_id =#{userId}
    </select>

第二步：修改更新数据库金额的语句：

 @Override
    @Transactional
    public void deductMoney(int userId, BigDecimal money) {
        //获取线程名
        String threadName = Thread.currentThread().getName();
        //查询当前用户钱包信息
        UserWallet userWallet = userWalletMapper.getWalletByUserId(userId);
        log.info("线程：{}，用户id：{}，钱包余额：{}", threadName, userId, userWallet.getBalance());
        //判断当前用户是否存在
        if (null == userWallet) {
            log.info("线程：{}，用户id：{}，不存在", threadName, userId);
            return;
        }
        //判断用户的金额是否足够扣除
        if (userWallet.getBalance().subtract(money).compareTo(BigDecimal.ZERO) < 0) {
            log.info("线程：{}，用户id：{}，余额不足", threadName, userId);
            return;
        }
        //修改余额
        userWallet.setBalance(userWallet.getBalance().subtract(money));
        //扣钱，修改数据库
        Integer update = userWalletMapper.updateByVersion(userWallet);
        if(update == 0){
            log.info("线程：{}，用户id：{}，修改金额失败", threadName, userId);
            return ;
        }
        
        //userWalletMapper.update(userWallet,new UpdateWrapper<UserWallet>().lambda().eq(UserWallet::getUId,userId));
        //获取用户扣款之后的余额
        UserWallet wallet = userWalletMapper.selectOne(new QueryWrapper<UserWallet>().lambda().eq(UserWallet::getUId, userId));
        log.info("线程：{}，用户id：{}，扣钱之后余额：{}", threadName, userId, wallet.getBalance());
    }

第三步：修改mapper代码：

/**
     * 扣钱
     * @param userWallet
     */
    Integer updateByVersion(UserWallet userWallet);

第四步：修改与mapper对应的xml：

<update id="updateByVersion">

        update user_wallet  balance = #{balance},version = version+1 where u_id = #{uId} and version = #{version}
    </update>

记住，修改的同时一定要改变version的值，我这里做了+1处理（最好做累加处理，防止出现ABA问题）。

第四步：单元测试还是修改同一个用户的金额，部分代码如下：

//新建第一个线程t1
        Thread t1 = new Thread(() ->{
            //线程1：让用户1扣除100元
            userWalletService.deductMoney(1, meney);
        });
        //新建第一个线程t2
        Thread t2 = new Thread(() ->{
            //线程2：让用户1扣除100元
            userWalletService.deductMoney(1, meney);
        });

运行结果：

线程2扣钱成功，金额变成了0，线程3扣除失败，符合预期要求。

总结

悲观锁强调互斥，与java的锁很类似，乐观锁强调对比，与java的原子类操作很相似，悲观锁会降低系统的可用性（阻塞超时等等），乐观锁会降低系统的强一致性（很多无效请求），我们在选择悲观锁与乐观锁的时候需要结合自己的实际项目，因为他们都不是完美的，看系统愿意舍弃哪一种。