OutOfMemoryError是Error的子类，表示JVM内存耗尽，虽不可完全恢复，但可捕获用于日志记录、触发清理或优雅降级；可通过try-catch在关键线程中捕获，结合-XX:+HeapDumpOnOutOfMemoryError等JVM参数生成堆转储文件辅助分析；预防更关键，应监控内存使用、限制缓存大小、使用软引用、设置内存阈值预警；线程级处理可避免整体崩溃，根本解决需依赖JVM调优、堆分析与内存优化。
Java中的OutOfMemoryError不是普通的异常，而是Error的子类，表示JVM内存资源耗尽，无法继续执行。虽然它不能像普通异常那样通过常规手段完全“恢复”，但可以进行捕获、记录和有限处理，帮助排查问题或实现优雅降级。
1. 捕获OutOfMemoryError的基本方式
尽管不推荐在生产环境中广泛捕获Error类型，但在某些关键模块中，可以通过try-catch块捕获OutOfMemoryError，用于日志记录或触发清理逻辑。
示例代码：
try {
// 可能导致内存溢出的操作
List
注意：一旦发生OutOfMemoryError，JVM状态可能不稳定，部分对象仍可能处于不可用状态，因此不应依赖程序继续正常运行。
立即学习“Java免费学习笔记（深入）”；
2. 使用JVM参数辅助诊断
捕获Error只是应急手段，更重要的是提前配置JVM参数，帮助定位问题根源。
- -XX:+HeapDumpOnOutOfMemoryError：发生OOM时自动生成堆转储文件（hprof）
- -XX:HeapDumpPath=/path/to/dump.hprof：指定堆转储文件保存路径
- -XX:+PrintGCDetails 和 -Xlog:gc*：输出GC详细日志，观察内存回收情况
例如启动参数：
java -Xmx512m -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=./oom.hprof MyApp
生成的dump文件可用VisualVM、Eclipse MAT等工具分析，找出内存泄漏点。
3. 预防与主动监控策略
比起事后捕获，更有效的方式是预防和监控内存使用。
- 定期检查堆内存使用情况，可通过Runtime.getRuntime().totalMemory()和freeMemory()估算使用率
- 对缓存使用软引用（SoftReference）或弱引用（WeakReference），允许JVM在内存紧张时回收
- 限制缓存大小，使用LRU等策略避免无限增长
- 在高负载服务中设置内存阈值，接近上限时拒绝新请求或触发清理任务
示例：简单内存预警
if (usedMemory / maxMemory > 0.8) {
System.warn("内存使用超过80%，建议检查或清理缓存");
}
4. 线程级别的OOM处理建议
如果某个线程因大量对象分配引发OOM，而其他线程仍需运行，可在该线程内捕获Error并退出，避免整个应用崩溃。
例如在独立线程中处理大数据：
new Thread(() -> {
try {
// 执行高内存操作
} catch (OutOfMemoryError e) {
System.err.println("线程内存溢出，已终止");
Thread.currentThread().interrupt();
}
}).start();
这种做法适用于批处理或异步任务场景。
基本上就这些。捕获OutOfMemoryError可用于日志记录和有限响应，但重点应放在预防、监控和问题定位上。合理设置JVM参数、分析堆dump、优化内存使用才是根本解决之道。
