初识“锁”：解决线上做业提交系统 多人阅卷时 产生的并发问题

零、并发问题

假设，有一个线上做业系统，当阅卷时，会从数据库取出第一个未评阅的做业。
评阅完成后，会把做业状态改成“已评阅”：

这样没什么问题。

若是是两我的同时评阅呢？若是B获取做业时，A已经把做业1评阅完毕，此时B获取的是做业2。这样，彷佛看上去也没什么问题。（①②③④表明时序）：

可是，这是不现实的，B不可能每次都等到A评阅完成以后再发起请求。
若是AB同时评阅，就会出现问题（①②③④表明时序）：

A和B前后从后台获取一个做业，假设A先发起请求，那么当B获取做业时，A尚未评阅完成，此时做业1仍是未评阅状态。
因而B也会获取到做业1，而不是做业2。接下来，A评阅完成，此时做业1变成已评阅状态。再轮到B评阅做业1时，系统就报错了。

所以，目前的系统，因为出现了并发问题，没法实现多人同时评阅做业。

1、初识“锁”

锁的好处之一，就是在必定程度上解决了并发问题，上面提到的多人阅卷，就是一个生动的例子，此外还有其余场景，好比：取钱。
数据库的锁和事务是相关的，关于这部份内容，张喜硕学长在《MySQL RR 与 锁》中有详细的介绍。

值得注意的是，因为是第一次接触，而且这个项目比较简单，所以不必使用Mysql中真正的事务和锁，而是用代码来实现相似“锁”效果。具体逻辑以下：

• 增长一个字段，当前评阅人CurrentUserId。
• A获取做业时，查询此字段为空的做业，查询成功后，返回做业1，设置评阅人为本身（至关于加入读锁）。
• 此时，B若是再获取做业，就不会再获取到做业1。
• 当A提交以后，清空当前评阅人字段（解锁），状态改成已评阅。

（下图①②③④表明时序）

这样，就成功解决了并发问题，不管有多少人同时评阅，也不会冲突了。

2、带时间的“锁”

以上的解决方式还存在问题，若是A获取做业1以后，并无提交分数（好比A掉线了、或者A没有点击评阅按钮），做业1的锁，就永远不会被解除了。

这就致使，做业1不会再被别人获取到。

所以，须要为锁自动加上倒计时，一旦时间结束，若是阅卷人仍然没有评阅的话，就自动解锁，清空CurrentUserId。（下图①②③④⑤表明时序）

这样，即便在A获取做业以后没有完成阅卷，也不会遗漏掉任何做业。

总结

本文中，咱们经过手写代码，实现了Mysql中“读锁”（共享锁）的功能（事实上，这段代码有点麻烦，涉及到改字段、多线程、定时任务...因此文中只谈思路）。

随着知识了解的愈来愈多，咱们思考问题的角度，已经从如何生产一个新项目，变成了如何更新已经上线的项目。后者的要求更高，这须要咱们进行更新时，必须考虑和原有数据的无缝衔接。

相信不久后的未来，咱们就能学会使用真正的锁和事务来处理并发问题了。

版权声明

本文做者： 河北工业大学梦云智开发团队 - 刘宇轩