Error java.lang.OutOfMemoryError: GC overhead limit exceeded

后端 未结 20 2332
攒了一身酷
攒了一身酷 2020-11-21 05:23

I get this error message as I execute my JUnit tests:

java.lang.OutOfMemoryError: GC overhead limit exceeded

I know what an OutOfMemo

相关标签:
20条回答
  • 2020-11-21 05:28

    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 :)

    In short, I had to change my app-level 'build.gradle' file from: //...

    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
        }
    }
    
    //...
    
    0 讨论(0)
  • 2020-11-21 05:29

    If you are sure there are no memory leaks in your program, try to:

    1. Increase the heap size, for example -Xmx1g.
    2. Enable the concurrent low pause collector -XX:+UseConcMarkSweepGC.
    3. Reuse existing objects when possible to save some memory.

    If necessary, the limit check can be disabled by adding the option -XX:-UseGCOverheadLimit to the command line.

    0 讨论(0)
  • 2020-11-21 05:29

    For me, the following steps worked:

    1. Open the eclipse.ini file
    2. Change

      -Xms40m
      -Xmx512m
      

      to

      -Xms512m
      -Xmx1024m
      
    3. Restart Eclipse

    See here

    0 讨论(0)
  • 2020-11-21 05:30

    try this

    open the build.gradle file

      android {
            dexOptions {
               javaMaxHeapSize = "4g"
            }
       }
    
    0 讨论(0)
  • 2020-11-21 05:31

    To increase heap size in IntelliJ IDEA follow the following instructions. It worked for me.

    For Windows Users,

    Go to the location where IDE is installed and search for following.

    idea64.exe.vmoptions
    

    Edit the file and add the following.

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

    That is it !!

    0 讨论(0)
  • 2020-11-21 05:32

    It's usually the code. Here's a simple example:

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

    Using Java 1.6.0_24-b07 on a Windows 7 32 bit.

    java -Xloggc:gc.log GarbageCollector
    

    Then look at gc.log

    • Triggered 444 times using BAD method
    • Triggered 666 times using WORSE method
    • Triggered 354 times using BETTER method

    Now granted, this is not the best test or the best design but when faced with a situation where you have no choice but implementing such a loop or when dealing with existing code that behaves badly, choosing to reuse objects instead of creating new ones can reduce the number of times the garbage collector gets in the way...

    0 讨论(0)
提交回复
热议问题