RocketMQ：底层Netty频繁OS OOM
JVM使用jemalloc分配native内存，排查发现无明显泄漏。通过pmap、gdb分析及Arthas查看Netty堆外内存占用，定位到RocketMQ客户端因Netty直接内存分配导致内存超1G。调整MaxDirectMemorySize引发消息积压，最终确认问题源于Netty内存管理机制。短期方案为压缩Java堆，腾出堆外空间保障MQ可用性。
RocketMQ：底层Netty频繁OS OOM
某核心应用出现少量机器OOM被杀，排查发现容器内存8G，JVM堆4G、MaxDirectMemorySize设为1G，但实际RSS远超预期。通过NMT定位到“Other”内存持续增长，结合Arthas发现7个不同ClassLoader加载了Netty的PooledByteBufAllocator，每个独立占用堆外内存，导致总使用量突破1G限制。其中rocketmq-client实例几乎占满1G，最终确认为多ClassLoader引发的堆外内存超额使用问题。
RocketMQ：A2A协议实现多智能体优化
Apache RocketMQ 推出轻量级通信模型 LiteTopic，专为 AI 多智能体协作设计，支持海量会话、上下文持久化与断点续传。结合 A2A 协议与阿里 AgentScope 框架，实现高可靠、低延迟的智能体通信，助力企业构建稳定高效的多智能体应用。
RocketMQ：A2A协议实现多智能体优化
Agentic AI 时代已至，在智能客服、代码生成、流程自动化等场景中，多智能体（Multi-Agent）协作正从构想走向落地。然而，当多个 Agent 需要像一个团队那样高效协作时，脆弱的通信机制可能因网络抖动或服务宕机，就让整个系统瞬间瘫痪，导致昂贵的计算任务失败、会话状态丢失。如何为这些聪明的“数字员工”们构建一个真正可靠、高效的通信基座？
本文将为您介绍 Apache RocketMQ 全新推出的轻量级通信模型 LiteTopic，如何在 AI 应用场景中有效简化系统架构、提升稳定性与可靠性，并结合 A2A（Agent-to-Agent）协议与阿里巴巴AgentScope 框架的生产
RocketMQ：底层Netty频繁OS OOM
本文记录了一例Java应用因Netty在多个ClassLoader中重复加载PooledByteBufAllocator，导致堆外内存超限引发OS OOM的排查过程。通过NMT、Arthas等工具分析，发现多个中间件独立占用堆外内存，总量远超MaxDirectMemorySize限制。最终定位为RocketMQ客户端大量使用堆外内存所致，建议短期内调整JVM堆内存比例以缓解问题。
RocketMQ：底层Netty频繁OS OOM
前言：此文记录最近一例Java应用OOM问题的排查过程，希望可以给遇到类似问题的同学提供参考。在本地集团，大多数情况下Java堆的大小会设置为容器规格的50%～70%，但如果你设置为50%时还是遇到了OS OOM的问题，会不会无法忍受进而想要知道这是为什么？没错，我也有一样的好奇。
背景
某核心应用的负责同学反馈应用存在少量机器OOM被OS kill的问题。看sunfire监控信息，的确如此。
初步收集到的信息：
容器内存=8G，Java 11，G1 GC=4G，MaxDirectMemorySize=1G。详见下图：
业务同学已经做过Java dump，可以看到堆外对象几乎没有，堆内的使用量
RocketMQ：底层Netty频繁OS OOM
本文记录了一例Java应用因多ClassLoader加载多个Netty的PooledByteBufAllocator，导致堆外内存超限引发OS OOM的排查过程。虽设MaxDirectMemorySize为1G，但7个独立实例各自占用近1G，总量远超限制。通过NMT、Arthas等工具定位问题，最终确认为中间件类加载隔离所致。建议短期调小堆内存腾出空间，长期推动中间件优化。
