JProfiler 让 AI 智能体得以有效利用堆转储
JProfiler 16.3 通过其 MCP 服务器将 JProfiler 的所有主要子系统开放给 AI 智能体。其中最实用的新增功能之一是堆转储分析。智能体现在可以检查堆中的对象、追踪它们的引用，并查明它们为何未被垃圾回收。
没有运行时数据，AI 智能体就无法看到哪些对象仍然存活，也不知道是什么使它们保持可达。JProfiler 填补了这一空白，使智能体能够从真实证据出发，并据此找到相关的源代码。
让 JProfiler MCP 服务器对较弱模型更加稳健
旗舰模型并不适合所有编码任务。它们速度慢，而且成本高昂。因此许多任务，尤其是琐事类任务，更适合交给响应更敏捷、成本只有其零头的较低档模型。然而，这些模型的工具调用行为可能比顶级模型更加不稳定。
在 JProfiler 16.1 中，我们添加了一个 MCP 服务器，让 AI 编码代理能够对 Java 应用程序进行性能分析并分析结果。这一功能收到了客户的大量积极反馈，因此这是我们打算在即将发布的版本中继续拓展的一个领域。
在初始发布时，我们的测试主要使用 Claude Code 完成。对于 JProfiler 16.2，我们已经使 MCP 服务器对其他 AI 模型更加稳健。请继续阅读，了解其他模型出了哪些问题，以及我们如何让性能分析工作流能够抵御它们的缺陷。
我如何借助 JProfiler MCP 让 jclasslib 的性能翻倍
最近，我借助 Codex 和一个性能分析智能体，提升了我的开源 JVM 字节码查看器 jclasslib 的性能。这并不是因为我有某个具体的痛点，而是因为我想试用随 JProfiler 16.1 一起发布的 MCP 服务器。请继续阅读，了解这个智能体如何让类文件读取提速一倍以上，以及为什么性能分析不再需要理由就能开始。
JProfiler 16.1：AI 智能体现在可以对您的 Java 应用程序进行性能分析
自 JProfiler 1.0 以来，性能分析一直是开发人员借助 GUI 完成的工作：启动会话、浏览各个视图、解读数据。在实际工作中，这意味着只有当问题严重到值得进行上下文切换时，才会开展性能分析，而许多问题在从未经过性能分析的情况下就上线到了生产环境。
在 JProfiler 16.1 中，我们正在改变性能分析的工作方式：AI 编码智能体现在可以对您的 Java 应用程序进行性能分析、分析结果并据此采取行动。这是自我们创立以来，开发人员使用性能分析方式的最大变革。
全新的 JProfiler MCP 服务器以 @ej-technologies/jprofiler-mcp npm 包的形式提供，它通过 模型上下文协议（MCP）公开 JProfiler 的性能分析和堆分析能力。它可与 Claude Code、Cursor、Codex、Gemini CLI 以及任何其他兼容 MCP 的 AI 编码工具协同工作。
AI 剖析：LangChain4j 与 Spring AI
智能体（agentic）应用带来了独特的剖析挑战。除了标准的 CPU 使用率之外，性能和成本还取决于提示词、RAG 检索器和工具调用所构成的复杂结构，而这些结构往往隐藏在框架抽象之下。
为了避免厂商锁定，大多数开发者都会使用 LangChain4j 或 Spring AI 这样的框架。JProfiler 的 AI 探针可让您深入了解这些框架。
这段录屏视频逐步演示了如何剖析一个 LangChain4j 客户支持智能体，展示了 AI 探针如何将提示词的构成可视化、隔离出 token 消耗高的异常调用，并将资源成本直接投射到所记录的调用树上。
JProfiler 16：智能体 Java 应用性能分析
AI 为什么需要性能分析
传统性能分析关注的是 JVM 的内部执行，例如方法执行时长、内存分配和线程同步问题。JProfiler 过去的一项主要创新立足于其探针：对 HTTP、JDBC 和 RPC 调用等更高层级系统的测量。随着 LangChain4j 和 Spring AI 等 LLM 框架的出现，新的性能挑战随之而来。LLM 交互会引入高度不确定的延迟和可观的资源成本，而标准 CPU 分析无法将其置于上下文中加以解读。JProfiler 在弥合这一差距方面具有得天独厚的优势：它将 AI 交互视为新探针的数据来源。