OutOfMemoryError 是 JVM 级别严重错误，不可捕获处理；应通过合理内存配置、GC 监控、堆转储诊断及代码层防御（如软引用、分页加载）来预防和应对。
OutOfMemoryError 不是普通异常，不能也不该用 try-catch 捕获处理。它是 JVM 级别的严重错误，表示堆、元空间或直接内存等已彻底耗尽，JVM 无法继续安全运行。此时程序状态不可靠，强行捕获并“继续执行”极易导致数据错乱、逻辑崩溃或静默失败。
为什么不能 catch OutOfMemoryError
– 它继承自 Error 而非 Exception，语义上属于“不应被应用程序处理”的系统级故障
– 即使 catch 到，JVM 很可能已处于不稳定状态：GC 频繁失败、线程挂起、部分对象无法构造、类加载中断
– 常见误操作如在 catch 块中记录日志、发送通知或尝试清理缓存，反而会触发新一轮内存分配，加剧崩溃
正确应对策略：预防 + 监控 + 快速响应
1. 启动时预留安全余量
– 设置合理的 -Xms 和 -Xmx，建议两者相等（避免动态扩容开销），例如：-Xms2g -Xmx2g
– Java 8+ 移除永久代，需关注元空间：添加 -XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=512m
– 处理大文件或批量数据时，显式限制单次加载量（如分页读取、流式解析）
2. 构建期与运行期主动监控
– 在 JVM 启动参数中加入 GC 日志：-Xlog:gc*:gc.log:time,tags,level（Java 9+）
– 使用 VisualVM、JConsole 或 Prometheus + JMX 持续观察堆使用率、GC 频次和停顿时间
– 当老年代使用率持续 >85% 或 Full GC 频繁（如每分钟多次），视为高危信号，需立即干预
3. 发生后快速止损与诊断
– 自动触发堆转储：添加参数 -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/path/to/dumps/
– 配合 -XX:OnOutOfMemoryError="kill -9 %p"（Linux）强制终止进程，防止僵尸状态拖垮整个服务
– 用 Eclipse MAT 或 JProfiler 分析 dump 文件，聚焦：最大对象集合、GC Roots 引用链、重复实例类名
代码层面可做的防御性措施
– 对大对象（如 byte[]、List
