对常见的加锁场景的归纳，只涉及到了JVM的api锁和redis的分布式锁。其实也可以用zookeeper或者mysql，其他的以后在分享吧，其实最完美的还是老外那套saga状态机 解决分布式事务比较完美，缺点就是难度很大要用到领域驱动的思想，国内普遍用的贫血模型，切换到DDD还是需要些时间研究的，对了也可以用Etcd代替Redis。
A. JVM synchronized 失效的场景
1.多例模式
fe: (@Scope value="prototype",roxyMode = Scop)
为啥synchronized 会失效？
因为synchronized每一次锁的都是同一个对象，但是如果是多例模式，就会变化。
2.事务模式 添加了@Transactional注解
锁释放了，但是事务没提交！ 你在先查询库存的时候，需要开启新的事务。所以必须用其他的service来封装这个逻辑。
把synchronized放在controller层
3.集群模式
B.Redis实现分布式锁
互斥性、可重入、锁超时，放死锁、锁释放正确，防误删 、阻塞和非阻塞 、公平和非公平
高并发 写和读
原子操作
支持分布式部署，节点数据复制和同步
简单版本的分布式锁的缺点：
1.没有实现可重入,
2解决锁超时,
3.超时问题, 死锁 （过期时间）
4.锁释放正确，防误删 （增加uuid防止误删）
5.非阻塞（阻塞几秒）
6.公平和非公平
setnx的指令？ 为啥要用luna代替setnx脚本
1.先get，再判断，后set。 缺点：并发冲突。
解决方式:luna脚本
2.解决uuid值被替换
3.读写锁。公平，实现原子性。
标签：synchronized,Redis,阻塞,误删,构建,公平,分布式 From： https://www.cnblogs.com/andrewlovemeimei/p/17932564.html