分布式锁是Java后端面试的高频考点也是微服务架构中解决跨节点并发控制的核心组件。在分布式系统中多个服务实例可能同时操作共享资源若缺乏有效的互斥机制就会出现库存超卖、重复下单等数据一致性问题。本文从Java面试实战视角出发对比五种主流分布式锁实现方案帮助你快速建立选型判断力。方案一基于数据库唯一索引这是最直观的实现方式。创建一张锁表对lock_key字段加唯一索引。加锁时执行INSERT操作插入成功即获取锁插入失败则说明锁已被占用解锁时删除对应记录即可。基于数据库行锁的SELECT FOR UPDATE也可以实现互斥但性能瓶颈更为明显。该方案实现简单无需引入额外中间件适合并发量极低的内部管理系统。但数据库操作涉及磁盘I/O高并发下性能急剧下降且锁表本身也会成为单点瓶颈生产环境中较少采用。方案二基于Redis原生SET NX利用Redis单线程模型的原子性通过SET key value NX PX milliseconds一条命令完成加锁和过期时间设置避免死锁。解锁时必须使用Lua脚本先校验value是否为当前客户端的唯一标识一致才删除防止误释放他人持有的锁。Redis方案性能极高纯内存操作下QPS可达5万以上是三种主流方案中性能最好的。但Redis基于AP模型主从切换时存在锁丢失风险无法保证强一致性。方案三基于RedissonRedis工业级封装原生SET NX需要开发者自行处理续期、可重入、锁竞争等问题Redisson作为Redis分布式锁的业界标准实现封装了完整的工业级能力。其核心创新是看门狗机制当调用lock()未指定租约时间时Redisson为锁设置默认30秒有效期并启动后台定时任务每隔10秒超时时间的1/3通过Lua脚本检查锁状态并续期。只要业务线程仍在运行锁就不会提前过期线程异常终止时续期停止锁到期自动释放避免死锁。Redisson还实现了可重入锁基于Hash结构记录客户端标识和重入次数、公平锁、读写锁等丰富语义是绝大多数互联网业务场景的首选方案。方案四基于ZooKeeper临时顺序节点ZooKeeper是CP系统通过临时顺序节点实现分布式锁。客户端在指定目录下创建临时顺序节点序号最小者获得锁其他客户端监听前一个节点的删除事件实现事件驱动的等待唤醒避免了“惊群效应”。客户端会话断开时临时节点自动删除天然具备防死锁能力。ZooKeeper的强一致性保证了锁的可靠性适用于金融核心系统等对正确性要求极高的场景。但每次锁操作涉及多个节点间的ZAB协议同步性能低于Redis且需要维护独立的ZK集群部署和运维成本较高。方案五基于etcd租约与事务etcd作为云原生场景的协调服务通过Lease租约和Txn事务实现分布式锁。客户端申请租约后利用事务的IF-Then-Else判断锁key的创建版本号是否为0条件成立则写入key并绑定租约同时通过KeepAlive机制自动续租租约到期后key自动删除。etcd在Kubernetes生态中广泛使用适合云原生环境的服务发现与锁需求但Java生态的客户端成熟度不如Curator和Redisson。五种方案对比与选型建议维度数据库Redis原生RedissonZooKeeperetcd性能低~1000 QPS高5万 QPS高同Redis中~5000 QPS中高一致性强单库AP可能丢锁AP可能丢锁CP强一致CP强一致实现复杂度低中需Lua低封装完善高需ZK集群中适用场景低并发内部系统轻量高并发互联网业务首选金融级强一致云原生环境选型核心原则绝大多数互联网业务首选Redisson它以Redis的极致性能为基础通过看门狗机制解决了锁续期的核心痛点API友好且功能完备。对一致性要求极高的场景选择ZooKeeper或etcd以性能换取正确性。数据库方案仅在极低并发或无法引入新组件时作为兜底选择。面试中如果能点出“Redis的AP模型与ZK的CP模型在分布式锁场景下的本质差异”往往会成为加分项。