jcmd Thread.dump_to_file 不支持 JSON 格式，因 JDK 官方至今未提供该功能，强行使用 --json 等参数会报错；其输出为无结构纯文本，无法可靠解析为 JSON。
为什么 jcmd Thread.dump_to_file 不能直接生成 JSON 格式
jcmd Thread.dump_to_file 输出的是传统 JVM 线程快照（text format），和 jstack 输出完全一致：纯文本、无结构、无嵌套关系、不带时间戳字段或线程状态元信息。它根本**不支持 JSON 输出模式**，JDK 官方至今（JDK 21）也未提供任何内置参数来切换格式。
强行用 -F 或加 --json 类似参数会报错：Unrecognized option: --json。别试了，没这功能。
常见误操作是想靠 shell 管道转 JSON，比如：jcmd —— 这种方式失败率极高，因为原始文本没有统一分隔符、线程名含空格/括号、堆栈行数不定，jq 无法可靠解析。
生产环境真正可行的 JSON 线程转储方案
必须绕过 jcmd Thread.dump_to_file 的文本限制，改用 JVM 内置的 JMX 接口或轻量 agent 方案。推荐以下两种路径：
- 用
jdk.jfr录制线程事件（JDK 8u261+ / JDK 11+），再导出为 JSON：jcmd <pid> VM.unlock_commercial_features<br>jcmd <pid> VM.start_flightrecording name=thread-dump settings=profile duration=1s filename=/tmp/td.jfr<br>jfr print --json /tmp/td.jfr | grep -A 20 "event\": \"jdk.ThreadPark\"" > /tmp/threads.json</pid></pid>
注意：这不是完整线程快照，而是采样事件，适合分析阻塞/等待热点，不适合全量线程状态审计。 - 部署微型 agent（如
async-profiler或自研 JMX client）：它通过ThreadMXBean.dumpAllThreads()获取ThreadInfo[]对象，再用 Jackson/Gson 序列化——这才是真正结构化、含threadName、threadState、lockName、stackTrace数组的 JSON。
如果你已有 Spring Boot Actuator，/actuator/threaddump 默认返回 JSON，且支持 ?full=true 包含锁信息，比手动调 JMX 更省事。
用 JMX 手动获取 JSON 线程转储的关键细节
核心是调用 java.lang:type=Threading MBean 的 dumpAllThreads 操作，但要注意三个易错点：
Node.js 可靠编程技能。避免事件循环阻塞、异步陷阱、ESM 兼容问题和内存泄漏。触发词：Node.js 开发、async/await、流处理、性能优化、安全编码。
- 参数顺序不能错：
boolean lockedMonitors必须为true，否则lockedSynchronizers字段为空；第二个参数boolean lockedSynchronizers也要传true，否则拿不到 ReentrantLock 等信息。 - JDK 版本差异：JDK 8 返回
ThreadInfo数组，字段名是threadName；JDK 17+ 新增isVirtual字段，JSON 序列化器需兼容，否则抛NoSerializerFound。 - 生产环境权限：如果 JVM 启用了
-Dcom.sun.management.jmxremote.authenticate=true，必须提供 valid credentials；未开认证时，本地jmxurl可用service:jmx:rmi:///jndi/rmi://localhost:9999/jmxrmi，但端口得提前在management.properties中配好。
一个最小可用的 curl 示例（假设已启用 JMX 且无密码）：
curl -X POST "http://localhost:8080/actuator/threaddump?full=true" -H "Accept: application/json"
——这是最稳的生产路径。
为什么别在生产上临时跑 Python/Java 脚本做文本转 JSON
看似简单，实则埋雷：
- 文本解析逻辑脆弱：线程名里有
"main@123"、"pool-1-thread-2"、甚至"RMI TCP Connection(17)-10.0.1.5"，正则一写错就漏线程； - 堆栈缩进不统一：有些 JVM 输出用 4 空格，有些用 tab，有些混合，
stackTrace数组字段极易错位； - OOM 风险：把几万行文本读进内存再 parse + build map + serialize，GC 压力陡增，尤其老年代已满时可能触发 full GC；
- 超时不可控：脚本执行慢于 3 秒，可能被监控系统判定为“接口卡死”并自动告警重启。
真正关键的不是“怎么转”，而是“谁来转”：让 JVM 自己吐结构化数据，而不是让外部程序猜文本结构。这点在高负载生产环境里，差一个数量级的稳定性。
