直接看日志错误类型和GC行为可快速定位问题：Java heap space为堆内存不足，Metaspace为类加载过多，Direct buffer memory为NIO直接内存未释放，unable to create new native thread为线程数超限，GC overhead limit exceeded表明堆近满且对象难回收。
直接看日志里的错误类型和 GC 行为，就能快速圈定问题区域。
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
先盯住错误信息，分清是哪块内存满了
每种 OutOfMemoryError 都对应特定内存区域：
-
Java heap space→ 堆内存不足，重点查对象堆积或泄漏 -
Metaspace→ 类加载过多，常见于热部署、CGLIB 动态代理、反射滥用 -
Direct buffer memory→ NIO 直接内存超限，和-Xmx无关，得查ByteBuffer.allocateDirect()是否未释放 -
unable to create new native thread→ 线程数超系统限制，多因线程池无界或递归创建线程 -
GC overhead limit exceeded→ GC 花了 98% 时间只回收不到 2% 内存，说明堆快满了且对象难回收
再翻 GC 日志，看三组数字的变化趋势
找到日志中类似这样的行：[PSYoungGen: 8192K->1024K(9216K)] [ParOldGen: 5120K->9216K(9216K)]
重点关注：
- 年轻代（YoungGen）使用率长期 >95%，Minor GC 频繁但每次只回收一点点 → 可能 Survivor 太小、对象存活率高，或大对象直接进老年代
- 老年代（OldGen）占用持续缓慢上升，Full GC 后仅从 98% → 95%，释放量极小（如几十 KB）→ 典型内存泄漏信号
- Full GC 耗时越来越长（>1s），但 OldGen 使用率几乎不变 → 对象强引用未断，无法被回收
最后确认日志末尾有没有明确 OOM 提示
有报错就往上回溯几行，找最后一次 Full GC 前后的内存快照，比对 Eden、Survivor、Old 的 used 值变化。
没有明显报错但 Full GC 越来越频繁、间隔越来越短 → 很可能是泄漏初期，还没触发最终 OOM。
不复杂但容易忽略
