我在一个程序中得到这个错误，该程序创建了几个(数十万)HashMap对象，每个对象有几个(15-20)文本条目。在将这些字符串提交到数据库之前，必须收集所有这些字符串(而不将其分解为更小的数量)。
根据Sun的说法，错误发生在“如果在垃圾收集上花费了太多的时间:如果超过98%的总时间花在垃圾收集上，而不到2%的堆被恢复，则会抛出OutOfMemoryError”。
显然，可以使用命令行将参数传递给JVM
增加堆的大小，通过“-Xmx1024m”(或更多)，或者 通过"-XX:-UseGCOverheadLimit"完全禁用错误检查。
第一种方法工作得很好，第二种方法在另一个java.lang中结束。OutOfMemoryError，这次是关于堆的。
那么，问题是:对于特定的用例(即几个小HashMap对象)，是否有任何编程替代方案?例如，如果我使用HashMap clear()方法，问题就会消失，但存储在HashMap中的数据也会消失!: -)
该问题也在StackOverflow的相关主题中进行了讨论。
当前回答
不要在等待结束时将整个结构存储在内存中。
将中间结果写入数据库中的临时表，而不是hashmap——从功能上讲，数据库表相当于hashmap，即两者都支持按键访问数据，但表不受内存限制，因此在这里使用索引表而不是hashmap。
如果操作正确，您的算法甚至不应该注意到这个变化——这里的正确意思是使用一个类来表示表，甚至像hashmap一样给它一个put(键，值)和get(键)方法。
当中间表完成时，从中间表而不是从内存中生成所需的sql语句。
其他回答
使用概要工具(如eclipse MAT或VisualVM)修复应用程序中的内存泄漏
使用JDK 1.7。x或更高版本，使用G1GC，它在垃圾收集上花费10%，而不像其他GC算法花费2%。
除了使用-Xms1g -Xmx2g设置堆内存之外，请尝试'
-XX:+UseG1GC
-XX:G1HeapRegionSize=n,
-XX:MaxGCPauseMillis=m,
-XX:ParallelGCThreads=n,
-XX:ConcGCThreads=n`
请参阅oracle的文章，对这些参数进行微调。
关于SE中G1GC的一些问题:
G1上的Java 7 (JDK 7)垃圾收集和文档
生产环境中的Java G1垃圾收集
积极的垃圾回收策略
使用替代HashMap实现(Trove)。标准Java HashMap有12倍的内存开销。 你可以在这里阅读细节。
对于我来说，使用-Xmx选项增加内存是解决方案。
我用java读取了一个10g的文件，每次我都得到相同的错误。当top命令中的RES列的值达到-Xmx选项中设置的值时，就会发生这种情况。然后使用-Xmx选项增加内存，一切正常。
还有一点。当我在用户帐户中设置JAVA_OPTS或CATALINA_OPTS并再次增加内存数量时，我得到了相同的错误。然后，我在我的代码中打印这些环境变量的值，它们给我的值与我设置的值不同。原因是Tomcat是该进程的根，然后由于我不是su-doer，我要求管理员在Tomcat中增加catalina.sh中的内存。
The parallel collector will throw an OutOfMemoryError if too much time is being spent in garbage collection. In particular, if more than 98% of the total time is spent in garbage collection and less than 2% of the heap is recovered, OutOfMemoryError will be thrown. This feature is designed to prevent applications from running for an extended period of time while making little or no progress because the heap is too small. If necessary, this feature can be disabled by adding the option -XX:-UseGCOverheadLimit to the command line.
如果您正在创建数十万个哈希映射，那么您使用的哈希映射可能远远超过实际需要;除非处理大文件或图形，否则存储简单数据不应超过Java内存限制。
你应该重新考虑一下你的算法。在这种情况下，我会在这个问题上提供更多的帮助，但在你提供更多关于问题背景的信息之前，我不能提供任何信息。
