悲观锁和乐观锁

悲观锁(Pessimistic Lock), 字面意思就明白就是很悲观，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会block直到它拿到锁，实现悲观锁首先，在要锁定的表里，加一个字段如 lock_at 时间标志，表示当前记录被锁定时的时间， 当为 0 时，表示该记录未被锁定，当要修改某个记录时，先看看当前时间与 lock_at 字段相差是否超过预定的一个时长T，比如 30 分钟 ，1 小时 之类的，如果没超过，说明该记录有人正在修改，我们暂时不能修改。 否则，说明可以修改，主要通过这个时间戳实现的。

乐观锁每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据版本号或时间戳控制，适用于多读少写的场景悲观锁每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会block直到它拿到锁DB的行锁、表锁等，适用于数据一致性比较高的场景实现乐观锁在程序里面我们需要定义两个方法，分别是使用乐观锁返回版本号没有使用锁返回null，在添加一条记录前，再次读取这个记录的版本号 字段，与之前读取的值进行

一个比较清楚的场景

下面这个假设的实际场景可以比较清楚的帮助我们理解这个问题：假设当当网上用户下单买了本书，这时数据库中有条订单号为001的订单，其中有个status字段是’有效’,表示该订单是有效的；后台管理人员查询到这条001的订单，并且看到状态是有效的用户发现下单的时候下错了，于是撤销订单，假设运行这样一条SQL: update order_table set status = ‘取消’ where order_id = 001;

后台管理人员由于在b这步看到状态有效的，这时，虽然用户在c这步已经撤销了订单，可是管理人员并未刷新界面，看到的订单状态还是有效的，于是点击”发货”按钮，将该订单发到物流部门，同时运行类似如下SQL，将订单状态改成已发货:update order_table set status = ‘已发货’ where order_id = 001

观点1：只有冲突非常严重的系统才需要悲观锁；“所有悲观锁的做法都适合于状态被修改的概率比较高的情况，具体是否合适则需要根据实际情况判断。”，表达的也是这个意思，不过说法不够准确；的确，之所以用悲观锁就是因为两个用户更新同一条数据的概率高，也就是冲突比较严重的情况下，所以才用悲观锁。

观点2：最后提交前作一次select for update检查，然后再提交update也是一种乐观锁的做法，的确，这符合传统乐观锁的做法，就是到最后再去检查。但是wiki在解释悲观锁的做法的时候，’It is not appropriate for use in web application development.’， 现在已经很少有悲观锁的做法了，所以我自己将这种二次检查的做法也归为悲观锁的变种，因为这在所有乐观锁里面，做法和悲观锁是最接近的，都是先select for update，然后update比对，

在实际应用中我们在更新数据的时候，更严谨的做法是带上更新前的“状态”，如

update order_table set status = ‘取消’ where order_id = 001 and status = ‘待支付’ and ..........;

update order_table set status = ‘已发货’ where order_id = 001 and status = ‘已支付’ and ..........;

然后在业务逻辑代码里判断更新的记录数，为0说明数据库已经被更新了，否则是正常的。