基于开源 Jifa 打造 AI 智能诊断助手让 Heap Dump、GC 和线程问题交给 AI 分析在 Java 生产环境中Heap Dump、GC 日志和 Thread Dump 往往是定位问题最重要的证据但传统分析需要工程师熟悉大量命令、指标和对象引用关系。我基于开源项目 Eclipse Jifa 做了一套增强让 Jifa 不仅能够分析文件还能够通过 MCP 和 AI Agent帮助用户直接回答“是否存在内存泄漏”“哪个线程被阻塞”“GC 为什么频繁”等生产问题。欢迎大家体验、提出建议也欢迎给项目点一个 StarGitHub - 01o00o10/jifa-ai-mcp: Online Heap Dump, GC Log, Thread Dump JFR File AnalyzerAI-MCP · GitHub这次主要改了什么首先将原有 Java 模块从 Gradle 迁移到了 Maven保留了原项目的分析能力和构建行为包括 MAT、OSGi、HPROF Hook 以及本地 MAT 依赖装配。其次新增了独立的 MCP 模块。MCP 可以动态暴露 Jifa 已注册的 Heap Dump、GC Log、Thread Dump 和 JFR 分析 APIAI 不需要猜测文件内容而是可以调用真实的分析工具获取证据。另外前端新增了悬浮式 AI 诊断助手。用户选择一个分析文件后可以直接提问不同文件拥有独立会话刷新页面后仍可以恢复之前的对话。当前支持配置 DeepSeek、Qwen 以及其他 OpenAI 兼容模型并支持运行时修改模型、Base URL、API Key 和 MCP 地址。它是一个什么样的 AI Agent这里不是简单地把用户问题转发给大模型而是实现了一个面向 Jifa 分析场景的轻量 AI Agenttext用户问题↓读取当前文件的 Jifa 初始分析证据↓AI Agent 将当前文件类型对应的分析 API 注册为工具↓大模型判断下一步是否需要调用工具↓MCP / Jifa 执行真实分析↓工具结果返回给 Agent↓继续分析或生成最终诊断结论其中大模型负责推理和决策Agent 负责上下文管理、工具调用、循环控制、结果汇总和会话保存Jifa 和 MCP 负责真正执行文件分析。底层实现原理1. 先获取事实再让 AI 推理当用户选择 Heap Dump 并提问“分析疑似内存泄漏”时服务端首先调用 Jifa 的分析 API获取 Leak Suspects、对象占用、引用链等真实数据然后把这些结果作为证据交给模型。这样可以避免 AI 仅凭问题描述臆测结论。2. MCP 将 Jifa 分析能力转换成 AI 工具MCP 服务启动后会读取 Jifa 的 ApiService.supportedApis()动态生成工具列表。例如textheap-dump.overviewheap-dump.histogramheap-dump.outboundOfObjectgc-log.diagnosethread-dump.deadlock模型需要更多证据时Agent 会调用对应工具MCP 再将参数转换为 Jifa API 所需的 Path、枚举和分页参数最后复用原有分析执行链路。3. Agent 会控制工具调用循环实际使用中模型有时会反复请求同一个工具。为避免无限循环Agent 做了几层保护- 使用“工具名 参数”识别重复调用。- 相同工具和参数只执行一次。- 单个工具结果和总证据都有大小限制。- 单次请求最多进行 8 轮工具决策。- 检测到重复调用或达到预算后创建一个干净的无工具上下文强制生成最终诊断。这也是解决部分 DeepSeek 模型输出 DSML、data: 或工具协议文本的关键最终总结不再复用原来的工具调用轨迹。4. 会话保存在分析机器项目没有引入 Redis。AI 会话以 JSON 文件的形式保存在实际执行分析的机器上text${jifa.storage-path}/ai-sessions/{sessionId}.json在 Master/Worker 模式下AI 请求会被路由到文件所属 Worker会话文件和分析缓存保持在同一台分析机器上。前端则使用浏览器 localStorage 保存展示记录因此刷新页面后仍能恢复当前文件的会话。从 Heap Dump 到最终诊断以疑似内存泄漏为例完整链路大致如下text上传 java_pid.hprof↓Jifa 保存文件并建立分析上下文↓AI Agent 获取 Leak Suspects / Histogram 初始证据↓模型发现 ArrayList 保留大量对象↓Agent 调用 outboundOfObject 等引用分析工具↓MCP 复用 MAT / OSGi 分析能力↓模型综合 retained size、引用链和栈信息↓输出结论、证据、风险等级和处理建议最终结果仍然以 Jifa 分析数据为基础AI 主要负责把底层分析结果转换成更容易理解、更适合生产排障的结论。为什么保留 Jifa 原有能力Jifa 已经具备成熟的文件分析、缓存、异步任务、Worker 路由和 MAT 集成能力。这次改造没有重新实现 Heap Dump 或 GC 分析器而是将这些能力通过 MCP 和 Agent 暴露给 AI。这样做有三个好处- 分析结果来自成熟的 Jifa 引擎而不是模型猜测。- 新增 Jifa 分析 API 后可以动态进入 MCP 工具列表。- Web 页面、MCP 和 AI Agent 共享同一套分析能力。## 适合哪些场景- Java 服务疑似内存泄漏。- Full GC 频繁或 GC 停顿过长。- 线程死锁、线程池阻塞和请求堆积。- CPU 热点、锁竞争和内存分配热点。- 需要快速阅读 Heap Dump、GC Log、Thread Dump 或 JFR 的场景。这套能力更适合内网和受控环境。MCP 会限制文件访问根目录但生产部署仍建议配置访问控制、API Key 管理和网络隔离。## 写在最后这次改造的目标不是让 AI 替代 Jifa而是让 Jifa 的分析能力更容易被使用工程师可以继续查看原始指标和引用链也可以直接向 AI 提问让它帮助整理证据、解释原因和给出排查建议。如果你对 Java 性能分析、MCP、AI Agent 或 Jifa 的底层实现感兴趣欢迎访问项目、试用功能、提交 Issue 或 Pull Request。欢迎 Star、Fork也欢迎一起把 Java 生产问题诊断做得更简单https://github.com/01o00o10/jifa-ai-mcp
基于开源 Jifa 打造 AI 智能诊断助手：让 Heap Dump、GC 和线程问题交给 AI 分析
基于开源 Jifa 打造 AI 智能诊断助手让 Heap Dump、GC 和线程问题交给 AI 分析在 Java 生产环境中Heap Dump、GC 日志和 Thread Dump 往往是定位问题最重要的证据但传统分析需要工程师熟悉大量命令、指标和对象引用关系。我基于开源项目 Eclipse Jifa 做了一套增强让 Jifa 不仅能够分析文件还能够通过 MCP 和 AI Agent帮助用户直接回答“是否存在内存泄漏”“哪个线程被阻塞”“GC 为什么频繁”等生产问题。欢迎大家体验、提出建议也欢迎给项目点一个 StarGitHub - 01o00o10/jifa-ai-mcp: Online Heap Dump, GC Log, Thread Dump JFR File AnalyzerAI-MCP · GitHub这次主要改了什么首先将原有 Java 模块从 Gradle 迁移到了 Maven保留了原项目的分析能力和构建行为包括 MAT、OSGi、HPROF Hook 以及本地 MAT 依赖装配。其次新增了独立的 MCP 模块。MCP 可以动态暴露 Jifa 已注册的 Heap Dump、GC Log、Thread Dump 和 JFR 分析 APIAI 不需要猜测文件内容而是可以调用真实的分析工具获取证据。另外前端新增了悬浮式 AI 诊断助手。用户选择一个分析文件后可以直接提问不同文件拥有独立会话刷新页面后仍可以恢复之前的对话。当前支持配置 DeepSeek、Qwen 以及其他 OpenAI 兼容模型并支持运行时修改模型、Base URL、API Key 和 MCP 地址。它是一个什么样的 AI Agent这里不是简单地把用户问题转发给大模型而是实现了一个面向 Jifa 分析场景的轻量 AI Agenttext用户问题↓读取当前文件的 Jifa 初始分析证据↓AI Agent 将当前文件类型对应的分析 API 注册为工具↓大模型判断下一步是否需要调用工具↓MCP / Jifa 执行真实分析↓工具结果返回给 Agent↓继续分析或生成最终诊断结论其中大模型负责推理和决策Agent 负责上下文管理、工具调用、循环控制、结果汇总和会话保存Jifa 和 MCP 负责真正执行文件分析。底层实现原理1. 先获取事实再让 AI 推理当用户选择 Heap Dump 并提问“分析疑似内存泄漏”时服务端首先调用 Jifa 的分析 API获取 Leak Suspects、对象占用、引用链等真实数据然后把这些结果作为证据交给模型。这样可以避免 AI 仅凭问题描述臆测结论。2. MCP 将 Jifa 分析能力转换成 AI 工具MCP 服务启动后会读取 Jifa 的 ApiService.supportedApis()动态生成工具列表。例如textheap-dump.overviewheap-dump.histogramheap-dump.outboundOfObjectgc-log.diagnosethread-dump.deadlock模型需要更多证据时Agent 会调用对应工具MCP 再将参数转换为 Jifa API 所需的 Path、枚举和分页参数最后复用原有分析执行链路。3. Agent 会控制工具调用循环实际使用中模型有时会反复请求同一个工具。为避免无限循环Agent 做了几层保护- 使用“工具名 参数”识别重复调用。- 相同工具和参数只执行一次。- 单个工具结果和总证据都有大小限制。- 单次请求最多进行 8 轮工具决策。- 检测到重复调用或达到预算后创建一个干净的无工具上下文强制生成最终诊断。这也是解决部分 DeepSeek 模型输出 DSML、data: 或工具协议文本的关键最终总结不再复用原来的工具调用轨迹。4. 会话保存在分析机器项目没有引入 Redis。AI 会话以 JSON 文件的形式保存在实际执行分析的机器上text${jifa.storage-path}/ai-sessions/{sessionId}.json在 Master/Worker 模式下AI 请求会被路由到文件所属 Worker会话文件和分析缓存保持在同一台分析机器上。前端则使用浏览器 localStorage 保存展示记录因此刷新页面后仍能恢复当前文件的会话。从 Heap Dump 到最终诊断以疑似内存泄漏为例完整链路大致如下text上传 java_pid.hprof↓Jifa 保存文件并建立分析上下文↓AI Agent 获取 Leak Suspects / Histogram 初始证据↓模型发现 ArrayList 保留大量对象↓Agent 调用 outboundOfObject 等引用分析工具↓MCP 复用 MAT / OSGi 分析能力↓模型综合 retained size、引用链和栈信息↓输出结论、证据、风险等级和处理建议最终结果仍然以 Jifa 分析数据为基础AI 主要负责把底层分析结果转换成更容易理解、更适合生产排障的结论。为什么保留 Jifa 原有能力Jifa 已经具备成熟的文件分析、缓存、异步任务、Worker 路由和 MAT 集成能力。这次改造没有重新实现 Heap Dump 或 GC 分析器而是将这些能力通过 MCP 和 Agent 暴露给 AI。这样做有三个好处- 分析结果来自成熟的 Jifa 引擎而不是模型猜测。- 新增 Jifa 分析 API 后可以动态进入 MCP 工具列表。- Web 页面、MCP 和 AI Agent 共享同一套分析能力。## 适合哪些场景- Java 服务疑似内存泄漏。- Full GC 频繁或 GC 停顿过长。- 线程死锁、线程池阻塞和请求堆积。- CPU 热点、锁竞争和内存分配热点。- 需要快速阅读 Heap Dump、GC Log、Thread Dump 或 JFR 的场景。这套能力更适合内网和受控环境。MCP 会限制文件访问根目录但生产部署仍建议配置访问控制、API Key 管理和网络隔离。## 写在最后这次改造的目标不是让 AI 替代 Jifa而是让 Jifa 的分析能力更容易被使用工程师可以继续查看原始指标和引用链也可以直接向 AI 提问让它帮助整理证据、解释原因和给出排查建议。如果你对 Java 性能分析、MCP、AI Agent 或 Jifa 的底层实现感兴趣欢迎访问项目、试用功能、提交 Issue 或 Pull Request。欢迎 Star、Fork也欢迎一起把 Java 生产问题诊断做得更简单https://github.com/01o00o10/jifa-ai-mcp
