java.lang.OutOfMemoryError:GC overhead limit exceeded填坑心得

我遇到这样的问题,本地部署时抛出异常java.lang.OutOfMemoryError:GC overhead limit exceeded导致服务起不来,查看日志发现加载了太多资源到内存,本地的性能也不好,gc时间消耗的较多。解决这种问题两种方法是,增加参数,- XX:-UseGCOverheadLimit,关闭这个特性,同时增加heap大小,-Xmx1024m。坑填了,but why?

OOM大家都知道,就是JVM内存溢出了,那GC overhead limit exceed呢?

GC overhead limt exceed检查是Hotspot VM 1.6定义的一个策略,通过统计GC时间来预测是否要OOM了,提前抛出异常,防止OOM发生。Sun 官方对此的定义是:“并行/并发回收器在GC回收时间过长时会抛出OutOfMemroyError。过长的定义是,超过98%的时间用来做GC并且回收 了不到2%的堆内存。用来避免内存过小造成应用不能正常工作。“

听起来没啥用...预测OOM有啥用?起初开来这玩意只能用来Catch住释放内存资源,避免应用挂掉。后来发现一般情况下这个策略不能拯救你的应用,但是可以在应用挂掉之前做最后的挣扎,比如数据保存或者保存现场(Heap Dump)。

而且有些时候这个策略还会带来问题,比如加载某个大的内存数据时频繁OOM。

假如你也生产环境中遇到了这个问题,在不知道原因时不要简单的猜测和规避。可以通过-verbose:gc -XX:+PrintGCDetails看 下到底什么原因造成了异常。通常原因都是因为old区占用过多导致频繁Full GC,最终导致GC overhead limit exceed。如果gc log不够可以借助于JProfile等工具查看内存的占用,old区是否有内存泄露。分析内存泄露还有一个方法-XX:+HeapDumpOnOutOfMemoryError,这样OOM时会自动做Heap Dump,可以拿MAT来排查了。还要留意young区,如果有过多短暂对象分配,可能也会抛这个异常。

日志的信息不难理解,就是每次gc时打条日志,记录GC的类型,前后大小和时间。举个例子。

33.125: [GC [DefNew: 16000K->16000K(16192K), 0.0000574 secs][Tenured: 2973K->2704K(16384K), 0.1012650 secs] 18973K->2704K(32576K), 0.1015066 secs]

100.667:[Full GC [Tenured: 0K->210K(10240K), 0.0149142 secs] 4603K->210K(19456K), [Perm : 2999K->2999K(21248K)], 0.0150007 secs] 

GC和Full GC代表gc的停顿类型,Full GC代表stop-the-world。箭头两边是gc前后的区空间大小,分别是young区、tenured区和perm区,括号里是该区的总大小。冒 号前面是gc发生的时间,单位是秒,从jvm启动开始计算。DefNew代表Serial收集器,为Default New Generation的缩写,类似的还有PSYoungGen,代表Parallel Scavenge收集器。这样可以通过分析日志找到导致GC overhead limit exceeded的原因,通过调节相应的参数解决问题。

文中涉及到的名词解释,

Eden Space:堆内存池,大多数对象在这里分配内存空间。

Survivor Space:堆内存池,存储在Eden Space的gc中存活下来的对象。

Tenured Generation:堆内存池,存储Survivor Space中存活过几次gc的对象。

Permanent Generation:非堆空间,存储的是class和method对象。

Code Cache:非堆空间,JVM用来存储编译和存储native code。

最后附上GC overhead limit exceed HotSpot的实现:


1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59

60

61

62

bool print_gc_overhead_limit_would_be_exceeded = false;

if (is_full_gc) {

  if (gc_cost() > gc_cost_limit &&

    free_in_old_gen < (size_t) mem_free_old_limit &&

    free_in_eden < (size_t) mem_free_eden_limit) {

    // Collections, on average, are taking too much time, and

    //      gc_cost() > gc_cost_limit

    // we have too little space available after a full gc.

    //      total_free_limit < mem_free_limit

    // where

    //   total_free_limit is the free space available in

    //     both generations

    //   total_mem is the total space available for allocation

    //     in both generations (survivor spaces are not included

    //     just as they are not included in eden_limit).

    //   mem_free_limit is a fraction of total_mem judged to be an

    //     acceptable amount that is still unused.

    // The heap can ask for the value of this variable when deciding

    // whether to thrown an OutOfMemory error.

    // Note that the gc time limit test only works for the collections

    // of the young gen + tenured gen and not for collections of the

    // permanent gen.  That is because the calculation of the space

    // freed by the collection is the free space in the young gen +

    // tenured gen.

    // At this point the GC overhead limit is being exceeded.

    inc_gc_overhead_limit_count();

    if (UseGCOverheadLimit) {

      if (gc_overhead_limit_count() >=

          AdaptiveSizePolicyGCTimeLimitThreshold){

        // All conditions have been met for throwing an out-of-memory

        set_gc_overhead_limit_exceeded(true);

        // Avoid consecutive OOM due to the gc time limit by resetting

        // the counter.

        reset_gc_overhead_limit_count();

      } else {

        // The required consecutive collections which exceed the

        // GC time limit may or may not have been reached. We

        // are approaching that condition and so as not to

        // throw an out-of-memory before all SoftRef's have been

        // cleared, set _should_clear_all_soft_refs in CollectorPolicy.

        // The clearing will be done on the next GC.

        bool near_limit = gc_overhead_limit_near();

        if (near_limit) {

          collector_policy->set_should_clear_all_soft_refs(true);

          if (PrintGCDetails && Verbose) {

            gclog_or_tty->print_cr("  Nearing GC overhead limit, "

              "will be clearing all SoftReference");

          }

        }

      }

    }

    // Set this even when the overhead limit will not

    // cause an out-of-memory.  Diagnostic message indicating

    // that the overhead limit is being exceeded is sometimes

    // printed.

    print_gc_overhead_limit_would_be_exceeded = true;

 

  } else {

    // Did not exceed overhead limits

    reset_gc_overhead_limit_count();

  }

}

时间: 2024-09-28 17:44:37

java.lang.OutOfMemoryError:GC overhead limit exceeded填坑心得的相关文章

android studio Error:java.lang.OutOfMemoryError: GC overhead limit exceeded

android studio Error:java.lang.OutOfMemoryError: GC overhead limit exceeded 在app下的build.gradle中找到android,并添加如下配置 dexOptions { javaMaxHeapSize "4g" } 如: android { ... ... dexOptions { javaMaxHeapSize "4g" } ... ... }  

java.lang.OutOfMemoryError: GC overhead limit exceeded 问题分析和解决(转)

在项目历史数据导入过程中,出现了应用无法访问的情况.立刻对Weblogic进行分析,发现Weblogic的内存.线程等性能良好,Server也是Running的状态.随后查看了Weblogic日志,在日志中发现下述错误   通过排查问题后得出造成此类问题的原因是,项目的一个模块在批量导入数据,程序需要New一个很大的对象,GC发现内存不够后,对内存进行回收,但是发现回收后的内存还不能满足大对象的需要.应此造成了内存溢出.   解决方案:调大Weblogic的启动内存即可.   http://bl

Hive优化Hive Multi Insert 引起的GC overhead limit exceeded笔记

当你有这么个需求从某张hive表里做各类统计,完了之后落到各个分类的统计表里存储.自然而然我们会想到使用hive的Multi Insert 语句来实现.因为使用Multi Insert 语句可以避免多次扫描同一份原始表数据.本文记录一次使用Multi Insert 语句出现的GC overhead limit exceeded问题. 问题描述 我有这么个需求从某个域名相关的表里统计各个维度的数据落到相应的表里面.下面是我的SQL实例代码: + expand source 上述语句会产生6个Job

An internal error occurred during: &quot;Retrieving archetypes:&quot;. GC overhead limit exceeded

An internal error occurred during: "Retrieving archetypes:".GC overhead limit exceeded 异常,分享牛系列,分享牛专栏,分享牛. 出现这种情况是什么原因造成的呢? 1.肯定是jvm抛出的异常. 2.eclipse或者myeclipse配置的文件在安装的目录下myeclipse.ini或者eclipse.ini.所有能配置的大概就在这个地方了. 3.修改文件如下: -vmargs-Xmx1024m-Xms

eclipse报错GC overhead limit exceed,卡顿

在使用Eclipse的Build Project功能时,提示以下错误: An internal error occurred during: "Build Project". GC overhead limit exceeded 如图: 搜索的一下,是属于java.lang.OutOfMemoryError. OOM大家都知道,就是JVM内存溢出了,那GC overhead limit exceed呢? GC overhead limt exceed检查是Hotspot VM 1.6定

服务器java.lang.OutOfMemoryError: allocLargeArray内存溢出的解决

今天一个web服务器不工作了,查看日志.tomcat报出如下信息: Caused by: java.lang.OutOfMemoryError: allocLargeArray - Object size: 80040, Num elements: 40010 以上日志信息基本的意思是程序要分配一个大小为 80040字节的数组(在JVM中数组也是对象,也是在heap中分配的),40010是指数组元素的多少.但是分配这个数组的时候, heap没有可用的空间了. 针对以上情况,解决办法如下: A:调

Java 内存溢出(java.lang.OutOfMemoryError)的常见情况和处理方式总结(转)

java.lang.OutOfMemoryError这个错误我相信大部分开发人员都有遇到过,产生该错误的原因大都出于以下原因:JVM内存过小.程序不严密,产生了过多的垃圾. 导致OutOfMemoryError异常的常见原因有以下几种: 内存中加载的数据量过于庞大,如一次从数据库取出过多数据: 集合类中有对对象的引用,使用完后未清空,使得JVM不能回收: 代码中存在死循环或循环产生过多重复的对象实体: 使用的第三方软件中的BUG: 启动参数内存值设定的过小: 此错误常见的错误提示: tomcat

java.lang.OutOfMemoryError: Java heap space 解决方法

java.lang.OutOfMemoryError: Java heap space 解决方法 这个问题的根源是jvm虚拟机的默认Heap大小是64M,可以通过设置其最大和最小值来实现.设置的方法主要是几个. 1.可以在windows 更改系统环境变量加上JAVA_OPTS=-Xms64m -Xmx512m 2,如果用的tomcat,在windows下,可以在 C:/tomcat5.5.9/bin/catalina.bat  中加上: set JAVA_OPTS=-Xms64m -Xmx256

java.lang.OutOfMemoryError: PermGen space及其解决方法

PermGen space的全称是Permanent Generation space,是指内存的永久保存区域OutOfMemoryError: PermGen space从表面上看就是内存益出,解决方法也一定是加大内存.说说为什么会内存益出:这一部分用于存放Class和Meta的信息,Class在被 Load的时候被放入PermGen space区域,它和和存放Instance的Heap区域不同,GC(Garbage Collection)不会在主程序运行期对PermGen space进行清理