Java怎么在synchronized块中避免由于FastJson解析引发的死锁

先说一个容易混淆的地方：synchronized块里因为FastJson解析出现的问题，本质上不是死锁（deadlock），而是线程被卡住、无限等待。问题出在FastJson旧版本（1.2.24–1.2.83）的RCE漏洞被恶意JSON触发后，解析器里会执行Thread.sleep(Long.MAX_VALUE)、死循环或者网络等待——线程就这么傻傻地停在parseObject()里，根本没法继续推进。

这不是两个线程互相等着对方释放锁形成的循环等待。你用ThreadMXBean.findDeadlockedThreads()检测，结果是空；jstack里看到的线程状态是RUNNABLE，但堆栈一直停在ASMDeserializer或DefaultJSONParser.parseObject那里不动。

所以问题关键不是“怎么在synchronized里防止死锁”，而是别让FastJson的失控行为污染线程池，同时别把高风险解析放进同步块里放大影响。

✅ 明确禁止AutoType，切断漏洞入口

FastJson的AutoType机制是罪魁祸首。只要关了它，绝大部分恶意反序列化就失效了。

// 应用启动时一次性设置（必须早于任何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 safeParse(String json, Class 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阻塞

发现后者，优先查JSON输入源、升级FastJson、检查setAutoTypeSupport(false)是否生效。不复杂，但容易忽略。