FastJson旧版本RCE漏洞导致线程在synchronized块中长期RUNNABLE阻塞，并非死锁；应禁用AutoType、避免同步块内解析、加超时隔离。
这个问题本身存在概念混淆——synchronized块中不会因FastJson解析引发“死锁”（deadlock），真正发生的是线程阻塞或无限等待，根源是FastJson旧版本（1.2.24–1.2.83）的RCE漏洞被恶意JSON触发，导致线程卡在parseObject()里执行Thread.sleep(Long.MAX_VALUE)、死循环或网络等待等逻辑。
它不是两个线程互相持有对方需要的锁形成的循环等待，JVM用ThreadMXBean.findDeadlockedThreads()查不到结果，jstack里看到的是单个线程长期处于RUNNABLE状态但实际不推进，堆栈停在ASMDeserializer或DefaultJSONParser.parseObject。
所以，重点不是“在synchronized里怎么防死锁”，而是：别让FastJson解析失控行为污染线程池 + 避免把高风险解析放进同步块内放大影响。
✅ 明确禁止AutoType，切断漏洞入口
FastJson的AutoType机制是罪魁祸首。只要关闭它，绝大多数恶意反序列化就失效。
立即学习“Java免费学习笔记（深入）”；
// 应用启动时一次性设置（必须早于任何JSON.parse调用） JSON.DEFAULT_PARSER_CONFIG.setAutoTypeSupport(false);
⚠️ 注意：
-
setAutoTypeSupport(false)是静态全局配置，对所有线程生效； - 如果用的是 FastJson 2.x，改用 builder 方式：
ParserConfig config = ParserConfig.builder().autoTypeSupport(false).build(); JSON.parse(json, Target.class, config);
✅ 不在synchronized块内做JSON解析
把耗时、不可控、有安全风险的操作（如外部输入的JSON解析）放进synchronized块，等于把整个临界区拖进泥潭：
- 一旦解析卡住，持有锁的线程无法释放，其他线程全被堵死；
- 表象就像“死锁”，其实是锁被长期霸占。
正确做法：先解析，再加锁处理结果。
// ❌ 危险：解析和业务逻辑混在同一同步块
synchronized (lock) {
Data data = JSON.parseObject(json, Data.class); // 若这里卡住，lock永远不放
updateCache(data);
}
// ✅ 安全：解析放开，只锁真正需要互斥的业务逻辑
Data data = JSON.parseObject(json, Data.class); // 独立执行，失败/阻塞不影响锁
synchronized (lock) {
updateCache(data); // 纯内存操作，快且可控
}✅ 给JSON解析加超时与隔离保护
即使关闭AutoType，也不能完全排除某些极端构造导致解析器内部卡顿（如超深嵌套、超长字符串）。建议封装一层带超时的解析：
public static <T> T safeParse(String json, Class<T> clazz) {
ExecutorService parserPool = Executors.newSingleThreadExecutor();
try {
return parserPool.invokeAny(
Collections.singletonList(() -> JSON.parseObject(json, clazz)),
3, TimeUnit.SECONDS
);
} catch (Exception e) {
throw new IllegalArgumentException("JSON解析超时或失败", e);
} finally {
parserPool.shutdownNow();
}
}这样即使FastJson某次异常卡死，也只影响当前任务，不会拖垮整个线程池或同步块。
✅ 补充：排查时快速识别真死锁 vs FastJson阻塞
| 特征 | synchronized死锁 | FastJson引发的阻塞 |
|---|---|---|
jstack是否显示Found 1 deadlock
|
是 | 否 |
| 卡住的线程状态 | BLOCKED（明确等待某把锁） | RUNNABLE（但堆栈停在fastjson内部） |
是否能用ThreadMXBean.findDeadlockedThreads()检测到 |
能 | 不能 |
| 是否涉及多个锁对象循环等待 | 是 | 否（通常单线程卡死） |
发现后者，优先查JSON输入源、升级FastJson、检查setAutoTypeSupport(false)是否生效。
不复杂但容易忽略
