使用 jconsole 时 Java 转储堆文件的位置？
嗯，这很尴尬......
我开始使用 Eclipse Memory Analyzer 来查找 Windows 机器上的 Java 内存泄漏。第 1 步是获取堆转储文件。为此，我从 Eclipse 中启动 Java (javaw.exe) 进程并使用 jconsole 连接到它。然后在 jconsole MBeans 选项卡上单击 dumpHeap 按钮。我第一次这样做时，我看到一个弹出窗口，说它已经创建了堆转储文件，但没有给出其名称或位置。现在，每当我在连接到不同的 javaw.exe 进程时再次执行 dumpHeap 时，jconsole 都会说：
Problem invoking dumpHeap : java.io.IOException: File exists
并且当然不会给出其名称或路径。它可能在哪里？
我在我的 C: 驱动器（使用 cygwin 命令行工具）中搜索了包含“hprof”或“java_pid”或“heapdump”的文件，但没有找到任何可信的内容。我什至使用 Windows 搜索来查找 Eclipse 工作区中最近一天发生更改的所有文件。
我使用的是 Sun Java 1.6 JVM，并且没有设置 -XX:HeapDumpPath。
更新（2010 年 4 月 28 日）： 我的原始堆文件位置必须由 jconsole（我触发堆转储的工具）确定。 JVM 的堆转储位置必须仅适用于它触发的堆转储（例如，在 OutOfMemoryException 上）。
Matt B 使用 jvisualvm 的建议很好地解决了我的问题，它为我指出了旧 jconsole 的更有用的替代品。它有一个很好的内存分析器，可以显示哪些类型的对象数量最多并且占用最多的内存。它有一个监视器，可以显示一段时间内的实际内存使用情况。当您要求它进行堆转储时，它甚至会告诉您文件名！ Eclipse Memory Analyzer 为您提供完整的详细信息。
Well this is embarrassing ...
I'm starting to play with the Eclipse Memory Analyzer to look for Java memory leaks on a Windows box. Step 1 is to obtain a heap dump file. To do this I start my Java (javaw.exe) process from within Eclipse and connect to it with jconsole. Then on the jconsole MBeans tab I click the dumpHeap button. The first time I did this, I saw a pop-up saying it had created the heap dump file, but not giving its name or location. Now whenever I do a dumpHeap again while connected to a different javaw.exe process, jconsole says:
Problem invoking dumpHeap : java.io.IOException: File exists
and of course doesn't give its name or path. Where could it be?
I've searched my C: drive (using cygwin command line tools) for files containing "hprof" or "java_pid" or "heapdump" and didn't find anything plausible. I've even used the Windows search to look for all files in my Eclipse workspace that have changed in the last day.
I'm using the Sun Java 1.6 JVM, and don't have -XX:HeapDumpPath set.
Update (28 April 2010): My original heap file location must have been determined by jconsole, the tool I triggered the heap dump from. The JVM's heap dump location must apply only to heap dumps it triggers (eg, on an OutOfMemoryException).
Matt B's suggestion to use jvisualvm nicely solves my problem by pointing me to a far more useful replacement for the old jconsole. It has a nice memory profiler that shows which types of objects are most numerous and hold the most memory. And it has a monitor that shows actual memory use over time. When you ask it for a heap dump, it tells you the file name even! The Eclipse Memory Analyzer gives you full details.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
尝试jvisualvm，它有一个更好的界面。
请注意，从 JDK 版本 6 update 7 或更高版本开始，Java VisualVM 与 JDK 捆绑在一起。请参阅此处。
Try jvisualvm, it has a much better interface.
Note that starting with JDK version 6 update 7 or greater, Java VisualVM is bundled with JDK. See here.
根据文档 Sun Java SE6 JVM：
在 Eclipse 中，工作目录是在“运行配置”对话框的“参数”选项卡上定义的。默认值是与您正在运行的类相同的目录。
According to the docs for the Sun Java SE6 JVM:
In Eclipse, the working directory is defined on the "Arguments" tab of the "Run Configurations" dialog. The default value is the same directory as the class that you are running.
当您尝试从 jconsole 调用 dumpHeap() 时，为什么不为 dumpHeap(String,boolean) 设置第一个参数？它是生成的堆转储文件的位置和文件名。
why don't you set the first parameter for dumpHeap(String,boolean) when you try to invoke dumpHeap() from jconsole? it's the generated heapdump file's location and filename.
您始终可以使用 ProcessMonitor 来查看它尝试写入的位置： ）我自己过去也这样做过。
You could always use ProcessMonitor to see where it's trying to write to :) Done this myself in the past.
我发现转储的文件位于启动我的 java 应用程序的 .bat 文件所在的同一文件夹中。 （我使用的是Windows 8.1，java 7）
就我而言，jboss 为 /jboss-as/bin/ 文件夹。
为了找到它，我搜索了 * 文件，其创建日期为今天，大小超过 200MB。
I found the dumped file into the same folder where the .bat file whic launch my java application is placed. (I'm using windows 8.1, java 7)
In my case jboss, /jboss-as/bin/ folder.
To find it I searched * files, with today creation date and more than 200MB.