补充 at 20191218
很重要!!!
1,锁只能加在key的查找方法上(如:findFirstById),加在其余字段的查找方法上,效果极其怪异。各类参考博文几乎都是根据id索引的方法上加锁,但没人提到过是不是非得这么干。实测,不这么干不行。
2,关于事务。因为锁会涉及事务,我们很多时候并不知道自己要在那行数据上加锁,所以会有select操作,拿到需要加锁的那行数据,再根据id去加锁。但是,事务中是有缓存的,这意味着,其它地方修改后,你get不到修改。比如:你先findFirstByStatus拿到一个ent,然后findFirstById加锁,等你锁返回的时候,如果这期间其余地方修改了这行数据,你是get不到的。其实这个和锁没关系,是事务缓存的范畴。最后,实在没找到终止事务缓存的办法,只能退而求其次–不在事务中二次select了。
前言
如何处理资源访问并发是老生常谈的问题
java中可以用mutex机制,可以用synchronized代码块,但是遇到分布式就GG了。分布式可以用分布式锁。但是,我真没非得上它的必要,我的需求还没到这复杂度。参考了一些分布式锁的原理,真要用的话,我也宁愿自己写一套,基于网络访问+统一的信号量管理,应该没问题的。我的境况决定了,我没有那么多功夫就研究轮子,只能追求小而美的东西, 最主要的是一定要可控,即便出问题,也得在可控的范围内。
因此,数据库锁是一个不错的选择
<