synchronized块中调用sleep()不会导致集群死锁，仅引发单jvm内线程饥饿：sleep不释放锁，持锁线程反复抢占致其他线程长期阻塞，表现为响应停滞、吞吐骤降。

在 synchronized 块中调用 sleep() 不会引发“整个微服务集群”的死锁——它根本不会跨 JVM 生效，更不会扩散到其他服务实例。真正发生的是：单个 JVM 内部的线程饥饿与假性死锁，表现为部分线程长期阻塞、响应停滞、吞吐骤降，容易被误判为“集群级死锁”。

sleep() 在 synchronized 块里到底做了什么？

sleep() 只让出 CPU，但绝不释放锁。 这是关键前提。只要线程还持有 synchronized 锁，哪怕它睡上 5 秒、5 分钟，其他线程就只能排队等待，无法进入临界区。

常见错误模式：

JavaStoryDevelop

你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在

下载

• 轮询式检查资源（如队列是否非空），却在 synchronized 块内 sleep(100)
• 业务逻辑中混入耗时 I/O 或模拟延迟，直接写在同步块里
• 把“等待条件成立”错误当成“暂停执行”，用 sleep 替代 wait/notify

为什么看起来像“大面积卡死”？

当多个线程反复争夺同一把锁，而持锁者总在 sleep 后立刻重新抢到锁（synchronized 是非公平锁），就会形成锁垄断现象：

• 线程 A 持锁 → sleep(100) → 醒来 → 立即再次获取锁（概率极高）→ 再 sleep
• 线程 B/C/D 一直在 entry set 中排队，迟迟得不到执行机会
• 监控看到线程状态为 RUNNABLE（不是 WAITING/BLOCKED），但实际业务无进展
• 若该锁保护的是核心共享结构（如本地缓存、计数器、任务队列），整个模块功能就“静默瘫痪”

和集群、分布式完全无关的真相

synchronized 是 JVM 级别锁，只在当前进程内存中生效。三个部署在不同机器上的 Spring Boot 实例，各自有独立的 JVM 和锁空间：

• 实例1 的 synchronized 锁，对实例2、实例3 完全不可见
• 超卖、重复发券等问题，源于多个实例同时操作共享数据库或 Redis，而非 synchronized 失效
• 所谓“集群死锁”是误归因——真实问题是：单机资源争用 + 错误等待机制 + 缺乏跨节点协调

正确替代方案：用 wait() + notify() 或现代工具

需要“等条件满足再继续”，必须释放锁让其他线程有机会修改状态：

• ✅ 用 synchronized + wait()/notifyAll()：wait 会释放锁并进入 WAITING 状态，直到被唤醒
• ✅ 用 Lock + Condition：更灵活的 await()/signal() 组合
• ✅ 用 BlockingQueue（如 LinkedBlockingQueue）：take()、poll(long, TimeUnit) 内置等待逻辑，自动释放锁
• ❌ 永远不要在 synchronized 块里 sleep()，除非你明确知道它只是短暂让出 CPU 且不依赖外部状态变更