java本地锁仅限单jvm内生效，分布式锁用于跨进程/机器的并发控制；单机场景用synchronized/reentrantlock性能高、语义清晰；多实例部署必须用redis（高吞吐、ap）、zookeeper或数据库（强一致、cp）等分布式锁方案。
Java 本地锁（如 synchronized、ReentrantLock）只在单 JVM 内生效，而分布式锁要解决的是跨进程、跨机器的并发控制问题。选型不是“哪个更好”，而是“在哪用对”。关键看部署结构和一致性要求。
单机服务场景：本地锁完全够用
当业务逻辑全部运行在同一个 JVM 实例中，且没有水平扩容需求时，本地锁是首选：
- 无网络开销，性能极高（纳秒级加锁）
- 语义清晰、调试简单，JVM 自动管理锁生命周期
- 天然支持可重入、条件等待（
Condition）、公平性等高级特性
例如：订单号生成器（单实例内存缓存递增）、线程安全的本地计数器、定时任务内部状态同步等。
多实例部署场景：必须用分布式锁
一旦应用部署在多个节点（哪怕只是两个 Tomcat 或 Spring Boot 实例），本地锁就彻底失效。此时需外部协调机制：
- 库存扣减：两个实例同时读到“剩余10件”，都执行 -1 → 实际变成 -2
- 重复提交：用户快速点击两次下单，不同节点同时创建订单
- 分布式定时任务：避免多个节点重复执行同一调度（如每天凌晨清理日志）
这类场景下，本地锁不仅无效，还会掩盖并发问题，导致数据错乱。
Java JDK 25
下载
Java JDK 25 来自 OpenJDK 官方归档，版本为 JDK 25，本条下载地址已指向官方 Windows x64 zip 安装包直链，适合调试旧项目或兼容旧版 Java 运行环境。
Redis 分布式锁适合高吞吐、容忍短暂不一致的业务
Redis 因其高性能、低延迟和广泛支持，成为最常用的分布式锁载体，但适用有前提：
- 业务能接受 CAP 中的 AP：Redis 主从异步复制下，极端情况下可能短暂出现双写（如主节点写入后宕机、从节点未同步就被提升为主）
- 锁粒度较粗、持有时间可控（建议 ≤ 30 秒），避免阻塞其他请求
- 推荐使用 Redisson 客户端：自带看门狗自动续期、Lua 脚本保证删除原子性、支持可重入和公平锁
典型例子：秒杀商品预占、优惠券领取、用户操作幂等校验（如“发送短信”去重）。
ZooKeeper 或数据库锁更适合强一致性要求场景
如果业务对“绝不允许两个节点同时写”有硬性要求（如金融核心账务），应优先考虑 CP 系统：
- ZooKeeper：利用临时顺序节点 + Watch 机制，天然满足互斥+自动释放+唤醒通知，但性能较低、运维复杂
- 数据库悲观锁（
SELECT ... FOR UPDATE）：依赖事务隔离级别和索引优化，适合低频、关键路径（如支付最终扣款）
注意：MySQL 分布式锁不适合高并发，仅适用于偶发冲突、QPS
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
