如何解决“java.lang.OutOfMemoryError：超出GC开销限制”
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/12813203/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
how to solve 'java.lang.OutOfMemoryError: GC overhead limit exceeded'
提问by user1253952
I read this stack overflow pageabout solving this problem and tried adding the command line option -XX:-UseGCOverheadLimit and also "-Xmx" arguments. However, my program still threw the out of memory error.
我阅读了有关解决此问题的堆栈溢出页面，并尝试添加命令行选项 -XX:-UseGCOverheadLimit 以及“-Xmx”参数。但是，我的程序仍然抛出内存不足错误。
The program saves a large number (>40,000 keys) of words into a MultiKeyMap and is running on a server with plenty of memory.
该程序将大量（> 40,000 个键）单词保存到 MultiKeyMap 中，并在具有大量内存的服务器上运行。
Any suggestions on how I can aviod the error?
关于如何避免错误的任何建议？
回答by Rich
If your problem is reliably reduced (to be honest, even if it's not) I suggest activating the -XX:+HeapDumpOnOutOfMemoryErrorJVM flag. This will, when there is an OutOfMemoryError, produce a binary dump of the memory. This can then be analysed by tools such as Eclipse MATto identify potential memory leaks and help to explain why the Garbage Collector is having such a hard time clearing out your objects.
如果您的问题可靠地减少了（老实说，即使不是），我建议激活-XX:+HeapDumpOnOutOfMemoryErrorJVM 标志。当有 时，这将OutOfMemoryError生成内存的二进制转储。然后可以通过Eclipse MAT等工具对其进行分析，以识别潜在的内存泄漏，并帮助解释垃圾收集器为何如此难以清除您的对象。
回答by Nikem
This problem means that Garbage Collector cannot free enough memory for your application to continue. So even if you switch that particular warning off with "XX:-UseGCOverheadLimit" your application will still crash, because it consumes more memory than is available.
此问题意味着垃圾收集器无法释放足够的内存让您的应用程序继续运行。因此，即使您使用“XX:-UseGCOverheadLimit”关闭该特定警告，您的应用程序仍会崩溃，因为它消耗的内存多于可用内存。
I would say you have memory leak symptoms. Either try digging in memory dump as suggested in another answer, or try Plumbr, which is memory leak monitoring tool created exactly for these situations.
我会说你有内存泄漏症状。要么尝试按照另一个答案中的建议挖掘内存转储，要么尝试Plumbr，它是专为这些情况创建的内存泄漏监控工具。
回答by Fabian Lange
"GC Overhead limit" might be related to a memory leak, but it does not have to be the case. Based on the original question it is hard to say what the real problem is. You should have a "normal" Command line Config without all esotheric flags, and a sensible setting for Xmx to hold all your data. You should activate verbose gc logging to understand what GC is actually causing the overhead and tune it by changing the GC strategy or the generation sizes.
“GC 开销限制”可能与内存泄漏有关，但并非一定如此。根据最初的问题，很难说真正的问题是什么。你应该有一个“正常”的命令行配置，没有所有的esotheric标志，以及一个合理的Xmx设置来保存你的所有数据。您应该激活详细 gc 日志记录以了解 GC 实际导致开销的原因，并通过更改 GC 策略或生成大小对其进行调整。
Usually the Overhead error come sup when you use structures that try to be memory friendly and use soft or weak references. If you use them on your own, double check that you understand what they do, because they can easily be misunderstood.
当您使用尝试对内存友好的结构并使用软引用或弱引用时，通常会出现开销错误。如果您自己使用它们，请仔细检查您是否了解它们的作用，因为它们很容易被误解。
