如果确定程序中没有内存泄漏，请尝试：
例如，增加堆大小 -Xmx1g .
启用并发低暂停采集器 -XX:+UseConcMarkSweepGC .
尽可能重用现有对象以节省一些内存。
如有必要，可以通过添加选项禁用限制检查 -XX:-UseGCOverheadLimit 到命令行。

我不知道这是否仍然是相关的或没有，但只是想分享什么为我工作。
将kotlin版本更新至最新版本。https://blog.jetbrains.com/kotlin/category/releases/
一切都结束了。

下面这些对我有用。只需添加以下代码段：

android {
        compileSdkVersion 25
        buildToolsVersion '25.0.1'

defaultConfig {
        applicationId "yourpackage"
        minSdkVersion 10
        targetSdkVersion 25
        versionCode 1
        versionName "1.0"
        multiDexEnabled true
    }
dexOptions {
        javaMaxHeapSize "4g"
    }
}

您需要增加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**
)

以及

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**

错误原因根据java[8]平台标准版故障排除指南：（增加了强调和换行符）
[…]“gc overhead limit exceeded”表示垃圾收集器一直在运行，java程序进展非常缓慢。
在垃圾收集之后，如果java进程花费大约98%以上的时间进行垃圾收集，并且恢复的堆不到2%，并且一直在进行最后5次（编译时常量）连续的垃圾收集，那么 java.lang.OutOfMemoryError 被抛出。[…]
如果当前堆不够，请增加堆大小。
如果在增加堆内存后仍然出现此错误，请使用内存分析工具，如mat（内存分析器工具）、visualvm等，并修复内存泄漏。
将jdk版本升级到最新版本（1.8.x）或至少1.7.x，并使用g1gc算法。g1gc的吞吐量目标是90%的应用程序时间和10%的垃圾收集时间
除了设置堆内存- Xms1g -Xmx2g ，试试看

-XX:+UseG1GC -XX:G1HeapRegionSize=n -XX:MaxGCPauseMillis=m  
-XX:ParallelGCThreads=n -XX:ConcGCThreads=n

看看关于g1gc的一些更相关的问题
Java7（JDK7）垃圾收集和g1上的文档
生产中的javag1垃圾回收
用于gc微调的oracle technetwork文章

您还可以通过将其添加到内存中来增加内存分配和堆大小 gradle.properties 文件： org.gradle.jvmargs=-Xmx2048M -XX\:MaxHeapSize\=32g 它不必是2048米和32克，让它大你想要的。

引用oracle的文章“java se 6 hotspot[tm]virtual machine garbage collection tuning”：
gc时间过长和outofmemoryerror
如果在垃圾收集中花费的时间太多，并行收集器将抛出outofmemoryerror：如果在垃圾收集中花费的时间超过总时间的98%，而恢复的堆少于2%，则将抛出outofmemoryerror。此功能旨在防止应用程序长时间运行，同时由于堆太小而很少或没有进展。如有必要，可通过添加选项禁用此功能 -XX:-UseGCOverheadLimit 到命令行。
编辑：好像有人打字比我快：）

要在intellij idea中增加堆大小，请遵循以下说明。它对我有用。
对于windows用户，
转到安装ide的位置并搜索以下内容。

idea64.exe.vmoptions

编辑文件并添加以下内容。

-Xms512m
-Xmx2024m
-XX:MaxPermSize=700m
-XX:ReservedCodeCacheSize=480m

就这样！！

只需通过在中设置此选项来稍微增加堆大小
跑→ 运行配置→ 论据→ 虚拟机参数

-Xms1024M -Xmx2048M

xms-最低限度
xmx-最大限值

解决了的：
只需添加 org.gradle.jvmargs=-Xmx1024m 在里面 gradle.properties 如果它不存在，就创建它。

对我来说，以下步骤奏效了：
打开 eclipse.ini 文件
改变

-Xms40m
-Xmx512m

到

-Xms512m
-Xmx1024m

重新启动eclipse
看到这里了吗

java堆大小描述（xms、xmx、xmn）

-Xms size in bytes

Example : java -Xms32m

设置java堆的初始大小。默认大小为2097152（2mb）。这些值必须是1024字节（1kb）的倍数，并且大于1024字节（1kb）(-server标志将默认大小增加到32m。）

-Xmn size in bytes

Example : java -Xmx2m

设置eden生成的初始java堆大小。默认值为640k(-server标志将默认大小增加到2m。）

-Xmx size in bytes

Example : java -Xmx2048m

设置java堆可以增长到的最大大小。默认大小为64m(-server标志将默认大小增加到128m。）最大堆限制约为2GB（2048mb）。
java内存参数（xms，xmx，xmn）格式
在设置java堆大小时，应该使用字母“m”或“m”中的一个表示mb，或“g”或“g”表示gb来指定内存参数。如果指定“mb”或“gb”，则设置无效。有效参数如下所示：
-xms64m或-xms64m-xmx1g或-xmx1g也可以使用2048mb来指定2gb。另外，请确保在指定参数时只使用整数。使用-xmx512m是一个有效的选项，但是-xmx0.5g将导致错误。
这个参考资料对某人有帮助。

您可以尝试通过引用此图像对服务器设置进行更改，并增加内存大小以处理以黄色突出显示的进程更改
您还可以通过打开cmd-> set _java_opts -Xmx2g 2g（2g字节）取决于程序的复杂性
尽量少用常量变量和临时变量

此消息意味着由于某些原因，垃圾收集器占用了大量时间（默认情况下占进程所有cpu时间的98%），并且每次运行时恢复的内存非常少（默认情况下占堆的2%）。
这实际上意味着您的程序停止执行任何进度，并且一直忙于运行垃圾收集。
为了防止应用程序在没有完成任何工作的情况下占用cpu时间，jvm抛出 Error 这样你就有机会诊断出问题。
我见过这种情况的罕见情况是，一些代码在已经非常内存受限的环境中创建了大量临时对象和大量弱引用对象。
查看java gc tuning guide（java gc调优指南），该指南可用于各种java版本，并包含有关此特定问题的部分：
java 11 tuning guide（java 11调优指南）有专门针对不同垃圾收集器的过度gc部分：
对于并行收集器
对于并发标记扫描（cms）收集器
对于垃圾优先（g1）收集器，没有提到这个特定的错误条件。
Java8调优指南及其gc部分
Java6调优指南及其gc部分。

通常是密码。下面是一个简单的例子：

import java.util.*;

public class GarbageCollector {

    public static void main(String... args) {

        System.out.printf("Testing...%n");
        List<Double> list = new ArrayList<Double>();
        for (int outer = 0; outer < 10000; outer++) {

            // list = new ArrayList<Double>(10000); // BAD
            // list = new ArrayList<Double>(); // WORSE
            list.clear(); // BETTER

            for (int inner = 0; inner < 10000; inner++) {
                list.add(Math.random());
            }

            if (outer % 1000 == 0) {
                System.out.printf("Outer loop at %d%n", outer);
            }

        }
        System.out.printf("Done.%n");
    }
}

在Windows7 32位上使用Java1.6.0\u24-b07。

java -Xloggc:gc.log GarbageCollector

然后看看 gc.log 使用错误方法触发444次
使用更差的方法触发666次
使用更好的方法触发354次
现在可以肯定的是，这不是最好的测试或设计，但当您面临除了实现这样一个循环之外别无选择的情况时，或者在处理表现糟糕的现有代码时，选择重用对象而不是创建新对象可以减少垃圾回收器妨碍的次数。。。