当 Java 进程的内存使用超过 JVM 设置的最大内存限制时，具体会发生以下情况，取决于内存溢出的区域和配置：
1. 堆内存溢出（Heap Memory Exhaustion）
触发条件：对象分配请求超过
-Xmx（最大堆内存）设置，且垃圾回收（GC）无法释放足够空间。表现：
JVM 抛出
java.lang.OutOfMemoryError: Java heap space。进程可能崩溃（如果未捕获异常）或进入不可恢复状态。
常见原因：
内存泄漏：对象因错误引用无法被 GC 回收（如静态集合缓存数据未清理）。
堆内存不足：业务负载超出
-Xmx配置的容量。
解决方案：
使用
jmap或jvisualvm分析堆转储（Heap Dump）。增加
-Xmx参数（需结合物理内存容量）。修复代码中的内存泄漏（如及时释放资源、避免全局缓存失控）。
2. 元空间溢出（Metaspace Overflow）
触发条件：加载的类信息、方法元数据等超出
-XX:MaxMetaspaceSize设置。表现：
JVM 抛出
java.lang.OutOfMemoryError: Metaspace。常见于动态生成类（如反射、字节码增强框架）或未限制元空间大小的场景。
解决方案：
增加
-XX:MaxMetaspaceSize（默认无上限，依赖系统内存）。检查类加载器泄漏（如未关闭的 WebApp 上下文）。
3. 直接内存溢出（Direct Memory Overflow）
触发条件：堆外内存（如
ByteBuffer.allocateDirect()）超出-XX:MaxDirectMemorySize。表现：
JVM 抛出
java.lang.OutOfMemoryError: Direct buffer memory。常见于高频 NIO 操作（如网络传输、文件读写）未合理管理
DirectByteBuffer。
解决方案：
限制直接内存使用：
-XX:MaxDirectMemorySize=256m。优化代码，复用
DirectByteBuffer或及时释放。
4. 栈溢出（Stack Overflow）
触发条件：线程栈深度（如递归调用）超过
-Xss设置的栈大小。表现：
JVM 抛出
java.lang.StackOverflowError。进程可能崩溃或线程终止。
解决方案：
增大线程栈：
-Xss2m（默认通常为 1MB）。优化代码逻辑，减少栈深度（如将递归改为迭代）。
5. 系统内存耗尽（OS-Level OOM）
触发条件：Java 进程总内存（堆 + 元空间 + 直接内存 + 其他）超出操作系统可用内存。
表现：
Linux 内核触发 OOM Killer，强制终止进程（日志见
/var/log/messages）。提示
Killed process <pid> (java)。
解决方案：
限制容器内存（如 Docker
-m 4g）并调整 JVM 参数适配。使用
-XX:+UseContainerSupport让 JVM 自动感知容器内存限制。优化应用程序内存占用。
关键配置参数
| 内存区域 | JVM 参数 | 默认行为 |
|---|---|---|
| 堆内存（Heap） | -Xms（初始堆）, -Xmx（最大堆） |
未设置时默认根据系统内存动态分配 |
| 元空间（Metaspace） | -XX:MaxMetaspaceSize |
默认无限制（使用系统内存） |
| 直接内存（Direct） | -XX:MaxDirectMemorySize |
默认与 -Xmx 相同 |
| 线程栈（Stack） | -Xss |
通常默认 1MB/线程 |
诊断工具
1）堆内存分析：
jmap -dump:format=b,file=heap.hprof <pid>：生成堆转储文件。Eclipse MAT 或 VisualVM：分析堆转储，定位泄漏对象。
2）实时监控：
jstat -gc <pid>：查看 GC 统计信息。jcmd <pid> VM.native_memory：追踪本地内存使用。
3）系统级监控：
top、htop：查看进程实际内存占用。dmesg | grep -i oom：检查系统 OOM 事件。
总结
JVM 内存溢出：通过
OutOfMemoryError类型定位问题区域，针对性优化。系统级内存耗尽：需结合容器化配置和系统监控，避免资源争抢。
终极原则：合理设置 JVM 参数 + 代码内存优化 + 监控告警。