首先确定OOM类型，如堆内存、元空间、栈或直接内存溢出；通过-XX:+HeapDumpOnOutOfMemoryError生成dump文件，结合MAT、JVisualVM、Arthas等工具分析内存使用；利用jstat、jmap、jstack监控GC、对象分布和线程状态；针对内存泄漏、缓存未设限、大对象创建、类加载器泄漏等问题，优化代码并调整JVM参数，如设置MaxMetaspaceSize、MaxDirectMemorySize，使用线程池控制线程数量，预防性配置监控系统实现早期预警。
Java中发生OOM（OutOfMemoryError）时，系统会提示内存不足，常见于堆内存、元空间、栈内存或直接内存耗尽。排查和解决这类问题需要结合日志、工具和代码分析，以下是常用的诊断手段和解决方案。
1. 明确OOM类型和错误信息
首先查看异常堆栈信息，确定是哪种类型的OOM，不同类型的处理方式不同：
- java.lang.OutOfMemoryError: Java heap space：堆内存不足，最常见，通常是因为对象过多且无法被回收。
- java.lang.OutOfMemoryError: Metaspace：元空间溢出，类加载过多（如动态生成类、频繁重载类）导致。
- java.lang.OutOfMemoryError: unable to create new native thread：线程数超限，可能线程未正确释放或系统限制。
- java.lang.OutOfMemoryError: Direct buffer memory：直接内存溢出，使用NIO时ByteBuffer.allocateDirect()分配过多。
根据错误类型缩小排查范围，避免盲目优化。
2. 启用JVM内存Dump功能
让JVM在发生OOM时自动生成堆转储文件（heap dump），便于后续分析：
立即学习“Java免费学习笔记（深入）”；
-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/path/to/dump.hprof -XX:+PrintGCDetails
dump文件生成后，可以用以下工具打开分析：
- Eclipse MAT (Memory Analyzer)：可快速定位内存泄漏对象、支配树（Dominator Tree）、GC Roots路径。
- JVisualVM 或 JConsole：JDK自带，可连接运行中的进程查看内存使用情况。
- Arthas：阿里开源的Java诊断工具，支持线上环境实时监控和dump操作。
3. 使用监控和诊断工具
在应用运行期间观察内存变化，有助于提前发现问题：
- jstat -gc：查看GC频率和各区内存使用情况，如果老年代持续增长且Full GC效果差，可能存在内存泄漏。
- jmap -histo：打印堆中对象数量和占用大小，找出实例最多的类。
- jstack：分析线程栈，排查是否有大量线程堆积或死锁导致内存占用。
- arthas dashboard：实时查看内存、线程、GC等指标，适合生产环境。
4. 常见原因与修复建议
根据分析结果，针对性地修复问题：
- 内存泄漏：集合类（如Map、List）被静态引用或缓存未清理，确保不再使用的对象能被GC回收，必要时使用WeakReference或SoftReference。
- 缓存未设上限：使用Guava Cache或Caffeine时设置最大容量和过期策略。
- 大对象频繁创建：避免一次性读取大文件到内存，改用流式处理。
- 元空间溢出：增加元空间大小 -XX:MaxMetaspaceSize=512m，检查是否有类加载器泄漏（如热部署场景）。
- 线程过多：使用线程池代替new Thread()，合理设置线程池大小。
- 直接内存问题：减少DirectByteBuffer的频繁分配，或调大-XX:MaxDirectMemorySize。
基本上就这些。关键在于先定位类型，再通过dump和工具分析对象来源，最后从代码和JVM参数两方面调整。日常开发中建议配合监控系统（如Prometheus + Grafana）提前预警内存趋势，防患于未然。
