文档java.lang.Error的文档说：
Error是Throwable的子类，表示应用程序不应该尝试捕获的严重问题
但是由于java.lang.Error是java.lang.Throwable的子类，我可以捕获这种类型的Throwable。
我理解为什么捕获这种异常不是一个好主意。据我所知，如果我们决定捕获它，catch处理程序不应该自己分配任何内存。否则会再次抛出OutOfMemoryError。
所以，我的问题是：
java.lang.OutOfMemoryError可能是个好主意？java.lang.OutOfMemoryError，如何确保catch处理程序不会自己分配任何内存（是否有任何工具或最佳实践）？OutOfMemoryError异常，在我个人的经验中（在Windows和Solaris JVM上），仅极少数情况下OutOfMemoryError会导致JVM崩溃。OutOfMemoryError，那就是要优雅地关闭，清除资源并记录失败原因（如果仍然可能这样做的话）。OutOfMemoryError是由于无法满足剩余堆资源的块内存分配而引起的。Error时，堆包含与不成功分配之前相同数量的已分配对象，现在是丢弃对运行时对象的引用以释放更多可能需要进行清理的内存的时候了。在这些情况下，可能仍然可以继续，但这绝对是个坏主意，因为你永远无法100%确定JVM是否处于可修复状态。OutOfMemoryError不意味着JVM已耗尽内存：private static final int MEGABYTE = (1024*1024);
public static void runOutOfMemory() {
MemoryMXBean memoryBean = ManagementFactory.getMemoryMXBean();
for (int i=1; i <= 100; i++) {
try {
byte[] bytes = new byte[MEGABYTE*500];
} catch (Exception e) {
e.printStackTrace();
} catch (OutOfMemoryError e) {
MemoryUsage heapUsage = memoryBean.getHeapMemoryUsage();
long maxMemory = heapUsage.getMax() / MEGABYTE;
long usedMemory = heapUsage.getUsed() / MEGABYTE;
System.out.println(i+ " : Memory Use :" + usedMemory + "M/" +maxMemory+"M");
}
}
}
以下是此代码的输出结果：
1 : Memory Use :0M/247M
..
..
..
98 : Memory Use :0M/247M
99 : Memory Use :0M/247M
100 : Memory Use :0M/247M
如果运行的是一些关键任务，我通常会捕获Error，将其记录到syserr，并使用我所选择的日志框架进行记录，然后清理资源并以清晰的方式关闭。最坏的情况是什么？ JVM已经崩溃（或已经死亡），通过捕获Error，至少有机会清理。
需要注意的是，您必须只在可以进行清理的地方针对这些类型的错误进行捕捉。不要像catch(Throwable t){} 这样无意义地覆盖所有地方。
你可以从中恢复：
package com.stackoverflow.q2679330;
public class Test {
public static void main(String... args) {
int size = Integer.MAX_VALUE;
int factor = 10;
while (true) {
try {
System.out.println("Trying to allocate " + size + " bytes");
byte[] bytes = new byte[size];
System.out.println("Succeed!");
break;
} catch (OutOfMemoryError e) {
System.out.println("OOME .. Trying again with 10x less");
size /= factor;
}
}
}
}
但这有意义吗？你还想做什么？为什么最初要分配那么多内存？使用更少的内存也可以吗？为什么不早点利用它呢？或者如果不可能，为什么不从一开始就给JVM更多的内存呢？
回到你的问题:
1：是否存在真正的场景，捕获 java.lang.OutOfMemoryError 可能是一个好主意?
我想不到任何场景。
2：如果我们捕获java.lang.OutOfMemoryError，如何确保 catch 处理程序本身不会分配任何内存（有哪些工具或最佳实践）？
这取决于导致 OOME 的原因。如果它在try块之外被声明并且逐步发生，那么您的机会很小。您可以预先保留一些内存空间:
private static byte[] reserve = new byte[1024 * 1024]; // Reserves 1MB.
然后在 OOME 期间将其设置为零：
} catch (OutOfMemoryException e) {
reserve = new byte[0];
// Ha! 1MB free!
}
当然这样做没有任何意义;)只需要根据你的应用程序需求为JVM分配足够的内存。必要时运行分析器。
null ？ - Pacerier一般来说，试图捕获和恢复OOM并不是一个好主意。
其他线程也可能抛出OOM异常，包括您的应用程序甚至不知道的线程。这些线程现在都已经死亡，任何等待notify的操作都可能永远被卡住。简而言之，您的应用程序可能已经无法修复。
即使您成功地恢复了，您的JVM仍然可能遭受堆饥饿的问题，因此您的应用程序的性能将大为降低。
对于OOM，最好的处理方式是让JVM崩溃。
（这假设JVM确实会崩溃。例如，在Tomcat servlet线程上发生OOM不会使JVM崩溃，这会导致Tomcat进入一种无法响应任何请求的定态状态...即使是要求重新启动的请求）
编辑
我并不是说根本不应该捕获OOM。问题出现在您尝试从OOM中恢复，无论是故意还是由于疏忽。每当捕获OOM（直接或作为Error或Throwable的子类型）时，您都应该重新抛出它或安排应用程序/JVM退出。
另外：这表明，为了在面对OOM时最大程度地保证健壮性，应用程序应该使用Thread.setDefaultUncaughtExceptionHandler()设置一个处理程序，以便在任何线程上抛出OOM时导致应用程序退出。我很想听听您的意见...
唯一的其他情况是您确信OOM没有造成任何副作用，即您知道：
有些应用程序可以知道这些事情，但对于大多数应用程序而言，您无法确定在OOME之后继续操作是否安全。即使在尝试时它表现得很好。
问题在于需要正式证明“预期”的OOME的后果是安全的，并且“未预期”的OOME不能在try/catch OOME的控制范围内发生。
Error子类型执行此操作。 - Stephen C是的，有现实世界的场景。这是我的场景：我需要在内存受限的集群上处理非常多的数据集。给定的JVM实例依次处理许多项目，但其中一些项目太大了，无法在集群上处理：我可以捕获OutOfMemoryError并记录哪些项目太大了。稍后，我可以在具有更多RAM的计算机上仅重新运行大型项目。
（由于是单个多GB分配的数组失败，捕获错误后JVM仍然正常，并且有足够的内存来处理其他项目。）
byte[] bytes = new byte[length] 这样的代码？为什么不在早期检查 size 呢？ - Raedwald有些情况下，捕捉 OOME 是有意义的。例如，IDEA 捕获它们并弹出一个对话框让你更改启动内存设置（然后在完成后退出）。应用服务器可能会捕获并报告它们。关键是在分派的高级别上执行此操作，以便在捕获异常时有合理的机会释放大量资源。
除了上面的 IDEA 场景外，在一般情况下，捕获应该是 Throwable，而不仅仅是 OOM，并且应该在至少线程将要很快终止的上下文中进行。
当然，大多数情况下，内存枯竭且情况不可恢复，但也有一些情况是有道理的。
BitmapFactory.Options bitmapOptions = new BitmapFactory.Options();
bitmapOptions.inSampleSize = 1;
boolean imageSet = false;
while (!imageSet) {
try {
image = BitmapFactory.decodeFile(filePath, bitmapOptions);
imageView.setImageBitmap(image);
imageSet = true;
}
catch (OutOfMemoryError e) {
bitmapOptions.inSampleSize *= 2;
}
}
我通过这种方式，为更多和性能不同的设备提供服务，以满足它们或者说它们的用户的需求和期望。
我有一个应用程序需要从OutOfMemoryError故障中恢复，而在单线程程序中总是有效的，但在多线程程序中有时无法正常工作。该应用程序是一个自动化Java测试工具，它执行生成的测试序列以达到测试类的最大可能深度。现在，UI必须稳定，但是在增加测试用例树时，测试引擎可能会耗尽内存。我通过以下代码惯用语来处理测试引擎中的问题：
boolean isOutOfMemory = false; // 用于报告的标志
try {
SomeType largeVar;
// 分配更多largeVar的主循环
// 可能正常终止，也可能抛出OutOfMemoryError
}
catch (OutOfMemoryError ex) {
// largeVar现在已经超出范围，所以是垃圾
System.gc(); // 清除largeVar数据
isOutOfMemory = true; // 标志可供使用
}
// 程序测试标志以报告恢复情况
这在单线程应用程序中每次都有效。但最近，我将我的测试引擎放入了与UI不同的工作线程中。现在，内存不足可能在任何一个线程中任意发生，并且对于如何捕获它并不清楚。
例如，当我的UI中的动画GIF的帧正在被一个由Swing类在幕后创建的专有线程循环时，我遇到了OutOfMemoryError。我原以为我已经提前分配了所有所需的资源，但显然动画程序每次获取下一张图片时都在分配内存。如果有人对如何处理在任何线程中引发的OutOfMemoryError有想法，我很乐意听取建议。
是的，真正的问题是“在异常处理程序中你要做什么？” 对于几乎所有有用的操作，您都需要分配更多的内存。如果您想在发生OutOfMemoryError时进行一些诊断工作，可以使用HotSpot VM提供的-XX:OnOutOfMemoryError=<cmd>钩子。它会在发生OutOfMemoryError时执行您的命令，您可以在Java堆之外执行一些有用的操作。您确实希望在应用程序首次运行内存不足时就防止其发生，因此找出原因是第一步。然后您可以根据需要增加MaxPermSize的堆大小。以下是一些其他有用的HotSpot钩子：
-XX:+PrintCommandLineFlags
-XX:+PrintConcurrentLocks
-XX:+PrintClassHistogram
完整列表请点击此处
OutOfMemoryError 可以在程序的任何时刻被抛出（不仅仅是从 new 语句），当您捕获该异常时，程序将处于未定义状态。 - Raedwald虽然可以捕获OOME，但通常情况下这是无用的，这取决于JVM是否能够在到达catch块时进行垃圾回收，并且此时还剩多少堆内存。
例如，在我的JVM中，该程序可以正常运行至完成：
import java.util.LinkedList;
import java.util.List;
public class OOMErrorTest {
public static void main(String[] args) {
List<Long> ll = new LinkedList<Long>();
try {
long l = 0;
while(true){
ll.add(new Long(l++));
}
} catch(OutOfMemoryError oome){
System.out.println("Error catched!!");
}
System.out.println("Test finished");
}
}
然而，只需在catch块中添加一行，即可理解我的意思：
import java.util.LinkedList;
import java.util.List;
public class OOMErrorTest {
public static void main(String[] args) {
List<Long> ll = new LinkedList<Long>();
try {
long l = 0;
while(true){
ll.add(new Long(l++));
}
} catch(OutOfMemoryError oome){
System.out.println("Error caught!!");
System.out.println("size:" +ll.size());
}
System.out.println("Test finished");
}
}
System.out.println行中是一个字符串），堆几乎满了，因此会抛出新的OOME。这是最坏的情况：我们尝试创建一个新对象，失败了，我们捕获了OOME，但现在需要新的堆内存（例如：创建新对象）的第一条指令将抛出新的OOME。想想看，在这种情况下，我们还能用那么少的内存做什么？可能只剩下退出，因此我说这是无用的。ll=null会怎么样？ - Naanavanalla我能想到唯一的捕获OOM错误的原因就是你有一些庞大的数据结构你不再使用，可以将其设置为null并释放一些内存。但这意味着你正在浪费内存，应该修复代码而不是在产生OOM错误后勉强运行。(2)即使你成功捕捉了OOM错误，你又能做什么呢？OOM错误可能会在任何时候发生，潜在地留下一切都未完成的情况。