调度卡死线程快照分析

SKILL运维和基础设施
运维和基础设施 未标注权限 许可证不明确
安装这个技能

调度卡死线程快照分析(jstack/trace dump 归因)。当用户说"调度卡死了/卡主了""线程快照分析""jstack分析""线程dump分析""Worker线程占满""CountDownLatch等待不退出""又卡死了,和上次一样吗"时使用。给定 >=2 次线程快照文件(jstack/jcad/arthas 导出 txt,>=3 次更佳、间隔 10~30s),自动解析线程块并按签名分类(CountDownLatch 主线程等待 / Redisson 解锁与等锁 / 银企 Socket / HTTP / DB / netty 空闲 / 哨兵正常长连接),统计卡死 Worker 清单,做跨采样一致性判定(静态卡死 vs 慢执行),提取 JVM 运行时长与堆内存排除 GC 因素,追溯"主线程 await → 根因子线程卡点",可对照历史卡死分析文档做同源判定,产出 Markdown 归因报告与 P0/P1 建议、Redis/sentinel 取证动作。仅只读分析:不修改快照与源码,仅用 Python 标准库(>=3.10)。

一句话选型结论

按资料字段整理

调度卡死线程快照分析是运维和基础设施类的 Agent Skill,安装方式未标注,权限级别未标注,许可证不明确,有可直接复制的安装命令。技能本质是给模型读的说明书,效果取决于模型与客户端;装完先用一个小任务验证,再放进正式流程。

分类运维和基础设施 安装方式未标注 权限级别未标注权限 许可证许可证不明确
累计安装 未标注 本周 未标注
GitHub 星标 未标注 仓库 未标注
下载量 未标注 技能市场下载数
权限级别 未标注权限 安装前请确认风险范围
许可证 许可证不明确 未说明

安装

未标注
在支持 Skills 的客户端里执行,装完问一句「你有哪些技能」验证
skillhub install user_edaf850d/scheduler-thread-dump-analysis
  1. 1
    确认客户端支持

    确认你的客户端支持 Skills(Claude、Codex、Cursor 等),并升级到较新的版本。

  2. 2
    拿到技能文件

    执行上面的命令安装;也可以把仓库里的 SKILL.md 手动放进客户端的 skills 目录。

  3. 3
    刷新技能列表

    重新打开客户端,或刷新技能列表,让新放进来的技能被加载。

  4. 4
    验证是否生效

    问一句「你有哪些技能」,确认列表里出现它,再拿一个小任务试跑。

技能档案

运维和基础设施
字段来自技能仓库与公开索引,中文说明由本站标注
作者 / 维护方user_edaf850d仓库 未标注 · 版本 未标注
宿主客户端未标注技能可被这些客户端加载
安装方式未标注安装包 community
权限级别未标注权限安装前请确认风险范围
许可证未说明许可证不明确,商用前请自行确认条款
仓库可用性available技能仓库当前是否可访问
最近核验2026-11-06上游最后核验时间 · 数据更新 2026-11-06
正文体量5.6 KBSKILL.md 原文大小,越大说明说明书写得越细

典型使用场景

3 类
按分类整理的常见用法,具体以 SKILL.md 为准
查服务与日志

按现象定位服务状态与日志线索。

写部署与巡检脚本

把重复的部署、巡检写成脚本。

故障排查

按步骤排查网络、依赖与配置。

选择建议

装之前先看这几条
按条目字段给出的判断,不替你决定用不用

值得选的地方

  • 有可直接复制的安装命令,不用自己翻文档找入口。

先想清楚的地方

  • 没有标注权限级别,实际能做什么要装好后确认。
  • 许可证不明确,商用或二次分发前先到仓库确认条款。
  • 没有做站内核验,内容以作者仓库为准。
  • 技能只是说明书,实际效果取决于模型与客户端,装完先用小任务试一遍。

更适合

  • 需要在运维和基础设施场景里给模型补一套做法的人。
  • 愿意先读一遍 SKILL.md、确认它会让模型做什么的人。

不太适合

  • 对许可证要求很严、必须明确可商用的人。
  • 只想装完就自动变强、不打算看说明书的人。

同类对比

6 个同类
同分类里挑最接近的几条,字段以各自详情页为准
技能权限级别安装方式累计安装宿主客户端安装命令
调度卡死线程快照分析当前 未标注权限 未标注 未标注 未标注 有
Azure 部署 调用外部服务 GitHub 仓库 664.2 万 Codex、Claude、Cursor 有
Azure diagnostics 问题管理 调用外部服务 GitHub 仓库 657.6 万 Codex、Claude、Cursor 有
Azure aigateway 部署 调用外部服务 GitHub 仓库 655.3 万 Codex、Claude、Cursor 有
Azure AI 搜索 调用外部服务 GitHub 仓库 651.4 万 Codex、Claude、Cursor 有
Azure Cloud migrate 部署 调用外部服务 GitHub 仓库 650.7 万 Codex、Claude、Cursor 有

SKILL.md 全文

5.6 KB
模型实际读到的说明书原文,来自技能仓库

调度卡死线程快照分析(jstack 归因)

面向银企直联调度"卡死/卡主"场景:调度 Worker 被占满、交易全部排队的定位与归因。
核心方法:多快照块解析 → 签名分类 → 卡死 Worker 清单 → 跨采样一致性判定 → 现象层(主线程 await)追溯根因层(子线程卡点)→ 对照历史文档同源判定 → 归因报告。

开始前先加载 @references/gotchas.md。快照解析与判读陷阱都在其中,违反会得出错误结论(如把"加锁流程 close 旧锁"误判成解锁缺陷、把 epollWait 空闲当成忙、单次快照下静态卡死结论)。

输入

项 必需 缺省行为
线程快照文件(jstack/jcad/arthas 导出 txt,>=2 次可跑,>=3 次、间隔 10~30s 最佳) 是 只有 1 次时只能分类不能判"静态卡死",报告须标注
关注线程名(如 RTF_CLUSTERED_JOB_SCHEDULER_Worker-44) 否 脚本按 --worker-pattern 自动发现所有卡死 Worker
历史卡死分析文档(路径) 否 给了则做逐帧同源比对;没给则输出首次归因
工程源码路径 否 给了则把卡点落到具体类与行,核对锁/超时逻辑

提问模板(用户侧)

一条消息给齐要素即可一次出完整报告:

读取一下 <快照目录> 日志,最新的 N 次线程快照。
上次卡死过,分析结论文档在:<应用侧分析文档路径>,工程路径和报错在:<txt 路径>。
本次卡死线程是 <线程名>。请对照上次结论做卡死归因分析,输出报告。

只给快照目录也能跑(线程自动发现 + 分类),但"同源复发"判定会缺失历史对照。

步骤

  1. 环境检查:python --version >= 3.10 即可(脚本仅用标准库)。注意 Windows 下传 D:/... 路径,Git Bash 的 /d/... Python 不识别。
  2. 跑初筛:
    bash python scripts/analyze_thread_dump.py <dump1> <dump2> <dump3> \ --out <报告目录>/thread-dump-analysis.md \ [--worker-pattern RTF_CLUSTERED_JOB_SCHEDULER_Worker] [--max-stack 25]
  3. 复核报告五个部分:内存概览(排除 GC)→ 卡死 Worker 清单(占池比例)→ 分类统计 → 一致性矩阵(静态卡死判定)→ 核心卡点完整栈。
  4. 现象层→根因层追溯:主线程卡 CountDownLatch.await(TransProcessor.process) 只是现象;找到它等待的同名业务子线程,看子线程栈顶落在哪个签名分类(等 Redis 解锁响应 / 无限等锁 / 银企 Socket / HTTP / DB)。
  5. 判读(详见 gotchas):RedissonBaseLock.unlock 多为加锁流程 internalAddLock 先 close 旧锁;redisson-netty-* 空闲 epollWait = 命令发出无响应;MasterListener/cache-sub 的 socketRead0 属正常。
  6. 同源判定:与历史文档的核心栈逐帧比对(类名 + 行号 + 调用链),记录差异点(包名前缀/行号漂移可忽略,卡点帧一致即同源)。
  7. 产出报告(结构 = 脚本生成模板 + 人工补充):
    - 结论速览表(卡死线程 / 卡点 / 根因 / 内存判定 / 同源判定)
    - 现象层栈、根因层栈原文
    - 与上次对比表(维度:主线程、根因子线程、内存、IO 线程、改造落地情况)
    - 建议:P0 主线程 await 兜底超时 / P1 锁改 tryLock+leaseTime / P1 银企 setSoTimeout
    - 取证动作:Redis slowlog 与 --latency、sentinel +switch-master 日志、redisson timeout/retryAttempts 配置、--scan --pattern "*lock*" 残留锁
  8. 汇报:简短中文结论(卡在哪 / 为什么 / 与上次关系 / 下一步),报告文件用 present_files 交付。

边界

  • 只读:不修改快照与源码,不执行 Redis/数据库操作。
  • 归因到"卡点签名 + 可复核栈帧"为止;Redis 侧最终取证(slowlog/sentinel 日志)需运维配合,报告列动作清单。
  • 快照含生产线程名与内部类名,对外分享前注意脱敏。

关于作者

本技能由公众号「技术日记本」维护。
每天 08:30,3 分钟读懂 AI 圈最重要的事:大模型、AI 工具、行业动态,每条资讯附主编解读 —— 微信搜索公众号「技术日记本」即可关注。
技能问题与需求反馈,欢迎在 SkillHub 私信或评论区留言。

常见问题

5 问
答案由本站依据条目字段整理
调度卡死线程快照分析怎么安装?

在支持 Skills 的客户端里执行:skillhub install user_edaf850d/scheduler-thread-dump-analysis。安装方式为未标注。装完刷新技能列表或重开客户端。

调度卡死线程快照分析支持哪些客户端?

资料没有标注宿主客户端,但只要客户端支持 Skills(Claude、Codex、Cursor 等),一般都能加载。

调度卡死线程快照分析权限高吗,安全吗?

权限级别为未标注权限。安装前先看它会读取或写入哪些内容。

调度卡死线程快照分析收费吗?

本站不代收费用,也没有标注具体价格。是否收费取决于技能本身和所用的模型或客户端,正式使用前按作者说明确认。

调度卡死线程快照分析用什么许可证?

许可证标注为 未说明(许可证不明确)。商用或二次分发前请到仓库确认条款原文。

热门专题

按场景挑技能
全部专题 →

技能内容以作者仓库为准;分类、权限级别与许可证状态的中文说明为中文整理,最近核验 2026-11-06。