我在一个程序中得到这个错误,该程序创建了几个(数十万)HashMap对象,每个对象有几个(15-20)文本条目。在将这些字符串提交到数据库之前,必须收集所有这些字符串(而不将其分解为更小的数量)。

根据Sun的说法,错误发生在“如果在垃圾收集上花费了太多的时间:如果超过98%的总时间花在垃圾收集上,而不到2%的堆被恢复,则会抛出OutOfMemoryError”。

显然,可以使用命令行将参数传递给JVM

增加堆的大小,通过“-Xmx1024m”(或更多),或者 通过"-XX:-UseGCOverheadLimit"完全禁用错误检查。

第一种方法工作得很好,第二种方法在另一个java.lang中结束。OutOfMemoryError,这次是关于堆的。

那么,问题是:对于特定的用例(即几个小HashMap对象),是否有任何编程替代方案?例如,如果我使用HashMap clear()方法,问题就会消失,但存储在HashMap中的数据也会消失!: -)

该问题也在StackOverflow的相关主题中进行了讨论。


当前回答

如果你有java8,你可以使用G1垃圾收集器,然后运行你的应用程序:

 -XX:+UseG1GC -XX:+UseStringDeduplication

这告诉G1寻找相似的字符串,并在内存中只保留其中一个字符串,其他字符串在内存中只是指向该字符串的指针。

当你有很多重复的字符串时,这很有用。此解决方案可能有效,也可能无效,这取决于每个应用程序。

更多信息: https://blog.codecentric.de/en/2014/08/string-deduplication-new-feature-java-8-update-20-2/ http://java-performance.info/java-string-deduplication/

其他回答

如果你有java8,你可以使用G1垃圾收集器,然后运行你的应用程序:

 -XX:+UseG1GC -XX:+UseStringDeduplication

这告诉G1寻找相似的字符串,并在内存中只保留其中一个字符串,其他字符串在内存中只是指向该字符串的指针。

当你有很多重复的字符串时,这很有用。此解决方案可能有效,也可能无效,这取决于每个应用程序。

更多信息: https://blog.codecentric.de/en/2014/08/string-deduplication-new-feature-java-8-update-20-2/ http://java-performance.info/java-string-deduplication/

@takrl:默认设置为:

java -XX:+UseConcMarkSweepGC

这意味着,默认情况下,该选项不是活动的。所以当你说你使用了期权 “+ XX: UseConcMarkSweepGC” 我假设你使用的是这样的语法:

java -XX:+UseConcMarkSweepGC

也就是说你明确地激活了这个选项。 为正确的语法和Java热点虚拟机选项的默认设置@此 文档

下面的方法对我很有效。只需添加以下片段:

dexOptions {
        javaMaxHeapSize "4g"
}

到你的建筑。gradle:

android {
    compileSdkVersion 23
    buildToolsVersion '23.0.1'

    defaultConfig {
        applicationId "yourpackage"
        minSdkVersion 14
        targetSdkVersion 23
        versionCode 1
        versionName "1.0"

        multiDexEnabled true
    }

    buildTypes {
        release {
            minifyEnabled false
            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
        }
    }

    packagingOptions {

    }

    dexOptions {
        javaMaxHeapSize "4g"
    }
}

郑重声明,我们今天也遇到了同样的问题。我们通过使用这个选项来修复它:

-XX:-UseConcMarkSweepGC

显然,这修改了用于垃圾收集的策略,使问题消失了。

对于我来说,使用-Xmx选项增加内存是解决方案。

我用java读取了一个10g的文件,每次我都得到相同的错误。当top命令中的RES列的值达到-Xmx选项中设置的值时,就会发生这种情况。然后使用-Xmx选项增加内存,一切正常。

还有一点。当我在用户帐户中设置JAVA_OPTS或CATALINA_OPTS并再次增加内存数量时,我得到了相同的错误。然后,我在我的代码中打印这些环境变量的值,它们给我的值与我设置的值不同。原因是Tomcat是该进程的根,然后由于我不是su-doer,我要求管理员在Tomcat中增加catalina.sh中的内存。