线程“main”中的异常java.lang.OutOfMemoryError：超出 GC 开销限制
我无法运行我的流程。它给出以下异常：“线程“main”java.lang.OutOfMemoryError中的异常：Java堆空间”
java -Xms32m -Xmx516m 过滤SNP_genus 线程“main”中的异常 java.lang.OutOfMemoryError：Java 堆空间 在 java.util.Arrays.copyOf(Arrays.java:2882) 在 java.lang.AbstractStringBuilder.expandCapacity(AbstractStringBuilder.java:100) 在 java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:515) 在 java.lang.StringBuffer.append(StringBuffer.java:306) 在 java.io.BufferedReader.readLine(BufferedReader.java:345) 在 java.io.BufferedReader.readLine(BufferedReader.java:362) 在 FilteringSNP_genus.main(FilteringSNP_genus.java:65)
我尝试了不同的内存使用配置，例如：
java -Xms32m -Xmx1024m 过滤SNP_genus
但它没有起作用，并且增加 -XmxVALUE 给出了 GC 开销限制超出异常：
线程“main”中出现异常 java.lang.OutOfMemoryError：超出 GC 开销限制 在 java.lang.String.substring(String.java:1940) 在 java.util.StringTokenizer.nextToken(StringTokenizer.java:335) 在 FilteringSNP_genus.main(FilteringSNP_genus.java:77)
任何人都可以提供一些线索来解决这个问题吗？
谢谢
I can't run my process. It gives the following exception: "Exception in thread "main" java.lang.OutOfMemoryError: Java heap space"
java -Xms32m -Xmx516m FilteringSNP_genus
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
at java.util.Arrays.copyOf(Arrays.java:2882)
at java.lang.AbstractStringBuilder.expandCapacity(AbstractStringBuilder.java:100)
at java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:515)
at java.lang.StringBuffer.append(StringBuffer.java:306)
at java.io.BufferedReader.readLine(BufferedReader.java:345)
at java.io.BufferedReader.readLine(BufferedReader.java:362)
at FilteringSNP_genus.main(FilteringSNP_genus.java:65)
I have tried different memory usage configurations like:
java -Xms32m -Xmx1024m FilteringSNP_genus
but it has not worked, and increasing the -XmxVALUE has given a GC overheadlimit exceeded exception:
Exception in thread "main" java.lang.OutOfMemoryError: GC overhead limit exceeded
at java.lang.String.substring(String.java:1940)
at java.util.StringTokenizer.nextToken(StringTokenizer.java:335)
at FilteringSNP_genus.main(FilteringSNP_genus.java:77)
Could anyone provide some clue to fix this?
Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我猜测您正在从文件或套接字读取并使用 readLine() 为方便起见，无需考虑其含义。尝试 读入 char[] 缓冲区。
或者，您正在读取行并将其硬引用存储在内存中，因此一旦您读得足够多，您显然会耗尽空间。
至于GC开销错误，根据 Oracle JVM文章：
“如果在垃圾收集上花费了太多时间，并行收集器将抛出 OutOfMemoryError：如果超过总时间的 98% 用于垃圾收集，并且回收的堆少于 2%，则会抛出 OutOfMemoryError。 ”
I'd hazard a guess that you're reading from a file or a socket and using readLine() for convenience without considering the implications. Try reading into a char[] buffer instead.
Alternately, you're reading lines in and storing hard references to them in memory, so you obviously will run out of room once you read enough.
As for the GC overhead error, according to an Oracle JVM article:
"The parallel collector will throw an OutOfMemoryError if too much time is being spent in garbage collection: if more than 98% of the total time is spent in garbage collection and less than 2% of the heap is recovered, an OutOfMemoryError will be thrown."
我发现如果寻找内存的时间太长，GC 就会放弃，即使内存确实存在。最简单的问题是当内存大部分是虚拟内存时，它比真实内存慢得多。此外，如果内存碎片过多，GC 可能需要一些时间才能找到所需的空间。如果您分配大块内存，情况可能会变得更糟。像这样的问题可能是间歇性的，当 GC 有时间清理内部并保持一切井井有条时，工作正常，但在过载时会失败。我的猜测是，在您的情况下，您要么存在分页问题，要么您在太大的块中使用了太多可用内存。
解决方案：获取更多实际内存（如果分页是问题所在）。使用更少的内存。使用较小的内存块。数组是处理数字的最快方法，但带有指针的数据结构使 GC 的工作更轻松。如果您能找到一种使用较小数组（或不使用数组）的方法，请这样做。
应该可以得到一个具有 8GB 或更多内存的适当 64 位系统（计算机和 JVM），这样您就可以忽略并忘记这个问题，但我还没有听说有人这样做。 （内存使用扩展以填满可用内存......）
I have found the GC will give up if it takes too long to find memory, even if the memory is actually there. The simplest problem is when the memory is mostly virtual, which is vastly slower than real memory. Also if memory is too fragmented, the GC can take time to find the space it needs. And if you are allocating big chunks of memory, that can make the situation much worse. A problem like this can be intermittent, working fine when the GC has had time to clean house and keep everything organized and failing when it is overloaded. My guess is that in your case you either have a paging problem or you are using too much of available memory in chunks that are too big.
Solutions: get more real memory (if paging is the problem). Use less memory. Use smaller pieces of memory. Arrays are the fastest way to crunch numbers, but data structures with pointers make life easier for the GC. If you can figure a way to use smaller arrays (or no arrays), do that.
It ought to be possible to get a proper 64-bit system (computer and JVM) with 8GB or more of memory so you can ignore and forget this problem, but I've yet to hear of anybody doing that. (And memory use expands to fill the memory available...)