4

如果满足以下条件，解决 Java VM 崩溃的最佳做法是什么：

  • 没有自己的或第三方的本机代码。100% 纯 Java
  • 相同的程序在许多其他系统上运行没有任何问题。

PS：VM崩溃的意思是VM写一个像hs_err_pid1234.log这样的转储文件并终止。

4

5 回答 5

4

阅读 hs_err_pid1234.log 文件（或任何错误日志文件名）。里面一般都有线索。下一步取决于您在日志中发现的内容。

是的，这可能是您正在使用的特定 JVM 实现版本中的错误，但我也看到了操作系统中内存碎片引起的问题。例如，Windows 很容易将 dll 固定在不适当的位置，因此当 JVM 要求时无法分配连续的内存块。其他 out opf 内存问题也可以通过这种类型的故障转储表现出来。

于 2008-10-22T11:13:23.797 回答
3

更新或更换您的 JVM。如果您当前拥有最新版本，请尝试使用旧版本，或者如果您没有最新版本，请尝试更新到它。也许它在您的特定版本中是一个已知问题？

于 2008-10-22T11:03:39.743 回答
2

Assuming the JVM version across machines is the same:

Figure out what is different about the machine where the JVM is crashing. Same OS and OS version? We have problems with JVMs crashing on a particular version of Red Hat for example. And we have also found some older Red Hat versions unable to cope with extra memory properly, resulting in running out of swap space. (Our solution was to upgrade RedHat).

Also, is the program doing exactly the same thing across machines? Is it accessing a shared filesystem? Is the file system mounted similarly on your machines (SMB/NFS etc)? Something must be different.

The log file should give you some idea of where the crash occurred (malloc for example).

于 2008-10-22T11:41:10.107 回答
0

查看转储文件中的堆栈跟踪，因为它应该告诉您崩溃发生时发生了什么。

除了深入研究hs_err转储文件之外，我还将它提交给 Sun 或制作你的 JVM 的任何人（我相信文件顶部有关于如何执行此操作的说明？）。它伤不起。

于 2008-10-22T14:22:46.630 回答
0

32位？64位？客户端机器中的内存量？处理器？操作系统？查看系统之间是否有任何连接。一个连接可能会导致一个线索。如果一切都失败了，请考虑使用不同的主要/次要版本的 JVM。此外，如果问题刚刚开始，您能否到达程序没有崩溃的时间（通过版本控制）？查看 hs_err 日志，您可能会了解导致崩溃的原因。它可能是 JVM 使用的其他一些客户端库的一个版本。最后，在 debug/profile 中运行程序，也许你会在崩溃前看到一些症状（假设你可以复制它）

于 2008-10-23T11:45:14.327 回答