在 Java 生态中，java.lang.OutOfMemoryError 并不是一个单一的错误，而是 JVM 资源耗尽的一种统称。工程师在看到日志中抛出 OOM 时，必须立即区分引发错误的具体区域。最常见的两种情况是 Java heap space 和 Metaspace 溢出。两者的成因截然不同，排查思路也有很大差异。
Java heap space 溢出发生在实例对象无法在堆内存中分配空间时。这通常是因为代码中存在大对象、内存泄漏或是垃圾回收（GC）速度赶不上对象创建的速度。排查堆内存 OOM 的标准动作，是在启动参数中加上 -XX:+HeapDumpOnOutOfMemoryError 和 -XX:HeapDumpPath=/data/logs/heapdump.hprof。当 OOM 发生时，JVM 会自动将当前的堆内存快照保存下来。
获取快照后，使用 Eclipse MAT (Memory Analyzer Tool) 是分析的利器。通过 MAT 的 “Leak Suspects”（泄漏嫌疑人）报告，可以快速定位占据堆内存绝大部分空间的集合或对象链。如果是从数据库中一次性查出了百万级数据加载到 List 中，或是 ThreadLocal 没有在 finally 块中调用 remove() 导致引用无法释放，MAT 的支配树（Dominator Tree）都能给出明确的线索。
而 Metaspace（元空间）溢出则与类的元数据有关。自从 Java 8 将方法区移至本地内存后，Metaspace 的大小不再受限于 JVM 堆内存，而是受限于 -XX:MaxMetaspaceSize 和主机的可用物理内存。如果抛出 OutOfMemoryError: Metaspace，意味着 JVM 加载的类结构数据耗尽了分配的内存。
Metaspace 溢出的根本原因往往是类的动态生成失控。例如使用了大量的 CGLib、ASM 字节码生成技术，或是脚本语言引擎（如 Groovy）在运行时不断编译新类，且旧类加载器没有被正确卸载。排查时，需要检查代码中是否有无限循环生成动态代理的逻辑，或者通过 -XX:+TraceClassUnloading 参数观察类卸载情况。
橙星云技术团队在设计复杂的心理测评量表引擎时，由于需要动态解析并编译海量的评估规则，曾重点关注过 Metaspace 的水位。通过合理设置元空间上限并优化类加载器的生命周期，确保了动态脚本类的正常回收。
无论是 Heap 还是 Metaspace，深入理解其运作机制是解决 OOM 的基础。依赖堆栈快照与 GC 日志的相互印证，工程师能够穿透异常表象，精准锁定那行存在缺陷的代码。