ReentrantLock或synchronized无法作为分布式锁的原因，主要归结于它们的设计初衷和使用范围
- 设计初衷
- ReentrantLock：是Java提供的一个可重入的互斥锁，用于控制多个线程对共享资源的访问。它属于JVM级别的锁，主要用于多线程编程中的同步控制。
- synchronized：是Java语言的一个关键字，用于实现方法或代码块的同步。同样，它也是JVM级别的锁，用于确保同一时刻只有一个线程可以执行某个方法或代码块。
- 使用范围
- JVM级别：ReentrantLock和synchronized都是基于JVM的锁机制，它们的作用范围仅限于单个JVM实例内部。在单个JVM实例中，这些锁可以有效地控制多个线程对共享资源的访问，防止数据竞争和线程安全问题。
- 分布式系统：在分布式系统中，应用通常部署在多台服务器上，每个服务器都运行着自己的JVM实例。因此，跨JVM的资源共享和同步控制成为了一个挑战。由于ReentrantLock和synchronized都是JVM级别的锁，它们无法跨JVM实例进行同步控制，因此在分布式系统中无法直接使用。
- 分布式锁的需求
- 跨JVM同步：分布式锁需要能够在不同的JVM实例之间进行同步控制，确保在分布式环境中对共享资源的访问是安全的。
- 容错性：分布式系统通常要求较高的容错性，即使某个JVM实例崩溃或网络故障，其他JVM实例也应该能够继续正常工作。
- 高性能：分布式系统通常需要处理大量的并发请求，因此分布式锁需要具有高性能和可扩展性。
- 替代方案
由于ReentrantLock和synchronized无法满足分布式锁的需求，因此在分布式系统中通常使用其他机制来实现分布式锁，如：
- 基于数据库的分布式锁：通过在数据库中设置锁表或锁字段，利用数据库的排他锁或乐观锁机制来实现分布式锁。但这种方式通常性能较低，且可能受到数据库单点故障的影响。
- 基于Redis的分布式锁：利用Redis的SETNX（Set if Not Exists）命令或Redisson等客户端库来实现分布式锁。Redis的原子操作和内存性能使得它成为实现分布式锁的理想选择之一。
- 基于Redisson实现的分布式锁。
后两者的使用较为常见。但是使用不同的分布式锁，又会需要考虑不同的风险，对不同的风险予以应对。不同的实现风险及解决方案可见我的另外一篇博客：待补充。