如何检查核心转储文件中java应用程序的内存泄漏？
在我的jboss应用程序突然停止，核心转储文件在 /var/crash/path中生成，进程ID为。在同一位置没有生成日志。Java版本是java-1.7.0-openjdk-1.7.0.45。x86_64。我想知道为什么我的应用程序被杀死，这个文件被生成。我怀疑发生了一些内存泄漏导致了这个失败。但是在应用程序日志中没有跟踪。如何调试这个代码转储文件（大约6 GB）
共有1个答案
因为我看不到我们的转储文件，所以我不能确切地说它的内存泄漏。对于内存泄漏检查，在运行的应用程序中有许多工具。在JDK内部，VisualVM工具也位于“JDK/bin”文件夹中。您可以将其指向生产服务器。
提供了其他多种解决方案@https://developers.redhat.com/blog/2014/08/14/find-fix-memory-leaks-java-application/
-
问题内容： 我需要一种 从应用程序内部 请求堆转储 的方法 。 基本原理：当遇到特定的错误情况时，我想转储堆，以便可以看到内存中有什么内容。 但是我想使它自动化（例如，当我检测到某些特定情况发生时。或者当看门狗不再收到ping命令时；当某些测试失败时）。因此，我需要一种从应用程序本身内部转储堆的方法。我似乎无法通过MX bean的东西找到它。尽管MX Bean可以通过监视器和“可拥有的同步器”信息
-
我有一个运行在Tomcat7上的Java web应用程序出现内存泄漏。在负载下（使用JConsole确定），应用程序的平均内存使用量随时间线性增加。在内存使用达到稳定期后，性能会显著下降。响应时间从大约100ms到[300ms,2500ms]，所以这实际上导致了真正的问题。 使用VisualVM，我看到至少一半的内存被字符数组（即char[])使用，而且大多数字符串（每个实例的数量大致相同，为30
-
我想知道，当我们为客户提供新的更新时，是否有丢失这些文件的风险。如果有更好的解决方案，上传文件和获取文件链接之后，与.NET core请告诉我：）
-
问题内容： 我有Java应用程序，不幸的是，它在一段时间后开始消耗大量内存。使事情复杂化的是，它不仅是Java应用程序，还是JavaFX 2应用程序。 我怀疑可能存在一些内存泄漏，甚至在底层JavaFX调用和本机库中也是如此。 理想的解决方案是在某个时刻获取所有java对象的转储（及其内存使用情况），然后分析该转储。有什么办法可以做到这一点？ 问题答案： 有很多方法可以获取堆转储，从简单的工具（例
-
我正在尝试将Java进程的Linux核心转储转换为堆转储文件，适合用Eclipse MAT进行分析。根据这篇博客文章，适应于较新的OpenJDK 12，我创建了一个核心转储，然后运行将转储转换为HPROF格式： 核心转储文件是22GB，而堆转储文件只有3MB，因此命令可能无法处理整个核心转储。此外，Eclipse MAT无法打开堆转储文件，并显示以下消息：
-
问题内容： 我的程序是用C ++编写的。使用-g3-O0-ggdb标志使用gcc编译。当它崩溃时，我想打开它的核心转储。它会创建核心转储文件，还是我需要做一些事情以在程序本身或在执行该文件的计算机上启用核心转储创建？该文件的创建位置以及名称是什么？ 问题答案： 您需要设置。如果此参数的值为0，则不会创建coredump文件。这样做：并检查是否一切正确。当应用程序完成某些不适当的操作时，将创建cor