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