据孙：
Error 是 Throwable 的子类，表示合理的应用程序不应尝试捕获 的严重问题
我不同意这个建议，因为可能会捕获错误并且应用程序可以继续（我的意思不是让抛出Errorlive 的线程。那个线程已经死了；其余的应用程序仍然存在）。这样的错误是 OutOfMemory。
认为这是正确的（如果您认为我在这里错了，我很乐意在这里提出论点）我想知道您是否尝试在应用程序中实现某种监视代码。
举一个具体的例子：我正在考虑在现有应用程序中放置一个小类，该类从日志中检测各种错误（例如 OOM）并创建某种健康统计信息，以便在出现问题时重新启动 JVM。
例如，如果检测到过多的 OutOfMemoryErrors，则重新启动 JVM。太多可能是某种门槛。老实说，我不知道如何计算这个阈值。也许与其他错误类似。
我想知道这样的机制有用吗？你做过类似的事情吗？如果是，您有什么建议或示例代码吗？还是我走错了路，应该以其他方式思考？
通常，一旦你点击 OutOfMemory，你就会被搞砸了——JVM（这可能有点不准确，从内存中）在它已经运行完整的 GC 并且无法释放足够的内存之前不会抛出这个。
我能想到的最接近您正在寻找的东西是使用 -XX:printGC 和 -XX:printGCdetails输出 GC 活动并从外部脚本触发重置。
但是，如果您的应用程序经常耗尽内存，则可能表明您应该修复一个问题。
这样的东西可能有用，但我自己没有使用过。我尝试做的一件事是避免根据客户的要求分配内存。
想想像 HTTP 分块编码的处理器。每个块都以长度为前缀。您可以分配该长度的缓冲区，然后将数据读入其中，这实际上是大多数服务器所做的，因为它既快速又简单。
但我更喜欢使用 a 之类的东西ByteArrayOutputStream，它可以根据需要增长。当我开始解析时，我将输入流包装在一个长度限制的装饰器中，如果读取的数据总量过大，它会抛出异常。
该限制可以为应用程序配置。因此，例如，如果我正在处理表单，我可能会将输入限制为几千字节。如果我支持图片上传，可能只有几兆字节。但是，如果某个小丑声称要发送数 GB 的块，我不希望我的服务器盲目地尝试为其分配缓冲区。