当我执行JUnit测试时,我得到了这个错误消息:
java.lang.OutOfMemoryError: GC overhead limit exceeded
我知道什么是OutOfMemoryError,但是GC开销限制意味着什么?我怎么解决这个问题?
当我执行JUnit测试时,我得到了这个错误消息:
java.lang.OutOfMemoryError: GC overhead limit exceeded
我知道什么是OutOfMemoryError,但是GC开销限制意味着什么?我怎么解决这个问题?
当前回答
在Netbeans中,设计最大堆大小可能会有所帮助。执行命令Run =>设置项目配置=>自定义。在弹出窗口的运行中,进入虚拟机选项,填写-Xms2048m -Xmx2048m。它可以解决堆大小的问题。
其他回答
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
}
}
//...
您还可以通过将此添加到gradle中来增加内存分配和堆大小。属性文件:
org . gradle。jvmargs = -Xmx2048M -XX: MaxHeapSize \ = 32g
它不需要2048M和32g,你想要多大就有多大。
@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语言规范。
如果您确定程序中没有内存泄漏,请尝试:
增加堆的大小,例如-Xmx1g。 启用并发低暂停收集器-XX:+UseConcMarkSweepGC。 在可能的情况下重用现有对象以节省内存。
如果需要,可以通过在命令行中添加-XX:-UseGCOverheadLimit选项来禁用限制检查。
通常是代码。这里有一个简单的例子:
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次
现在承认,这不是最好的测试或最好的设计,但当你面临别无选择只能实现这样的循环或处理行为糟糕的现有代码时,选择重用对象而不是创建新对象可以减少垃圾收集器阻碍的次数……