分布式OOM需从请求流、资源流、配置流三线并进：先据错误后缀（如Java heap space、Metaspace等）锁定失守区域；再通过链路追踪识别热点节点与数据倾斜；接着验证各节点JVM参数一致性；最后用MAT分析堆转储，聚焦跨服务引用与静态集合泄漏。
分布式场景下 Java 内存溢出（OOM）不是单机问题的简单放大，而是多节点协同、网络调用、状态共享共同作用的结果。它往往表现为局部节点突然 OOM，但根因可能藏在服务间的数据倾斜、缓存穿透、线程模型不匹配或配置未统一等环节。排查不能只看单个 JVM 堆内存，得从“请求流+资源流+配置流”三线并进。
看错误后缀，快速锁定失守区域
分布式系统日志量大，第一时间抓取 OOM 错误末尾关键词，决定后续排查方向：
- Java heap space：常见于下游服务被突发流量打穿（如某接口被上游重试风暴击中），或本地缓存未设限（如 Guava Cache 未配置 maximumSize 或 expireAfterWrite）；
- Metaspace：微服务频繁发布/灰度时，类加载器未卸载，尤其 Spring Cloud Gateway + 动态路由 + Groovy 脚本过滤器组合极易触发；
- Direct buffer memory：RPC 框架（如 gRPC、Dubbo 3 的 Triple 协议）大量使用 Netty DirectBuffer，但 -XX:MaxDirectMemorySize 未随堆比例调整；
- unable to create new native thread：线程池未隔离（如共用 Tomcat 线程池处理 HTTP 和 Dubbo 回调），或 Feign 客户端未配置连接池，每次调用新建线程；
- GC overhead limit exceeded：跨服务链路中某节点长期持有大对象引用（如将全量用户画像 Map 存入 ThreadLocal），且该节点 GC 参数未适配高吞吐场景。
查链路与流量分布，识别热点节点
单点 OOM 往往是“果”，背后常有流量不均或数据倾斜：
- 用 SkyWalking / Pinpoint 查看慢调用、高 QPS 接口是否集中在某台实例——确认是不是机器维度负载不均；
- 检查注册中心（Nacos/Eureka）中该实例的元数据标签（如 version、zone）是否异常，导致流量无法正常分发；
- 对比同一服务不同节点的 GC 日志（-Xloggc），若仅某台 Full GC 频繁且耗时飙升，大概率存在本地状态泄漏（如静态 Map 缓存了 region=shanghai 的全量商户）；
- 通过 Arthas 的 thread -n 5 观察 CPU 和线程阻塞情况，确认是否存在线程池打满后任务排队、间接加剧内存堆积。
验配置一致性，避免“隐性雪崩”
分布式系统里，JVM 参数不统一是低级但高频的 OOM 诱因：
立即学习“Java免费学习笔记（深入）”；
- 所有节点必须统一设置 -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/data/dump/，否则故障时无法回溯；
- 堆大小（-Xmx）需按物理内存比例配置，避免容器环境下因 cgroup 限制导致 OOM Killer 杀进程，建议设为容器内存上限的 75%；
- Netty 直接内存默认等于堆大小，若堆设 2G，但 -XX:MaxDirectMemorySize 未显式指定，实际可用仅 2G，而高并发下 DirectBuffer 可能瞬间突破；
- 线程栈大小（-Xss）在容器小内存场景下建议从默认 1M 降至 512k，否则 200 个线程就吃掉 100MB 栈空间。
分析堆转储，聚焦跨服务引用关系
拿到 .hprof 文件后，重点不是找最大对象，而是查“不该跨服务持有的东西”：
- 用 MAT 的 Dominator Tree 看 top 对象，若发现大量 com.alibaba.nacos.client.config.impl.CacheData 或 io.grpc.internal.ManagedChannelImpl 实例，说明配置监听或 gRPC 连接未正确关闭；
- 用 Histogram → Group by package 检查是否有业务包下的静态集合（如 com.xxx.service.cache.UserCacheHolder.cacheMap）长期增长；
- 运行 OQL 查询：SELECT * FROM com.xxx.model.UserProfile WHERE this.age > 100，验证是否因反序列化污染（如 JSON 解析时类型不匹配）导致无效大对象滞留；
- 特别关注 java.lang.ThreadLocal$ThreadLocalMap$Entry 引用链，确认业务线程池是否复用 Tomcat 线程，造成 ThreadLocal 泄漏。
