outofmemoryerror需先区分错误类型并定位内存区域，再通过堆转储、jstat、jstack分析；调整-xms/-xmx、gc策略；用mat分析dump文件；调优metaspace与直接内存；修复静态集合、threadlocal、资源未关闭等代码泄漏。
当Java程序运行过程中抛出OutOfMemoryError异常，表明JVM堆内存或元空间等区域已无法分配所需内存。以下是针对该问题的多种排查与调整方法：
一、确认错误类型并定位内存区域
OutOfMemoryError有多种子类型，需先区分具体发生位置，如java.lang.OutOfMemoryError: Java heap space、Metaspace、Compressed class space或unable to create new native thread等，不同区域对应不同调优路径。
1、在启动参数中添加-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/path/to/dump.hprof，使JVM在OOM时自动生成堆转储文件。
2、通过jstat -gc
3、使用jstack
二、调整JVM堆内存参数
通过显式设置初始堆（-Xms）和最大堆（-Xmx）大小，避免堆动态扩容带来的开销，并确保容量匹配应用实际需求。
1、将-Xms与-Xmx设为相同值，例如：-Xms2g -Xmx2g，防止运行期堆伸缩引发的额外GC压力。
2、根据应用对象生命周期特征，调整新生代比例，如添加-XX:NewRatio=2（老年代:新生代=2:1）或直接指定-XX:MaxNewSize=768m。
3、启用G1垃圾收集器并配置目标停顿时间，例如：-XX:+UseG1GC -XX:MaxGCPauseMillis=200，适用于大堆且对延迟敏感的场景。
三、分析堆转储文件定位内存泄漏
获取到.hprof文件后，需借助工具识别长期存活的大对象及其引用链，从而发现未释放的集合、静态缓存、监听器等泄漏源。
1、使用Eclipse MAT（Memory Analyzer Tool）打开dump文件，执行Leak Suspects Report，自动标出疑似泄漏对象组。
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
2、在Dominator Tree视图中按Shallow Heap或Retained Heap排序，查找占用内存最大的类实例。
3、右键选中可疑对象 → Path to GC Roots → exclude weak/soft references，查看强引用链，定位持有该对象的静态字段或长生命周期容器。
四、检查非堆内存相关配置
元空间（Metaspace）或直接内存（Direct Memory）不足也会触发OOM，需单独监控与调优。
1、限制元空间最大容量，添加-XX:MaxMetaspaceSize=512m，避免动态加载大量类导致无节制扩张。
2、若使用NIO ByteBuffer.allocateDirect()，需同步设置-XX:MaxDirectMemorySize=1g，防止直接内存耗尽。
3、验证类加载器是否泄漏：在MAT中筛选ClassLoader实例，检查其loadedClassCount是否持续增长且无对应卸载迹象。
五、代码层面常见泄漏点修复
部分内存泄漏源于编程习惯，无需修改JVM参数即可消除，应优先审查以下典型模式。
1、静态集合类（如static Map）未做清理，每次put操作累积对象，应改用WeakHashMap或定期清除过期条目。
2、ThreadLocal变量未调用remove()，尤其在线程池场景下会导致线程复用时内存持续累积，必须在业务逻辑结束后显式调用ThreadLocal.remove()。
3、数据库连接、文件流、网络Socket等资源未在finally块或try-with-resources中关闭，造成底层本地内存无法释放。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
