如果您确定程序中没有内存泄漏，请尝试:

增加堆的大小，例如-Xmx1g。 启用并发低暂停收集器-XX:+UseConcMarkSweepGC。 在可能的情况下重用现有对象以节省内存。

如果需要，可以通过在命令行中添加-XX:-UseGCOverheadLimit选项来禁用限制检查。

@Buhb 我在一个普通的spring-boot web应用程序的main方法中复制了这个过程。代码如下:

public static void main(String[] args) {
    SpringApplication.run(DemoServiceBApplication.class, args);
    LOGGER.info("hello.");
    int len = 0, oldlen=0;
    Object[] a = new Object[0];
    try {
        for (; ; ) {
            ++len;
            Object[] temp = new Object[oldlen = len];
            temp[0] = a;
            a = temp;
        }
    } catch (Throwable e) {
        LOGGER.info("error: {}", e.toString());
    }
}

引起come的示例代码也是来自oracle java8语言规范。

对我来说，以下步骤是有效的:

打开eclipse.ini文件 改变 -Xms40m -Xmx512m 来 -Xms512m -Xmx1024m 重新启动Eclipse

在这里看到的

通过设置这个选项，稍微增加堆的大小

运行→运行配置→参数→虚拟机参数

-Xms1024M -Xmx2048M

Xms—用于最小限制

Xmx -表示最大限制

I'm working in Android Studio and encountered this error when trying to generate a signed APK for release. I was able to build and test a debug APK with no problem, but as soon as I wanted to build a release APK, the build process would run for minutes on end and then finally terminate with the "Error java.lang.OutOfMemoryError: GC overhead limit exceeded". I increased the heap sizes for both the VM and the Android DEX compiler, but the problem persisted. Finally, after many hours and mugs of coffee it turned out that the problem was in my app-level 'build.gradle' file - I had the 'minifyEnabled' parameter for the release build type set to 'false', consequently running Proguard stuffs on code that hasn't been through the code-shrinking' process (see https://developer.android.com/studio/build/shrink-code.html). I changed the 'minifyEnabled' parameter to 'true' and the release build executed like a dream :)

简而言之，我必须改变应用程序级别的“构建”。Gradle文件来自: / /……

buildTypes {
    release {
        minifyEnabled false
        proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
        signingConfig signingConfigs.sign_config_release
    }
    debug {
        debuggable true
        signingConfig signingConfigs.sign_config_debug
    }
}

//...

to

    //...

buildTypes {
    release {
        minifyEnabled true
        proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
        signingConfig signingConfigs.sign_config_release
    }
    debug {
        debuggable true
        signingConfig signingConfigs.sign_config_debug
    }
}

//...

通常是代码。这里有一个简单的例子:

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");
    }
}

在Windows 7 32位操作系统上使用Java 1.6.0_24-b07。

java -Xloggc:gc.log GarbageCollector

然后查看gc.log

使用BAD方法触发444次 使用WORSE方法触发666次 使用BETTER方法触发354次

现在承认，这不是最好的测试或最好的设计，但当你面临别无选择只能实现这样的循环或处理行为糟糕的现有代码时，选择重用对象而不是创建新对象可以减少垃圾收集器阻碍的次数……