Java等价于未捕获异常上的coredump

Linux coredump或Windows minidump的Java等价物是什么？我读过关于堆转储的文章，看起来像是我想要的，但是如何在未捕获异常时（自动）触发它们呢

我知道uncaught异常处理程序，我已经在使用它打印异常+堆栈跟踪并终止整个应用程序（否则线程会死，应用程序会继续运行？嗯？），我还发现了如何从代码中记录堆转储，但是如果我从未处理的异常处理程序中执行此操作，Java已经捕获了异常，堆栈跟踪（和参数）也消失了

我遇到了

-XX:+HeapDumpOnOutOfMemoryError

标志，它似乎做了我需要的事情，不幸的是，只针对内存不足的异常，而不针对其他未捕获的异常

到目前为止，这是我能从谷歌得到的唯一东西。目前，我正在使用带有异常断点的附加调试器，但这是不切实际的，因为它也会在处理的异常上中断，所以不能在无监督的情况下使用

[动机更新]

---

我希望能够检查堆栈跟踪的参数和局部变量，以找出导致异常的原因。它通常是空引用异常或失败的断言，我不能总是从行号猜测到底出了什么问题。在C/C++中，我习惯于使用coredump/minidump崩溃，然后进一步检查导致崩溃的实际原因。

我认为堆转储不是您想要的。它只是堆的一个转储，打开该开关的原因是，如果出现OOM异常，您可能需要调查内存的用途，以便找到泄漏（或其他问题）

---

那正是你想用它们的目的？也许有另一种更好的方法来满足您在java中的需求。我不认为我需要java的核心或小型转储。除了我希望有一种调用abort（）的方法，以便能够研究代码是如何结束的情况以外。

如果不执行JNI并调用本机代码，很难破坏JVM的内存，异常不应该需要堆转储或核心转储

在java世界中，引发异常的代码预计将为读取异常的人提供足够的信息，以便能够确定问题的原因。有时这种情况不会发生，正确的处理方法是修改异常引发代码以在异常中提供更多信息，或者将某些内容记录到日志文件中

如果抛出异常的代码不在您的控制之下，并且您没有访问源代码的权限，那么您可以使用AspectJ编写一些关于抛出异常的方法的建议，然后您可以检查aspect中的函数参数并记录它们。但是，在您开始路由aspectJ/字节代码编织之前，您可能想看看您试图理解的代码是否使用log4j或其他具有调试日志级别的日志框架，这可能包含您要查找的信息

您可能想看看Google Guava开源库，它有一个关于预conidtions的不错的部分，您可以使用它来验证参数，并获得有关问题原因的更多上下文

您还需要了解哪一个具有良好的日志api，您可以使用它来记录有关遇到的问题的信息

您还可以在eclipse中执行条件断点，这允许您仅在特定情况下执行断点

---

另一个要使用的工具是jvisualvm，它允许您连接到一个活动的vm，并了解很多关于vm内部发生的事情的信息，比如所有线程在哪里，如果有死锁，GC在做什么，您可以使用它触发heapdump，然后查询它们并查看堆转储中特定对象的状态

Oracle的这篇博客介绍了如何通过编程方式进行堆转储：

它基本上使用了Hotspot的

com.sun.management.HotSpotDiagnosticMXBean

及其

dumpHeap（）方法。它可能只适用于Oracle/Sun JVM，不保证它在遥远的将来能够工作

然而，困难的部分是，一旦您拥有了这个堆转储，如何从中获取有用的信息。我想象你会从找到新抛出的异常对象开始，然后从那里开始。堆转储无法帮助您将方法参数和局部变量值作为原语和引用的内容不会出现在堆转储中
 我想检查堆栈跟踪的参数，以及可能可以从它们访问的对象。堆栈跟踪只是告诉我发生了什么错误，而不是什么原因造成的。堆转储在这方面对您毫无帮助。我建议更改代码以抛出适当的异常，或者（如果是第三方库）更改为可以按预期工作的代码。如果不是在客户站点进行事后调试，而是在开发阶段，那么任何调试器都应该足够了。请参阅@ams answer以获得更详细的解释。好吧，但我想做“事后调试”，这是一个游戏服务器应用程序，有很多交互在进行，因此，在附加了调试器的情况下第二次复制可能不太明显。但是谢谢你的关键词，也许我可以在事后调试中找到一些东西。如果你控制服务器的话。也许您可以编写一个UncaughtExceptionHandler，它可以在终止之前存储尽可能多的关于当前状态的信息？我在谷歌上搜索的第一个链接是这个链接，它可能已经过时了，但可以作为一个起点。好吧，就像我已经写的，在未捕获的异常处理程序中，堆栈已经被解开了，所以“尽可能多的信息”只是堆栈跟踪，缺少最多的im