全站假死源于库存扣减时粗粒度分布式锁导致线程池耗尽。锁应仅保护读-判-写库存三步，外部调用须移出锁外；redis锁需设≤3秒超时、启用看门狗，并配隔离线程池与监控告警。
全站假死不是服务器宕机，而是请求全部卡在某个环节，响应时间飙升到几十秒甚至超时。这次事故的根因，是一个看似合理、实则危险的并发锁设计——在全局共享资源上用了同步阻塞锁，且锁粒度粗、持有时间长、未设超时，最终引发线程池耗尽、连接堆积、雪崩式级联失败。
锁不该用在高频、长耗时、跨服务的操作上
出问题的代码是在用户下单时，对“商品库存”做分布式锁校验+扣减。但实际逻辑里混入了调用营销系统查优惠券、调用风控系统做实名核验、写多张业务表——整个过程平均耗时 800ms。锁一加就是 800ms，而 QPS 上千时，大量线程排队等锁，Tomcat 线程池迅速打满。
- 锁只应保护真正需要互斥的最小临界区（比如“读库存→判断是否充足→更新库存”这三行）
- 外部调用、日志记录、消息发送、复杂计算等，必须移出锁作用域
- 如果必须串行化某类操作，优先考虑异步队列 + 幂等消费，而非同步加锁
分布式锁必须带超时，且超时时间要严控
当时用 Redis 实现的 SETNX 锁，设置了 10 秒过期，但没配自动续期（Redisson 的 watch dog），也没在业务代码里做超时兜底。结果某次风控接口偶发延迟 12 秒，锁提前释放，导致后续请求误判库存充足，出现超卖；同时原线程还在执行，又试图释放已失效的锁，引发异常日志刷屏，进一步拖慢 JVM。
- 锁超时时间 = 预估最大业务耗时 × 1.5，上限建议 ≤ 3 秒
- 使用成熟封装（如 Redisson），开启看门狗机制，避免锁被误删
- 业务主流程中加 try-with-resources 或 finally 块，确保锁释放不遗漏
别让一个锁拖垮整个应用线程池
锁等待是同步阻塞，线程挂起不释放，会直接吃掉 Tomcat 的 worker 线程。当 200 个线程全卡在等锁，新请求进来只能排队或拒绝，HTTP 连接堆积，负载均衡器判定实例失活，流量切走，剩余机器压力倍增，最终全站不可用。
- 为锁操作单独划出隔离线程池（如用 Hystrix 或 Resilience4j 配置 fallback 和 timeout）
- 在获取锁前设置最大等待时间（如 Jedis 的 setTimeout），超时立即返回失败，不排队
- 监控锁等待时长、获取成功率、超时次数，阈值告警（例如：等待 > 500ms 或失败率 > 1% 立刻告警）
上线前必须压测锁路径的真实并发表现
测试环境没复现问题，因为单机压测只起了 50 并发，而生产峰值是 1200+。更关键的是，测试没模拟下游依赖（风控、营销）的随机延迟和超时，导致锁持有时间严重低估。
- 压测要包含“最差路径”：下游服务注入 30% 概率 1s 延迟 + 5% 概率超时
- 用 Arthor 或 JMC 抓取锁竞争热点，看 synchronized 或 ReentrantLock 的 Contention Count
- 观察线程堆栈，确认是否有大量线程停在 LOCKED / BLOCKED 状态
一次锁设计失误，暴露的是对并发本质的理解偏差：锁不是万能同步工具，而是性能毒药，要用得极谨慎、极克制、极可观测。不复杂，但容易忽略。
