JProfiler 让 AI 智能体得以有效利用堆转储
JProfiler 16.3 通过其 MCP 服务器将 JProfiler 的所有主要子系统开放给 AI 智能体。其中最实用的新增功能之一是堆转储分析。智能体现在可以检查堆中的对象、追踪它们的引用，并查明它们为何未被垃圾回收。
没有运行时数据，AI 智能体就无法看到哪些对象仍然存活，也不知道是什么使它们保持可达。JProfiler 填补了这一空白，使智能体能够从真实证据出发，并据此找到相关的源代码。
我是如何让 Apache Fory JSON 提速 4.5 倍的
最近，我一直在对比各类 Java 序列化框架。在二进制负载方面，我已成为 Apache Fory 的忠实拥趸——它在官方网站上宣称“快如闪电”，事实也确实如此。在这些对比中，我区分了 JSON 和二进制负载两类场景：Jackson 是 JSON 序列化（Kotlin 亦然）的王者，而 Apache Fory 则在二进制负载上称雄。
在 Apache Fory 最近发布的 1.7.0 版本中,JSON 支持作为主打新特性加入。自然而然,我满怀好奇,把 Fory JSON 加进了我的序列化演示项目。看到自己负载的测试数字时,我简直不敢相信:Fory 竟然比 Jackson 慢 2.8 倍。这里面一定有问题,我决定追查到底。
Java 与 Kotlin:谁能更快地(反)序列化?
在上一篇文章中,我对 Java 序列化框架进行了性能分析,发现 Apache Fory 以巨大优势击败了 Java 原生序列化和其他竞争者。这让一些人开始关注一个问题:Kotlin 的框架相比之下表现如何。Kotlin 生态拥有自己的序列化库,最著名的是具备编译期代码生成能力的 JetBrains 官方库 kotlinx.serialization,以及采用基于 KSP 的适配器生成的 Moshi。生成代码想必会胜过 Jackson 这类重度依赖反射的 Java 方案吧?
为了弄清答案,我扩展了这个对比项目,加入了一个等价的 Kotlin 数据模型,并用 JProfiler 对序列化往返进行了性能分析。结论是:模型类使用哪种语言编写,影响并不大。不过,其中有一些非常出人意料的发现。
Apache Fory 为什么如此之快?剖析 5 种 Java 序列化框架
JDK 架构师非常不喜欢 Java 序列化,这早已不是什么秘密。它是一场安全噩梦,让每一项新语言特性的实现都变得相当复杂,而且速度还非常慢。这正是其他序列化框架存在的原因。如今有一个新秀声称具备令人瞩目的性能:Apache Fory。在这篇博文中,我们将检验它是否名副其实(它以前名为 "Fury"),并将其与现有的主流框架进行比较。
为了进行比较,我用五种不同的框架剖析了一个真实对象图的序列化与反序列化往返过程:
- Java 序列化
- Kryo
- Apache Fory
- Jackson(同时使用 JSON 和 CBOR 后端)
剖析数据解释了为什么 Apache Fory 遥遥领先,以及 Java 序列化所做的大部分工作为什么其实并不是序列化本身。
推出 jvmguard：生产环境自动化剖析
JProfiler 背后的团队推出了一款全新的开源工具：jvmguard 可帮助您的公司对生产环境中的 JVM 进行剖析。
在生产环境中进行剖析存在风险，但这往往也是理解问题的唯一途径。借助 jvmguard，剖析采集会经过授权与审计，并且可以由人工、自动触发器或 AI 智能体启动。
jvmguard 可以与 JProfiler 配合使用，但并不局限于这一集成。它还可以记录 JFR 快照、HPROF 堆转储和线程转储，您可以使用其他工具对其进行分析。jvmguard 的基本理念是：轻量级信号始终开启，而深度采集只在特定条件下才会进行。
让 JProfiler MCP 服务器对较弱模型更加稳健
旗舰模型并不适合所有编码任务。它们速度慢，而且成本高昂。因此许多任务，尤其是琐事类任务，更适合交给响应更敏捷、成本只有其零头的较低档模型。然而，这些模型的工具调用行为可能比顶级模型更加不稳定。
在 JProfiler 16.1 中，我们添加了一个 MCP 服务器，让 AI 编码代理能够对 Java 应用程序进行性能分析并分析结果。这一功能收到了客户的大量积极反馈，因此这是我们打算在即将发布的版本中继续拓展的一个领域。
在初始发布时，我们的测试主要使用 Claude Code 完成。对于 JProfiler 16.2，我们已经使 MCP 服务器对其他 AI 模型更加稳健。请继续阅读，了解其他模型出了哪些问题，以及我们如何让性能分析工作流能够抵御它们的缺陷。
JProfiler 16.2：从命令行进行性能分析
JProfiler 16.2 让离线性能分析方便了许多。“离线性能分析”是指在不使用 JProfiler GUI 的情况下进行性能分析的模式。它适用于 CI 服务器、容器和生产系统。在以前的 JProfiler 版本中，必须通过命令行、借助从 JProfiler GUI 导出的配置文件将性能分析设置传递给代理，随后还需要通过 Controller API、JProfiler MBean 或 “jpcontroller” 命令行工具来执行记录命令。
对于许多场景而言，这种工作流程过于繁琐。我们现在引入了一种务实的方法：最常用的性能分析设置以及简单的自动记录序列可以直接在命令行上设置，既可以在 -agentpath VM 参数中设置，也可以在 jpenable 附加工具中设置，还可以在 Gradle 和 Ant 性能分析任务中设置。这不仅是对自动化任务的极大简化，也极大地惠及了命令行上的最新成员：AI 智能体。
我如何借助 JProfiler MCP 让 jclasslib 的性能翻倍
最近，我借助 Codex 和一个性能分析智能体，提升了我的开源 JVM 字节码查看器 jclasslib 的性能。这并不是因为我有某个具体的痛点，而是因为我想试用随 JProfiler 16.1 一起发布的 MCP 服务器。请继续阅读，了解这个智能体如何让类文件读取提速一倍以上，以及为什么性能分析不再需要理由就能开始。
Claude 仅靠阅读代码永远无法找到的热点
CommaFeed 是我日常使用的 RSS 阅读器。它是开源的,其作者在 commafeed.com 上运行着一个免费的公共实例。每次我刷新订阅源时,都是别人的服务器在承担这些工作。因此,当我想弄清楚这些工作究竟消耗在哪里时,我把 Claude Code 和 JProfiler MCP 指向了它。
最终,一项数据库优化被合并进了 CommaFeed。这个修复本身并不复杂,但 Claude 仅凭源代码是不可能想出它的。事后我问过它,它也证实了这一点:它的第一直觉本会修错地方。请继续阅读,看看连接到 JProfiler MCP 服务器的 Claude Code 如何带我从好奇心走向一个已合并的 PR。
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 编码工具协同工作。