Java锁?分布式锁?乐观锁?行锁?

Posted Java3y

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Java锁?分布式锁?乐观锁?行锁?相关的知识,希望对你有一定的参考价值。

以故事的方式来通俗易懂讲解锁的概念,建议阅读!



Tomcat的锁


Tomcat是这个系统的核心组成部分, 每当有用户请求过来,Tomcat就会从线程池里找个线程来处理,有的执行登录,有的查看购物车,有的下订单,看着属下们尽心尽职地工作,完成人类的请求,Tomcat就很有成就感。 


与此同时,它也很得意,所有的业务逻辑尽在掌握。mysql算啥!不就是一个保存数据的地方吗? Redis算啥!不就是一个加快速度的缓存吗?   


没有他们,我也能找到替代品,而我不可替代的, Tomcat经常这么想。 


昨天MySQL偶然说起隔壁机器入驻了一个叫做Node.js的家伙,居然只用一个线程来执行javascript代码,实现各种业务逻辑,JavaScript也能到后端来?还用回调? 这不是胡闹吗?不过得小心,别被他把业务都给抢走了。  


想到此处,Tomcat立刻去查看各个线程活干得怎么样,有没有人故意偷懒。 


线程0x9527和0x7954又在吵架了,原因非常简单,他们俩都去做扣减库存的操作:读取库存,修改库存,写回数据库。 


线程的并发执行导致三个操作交织在了一起,最后数据出现了不一致。 


Java锁?分布式锁?乐观锁?行锁?


Tomcat说:“你们怎么搞的,为什么要把库存读出来,直接update 库存不行吗? 让MySQL老头儿去保证正确性。要学会甩锅啊!” 


0x7954回答道:“没办法,张大胖的代码就是这么写的,好像是业务要求的,扣减库存之前要检查库存够不够。”  


Tomcat一阵牙疼, 不由得想起了Redis的处理办法, 对于每个读写缓存的请求,Redis都把他们给排成了队,用一个线程挨个去处理,肯定没有这个并发的问题了。  


可是自己这里不行啊,访问数据库是极慢的操作,如果只用一个线程,一个个地处理请求,所有的请求都得等待,人类会急死的。 


没办法,Tomcat扔给他们俩一个Java对象:“这是一把锁,以后谁先抢到谁才能执行扣减库存的三个操作。” 


“如果抢不到怎么办?” 


“阻塞等待,别人释放了锁,JVM自然会唤醒你,然后再去抢! 什么时候抢到,什么时候执行。”


分布式的锁


张大胖觉得有点不对劲, 这几天程序执行怎么有点儿慢了呢?  


他还以为是机器性能不够,就申请了几台新机器,又安装了几个Tomcat,组成了一个集群。 


Java锁?分布式锁?乐观锁?行锁?


这下可好,三个Tomcat, 每个Tomcat都有一把锁来控制对库存的访问。 


在Tomcat这个JVM进程内部,同一个时刻只有一个幸运儿线程可以扣减库存,可是现在有三个Tomcat,出现了三个幸运儿。 


这三个幸运儿在扣减库存的时候,仍然会出现0x7954和0x9527那样的错误,只不过现在他们互不知晓,连吵架的机会都没有了。 


三个Tomcat都觉得头大,在这个分布式的环境中,多个进程在运行,原来那种进程内的锁已经失效,当务之急是找一个客观、公正、独立的第三方来实现锁的功能。 


MySQL提议: “到我这里来找锁啊!”


“你那里能提供一个锁服务? 暴露出来让我们使用? ” Tomcat A问道。


“不不,不是一个锁服务,我给你们一个数据库表,这个表中的字段lock_name有个唯一性约束。”


Java锁?分布式锁?乐观锁?行锁?


“你的意思是,我们的线程每次想获得锁的时候,都去数据库插入一条数据? ”  Tomcat A 反映很快。 


insert into locks(lock_name,...) values('stock',...);


“对啊,我的唯一性约束只能保证一个成功,其他的都失败,就相当于获得锁了。 当然那个线程的操作完成以后,需要释放锁。”


delete from locks where lock_name='stock' 


Java锁?分布式锁?乐观锁?行锁?


这倒是一个简单的办法, 但也是一个重量级的办法:每次获得锁都得访问一次数据库! 


假设来自TomcatA的0x9527捷足先登,插入了一条数据,获得了锁, 那来自Tomcat B的0x7954操作肯定失败,这时候0x7954该怎么办? 能阻塞等待TomcatB来唤醒他吗? 不行,因为连TomcatB 都不知道0x9527什么时候操作完成, 除非MySQL来通知各个Tomcat, 这是肯定不行的。


那0x7954@TomcatB只能做一件事情: 等待一会儿,然后重试! 如此循环下去,直到获得锁为止 


可是如果0x9527获得了锁,在执行的过程中TomcatA 挂掉了,那数据库记录一直存在,无人删除,那锁就永远也无法释放了! 还得弄一个清理者, 清理那些过期没释放的锁, 这实在是太麻烦了。 


Redis


这时候Redis说道:“千万别上MySQL的贼船!他的办法太笨重了,不就是找个第三方来保存锁的信息吗? 用我的缓存多好!” 


“Redis这小子操作的是内存,速度会快很多!” Tomcat B说道。 


 “对,MySQL不是给你们提供了一张表让你们插入数据吗? 我这里不用那么麻烦,你们Tomcat的线程,都可以尝试到我的缓存中设置一个值,比如stock_lock=true, 谁先设置成功,谁就获得了锁,可以去扣减库存。” 


Java锁?分布式锁?乐观锁?行锁?


“ 如果有多个线程去设置,你能保证只有一个成功,别的都失败吗? ” 


 Redis拍拍胸脯: “绝对保证!” 


(码农翻身老刘注:其实就是setnx命令了) 


MySQL撇撇嘴:“和我的方案本质上是一样的。人家Tomcat 的线程对库存做了修改以后,也还得去解锁,去删除这个stock_lock。” 


Redis说:“我这里还能设置过期时间,如果Tomcat A上线程获得了锁,然后Tomcat A挂掉了, 到了过期时间,我就可以自动把这个stock_lock删除,别的线程又可以获得锁了!” 


“嗯,是比MySQL先进,并且速度更快,我们还是用这个锁吧。” 三个Tomcat都表示同意。 


定期自动释放的问题


“且慢,这个自动删除过期的锁有问题啊 !” MySQL突然反击。 


“什么问题?”  Redis没想到数据库老头儿还想负隅顽抗。 


“假设Tomcat A上的0x9527获得了锁, 去执行扣减库存的操作,然后由于某种原因被阻塞了,阻塞的时间超过了过期时间,锁被你释放掉了,最终还是会出现不一致!”


Java锁?分布式锁?乐观锁?行锁?


“你这是吹毛求疵,绝对是小概率事件!” Redis叫道!

“再说了,用你的数据库方案,也得定期清理那些锁,道理是一样的。” 


行锁


第二天, MySQL高兴得去找Tomcat:“兄弟们,我昨天晚上和Quartz(一个著名的定时执行框架)聊了半宿,他告诉了我一个新的用数据库实现分布式锁的办法, 行锁。”


Java锁?分布式锁?乐观锁?行锁?


 “看到没有, 通过添加一个for udpate ,这个SQL语句会把这一行给锁定,就是获得了锁! 只要事务一提交,这个行锁就自动释放了。”  


“那没有获得锁的别的线程呢? ”


自然是阻塞住了,等到别的线程释放了行锁,它可以自动去获取,代码中都不用循环重试,你看,之前的方案都做不到这一点吧。” MySQL说道。 


“那要是有个线程迟迟不释放行锁,会发生什么问题?” Tomcat最关心这个。


“那其他线程都会等待,并且占用着数据库连接不释放,嗯,如果连接被占用得过多,连接池就要出问题了......” MySQL底气不足了,这可是个致命的问题。


“哈哈,看你出的什么馊注意!还是用我的锁吧!” Redis笑道。


“那人家Quartz为什么可以用?”MySQL不死心。


“估计Quartz业务单一,并且锁释放得很快,不会出问题吧。” 


CAS


正在这时,Node.js悄悄地走过来, 把数据库老头儿拉走了:“前辈,别给他们一般见识,不就是扣减库存吗,用啥分布式锁!, 咱们这么做:”  


#old_num = 先获取现有的库存数量 


#new_num = #old_num - 10  


update stock set stock_num = #new_num where product_id=#product_id and stock_num = #old_num


MySQL眼前一亮, 是啊,每次把这个#old_num 作为条件传进去调用update语句,如果能成功,说明在这段时间内没有别的线程更新库存; 


如果不成功,那就重新执行这三条语句,直到成功为止, 就这个么简单, 完全不用锁,真是太爽了。 


过了几天,Tomcat他们也听说了这个方案, 惊讶地说:“这不就是我们Java常用的Compare And Set(CAS)吗?” 


总结


与此同时,张大胖开始做总结:分布式锁和进程内的锁本质上是一样的。 


1.  要互斥,同一时刻只能被一台机器上的一个线程获得。 


2.  最好支持阻塞,然后唤醒,这样那些等待的线程不用循环重试。 


3.  最好可以重入(本文没有涉及,参见《》) 


4.  获得锁和释放锁速度要快 


5.  对于分布式锁,需要找到一个集中的“地方”(数据库,Redis, Zookeeper等)来保存锁,这个地方最好是高可用的。 


6. 考虑到“不可靠的”分布式环境, 分布式锁需要设定过期时间 


7.  CAS的思想很重要。  


往期 精彩回顾





最后

有帮助?好看!转发!

以上是关于Java锁?分布式锁?乐观锁?行锁?的主要内容,如果未能解决你的问题,请参考以下文章

分布式锁

Java中的锁和分布式架构中的锁

乐观锁,悲观锁,表锁,行锁,共享锁,排他锁

Mysql:行锁 表锁 乐观锁 悲观锁 读锁 写锁

对mysql乐观锁悲观锁共享锁排它锁行锁表锁概念的理解

对mysql乐观锁悲观锁共享锁排它锁行锁表锁概念的理解