Java 内存问题的诊断策略
我的任务是调试一个 Java (J2SE) 应用程序，该应用程序在运行一段时间后开始抛出 OutOfMemory 异常。 我是 Java 新手，但有编程经验。 我有兴趣了解您对诊断此类问题的好方法的看法？
到目前为止，我已经使用 JConsole 来了解正在发生的情况。 我有预感，有些对象没有被正确释放，因此在垃圾收集期间没有被清理。
我可以使用任何工具来了解对象生态系统吗？ 你会从哪里开始？
I've been tasked with debugging a Java (J2SE) application which after some period of activity begins to throw OutOfMemory exceptions. I am new to Java, but have programming experience. I'm interested in getting your opinions on what a good approach to diagnosing a problem like this might be?
This far I've employed JConsole to get a picture of what's going on. I have a hunch that there are object which are not being released properly and therefor not being cleaned up during garbage collection.
Are there any tools I might use to get a picture of the object ecosystem? Where would you start?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
我将从一个合适的 Java 分析器开始。 JConsole 是免费的，但它的功能远不如付费的那么全面。 我用过 JProfiler，它非常物有所值。 请参阅https://stackoverflow.com/questions/14762/please-recommend-a-java-profiler 以获得更多选择和意见。
I'd start with a proper Java profiler. JConsole is free, but it's nowhere near as full featured as the ones that cost money. I used JProfiler, and it was well worth the money. See https://stackoverflow.com/questions/14762/please-recommend-a-java-profiler for more options and opinions.
尝试 Eclipse Memory Analyzer 或任何其他可以处理 java 堆转储的工具，然后运行当你的应用程序内存不足时，它会生成一个堆转储。
然后分析堆转储并查找可疑的高对象计数。
有关堆转储的详细信息，请参阅本文。
编辑：另外，请注意，您的应用程序可能合法地需要比您最初想象的更多的内存。 您可以尝试首先将 java 最小和最大内存分配增加到明显更大的值，然后看看您的应用程序是否无限期运行或只是稍微进一步运行。
Try the Eclipse Memory Analyzer, or any other tool that can process a java heap dump, and then run your app with the flap that generates a heap dump when you run out of memory.
Then analyze the heap dump and look for suspiciously high object counts.
See this article for more information on the heap dump.
EDIT: Also, please note that your app may just legitimately require more memory than you initially thought. You might try increasing the java minimum and maximum memory allocation to something significantly larger first and see if your application runs indefinitely or simply gets slightly further.
Sun JDK 的最新版本包括 VisualVM，它本质上本身就是 Netbeans 分析器。 效果非常好。
The latest version of the Sun JDK includes VisualVM which is essentially the Netbeans profiler by itself. It works really well.
http://www.yourkit.com/download/index.jsp 是唯一的您需要的工具。
您可以在（1）应用程序启动时和（2）运行应用程序 N 时间后拍摄快照，然后比较快照以查看内存分配的位置。 它还会在发生 OutOfMemoryError 时拍摄快照，以便您可以将此快照与 (1) 进行比较。
例如，我必须解决的最新项目抛出了 OutOfMemoryError 异常，并且在启动 YourKit 后，我意识到大多数内存实际上被分配给了一些 ehcache“LFU”类，重点是我们指定了某个 POJO 的负载缓存在内存中，但我们没有指定足够的 -Xms 和 -Xmx （启动和最大 JVM 内存分配）。
我还使用过Linux的vmstat，例如某些Linux平台没有启用足够的交换，或者没有分配连续的内存块，然后就有jstat（捆绑与 JDK）。
更新请参阅https://stackoverflow.com/questions/14762/please -推荐-java-profiler
http://www.yourkit.com/download/index.jsp is the only tool you'll need.
You can take snapshots at (1) app start time, and (2) after running app for N amount of time, then comparing the snapshots to see where memory gets allocated. It will also take a snapshot on OutOfMemoryError so you can compare this snapshot with (1).
For instance, the latest project I had to troubleshoot threw OutOfMemoryError exceptions, and after firing up YourKit I realised that most memory were in fact being allocated to some ehcache "LFU " class, the point being that we specified loads of a certain POJO to be cached in memory, but us not specifying enough -Xms and -Xmx (starting- and max- JVM memory allocation).
I've also used Linux's vmstat e.g. some Linux platforms just don't have enough swap enabled, or don't allocate contiguous blocks of memory, and then there's jstat (bundled with JDK).
UPDATE see https://stackoverflow.com/questions/14762/please-recommend-a-java-profiler
您还可以将“UnhandledExceptionHandler”添加到应用程序的线程中。 这将捕获“未捕获”的异常，例如内存不足错误，并且您至少会知道抛出异常的位置。 通常这不是问题所在，而是无法满足的“新”问题。 作为一项规则，如果没有其他要添加日志记录的情况，我总是将 UnhandledExceptionHandler 添加到线程中。
You can also add an "UnhandledExceptionHandler" to your Application's Thread. This will catch 'uncaught' exception, like an out of memory error, and you will at least have an idea where the exception was thrown. Usually this not were the problem is but the 'new' that couldn't be satisfied. As a rule I always add the UnhandledExceptionHandler to a Thread if nothing else to add logging.