[1] 博由
前几天与一些朋友谈到这个问题之前有一些概念的上的涉及但是并没有相对深入的了解因此找一些资料来帮助自己理解悲观锁和乐观锁的概念理解、场景、然后通过示例来阐述乐观锁和悲观锁的实现方式。
[2] 摘要
本文将从三个方面来阐述悲观锁和乐观锁以理论到实践的思维方式呈现出个人对悲观锁和乐观锁的理解。 [1] 悲观锁和乐观锁的理论知识 [2] 悲观锁和乐观锁的一般使用场景
术语描述常见案例乐观锁每次去拿数据的时候都认为别人不会修改所以不会上锁但是在更新的时候会判断一下在此期间别人有没有去更新这个数据版本号控制适用于多读少写的场景悲观锁每次去拿数据的时候都认为别人会修改所以每次在拿数据的时候都会上锁这样别人想拿这个数据就会block直到它拿到锁DB的行锁、表锁等适用于数据一致性比较高的场景[?] 个人理解假设每个操作的对象是一个或者多个资源悲观锁可以理解为很悲观的看待资源权限的访问因此每次去操作资源时总是会try操作问一问是否可以去访问这个问一问就是去尝试获取锁只有获取了锁之后才会开始放心操作资源了然后乐观锁却是相反的很乐观的看待资源不关心这个资源是否有锁而是直接去访问资源至多检查一下当前资源是不是最新的。用伪代码解释一下[1] 悲观锁 while (!lock.tryGet) { // 一直等待获取锁权限// do something会经历等待锁、获取锁、释放锁的过程是比较占用资源的但是确保了资源的并发访问可能出现的问题。lock.releasebreak}[2] 乐观锁:if (checkResourceVersion) { // 检查资源版本是否一致// do something}else {// 过期 更新数据无效}
[4] 案例
在大概了解了悲观锁和乐观锁的概念之后我们看看在实际生产中具体有那些案例和场景使用到了悲观锁和乐观锁以及其对应的一般问题解决方案。
[4.1] 乐观锁案例
一般实现乐观锁的方式 [1] 版本号控制 [2] 时间戳控制
[4.1.1] 乐观锁 - 版本号控制案例
一般会在数据库表增加一个version字段这个字段标识当前数据的版本每次更新操作都会version1流程下图
[1] 过程描述1,start transaction 2,first_version get_cur_version() // 获取当前数据版本3,update_data(version1) // 更新操作版本号14,cur_version get_cur_version() // 提交更新时获取版本号5,if first_version cur_version // 比较提交时的版本号与第一次获取的版本号如果一致那么认为资源是最新的可以更新then commit else rollback or raise exception // 否则回滚或者抛出异常[2] 原理描述最关键的点在于确保每次提交的信息是最新的认为是没有竞争的或者说很少竞争的通过version来标识每一次的数据更新操作当存在并发时同一个数据会又多个用户进行更新操作如果通过乐观锁来实现在多写的情况下会频繁出现异常或者回滚因此一般使用在多读少写的情况以提高系统吞吐量。
[4.1.2] 乐观锁 - 时间戳控制案例
时间戳的方式与版本号实际上原理差不多每次更新数据时会更新该时间戳字段以标识数据的更新情况。[过程描述]1, start transaction2, first_timestamp get_cur_timestamp()3, update_data(timestampget_sys_cur_timestamp)4, if first_timestamp get_cur_timestamp()then commit else rollback or raise Exception[原理]每次更新数据时时间戳会记录更新时间如果出现并发更新会导致AB事务更新提交时读取的不是事务起初读取的时间戳因而导致失败同样适合于多读少写的场景。
[4.2] 悲观锁案例
悲观锁的实现一般都是通过锁机制来实现的锁可以简单理解为资源的访问的入口。如果要对一个具有锁属性的资源执行访问时在更新操作时需要持锁权才能进行操作但是往往这种操作可以保证数据的一致性和完整性。
在数据库中表锁、行锁都是通过悲观锁形式来实现的通过模拟一下mysql的行锁形式来阐述悲观锁的运行机制
事务A事务B当事务A对id1的记录加了for update行锁之后事务B如果想访问id1的记录会出现block因为锁已经被事务A占有了要么事务A操作完成然后执行事务B block的操作要不等待超时。
[5] 场景
我们知道了乐观锁和悲观锁的概念已经一般的使用方式那么我们还需要了解到的是什么时候使用悲观锁,什么时候使用乐观锁?
[5.1] 什么时候使用悲观锁
一旦通过悲观锁锁定一个资源那么其他需要操作该资源的使用方只能等待直到锁被释放好处在于可以减少并发但是当并发量非常大的时候由于锁消耗资源并且可能锁定时间过长容易导致系统性能下降资源消耗严重。因此一般我们可以在并发量不是很大并且出现并发情况导致的异常用户和系统都很难以接受的情况下会选择悲观锁进行。
[5.2] 什么时候使用乐观锁?
乐观锁实际上并没用实际的锁资源操作就如上面概述的版本号和时间戳方式一样使用方都可以操作相应的资源而当第一个使用方提交之后其他使用方提交时会出现异常例如代码版本控制器SVN,GIT其可以增加系统的并发处理能力但是如果并发导致了资源提交冲突其他使用方需要重新读取资源会增加读的次数但是可以面对高并发场景前提是如果出现提交失败用户是可以接受的。因此一般乐观锁只用在高并发、多读少写的场景。 其中GIT,SVN,CVS等代码版本控制管理器就是一个乐观锁使用很好的场景例如A、B程序员同时从SVN服务器上下载了code.html文件当A完成提交后此时B再提交那么会报版本冲突此时需要B进行版本处理合并后再提交到服务器。这其实就是乐观锁的实现全过程。如果此时使用的是悲观锁那么意味者所有程序员都必须一个一个等待操作提交完才能访问文件这是难以接受的。
参考
[1]http://www.javaweb1024.com/java/JavaWebzhongji/2015/09/06/847.html [2]http://blog.csdn.net/sd4015700/article/details/50162965