Tomcat的锁
Tomcat是这个系统的核心组成部分， 每当有用户请求过来，Tomcat就会从线程池里找个线程来处理，有的执行登录，有的查看购物车，有的下订单，看着属下们尽心尽职地工作，完成人类的请求，Tomcat就很有成就感。
与此同时，它也很得意，所有的业务逻辑尽在掌握。MySQL算啥！不就是一个保存数据的地方吗？ Redis算啥！不就是一个加快速度的缓存吗？
没有他们，我也能找到替代品，而我不可替代的， Tomcat经常这么想。
昨天MySQL偶然说起隔壁机器入驻了一个叫做Node.js的家伙，居然只用一个线程来执行JavaScript代码，实现各种业务逻辑，JavaScript也能到后端来？还用回调？ 这不是胡闹吗？不过得小心，别被他把业务都给抢走了。
想到此处，Tomcat立刻去查看各个线程活干得怎么样，有没有人故意偷懒。
线程0x9527和0x7954又在吵架了，原因非常简单，他们俩都去做扣减库存的操作：读取库存，修改库存，写回数据库。
线程的并发执行导致三个操作交织在了一起，最后数据出现了不一致。 
Tomcat说：“你们怎么搞的，为什么要把库存读出来，直接update 库存不行吗？ 让MySQL老头儿去保证正确性。要学会甩锅啊！”
0x7954回答道：“没办法，张大胖的代码就是这么写的，好像是业务要求的，扣减库存之前要检查库存够不够。”
Tomcat一阵牙疼， 不由得想起了Redis的处理办法， 对于每个读写缓存的请求，Redis都把他们给排成了队，用一个线程挨个去处理，肯定没有这个并发的问题了。
可是自己这里不行啊，访问数据库是极慢的操作，如果只用一个线程，一个个地处理请求，所有的请求都得等待，人类会急死的。
没办法，Tomcat扔给他们俩一个Java对象：“这是一把锁，以后谁先抢到谁才能执行扣减库存的三个操作。”
“如果抢不到怎么办？”
“阻塞等待，别人释放了锁，JVM自然会唤醒你，然后再去抢！ 什么时候抢到，什么时候执行。”
分布式的锁
张大胖觉得有点不对劲， 这几天程序执行怎么有点儿慢了呢？
他还以为是机器性能不够，就申请了几台新机器，又安装了几个Tomcat，组成了一个集群。 
这下可好，三个Tomcat， 每个Tomcat都有一把锁来控制对库存的访问。
在Tomcat这个JVM进程内部，同一个时刻只有一个幸运儿线程可以扣减库存，可是现在有三个Tomcat，出现了三个幸运儿。
这三个幸运儿在扣减库存的时候，仍然会出现0x7954和0x9527那样的错误，只不过现在他们互不知晓，连吵架的机会都没有了。
三个Tomcat都觉得头大，在这个分布式的环境中，多个进程在运行，原来那种进程内的锁已经失效，当务之急是找一个客观、公正、独立的第三方来实现锁的功能。
MySQL提议： “到我这里来找锁啊！”
“你那里能提供一个锁服务？ 暴露出来让我们使用？ ” Tomcat A问道。
“不不，不是一个锁服务，我给你们一个数据库表，这个表中的字段lock_name有个唯一性约束。”
“你的意思是，我们的线程每次想获得锁的时候，都去数据库插入一条数据？ ” Tomcat A 反映很快。
insert into locks(lock_name,...) values(‘stock‘,...)；
“对啊，我的唯一性约束只能保证一个成功，其他的都失败，就相当于获得锁了。 当然那个线程的操作完成以后，需要释放锁。”
delete from locks where lock_name=‘stock‘ 
这倒是一个简单的办法， 但也是一个重量级的办法：每次获得锁都得访问一次数据库！
假设来自TomcatA的0x9527捷足先登，插入了一条数据，获得了锁， 那来自Tomcat B的0x7954操作肯定失败，这时候0x7954该怎么办？ 能阻塞等待TomcatB来唤醒他吗？ 不行，因为连TomcatB 都不知道0x9527什么时候操作完成， 除非MySQL来通知各个Tomcat， 这是肯定不行的。
那[email protected]只能做一件事情：等待一会儿，然后重试！ 如此循环下去，直到获得锁为止。
可是如果0x9527获得了锁，在执行的过程中TomcatA 挂掉了，那数据库记录一直存在，无人删除，那锁就永远也无法释放了！ 还得弄一个清理者， 清理那些过期没释放的锁， 这实在是太麻烦了。
Redis
这时候Redis说道：“千万别上MySQL的贼船！他的办法太笨重了，不就是找个第三方来保存锁的信息吗？ 用我的缓存多好！”
“Redis这小子操作的是内存，速度会快很多！” Tomcat B说道。
“对，MySQL不是给你们提供了一张表让你们插入数据吗？ 我这里不用那么麻烦，你们Tomcat的线程，都可以尝试到我的缓存中设置一个值，比如stock_lock=true， 谁先设置成功，谁就获得了锁，可以去扣减库存。” 
“ 如果有多个线程去设置，你能保证只有一个成功，别的都失败吗？ ”
Redis拍拍胸脯： “绝对保证！”
（码农翻身老刘注：其实就是setnx命令了）
MySQL撇撇嘴：“和我的方案本质上是一样的。人家Tomcat 的线程对库存做了修改以后，也还得去解锁，去删除这个stock_lock。”
Redis说：“我这里还能设置过期时间，如果Tomcat A上线程获得了锁，然后Tomcat A挂掉了， 到了过期时间，我就可以自动把这个stock_lock删除，别的线程又可以获得锁了！”
“嗯，是比MySQL先进，并且速度更快，我们还是用这个锁吧。” 三个Tomcat都表示同意。
定期自动释放的问题
“且慢，这个自动删除过期的锁有问题啊 ！” MySQL突然反击。
“什么问题？” Redis没想到数据库老头儿还想负隅顽抗。
“假设Tomcat A上的0x9527获得了锁， 去执行扣减库存的操作，然后由于某种原因被阻塞了，阻塞的时间超过了过期时间，锁被你释放掉了，最终还是会出现不一致！”
“你这是吹毛求疵，绝对是小概率事件！” Redis叫道！
“再说了，用你的数据库方案，也得定期清理那些锁，道理是一样的。”
行锁
第二天， MySQL高兴得去找Tomcat：“兄弟们，我昨天晚上和Quartz（一个著名的定时执行框架）聊了半宿，他告诉了我一个新的用数据库实现分布式锁的办法， 行锁。”
“看到没有， 通过添加一个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的思想很重要。
原文地址：https://blog.51cto.com/14295088/2383289