1. 死锁排查为什么总卡在“看栈”这一步后端服务偶发死锁最难受的地方不是它有多复杂而是它不稳定复现。线上跑几天没事流量一上来、某个批处理一叠加线程就卡住了。你去看日志往往只有一句超时或者连接池耗尽真正的锁等待链藏在 JVM 线程栈或者数据库的锁视图里。我处理这类问题的基本思路是固定的先确认“谁在等谁”再确认“谁持有锁不放手”最后才是改代码。问题在于从线程栈到锁等待链中间要读的东西太多了——jstack输出几百行、数据库锁表字段一堆缩写、再加上业务代码里嵌套的synchronized和SELECT ... FOR UPDATE人眼扫一遍很容易漏。这时候如果有个 AI 能帮你把线程栈和锁信息先做一轮归纳把“疑似死锁环”标出来排查效率会高很多。但直接用网页版对话工具每次都要手动复制粘贴大段栈信息而且不同工具要配不同的 Key管理起来很烦。我后来用 TaoToken 把 Key 统一起来让 AI 编码工具走同一个 API 通道排查时直接把栈丢进去分析省掉了来回切换的功夫。这篇就按这个场景走先讲死锁定位的通用思路再给一份可复制的settings.json配置骨架把 TaoToken 作为统一 Key/API 通道接进 AI 编码工具最后附上验证请求是否连通的命令行动作。适合后端开发、运维以及正在搭 AI 辅助排查环境的人。2. 死锁定位思路从线程栈到锁等待链2.1 先分清是 JVM 层死锁还是数据库层死锁这两类死锁表现很像但排查入口完全不同。JVM 层死锁通常是两个线程互相持有对方需要的对象锁jstack会直接告诉你Found one Java-level deadlock。数据库层死锁则是事务之间互相等待行锁或表锁应用线程只是“受害者”真正卡住的是数据库事务。判断方法很简单先jstack看有没有 Java-level deadlock。如果没有但线程大量处于BLOCKED或WAITING且堆栈停在数据库调用上那大概率是数据库锁等待。我一般两个都抓然后交给 AI 做交叉分析。2.2 抓线程栈的正确姿势不要只抓一次。死锁是瞬时的抓一次可能刚好错过。连续抓 3 到 5 次间隔 5 秒对比哪些线程一直卡在同一个位置。# 找到 Java 进程 PID jps -l # 连续抓 5 次线程栈每次间隔 5 秒 for i in 1 2 3 4 5; do jstack PID /tmp/jstack_$i.txt sleep 5 done # 快速看有没有 JVM 级死锁 grep -A 20 deadlock /tmp/jstack_1.txt抓完之后重点看BLOCKED状态的线程以及waiting to lock和locked这两行。它们会告诉你锁的对象地址两个线程如果互相waiting to lock对方持有的地址那就是一个死锁环。2.3 数据库锁等待链怎么读以 MySQL 为例information_schema里有现成的锁等待视图。核心是找到blocking_trx_id和waiting_trx_id的对应关系。-- MySQL 8.0 查看当前锁等待 SELECT r.trx_id AS waiting_trx, r.trx_mysql_thread_id AS waiting_thread, r.trx_query AS waiting_query, b.trx_id AS blocking_trx, b.trx_mysql_thread_id AS blocking_thread, b.trx_query AS blocking_query FROM information_schema.innodb_lock_waits w JOIN information_schema.innodb_trx b ON b.trx_id w.blocking_trx_id JOIN information_schema.innodb_trx r ON r.trx_id w.requesting_trx_id;如果用的是 SQL Server思路类似通过sys.dm_exec_requests和sys.dm_tran_locks关联找出blocking_session_id不为 0 的会话顺着链条往上追到根会话。原文里那段游标加临时表的写法本质也是在拼“进程—对象—锁类型”的对照表只是用 T-SQL 手工实现了一遍。2.4 把栈和锁信息整理成 AI 能读的输入AI 分析死锁输入质量决定输出质量。我一般整理成三段第一段是线程栈里所有BLOCKED线程的堆栈第二段是数据库锁等待查询结果第三段是相关业务代码片段尤其是加锁顺序。三段拼在一起让 AI 找“锁获取顺序不一致”的地方命中率很高。3. TaoToken 前置统一 Key 与 API 通道3.1 为什么需要统一 KeyAI 编码工具现在很多Claude Code、Cursor、Continue、各种 CLI 助手每个都要配 Key。如果每个工具单独申请、单独计费管理成本很高而且排查死锁时你可能同时开着两三个工具Key 散落各处很容易搞混。TaoToken 的作用就是提供一个统一的 API 通道你只需要维护一份 Key所有支持自定义 API 端点的工具都指向它。官网是 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 端点是 https://taotoken.net/api 注意 API 地址不带 UTM 参数。3.2 拿 Key 和确认模型登录后进控制台在 API Keys 页面创建一个新 Key。建议按用途命名比如deadlock-debug方便后面排查时区分。创建完先别急着配工具用一条 curl 确认通道是通的这一步能省掉后面很多“到底是工具配错了还是 Key 有问题”的扯皮。模型对话入口在 https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_contentmodel_chatutm_campaignrewrite 可以先在里面手动贴一段线程栈试试效果确认模型能正常响应再往下走。3.3 接入文档和 Coding Plan如果你要接的是 Claude Code 这类编码工具接入文档在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 。长期做编码和 Agent 任务的话Coding Plan 页面在 https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding_planutm_campaignrewrite 可以先了解额度规则再决定怎么用。4. 可复制配置settings.json 骨架4.1 通用 settings.json 结构下面这份骨架可以直接复制把你的Key替换成实际 Key 即可。不同工具字段名略有差异但核心就是baseUrl和apiKey两项。{ ai: { provider: openai-compatible, baseUrl: https://taotoken.net/api, apiKey: 你的Key, model: claude-sonnet-4-20250514, timeout: 60000, maxTokens: 8192 }, debug: { deadlockAnalysis: { enabled: true, includeThreadDump: true, includeDbLocks: true, maxStackLines: 500 } } }baseUrl填https://taotoken.net/api不要带末尾斜杠也不要加 UTM 参数。model按你实际可用的模型名填不确定就先在模型对话页面确认。4.2 Claude Code 的配置方式Claude Code 走的是 Anthropic 兼容协议配置入口在 https://taotoken.net/claude-code-anthropic?utm_sourcetaotoken_aicg_blog_endutm_contentclaudecodeutm_campaignrewrite 。环境变量方式最省事export ANTHROPIC_BASE_URLhttps://taotoken.net/api export ANTHROPIC_API_KEY你的Key配完之后在项目目录里启动 Claude Code它会自动读取这两个变量。如果工具提示认证失败先检查 Key 有没有多余空格再检查BASE_URL是不是被其他配置覆盖了。4.3 把死锁分析做成可复用提示词配置好通道之后建议把死锁分析的提示词固定下来避免每次重新描述。我用的模板大致是这样你是后端死锁分析助手。下面给你三段信息 1. JVM 线程栈含 BLOCKED 线程 2. 数据库锁等待查询结果 3. 相关业务代码片段 请完成 - 找出所有锁等待环标注线程/事务 ID - 指出锁获取顺序不一致的代码位置 - 给出最小改动的修复建议 - 如果信息不足明确说明还缺什么把这段和栈信息一起发给模型输出会比泛泛地问“帮我看看死锁”具体得多。5. 验证请求确认通道连通5.1 用 curl 做最小验证配置完先别急着开工具用 curl 打一发确认 Key 和端点都对。curl -s -X POST https://taotoken.net/api/v1/chat/completions \ -H Content-Type: application/json \ -H Authorization: Bearer 你的Key \ -d { model: claude-sonnet-4-20250514, messages: [ {role: user, content: 回复 OK 两个字母即可} ], max_tokens: 16 }正常返回里会有choices字段内容包含OK。如果返回 401是 Key 问题返回 404多半是路径写错注意是/api/v1/chat/completions返回超时检查网络和timeout设置。5.2 用真实线程栈做一次端到端验证curl 通了之后拿一段真实jstack输出做端到端测试。把栈内容塞进请求体让模型找BLOCKED线程。这一步能验证的不只是通道还有模型对长文本的处理能力。# 把线程栈转成 JSON 字符串简化处理实际可用 jq STACK$(cat /tmp/jstack_1.txt | head -200 | python3 -c import sys,json; print(json.dumps(sys.stdin.read()))) curl -s -X POST https://taotoken.net/api/v1/chat/completions \ -H Content-Type: application/json \ -H Authorization: Bearer 你的Key \ -d { \model\: \claude-sonnet-4-20250514\, \messages\: [ {\role\: \user\, \content\: \找出下面线程栈中所有 BLOCKED 线程并说明它们在等什么锁\n$STACK\} ], \max_tokens\: 1024 }如果模型能准确列出BLOCKED线程和对应的waiting to lock地址说明整条链路已经可用接下来就可以在编码工具里直接用了。5.3 成功结果长什么样一次正常的分析输出应该包含线程名、线程状态、等待的锁对象地址、持有该锁的线程名。如果模型只复述了栈内容而没有归纳说明提示词还不够具体把第 4.3 节的模板补上再试。6. 本篇常见错排查6.1 401 认证失败最常见的原因是 Key 复制时带了空格或者Authorization头写成了Bearer:Key冒号是错的应该是空格。另外确认 Key 没有过期控制台里可以重新生成。6.2 404 路径错误baseUrl和请求路径要拼对。baseUrl是https://taotoken.net/api请求路径是/v1/chat/completions拼起来是https://taotoken.net/api/v1/chat/completions。如果工具里填的是完整 URL就不要在baseUrl里重复带/v1。6.3 模型名不匹配不同工具默认模型名可能不一样填错会返回模型不存在。先在模型对话页面确认可用模型名再填到配置里。如果工具不支持指定模型就留空让它用默认值。6.4 线程栈太长被截断jstack输出可能上千行超过maxTokens会被截断。解决办法是先过滤只保留BLOCKED线程及其上下文或者分段发送。我一般用grep -B 2 -A 30 BLOCKED先筛一遍再发。6.5 数据库锁查询权限不足information_schema.innodb_lock_waits需要相应权限普通账号可能查不到。用有PROCESS权限的账号或者让 DBA 帮忙导出。SQL Server 那边同理sys.dm_tran_locks需要VIEW SERVER STATE权限。6.6 配置改了但工具没生效有些工具会缓存配置改完settings.json要重启。环境变量方式的话确认是在同一个 shell 会话里启动的工具export只对当前会话有效。7. 把 AI 辅助排查接进日常流程配置跑通之后我习惯把死锁排查做成一个固定动作线上告警触发时先自动抓jstack和数据库锁视图存到临时目录然后手动或脚本调用 AI 做第一轮归纳。这样等人介入的时候手里已经有一份“疑似死锁环 相关代码位置”的摘要而不是从零开始翻栈。如果你要长期做这类编码和 Agent 任务可以看下 Coding Plan 的额度规则https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding_planutm_campaignrewrite 。Key 管理在控制台https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_contentconsoleutm_campaignrewrite API Keys 页面https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi_keysutm_campaignrewrite 。接入细节以文档为准https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 。最后提醒一句AI 给的是排查线索不是最终结论。死锁环的确认、锁获取顺序的修改还是要回到代码和数据库事务边界上自己验证。把 AI 当成一个不会累的“第一轮筛选器”而不是替你拍板的人这条链路才真正稳。
