JProfiler 让 AI 智能体得以有效利用堆转储
JProfiler 16.3 通过其 MCP 服务器将 JProfiler 的所有主要子系统开放给 AI 智能体。其中最实用的新增功能之一是堆转储分析。智能体现在可以检查堆中的对象、追踪它们的引用，并查明它们为何未被垃圾回收。
没有运行时数据，AI 智能体就无法看到哪些对象仍然存活，也不知道是什么使它们保持可达。JProfiler 填补了这一空白，使智能体能够从真实证据出发，并据此找到相关的源代码。
HotSpot 的反击：JEP 544 会终结 GraalVM 的启动性能垄断吗？
HotSpot JVM 迎来了激动人心的时刻：JEP 544: Ahead-of-Time Code Compilation 刚刚被提议纳入 Java 28。它有望让 HotSpot AOT 缓存获得足以媲美 GraalVM 的启动性能，而且完全不必承受 GraalVM 的种种艰辛。但训练 AOT 缓存与 GraalVM 的预编译并不相同，那么两者究竟孰优孰劣？15 个月后 SBOM 将成为强制要求，而你的 SBOM 很可能是错的。
2027 年 12 月 11 日，《欧盟网络弹性法案》（EU Cyber Resilience Act）中的 SBOM 义务将开始生效。这意味着，如果你想在欧盟发行软件，很快就需要一份 SBOM。这不仅是欧盟的要求，更是一场以这种声明式方法强化供应链安全的全球性趋势：美国自 2021 年起就要求联邦软件供应商提供 SBOM，CISA/NSA/FBI 也在今年 7 月发布了更新版的 SBOM 最低要素。
把 SBOM 做对并不容易，而当你还需要为软件交付安装程序时，难度更会进一步加大。现在该怎么办？让我们一起来看一看。
我是如何让 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 服务器。请继续阅读，了解这个智能体如何让类文件读取提速一倍以上，以及为什么性能分析不再需要理由就能开始。