分布式锁未释放会导致后续请求长期阻塞并集中涌入，瞬间创建大量临时对象，引发频繁gc甚至oom；典型原因包括异常跳过unlock、网络抖动误判锁状态、业务超时致锁失效、watchdog未启用等。
分布式锁未释放，会导致后续请求长期阻塞在加锁逻辑上，大量线程卡在等待队列中；一旦锁突然释放或服务重启，这些积压线程会集中涌入业务代码，在短时间内创建大量临时对象（如 DTO、Builder、String 拼接结果、JSON 解析中间结构等），瞬间推高堆内存使用率，触发频繁 GC 甚至 java.lang.OutOfMemoryError: Java heap space。
锁未释放的典型场景
常见原因包括：
- 业务代码抛出未捕获异常，跳过了
unlock()调用（尤其是 try-with-resources 不适用 RedisLock 场景） - 网络抖动或 Redis 超时，客户端误判锁仍有效，但实际服务端锁已过期被其他节点续租或删除
- 锁设置了过期时间（如 30s），但业务执行耗时远超该值，锁自动失效后多个线程同时进入临界区，后续又尝试重复解锁引发异常，导致清理逻辑中断
- 使用 Redisson 的
RLock.lockInterruptibly()但未配合看门狗（watchdog）机制，或手动关闭了自动续期
临时对象爆发的根源
高并发排队线程并非“空等”，而是在锁等待期间持续做前置准备：解析请求体、校验参数、构造缓存 key、组装日志上下文等。一旦锁释放，它们几乎同时执行后续逻辑，例如：
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
- 每个请求都 new 一个
OrderDTO+OrderItemDTO[]+JSONObject+ 多个StringBuilder - 批量接口中，单次请求解析 JSON 数组生成上百个临时对象，100 个排队线程 = 上万个对象在毫秒级内诞生
- 日志框架（如 Logback）在 MDC 中塞入 traceId、userId 等字符串副本，加剧 String 常量池和堆外压力
关键防御措施
核心思路是：防死锁、控并发、减对象、早兜底。
-
强制释放保障：所有加锁必须配对使用
try-finally，且finally中调用unlock()；Redisson 推荐用lock(long leaseTime, TimeUnit unit)并启用 watchdog（默认开启），避免业务慢导致锁提前丢失 -
超时熔断：设置合理的
tryLock(waitTime, leaseTime, TimeUnit)，waitTime 建议 ≤ 500ms；超时直接返回失败或降级，不参与排队 - 对象复用与池化：对高频临时对象（如 JSON 解析器、ByteBuffer、DTO Builder）使用 ThreadLocal 缓存，或接入 Apache Commons Pool / JBoss Pool 管理轻量对象实例
- 异步削峰：将锁保护的强一致性操作（如库存扣减）与非关键路径（如日志记录、消息推送）分离；后者通过 MQ 或 Disruptor 异步处理，避免阻塞主线程并减少同步上下文中的对象创建
快速定位手段
发生溢出时优先检查：
- JVM 启动参数是否包含
-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/path/to/dump.hprof，用 VisualVM / Eclipse MAT 分析 dump，聚焦char[]、String、HashMap$Node、业务 DTO 类的实例数和 shallow heap 占比 - 通过
jstack -l <pid></pid>查看线程栈，搜索await、lockInterruptibly、tryAcquire等关键词，确认是否有大量线程卡在 RedisLock 等待队列 - 监控 Redis 中锁 key 的 TTL 变化（如
redis-cli ttl your_lock_key），对比业务平均耗时，判断是否存在 leaseTime 设置不合理问题
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
