Spring自带的分布式锁到底好不好用，你试过没，真能解决并发问题吗

Spring官方文档及社区实践反馈）Spring框架确实提供了一些用于处理分布式锁的组件，Spring本身并没有一个像Redis的Redisson或ZooKeeper那样开箱即用、功能完备的“官方分布式锁”实现，我们通常讨论的“Spring分布式锁”，其实是指Spring Integration模块中的RedisLockRegistry，或者结合Spring Data Redis使用Redis的SETNX命令自己实现的锁。

它好不好用？得分情况看。

对于简单的、并发压力不大的场景，比如防止定时任务在集群环境下重复执行，或者对性能要求不高、允许偶尔失效的业务，RedisLockRegistry这类基于Spring的方案是可以用的，而且用起来挺方便，因为它能和Spring生态无缝集成，配置几行代码就能跑起来，学习成本低。

但如果你指望它应对高并发、高可用的严苛生产环境，它可能就不那么好用了，甚至有点“坑”。

为什么这么说？主要问题出在以下几个方面：

1. 锁的可靠性存疑来源：Redis官方文档关于分布式锁的说明）Spring的RedisLockRegistry在早期版本中，其底层实现存在缺陷，它严重依赖Redis键的过期时间（TTL）来避免死锁，如果获得锁的客户端（比如一个JVM实例）因为垃圾回收（GC）停顿时间过长，或者网络延迟，导致在锁过期之前没有及时续期（也就是所谓的“看门狗”机制），那么锁可能会被提前释放，而原持有者却不知道，这时，另一个客户端就能获取到同一把锁，导致临界区被同时执行，锁就失效了，虽然新版本有所改进，但其可靠性与经过千锤百炼的专业库相比仍有差距。

2. 不具备可重入性来源：Spring官方GitHub Issue讨论）可重入的意思是，同一个线程可以多次获取同一把锁而不会阻塞自己，这在复杂的业务逻辑中非常有用，但RedisLockRegistry在某些版本中默认是不可重入的，这意味着，如果你在一個已经持有锁的方法中，又调用了另一个需要同一把锁的方法，线程就会自己卡死自己，造成死锁，虽然可以通过配置让它支持可重入，但这需要额外注意，而且性能会有损耗。

3. 锁的粒度问题来源：开发者社区实践经验分享）RedisLockRegistry创建的锁，其粒度（Lock Key）是在注册时就固定了的，这意味着你不能很灵活地根据动态参数（比如订单ID）来创建大量不同的锁实例，除非你预注册很多个LockRegistry，这在实际应用中很不方便，相比之下，专业的锁库通常提供更灵活的API，可以直接用字符串作为锁的key。

4. 缺乏高级功能来源：Redisson等第三方库功能列表）像Redisson这样的专业分布式锁库，提供了非常多的高级特性，

   • 公平锁：按照请求的顺序来获取锁，避免某些线程饿死。
   • 联锁（MultiLock）：一次性锁住多个资源。
   • 红锁（RedLock）：基于多个独立Redis节点实现更高可靠性的锁算法。
   • 自动续期：后台线程自动为未执行完的任务延长锁的持有时间，防止因执行时间过长导致锁过期。 而这些，Spring自带的简易锁都是没有的。

它真能解决并发问题吗？

能，但有前提和风险。

它能解决的是“有”和“无”的问题，在并发冲突不激烈、业务逻辑简单、对锁的可靠性要求不是百分百、并且你充分了解其局限性的前提下，用它来快速实现一个基本的互斥访问是可行的，你有一个每小时跑一次的统计任务，在集群中只允许一个实例执行，即使用锁偶尔失效了，顶多也就是重复计算一次，不会造成灾难性后果，这种场景下Spring的锁是够用的。

如果你的场景是“秒杀库存扣减”、“账户余额变更”这种对数据一致性要求极高、一分钱都不能错的场景，那么依赖Spring这个“轻量级”的锁就是非常危险的，一旦锁失效，就会导致超卖、资金错乱等严重问题。

你可以把Spring自带的分布式锁看作是一把“家用普通挂锁”，用它来锁一下家里的工具箱、自行车，防止被顺手牵羊，是没问题的，毕竟方便实惠，但如果你要锁银行金库或者重要的保险箱，那你肯定需要一把结构复杂、经过专业认证、极其可靠的“密码锁”或“指纹锁”，比如Redisson或Curator。

在选择技术方案时,关键是要“对症下药”，不要因为Spring名气大就认为它的所有组件都是万能的，对于分布式锁这种直接影响系统数据一致性的核心组件，务必根据你的业务场景的严苛程度，来选择是使用Spring的简易方案，还是引入更专业、更可靠的第三方库。