本文详细梳理了Java分布式锁的实现，包括悲观锁和乐观锁。悲观锁通过数据库的`select for update`确保原子性，适合写多读少的场景；乐观锁则在数据写入时检查冲突，适用于读多写少的情况，可通过数据库版本字段或CAS机制实现。文中列举了多个实例来解释如何利用数据库和缓存（如Redis）来实现分布式锁。
前言
以前一直用redis作为分布式锁的实现，也知道zookeeper可以实现，但是对于分布式锁没有系统梳理，忽略了数据库作为分布式锁的重要应用，本文主要梳理分布式锁实现的主要思路：
按照加锁位置，分为在应用层，缓存层，数据库层加锁
按照加锁的类型，分为乐观锁和悲观锁
悲观锁
顾名思义，悲观锁在修改整个过程中保持对修改数据的加锁，一直到修改结束，防止其它线程或者进程对数据修改。
悲观锁适用于写多读少的情况下，技术实现上依赖数据库的锁机制实现，保证最大程度的独占性。
常用select for update，进行加锁，并且取消事务的自动提交，在修改之后其它事务请求才可以修改数据，其间，select from只读操作是可以进行的。
乐观锁
分为三个阶段：数据读取、写入校验、数据写入。
假设数据一般情况下不会造成冲突，只有在数据进行提交更新时，才会正式对数据的冲突与否进行检测，如果发现冲突了，则返回错误信息，让用户决定如何去做。fail-fast机制
乐观锁在适用于读多写少的情况下，常用的实现技术包括
利用数据库锁机制实现
利用数据库实现的核心思想是数据读取，校验，写入放入数据库事务当中进行，如果分开，就存在并发操作问题。
例子1：
假如有个10个线程，每个线程执行10次，每次对sum加1操作（初始值为0&#
最低0.47元/天 解锁文章
2951
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
