我在一个程序中得到这个错误，该程序创建了几个(数十万)HashMap对象，每个对象有几个(15-20)文本条目。在将这些字符串提交到数据库之前，必须收集所有这些字符串(而不将其分解为更小的数量)。
根据Sun的说法，错误发生在“如果在垃圾收集上花费了太多的时间:如果超过98%的总时间花在垃圾收集上，而不到2%的堆被恢复，则会抛出OutOfMemoryError”。
显然，可以使用命令行将参数传递给JVM
增加堆的大小，通过“-Xmx1024m”(或更多)，或者 通过"-XX:-UseGCOverheadLimit"完全禁用错误检查。
第一种方法工作得很好，第二种方法在另一个java.lang中结束。OutOfMemoryError，这次是关于堆的。
那么，问题是:对于特定的用例(即几个小HashMap对象)，是否有任何编程替代方案?例如，如果我使用HashMap clear()方法，问题就会消失，但存储在HashMap中的数据也会消失!: -)
该问题也在StackOverflow的相关主题中进行了讨论。
当前回答
为此使用下面的代码在你的应用程序gradle文件下的android关闭。
dexOptions { javaMaxHeapSize “4g” }
其他回答
使用概要工具(如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垃圾收集
积极的垃圾回收策略
您实际上正在耗尽内存，无法顺利运行进程。想到的选项有:
像你提到的那样指定更多的内存，首先尝试介于两者之间的内存，比如-Xmx512m 如果可能，使用更小批量的HashMap对象一次性处理 如果你有很多重复的字符串，在将它们放入HashMap之前，对它们使用String.intern() 使用HashMap(int initialCapacity, float loadFactor)构造函数针对您的情况进行调优
你需要在Jdeveloper中增加内存大小，转到setDomainEnv.cmd。
set WLS_HOME=%WL_HOME%\server
set XMS_SUN_64BIT=256
set XMS_SUN_32BIT=256
set XMX_SUN_64BIT=3072
set XMX_SUN_32BIT=3072
set XMS_JROCKIT_64BIT=256
set XMS_JROCKIT_32BIT=256
set XMX_JROCKIT_64BIT=1024
set XMX_JROCKIT_32BIT=1024
if "%JAVA_VENDOR%"=="Sun" (
set WLS_MEM_ARGS_64BIT=-Xms256m -Xmx512m
set WLS_MEM_ARGS_32BIT=-Xms256m -Xmx512m
) else (
set WLS_MEM_ARGS_64BIT=-Xms512m -Xmx512m
set WLS_MEM_ARGS_32BIT=-Xms512m -Xmx512m
)
and
set MEM_PERM_SIZE_64BIT=-XX:PermSize=256m
set MEM_PERM_SIZE_32BIT=-XX:PermSize=256m
if "%JAVA_USE_64BIT%"=="true" (
set MEM_PERM_SIZE=%MEM_PERM_SIZE_64BIT%
) else (
set MEM_PERM_SIZE=%MEM_PERM_SIZE_32BIT%
)
set MEM_MAX_PERM_SIZE_64BIT=-XX:MaxPermSize=1024m
set MEM_MAX_PERM_SIZE_32BIT=-XX:MaxPermSize=1024m
嗯……你需要:
Completely rethink your algorithm & data-structures, such that it doesn't need all these little HashMaps. Create a facade which allows you page those HashMaps in-and-out of memory as required. A simple LRU-cache might be just the ticket. Up the memory available to the JVM. If necessary, even purchasing more RAM might be the quickest, CHEAPEST solution, if you have the management of the machine that hosts this beast. Having said that: I'm generally not a fan of the "throw more hardware at it" solutions, especially if an alternative algorithmic solution can be thought up within a reasonable timeframe. If you keep throwing more hardware at every one of these problems you soon run into the law of diminishing returns.
你到底想做什么?我怀疑有更好的方法来解决你的实际问题。
使用替代HashMap实现(Trove)。标准Java HashMap有12倍的内存开销。 你可以在这里阅读细节。
