如何排查将超长字符串在未做边界强转校验下反序列化导致的死锁-java教程-PHP中文网

超长字符串反序列化不会导致死锁，实际可能引发NumberFormatException、StackOverflowError或OutOfMemoryError；应通过jstack验证真死锁，再排查数值校验缺失、深层嵌套或循环引用等问题。

这个问题存在关键概念混淆：超长字符串反序列化不会导致死锁，它可能引发 numberformatexception、stackoverflowerror 或 outofmemoryerror，但不满足死锁的四个必要条件（互斥、占有并等待、不可剥夺、循环等待）。所谓“死锁”现象，大概率是误判——实际是线程卡在长时间计算、栈溢出或 gc 阻塞中，表现为“假死”。

先确认是不是真死锁

运行以下命令快速验证：

jps -l 找到目标 Java 进程 PID
jstack -l <pid> | grep -A 10 "Found 1 deadlock"</pid>

若无输出，说明没有 JVM 层死锁。此时应转向排查：反序列化异常、栈深度失控、内存耗尽或线程池阻塞，而非锁竞争问题。

检查反序列化入口是否缺失数值校验

重点扫描 JSON 解析、DTO 构造、自定义反序列化器等位置：

是否在 @JsonCreator 或 readObject() 中直接调用 Long.parseLong(str)、Integer.valueOf(str) 等，且未校验字符串长度或数值范围？
Jackson/Gson 是否启用了宽松模式（如 DeserializationFeature.ACCEPT_SINGLE_VALUE_AS_ARRAY）却忽略数字溢出策略？
是否将类似 "9223372036854775808"（超过 Long.MAX_VALUE）的字符串硬编码进配置或测试数据，触发解析失败？

排查深层嵌套或隐式循环引用

超长字符串常伴随深层对象图，容易引发递归假死：

检查 DTO 是否存在双向引用（如 User ↔ Department），且序列化器未启用引用跟踪（如 Jackson 的 ReferenceLoopHandling.IGNORE）
确认反序列化器是否设置了深度限制：
– Jackson：new JsonSerializerSettings { MaxDepth = 32 }
– System.Text.Json（Java 生态对应为 Jackson 或 Gson）：虽无原生 MaxDepth，但可通过自定义 JsonDeserializer 在解析前校验嵌套层级
用 jstack 抓取线程快照，观察调用栈是否出现数十层重复的 parseLong、convertValue 或 startObject —— 这是栈溢出或无限递归的典型信号