/ ディレクトリ / プレイグラウンド / tda
● コミュニティ irockel ⚡ 即起動

tda

作者 irockel · irockel/tda

Claudeに Java スレッドダンプを読み込む力を与えます — デッドロック、長時間実行スレッド、仮想スレッドピニング、ネイティブメソッドブロッカー。

TDA(Thread Dump Analyzer)は GUI と MCP モードの両方を提供します。ヘッドレス JAR モードでは、ダンプログの解析、状態の要約、デッドロック検出、長時間実行スレッド検出、仮想スレッドキャリアピニング分析用に 6 つ以上のツールを公開しています。

なぜ使うのか

主な機能

ライブデモ

実際の動作

tda.replay ▶ 準備完了
0/0

インストール

クライアントを選択

~/Library/Application Support/Claude/claude_desktop_config.json  · Windows: %APPDATA%\Claude\claude_desktop_config.json
{
  "mcpServers": {
    "tda": {
      "command": "TODO",
      "args": [
        "See README: https://github.com/irockel/tda"
      ],
      "_inferred": true
    }
  }
}

Claude Desktop → Settings → Developer → Edit Config を開く。保存後、アプリを再起動。

~/.cursor/mcp.json · .cursor/mcp.json
{
  "mcpServers": {
    "tda": {
      "command": "TODO",
      "args": [
        "See README: https://github.com/irockel/tda"
      ],
      "_inferred": true
    }
  }
}

Cursor は Claude Desktop と同じ mcpServers スキーマを使用。プロジェクト設定はグローバルより優先。

VS Code → Cline → MCP Servers → Edit
{
  "mcpServers": {
    "tda": {
      "command": "TODO",
      "args": [
        "See README: https://github.com/irockel/tda"
      ],
      "_inferred": true
    }
  }
}

Cline サイドバーの MCP Servers アイコンをクリックし、"Edit Configuration" を選択。

~/.codeium/windsurf/mcp_config.json
{
  "mcpServers": {
    "tda": {
      "command": "TODO",
      "args": [
        "See README: https://github.com/irockel/tda"
      ],
      "_inferred": true
    }
  }
}

Claude Desktop と同じ形式。Windsurf を再起動して反映。

~/.continue/config.json
{
  "mcpServers": [
    {
      "name": "tda",
      "command": "TODO",
      "args": [
        "See README: https://github.com/irockel/tda"
      ]
    }
  ]
}

Continue はマップではなくサーバーオブジェクトの配列を使用。

~/.config/zed/settings.json
{
  "context_servers": {
    "tda": {
      "command": {
        "path": "TODO",
        "args": [
          "See README: https://github.com/irockel/tda"
        ]
      }
    }
  }
}

context_servers に追加。保存時に Zed がホットリロード。

claude mcp add tda -- TODO 'See README: https://github.com/irockel/tda'

ワンライナー。claude mcp list で確認、claude mcp remove で削除。

ユースケース

実用的な使い方: tda

TDA でスレッドダンプから JVM ハングを診断します

👤 Java バックエンドエンジニア ⏱ ~20 min advanced

使うタイミング: 本番環境の JVM が応答しなくなった、複数の kill -3 ダンプがある場合です。

前提条件
  • tda.jar がダウンロード済み — github.com/irockel/tda releases から
  • Java 21 以上がインストール済み — Project Loom 分析機能用
フロー
  1. ログを解析します
    parse_log を /tmp/threaddumps.log で実行。要約:ダンプ数、ダンプあたりのスレッド数。✓ コピーしました
    → ダンプ概要
  2. デッドロックを確認します
    すべてのダンプ全体で check_deadlocks を実行。どのスレッド、どのロック?✓ コピーしました
    → デッドロックサイクル(存在する場合)
  3. 長時間実行スレッドを検索します
    すべてのダンプ全体で永続する find_long_running スレッド。何をしていますか?✓ コピーしました
    → スタックヘッド付きリスト

結果: ハングの原因となる特定のスレッド + ロック + コードパス。

注意点
  • stdout に出力するスクリプトが JSON-RPC ストリームを破損させますjava -Djava.awt.headless=true -jar tda.jar --mcp を使用し、出力するスクリプトでラップしないでください

Loom アプリで仮想スレッドキャリアピニングを探します

👤 Project Loom を採用しているチーム ⏱ ~30 min advanced

使うタイミング: 仮想スレッドが期待される並行性を提供していない — ピニングが疑われます。

フロー
  1. 負荷中にダンプをキャプチャします
    ピーク負荷時にスレッドダンプを収集。TDA で parse_log します。✓ コピーしました
    → ダンプロード完了
  2. 分析します
    analyze_virtual_threads を実行。キャリアピニングホットスポットとそれをピニングしている Java コード(通常は synchronized ブロックまたはネイティブメソッド)を表示します。✓ コピーしました
    → ソースヒント付きピニングリスト

結果: 証拠に基づいた、対象となった修正(synchronized の代わりに ReentrantLock など)。

ネイティブメソッドに固着しているスレッドを特定します

👤 JNI 集約型アプリのパフォーマンスエンジニア ⏱ ~15 min advanced

使うタイミング: アプリはネイティブライブラリと統合され、ブロッキングなネイティブコールが疑われます。

フロー
  1. ネイティブブロックされたスレッドを一覧表示します
    ダンプ #3 に対して get_native_threads を実行。どのネイティブメソッドに固着していますか?✓ コピーしました
    → スレッド + ネイティブフレームリスト

結果: 特定の JNI コールサイトの対象となったレビュー。

組み合わせ

他のMCPと組み合わせて10倍の力を

スレッドレベルの検出結果を JVM メトリクスと相関させます

TDA が lock X が競合していると言います — Prometheus から同じウィンドウの JVM thread_blocked_seconds を表示します。✓ コピーしました
tda + github

検出結果を、コードポインタ付きの issue に変えます

TDA の top 3 検出結果について、疑わしい Java ソースラインをリンクする GitHub issue を開きます。✓ コピーしました

ツール

このMCPが提供する機能

ツール入力呼び出すタイミングコスト
parse_log path: str 最初のステップ、常に ローカル CPU
get_summary 掘る前の概要 0
check_deadlocks ハング診断 0
find_long_running min_dumps?: int 永続スレッド 0
analyze_virtual_threads Loom 診断 0
get_native_threads dump_index?: int JNI 疑惑 0
get_zombie_threads 未解決のメモリ再配置 0
clear 新しいログを解析する前にリセット 0

コストと制限

運用コスト

APIクォータ
なし
呼び出しあたりのトークン
スレッドダンプは巨大です — フルダンプあたり 20k 以上のトークン。チャットにダンプする前に要約してください
金額
無料
ヒント
フルスタックを要求する前に get_summary/find_long_running で絞り込みを使用します

セキュリティ

権限、シークレット、影響範囲

認証情報の保管: なし
データ送信先: なし — 完全にローカルファイル解析

トラブルシューティング

よくあるエラーと対処法

MCP ハンドシェイク破損

README に従ってちょうど JAR を実行(ヘッドレス + --mcp、stdout に出力するラッパースクリプトなし)

parse_log がカスタムダンプフォーマットで失敗

ダンプが標準 HotSpot フォーマットであることを確認。いくつかの APM は TDA が解析できないプレフィックスを追加します

大規模ログでメモリが爆発

tda.jar の JVM ヒープを増やす:-Xmx4g またはログをチャンクに分割

代替案

tda 他との比較

代替案代わりに使う場面トレードオフ
FastThread / other online analyzersダンプをサードパーティにアップロードしても大丈夫な場合データがネットワークから外に出ます
async-profiler + flame graphsライブコントロールがあり、ダンプではなくサンプリングプロファイラーが欲しい場合異なるアーティファクト。エージェント接続が必要です

その他

リソース

📖 GitHub の公式 README を読む

🐙 オープンな issue を見る

🔍 400以上のMCPサーバーとSkillsを見る