java.lang.OutOfMemoryError:超出GC开销限制 [英] java.lang.OutOfMemoryError: GC overhead limit exceeded
问题描述
我在一个程序中出现这个错误,该程序创建了几个(数十万个)每个有几个(15-20)个文本项的HashMap对象。这些字符串在提交到数据库之前已经被收集(没有分解成更小的数量)。
据Sun称,错误发生在如果时间太长被用于垃圾收集:如果超过98%的时间用于垃圾回收,并且只有不到2%的堆被恢复,则会抛出OutOfMemoryError。。
显然,可以使用命令行将参数传递给JVM以用于
- 增加堆大小,通过-Xmx1024m (或更多)或
- 通过-XX:-UseGCOverheadLimit完全禁用错误检查。
第一种方法工作正常,第二种方法在另一个java.lang.OutOfMemoryError中结束,这次是关于堆。
所以,question:is有没有任何程序化的替代方案,对于特定的用例(即几个小的HashMap对象)?例如,如果我使用HashMap clear()方法,问题就会消失,但存储在HashMap中的数据也会消失! : - )
这个问题也在 你基本上没有足够的内存来顺利运行这个过程。想到这些选项: I am getting this error in a program that creates several (hundreds of thousands) HashMap objects with a few (15-20) text entries each. These Strings have all to be collected (without breaking up into smaller amounts) before being submitted to a database. According to Sun, the error happens "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.". Apparently, one could use the command line to pass arguments to the JVM for The first approach works fine, the second ends up in another java.lang.OutOfMemoryError, this time about the heap. So, question: is there any programmatic alternative to this, for the particular use case (i.e., several small HashMap objects)? If I use the HashMap clear() method, for instance, the problem goes away, but so do the data stored in the HashMap! :-) The issue is also discussed in a related topic in StackOverflow. You're essentially running out of memory to run the process smoothly. Options that come to mind:
这篇关于java.lang.OutOfMemoryError:超出GC开销限制的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!
-Xmx512m
first
HashMap
对象的小批量
String.intern()
,然后将它们放入 HashMap
HashMap(int initialCapacity,float loadFactor)
构造函数调整您的情况
-Xmx512m
firstHashMap
objects to process at once if possibleString.intern()
on them before putting them into the HashMap
HashMap(int initialCapacity, float loadFactor)
constructor to tune for your case