当我执行JUnit测试时,我得到了这个错误消息:
java.lang.OutOfMemoryError: GC overhead limit exceeded
我知道什么是OutOfMemoryError,但是GC开销限制意味着什么?我怎么解决这个问题?
当我执行JUnit测试时,我得到了这个错误消息:
java.lang.OutOfMemoryError: GC overhead limit exceeded
我知道什么是OutOfMemoryError,但是GC开销限制意味着什么?我怎么解决这个问题?
当前回答
试试这个
打开构建。gradle文件
android {
dexOptions {
javaMaxHeapSize = "4g"
}
}
其他回答
@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语言规范。
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
}
}
//...
这条消息意味着由于某种原因,垃圾收集器花费了过多的时间(默认情况下占进程所有CPU时间的98%),并且在每次运行中回收的内存非常少(默认情况下占堆时间的2%)。
这实际上意味着您的程序停止执行任何进度,并且一直忙于只运行垃圾收集。
为了防止应用程序占用CPU时间而不做任何事情,JVM抛出这个错误,以便您有机会诊断问题。
我很少看到这种情况发生的情况是,一些代码在已经非常受内存限制的环境中创建了大量临时对象和大量弱引用对象。
请查看Java GC调优指南,该指南可用于各种Java版本,其中包含关于此特定问题的部分:
Java 11调优指南中有针对不同垃圾收集器的过量GC的专门章节: 用于并联集热器 用于同步标记扫描(CMS)收集器 对于垃圾优先(G1)收集器,没有提到这种特定的错误条件。 Java 8调优指南及其过量GC部分 Java 6调优指南及其过量GC部分。
你需要在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**
您可以尝试通过参考此映像来更改服务器设置,并增加用于处理的内存大小 流程更改以黄色突出显示
你也可以通过打开cmd-> set _java_opts - xmx2g来改变java堆 2g(2gb),这取决于程序的复杂程度
尽量少使用常数变量和临时变量