fastthread 是专用于分析 java 线程转储（.txt）的在线工具，不支持 gc 日志（.log）或堆转储（.hprof）；正确使用需上传 jstack -l 生成的完整 thread dump 文件，支持多份对比分析死锁、cpu 消耗线程等。
FastThread 不是 GC 日志分析工具，它是专门用于 Java 线程转储（Thread Dump）分析 的在线可视化工具。
你可能混淆了 Tier1app 公司推出的三款工具：
- ✅ FastThread.io → 分析
jstack生成的 线程转储文件（.txt） - ✅ GCEasy.io → 分析
-Xlog:gc或-XX:+PrintGCDetails生成的 GC 日志（.log） - ✅ HeapHero.io → 分析
jmap -dump生成的 堆转储文件（.hprof）
所以，如果你手头是 GC 日志（比如 gc.log），请直接去 https://www.php.cn/link/3773f78718c5a0aec6305dc5f1b8b692 上传分析；用 FastThread 是无法解析、也无法提供有效信息的。
如果你实际想用的是 FastThread（即你有 Thread Dump 文件）
那它正确的使用流程如下：
上传前：确保你有一份有效的 Thread Dump
- 用
jstack -l <pid></pid>导出（推荐）jstack -l 12345 > thread_dump_$(date +%Y%m%d_%H%M%S).txt
- 或用
jcmd <pid> Thread.print</pid>（JDK8+ 更稳定） - 建议连续抓取 3~5 份，间隔 5–10 秒，便于观察线程状态变化
- Docker 环境下可用：
docker exec -it myapp jstack -l 1 > /tmp/dump.txt
上传与分析步骤
- 访问 https://www.php.cn/link/6c1941a1c1c95552c36a9785cacf865f
- 拖入
.txt文件（支持单个或多个，也支持 zip 打包） - 等待解析完成（通常几秒到十几秒）
- 进入分析页，重点关注以下 Tab：
Thread Dump - Intelligence Report
首页摘要，自动标出高风险项：死锁、CPU 消耗线程、Finalizer 阻塞、大量 WAITING 线程等。
CPU consuming threads
列出可能处于 RUNNABLE 状态且长时间执行的线程，结合栈顶方法定位热点代码（如无限循环、正则回溯、序列化瓶颈）。
Blocking Threads - Transitive Graph
以图谱形式展示线程间的阻塞链路，直观识别“谁在等谁”、“谁持有了哪个锁”。
Complex Deadlock
检测 JVM 自带死锁报告未覆盖的嵌套/间接死锁（例如 A→B→C→A 类型）。
Threads with identical stack trace
快速发现线程池中大量重复创建的线程（如未复用的 new Thread()），或异常重试导致的线程堆积。
常见误操作提醒
- ❌ 上传
.log（GC 日志）、.hprof（堆转储）、.jar或配置文件 → 解析失败或无结果 - ❌ 上传被截断、编码错误（如 GBK 中文乱码）、不完整（缺少
Full thread dump开头）的 dump → 报告不准或中断 - ❌ 只传 1 份 dump 就下结论 → 很多问题（如短暂 BLOCKED、瞬时 RUNNABLE）需对比多份才能确认趋势
补充建议：搭配使用效果更佳
- 线程问题 + GC 频繁？→ 同时用 FastThread（查线程卡点） + GCEasy（查是否因内存不足触发频繁 GC）
- 出现
OutOfMemoryError: unable to create new native thread？→ FastThread 查线程数暴增原因（如线程池未 shutdown、回调泄漏） - 怀疑锁竞争？→ 结合
jstack -l输出中的locked和waiting to lock行，再用 FastThread 的 Blocking Graph 验证
工具本身不替代思考，但能把几千行文本压缩成关键线索——重点始终是：看懂线程状态含义，再结合业务逻辑判断是否合理。
