简介：TDA-Thread Dump Analyzer 2.3.3 是面向 Java 开发与运维人员的线程分析工具，用于在应用响应缓慢、卡顿或无响应时解析线程 Dump，辅助定位线程阻塞、死锁、锁竞争及高耗时线程等并发问题。压缩包共 3 个文件，约 1.3MB，包含 Windows 与 Linux 启动脚本及核心 jar 程序，类型简洁，便于在常见桌面环境中使用。已有 1334 人学习，说明其在 Java 性能诊断场景中具有一定关注度。工具支持线程状态可视化、死锁链路标记、线程耗时统计、锁争用识别、线程活动度观察、堆栈深度比较，以及按条件过滤搜索和导出分析报告，可将复杂堆栈整理为较直观的视图。对于需要理解多线程运行状态、梳理故障线索并留存分析记录的开发者，具有较好的参考与实用价值。
1. 线上卡住但 CPU 只有 3%：一份 txt 才是唯一现场
凌晨两点接口全挂，登上机器一看 CPU 只有 3%，日志停在半小时前一动不动。重启能好，但现场没了，第二天复盘只剩一句「可能卡住了」。这种「CPU 不高、日志不写、接口没响应」的场面，多半是线程层面堵住了：死锁，或者所有请求都压在同一个锁、同一个连接池上。能救命的只有一份线程转储（Thread Dump），而 jstack 打出来的 txt 几百上千行平铺着，谁看谁懵。TDA（Thread Dump Analyzer）就是拆这份 txt 的：按状态归类线程、把锁的持有和等待关系串成链、死锁直接标出来。tda-bin-2.3.3.zip 是绿色包，解压加一个 Java 就能跑。适合替人排查线上卡顿的后端和运维，也适合想搞明白锁到底堵在哪的人。
2. 拆开 tda-bin-2.3.3.zip：目录、Java 版本与三种起法
拿到一个 bin 包，最忌讳的动作是双击。绿色 Java 工具的解压路径、JDK 版本、启动脚本里的 JVM 参数，这三样任何一个不对，表现都是「双击没反应」，然后你以为包坏了。先把结构看清楚。
2.1 先 unzip -l 看一眼再解压
压缩包不解压也能列目录，这一步能省掉很多来回：
# 只看目录，不解压 unzip -l tda-bin-2.3.3.zip # 确认结构后解到固定位置，路径别带空格和中文 sudo mkdir -p /opt/tda sudo unzip -q tda-bin-2.3.3.zip -d /opt/tda ls -lh /opt/tda-l只列表不落盘，-q静默解压，-d指定目标目录。解开后一般能看到三类东西：主程序 jar、一到两个启动脚本（tda.sh/tda.bat这种）、以及存放第三方依赖的lib目录。启动脚本本身没什么魔法，cat tda.sh看一遍就知道它最后拼的是一条java -jar，所以后面所有关于内存、编码、JDK 路径的调整，本质上都是在改这条命令。
提示：解压路径不要带空格、中文、括号。Java 工具读
-jar路径时对空格的处理一直不太稳，出问题时的报错还特别含糊，与其事后排查不如一开始就放到/opt或~/tools下面。
2.2 Java 版本对不上，是第一个跟头
TDA 2.x 系列一般跑在 JDK 8 及以上，但「装没装 Java」和「装的是哪个 Java」是两件事。机器上同时有 JDK 8 和 JDK 17 很常见，java -version打出来的那个未必是你想用的那个：
# 看当前默认 java -version 2>&1 # 看机器上到底有几个 ls -d /usr/lib/jvm/* 2>/dev/null update-alternatives --list java 2>/dev/null # 指定某个 JDK 启动，避免默认版本干扰 /usr/lib/jvm/java-8-openjdk/bin/java -jar /opt/tda/tda.jar如果版本不对，最常见的报错是UnsupportedClassVersionError后面跟一串class file version 52.0 / 55.0之类的数字，意思是这个 class 是用更高版本的 JDK 编译的，你当前的运行时太老。反过来，用很新的 JDK 跑老工具，有时会遇到模块系统相关的警告甚至反射失败，表现是界面弹不出来或者打开文件时抛异常。血泪经验是：先找到能跑起来的那个 JDK，再把它写死到启动脚本里，别依赖 PATH 里的默认值，因为服务器上的 PATH 经常被人改过。
内存也要在这里定好。dump 文件动辄几十上百 MB，解析时全在堆里展开，默认堆不够会直接 OOM：
# 直接给足堆再启动，2g 对大多数几百 MB 以内的 dump 够用 java -Xmx2g -jar /opt/tda/tda.jar # 或者不改脚本，用环境变量传给启动脚本 export JAVA_OPTS="-Xmx2g" bash /opt/tda/tda.sh-Xmx2g是最大堆，JAVA_OPTS能不能生效取决于启动脚本里有没有引用它——所以还是那句，cat一下脚本最稳妥，没引用就自己加。
2.3 三种起法，按场景选
第一种，图形界面本地看：把 dump 文件拉到自己的开发机上，bash tda.sh起界面，File → Open Log File选文件。这是最常用的方式，因为分析是交互式的，要不停点线程、看堆栈、跳监视器，远程桌面里点会很卡。
第二种，直接java -jar起，适合脚本里带参数、或者你想顺手加-Dfile.encoding之类的系统属性。这一种最可控，出问题也最容易复现。
第三种，命令行批处理。很多版本带了非 GUI 的参数，比如直接指定输入文件、指定输出报告：
# 先看这个版本支持哪些参数，别照抄网上的老教程 java -jar /opt/tda/tda.jar -help # 常见形式：指定输入、输出到 html，具体开关以 -help 为准 java -Xmx2g -jar /opt/tda/tda.jar -l /tmp/dump.txt -o /tmp/report.html这里之所以让你先跑-help，是因为不同小版本的命令行开关改动过，照抄别人的命令很可能报Unknown option。-l一般是 load 日志文件，-o是输出，输出格式还要看有没有对应的类型参数。跑通一次之后，这条命令就能塞进定时任务，把每天巡检抓的 dump 直接转成 html 存档，不用每次人工点。
2.4 打开就先改两个地方
界面起来之后别急着加载文件，先去Edit → Preferences（或菜单里同义的那一项）看两处设置。一是字符编码，默认多半是平台编码或者 UTF-8，如果你的 dump 是在 GBK 环境里抓的，这里不改，加载完全是乱码，堆栈里的中文类名、线程名全都读不出来。二是堆栈折叠和显示行数，线程多的时候把「相同堆栈合并显示」打开，几百个线程池线程会折成一行带计数的形式，视野立刻清爽。
这两项改完是持久的，下次启动还在。很多人第一次用觉得 TDA「看不清」，其实是默认视图把所有线程平铺了，没做折叠。
3. 抓一份 TDA 认得的转储：jstack 参数、5 秒间隔采样与编码兼容
工具再好，喂进去的文件不对也白搭。线程转储的坑集中在三处：参数漏了、只抓了一次、编码和换行在传输里被搞坏。
3.1 jstack 的参数，-l 不能省
先把进程找出来：
# 列出当前用户的 java 进程及主类 jps -l # 找不到就用 ps，注意容器里 jps 可能看不到宿主机进程 ps -ef | grep [j]ava然后抓：
# -l 打印额外的锁信息，包括 ownable synchronizers，必须带 jstack -l 12345 > /tmp/dump-01.txt # 进程完全无响应、普通 jstack 卡住时才用 -F 强制 jstack -F -l 12345 > /tmp/dump-force.txt # 需要看 native 帧时加 -m，输出会变长很多 jstack -m -l 12345 > /tmp/dump-mixed.txt-l是关键。不带它，输出里就没有Locked ownable synchronizers那一段，ReentrantLock、线程池 Worker 这类基于 AQS 的锁关系全部丢失，TDA 的监视器视图会变成一片空白，你会误判成「没有锁竞争」。-F是强制模式，它通过信号强行挂起进程再取栈，副作用是可能拿不到完整的锁信息，而且对进程有短暂影响，非必要不用。-m会把 C/C++ 帧也打出来，排查 JNI 或者 native 库卡死时才需要，平时用不上，加了只会让文件大一倍。
新版本 JDK 里jstack和jcmd是等价的，后者写法是：
jcmd 12345 Thread.print -l > /tmp/dump-01.txtjcmd的好处是同一个入口能干很多事，jcmd <pid> help列出所有可用的诊断命令，VM.flags、GC.heap_info 都能顺手拿。
3.2 只抓一次等于没抓：5 秒间隔采三次
单份 dump 是静态快照，你看到某个线程 BLOCKED，但它可能只是碰巧路过。真正的判断依据是同一个线程在不同快照里是否一直卡在同一个位置。所以标准动作是连抓三次：
#!/usr/bin/env bash # 用法: ./grab.sh <pid> [次数] [间隔秒] [输出目录] set -euo pipefail PID=${1:?用法: $0 <pid> [次数] [间隔秒] [输出目录]} COUNT=${2:-3} INTERVAL=${3:-5} OUTDIR=${4:-/tmp/tdumps} mkdir -p "$OUTDIR" for i in $(seq 1 "$COUNT"); do TS=$(date +%Y%m%d-%H%M%S) OUT="$OUTDIR/dump-$TS.txt" # 2> 单独收错误，避免 jstack 的报错混进 dump 导致解析失败 if jstack -l "$PID" > "$OUT" 2> "$OUT.err"; then echo "[$i/$COUNT] $OUT $(wc -l < "$OUT") 行" else echo "[$i/$COUNT] 抓取失败，见 $OUT.err" >&2 fi [ "$i" -lt "$COUNT" ] && sleep "$INTERVAL" done${1:?}是必填参数校验，没传 pid 直接报用法退出；COUNT默认 3 次，INTERVAL默认 5 秒，这个间隔足够让一轮请求跑完，又能保证三次之间业务状态有变化可对比。2>把标准错误单独落文件这一手很重要——jstack失败时会把Unable to open socket file之类的错误打到 stdout，混进 dump 里会让解析器在第一个线程块就崩掉。
如果进程是那种彻底僵住的，jstack可能十几秒都不返回，那就退回最原始的办法：
# 给 JVM 发 SIGQUIT，它会把自己的线程栈打到标准输出 kill -3 12345 # 输出一般落在应用的重定向文件里 tail -n 2000 nohup.outkill -3不终止进程，只是让 JVM 打一份栈。缺点是输出混在业务日志里，得靠时间戳和Full thread dump这个标记去截取。容器化之后更麻烦：如果容器里是精简的 JRE 镜像，压根没有jstack这个可执行文件，只能靠kill -3，或者进容器前先确认which jstack。
3.3 编码和换行：文件在传输里坏掉的最多
dump 里有中文线程名、中文类名时，编码不对就是满屏问号。先确认文件本身是什么编码：
file -i /tmp/dump-01.txt # 如果是 GBK 而工具按 UTF-8 读，先转一遍再加载 iconv -f GBK -t UTF-8 /tmp/dump-01.txt > /tmp/dump-01-utf8.txt还有一种隐蔽的坏法：文件从 Linux 拷到 Windows 再拷回来，换行符变成 CRLF，某些解析器按\n切块时会残留\r，表现为线程名末尾多个不可见字符，或者状态行匹配不上。这种用dos2unix处理掉就行，不用深究。
4. 在 TDA 里读 dump：线程树、监视器与死锁链的对照读法
文件加载成功后，界面信息量很大，容易一上来就扎进线程列表里逐条看，看十分钟什么也没得到。有个固定顺序：统计 → 监视器 → 死锁 → 具体线程。
4.1 统计页先给你三个数
加载完先看总览：线程总数、各状态分布、检测到的死锁数。这三个数决定后面怎么读。
线程总数暴涨到几千，基本就是线程池没设上限，或者某个地方在循环里new Thread；总数正常但 BLOCKED 占比很高，说明有热点锁；总数正常、大部分是 WAITING 或 TIMED_WAITING，那多半不是线程问题，而是下游依赖（数据库连接、HTTP 调用）在拖，线程都挂在等待上。
这里要分清三个状态的实际含义，很多人栽在这上面：
| 状态 | 含义 | 常见位置 |
|---|---|---|
| RUNNABLE | 正在跑或等在系统调用 | 计算密集、IO 未返回 |
| BLOCKED | 等进入 synchronized 临界区 | 锁竞争、锁粒度太粗 |
| WAITING | 无限期等待被唤醒 | Object.wait()、park()、join() |
| TIMED_WAITING | 限时等待 | sleep()、带超时的poll() |
BLOCKED 才是真正的「抢锁没抢到」，WAITING 大部分时候是正常现象——线程池里的空闲线程全是 WAITING，你把它们当成故障就闹笑话了。判断标准是它们等的东西是不是同一个。
4.2 监视器视图：从「谁持有」倒推代码
监视器（Monitors）视图按锁对象聚合，列出每个锁被哪些线程持有、哪些线程在等。这是整套工具里最值钱的一块。
看一份典型的 jstack 片段就明白它在解析什么：
"http-nio-8080-exec-23" #123 daemon prio=5 os_prio=0 tid=0x00007f... nid=0x7a2c waiting for monitor entry java.lang.Thread.State: BLOCKED (on object monitor) at com.example.order.OrderService.calc(OrderService.java:88) - waiting to lock <0x000000076ab0d8e8> (a com.example.order.OrderService) - locked <0x000000076ab0e120> (a java.lang.Object) "http-nio-8080-exec-7" #107 daemon prio=5 os_prio=0 tid=0x00007f... nid=0x3f10 runnable java.lang.Thread.State: RUNNABLE at com.example.order.OrderService.calc(OrderService.java:95) - locked <0x000000076ab0d8e8> (a com.example.order.OrderService)waiting to lock <地址>表示在等这个对象；locked <地址>表示已经持有。上面这段的意思很清楚：一堆exec线程在OrderService.java:88等同一把锁，而持有者是exec-7，它正卡在OrderService.java:95没出来。问题的落点于是很明确——第 95 行那一句，可能是慢 SQL、可能是远程调用、也可能是个大循环。
TDA 把这个关系画成树之后，你不需要自己比对地址，点开那个锁对象就能看到「持有者 1 个、等待者 47 个」，再点持有者直接跳到它的堆栈。内存地址是 16 进制数，肉眼比对很容易看错一位，这也是为什么要用工具。
注意：
waiting to lock针对的是 synchronized，parking to wait for针对的是 Lock/AQS。两者在监视器视图里的呈现方式不同，别混着看。前者一定是 BLOCKED 状态，后者通常还是 WAITING。
4.3 死锁页：链是怎么串起来的
死锁是环，A 等 B、B 等 A，JVM 自己在抓 dump 的时候其实已经检测过一轮，输出里会带一段：
Found one Java-level deadlock: ============================= "thread-A": waiting to lock monitor 0x00007f... (object 0x000000076ab0d8e8, a java.lang.Object), which is held by "thread-B" "thread-B": waiting to lock monitor 0x00007f... (object 0x000000076ab0e120, a java.lang.Object), which is held by "thread-A"TDA 的死锁页就是解析这段再加上自己的交叉分析。看到环之后，真正要做的不是「哦死锁了」，而是找出为什么两个线程会以相反顺序拿这两把锁。绝大多数代码级死锁都是加锁顺序不一致导致的：一个方法先锁订单再锁库存，另一个方法先锁库存再锁订单，平时并发低碰不上，一到大促流量上来必炸。
还有一种更常见、但死锁页里看不到的情况：不是环，而是一条特别长的等待链——几百个线程等一把锁，持有者自己在等数据库。这在死锁检测里不算死锁，因为没成环，但它造成的后果比死锁还严重，因为线程全耗在那儿了。这类问题只能在监视器视图里看出来，死锁页是空的，别因此就认为「没有问题」。
4.4 线程池线程的读法：名字就是线索
pool-1-thread-1到pool-1-thread-200全部卡在同一个方法，这种场面在线程池配置不当的系统里天天见。这里有两个判断维度：卡在同一个方法说明是同一个瓶颈；线程数顶到了池上限说明队列已经排满，上游开始超时。
如果项目里给线程池起了名字（ThreadFactory里设个有业务含义的前缀），在 TDA 的线程树里可以直接按名字过滤，一眼看出是哪个池子出的问题。这也是个反向建议：排查完之后回去把线程池名字补上，下次能省半小时。
线程栈本身是文本，工具做的是聚合和跳转，有时候脚本做二次统计比点界面更快：
import re, sys from collections import Counter HEAD = re.compile(r'^"(?P<name>[^"]+)"') STATE = re.compile(r'java\.lang\.Thread\.State:\s*(?P<s>[A-Z_]+)') def parse(path): threads, cur = [], None with open(path, encoding='utf-8', errors='replace') as f: for line in f: m = HEAD.match(line) # 只有带 nid/tid 的引号行才是线程头，避免误匹配堆栈里的字符串 if m and ('nid=' in line or 'tid=' in line): cur = {'name': m.group('name'), 'state': 'UNKNOWN', 'top': None} threads.append(cur) continue if cur is None: continue sm = STATE.search(line) if sm: cur['state'] = sm.group('s') continue if cur['top'] is None: s = line.strip() if s.startswith('at '): # 第一条 at 就是栈顶 cur['top'] = s[3:].split('(')[0] return threads if __name__ == '__main__': ts = parse(sys.argv[1]) print('线程总数:', len(ts)) print('状态分布:', Counter(t['state'] for t in ts).most_common()) print('栈顶方法 TOP10:') for k, v in Counter(t['top'] for t in ts if t['top']).most_common(10): print(f' {v:5d} {k}')errors='replace'保证遇到编码坏字节不中断；线程头判定加了nid=/tid=条件，否则堆栈里以引号开头的字符串会被当成新线程；栈顶取第一条at行，因为 Java 栈是从内到外打印的。跑出来的「栈顶方法 TOP10」往往比界面更快告诉你瓶颈函数——如果某个方法占了 80% 的线程栈顶，不用再往下看了。
5. 避坑与排查：TDA 打不开、乱码、看不出锁的五种现场
5.1 启动与显示类：看着像工具坏了，其实是环境的事
现象一：双击或者bash tda.sh之后毫无反应，连窗口都不闪。
原因通常是三种：默认java不在 PATH 里、JDK 版本高于工具能接受的范围、或者在没有图形界面的服务器上启动了带 GUI 的版本。第三种最常见——SSH 上去敲命令，脚本执行完就退出了，也不报错。
解决办法是先看退出码和错误输出：
bash -x /opt/tda/tda.sh 2>&1 | tail -n 30 echo "exit=$?"-x会把脚本每一行展开打印，能直接看到它最终拼的是哪条java命令。确认是图形环境问题，就老老实实把 dump 拉回本地看，或者改用命令行导出报告的方式。
现象二：能打开，但线程名、类名里全是问号或者方块。
原因是 dump 文件的实际编码和工具读取时用的编码不一致。GBK 环境下抓的 dump 被按 UTF-8 解析，中文就成了乱码；反过来，UTF-8 文件被按 GBK 读也一样。
解决办法分两步：先用file -i确认文件的真实编码，再用iconv转成 UTF-8；如果转完还是乱，就去首选项里检查编码设置，或者启动时加-Dfile.encoding=UTF-8显式指定。别指望工具自动猜，编码猜测在长文本上准确率有限。
现象三：加载大文件时卡死，或者直接抛OutOfMemoryError。
原因是对堆内展开的估算不足。一个 200MB 的 dump，解析成对象图之后占用可能是几倍，默认堆几百兆根本不够。
解决办法就是前面提过的-Xmx2g，文件再大就继续往上加。另一个思路是在命令行模式下只导出报告，不打开完整界面，内存占用会低不少。还有一点，别把几十份 dump 一股脑全加进去对比，工具的「对比模式」也是有内存代价的。
5.2 解析与判读类：文件是好的，结论是错的
现象四：加载成功，但监视器视图一片空白，可你明明知道有锁竞争。
原因是抓 dump 的时候jstack没带-l。不打印锁附加信息，AQS 那一层的持有关系就完全缺失，工具只能拿到 synchronized 这部分。
解决办法是重新抓一份带-l的。如果进程已经重启、现场没了，那就只能从代码侧找线索——把所有synchronized块和ReentrantLock的加锁点列出来，看有没有在高频路径上包了大段逻辑。这个教训值得记一次，之后就再也不会省那个-l了。
现象五：死锁页是空的，但线程确实全卡住了。
原因是「卡住」不等于「死锁」。死锁是环，而更常见的是一棵特别深的等待树：几百个线程等一把锁，持有者自己在等数据库连接，数据库连接池又被另一个卡住的线程占着。没成环，检测算法就不会报，但现象一样。
解决办法是把注意力从死锁页挪到监视器视图，按「等待者数量」排序，找到被等得最多的那个锁，然后顺着持有者往下看它卡在哪。如果是连接池耗尽，dump 里会看到大量线程卡在getConnection，这时候该去看的是连接池配置和慢 SQL，不是线程本身。
6. 三次采样叠着看：把偶发卡顿从噪声里捞出来的笨办法
单份 dump 最大的问题是不确定。某个线程 BLOCKED，可能只是恰好撞上了别人持锁的那一毫秒，你把它当罪魁祸首就是误判。我现在固定用三份 dump 交叉验证，规则很土但有效：
| 三次采样中的表现 | 判断 |
|---|---|
| 同一线程三次都在同一行栈顶 | 确定的卡点 |
| 同一把锁的持有者三次都是同一个线程 | 锁被长期占用 |
| BLOCKED 数量三次递增 | 请求在堆积，正在雪崩 |
| 三次状态各不相同、栈顶乱跳 | 正常调度，别过度解读 |
具体做法是，把三份 dump 都在 TDA 里打开，利用工具的对比能力，或者干脆用第 4 章那个脚本跑三遍，把三次的「栈顶方法 TOP10」并排放。第一次的 TOP1 是 A、第二次是 B、第三次是 C，那说明系统只是在正常地轮转；三次的 TOP1 都是同一个方法而且占比越来越高，那才是真瓶颈。
有个细节值得单独说：就算三次栈顶一致，也要看线程名是不是同一批。线程池里exec-1到exec-200轮着用，如果第一次是exec-23卡住、第二次换成exec-7卡在同一个方法，这仍然是同一个问题；但如果三次都是exec-23这一个线程卡着不动，其余线程正常流转，那就是单个线程陷进去了，可能是死循环或者某个没设超时的调用，性质完全不同，处理方式也不同。
还有一条容易被忽略：三次采样不要跨太长时间。间隔 5 秒、总跨度 10 秒，抓到的是同一个故障窗口内的状态；如果你间隔 5 分钟抓三次，中间业务可能自己恢复了，三份文件讲的就不是一件事。真的需要看趋势，那是监控该干的活，不是 dump 该干的活。
从那以后我每次处理线上卡顿，都强制自己先连抓三次、确认卡点稳定存在，再决定要不要重启——多花的这二十秒，救回来的往往是整晚的排查时间。希望帮到你。
本文还有配套的精品资源，点击获取
