标签:
我遇到这样的问题,本地部署时抛出异常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 bool print_gc_overhead_limit_would_be_exceeded = false; 2 3 if (is_full_gc) { 4 5 if (gc_cost() > gc_cost_limit && 6 7 free_in_old_gen < (size_t) mem_free_old_limit && 8 9 free_in_eden < (size_t) mem_free_eden_limit) { 10 11 // Collections, on average, are taking too much time, and 12 13 // gc_cost() > gc_cost_limit 14 15 // we have too little space available after a full gc. 16 17 // total_free_limit < mem_free_limit 18 19 // where 20 21 // total_free_limit is the free space available in 22 23 // both generations 24 25 // total_mem is the total space available for allocation 26 27 // in both generations (survivor spaces are not included 28 29 // just as they are not included in eden_limit). 30 31 // mem_free_limit is a fraction of total_mem judged to be an 32 33 // acceptable amount that is still unused. 34 35 // The heap can ask for the value of this variable when deciding 36 37 // whether to thrown an OutOfMemory error. 38 39 // Note that the gc time limit test only works for the collections 40 41 // of the young gen + tenured gen and not for collections of the 42 43 // permanent gen. That is because the calculation of the space 44 45 // freed by the collection is the free space in the young gen + 46 47 // tenured gen. 48 49 // At this point the GC overhead limit is being exceeded. 50 51 inc_gc_overhead_limit_count(); 52 53 if (UseGCOverheadLimit) { 54 55 if (gc_overhead_limit_count() >= 56 57 AdaptiveSizePolicyGCTimeLimitThreshold){ 58 59 // All conditions have been met for throwing an out-of-memory 60 61 set_gc_overhead_limit_exceeded(true); 62 63 // Avoid consecutive OOM due to the gc time limit by resetting 64 65 // the counter. 66 67 reset_gc_overhead_limit_count(); 68 69 } else { 70 71 // The required consecutive collections which exceed the 72 73 // GC time limit may or may not have been reached. We 74 75 // are approaching that condition and so as not to 76 77 // throw an out-of-memory before all SoftRef‘s have been 78 79 // cleared, set _should_clear_all_soft_refs in CollectorPolicy. 80 81 // The clearing will be done on the next GC. 82 83 bool near_limit = gc_overhead_limit_near(); 84 85 if (near_limit) { 86 87 collector_policy->set_should_clear_all_soft_refs(true); 88 89 if (PrintGCDetails && Verbose) { 90 91 gclog_or_tty->print_cr(" Nearing GC overhead limit, " 92 93 "will be clearing all SoftReference"); 94 95 } 96 97 } 98 99 } 100 101 } 102 103 // Set this even when the overhead limit will not 104 105 // cause an out-of-memory. Diagnostic message indicating 106 107 // that the overhead limit is being exceeded is sometimes 108 109 // printed. 110 111 print_gc_overhead_limit_would_be_exceeded = true; 112 113 114 115 } else { 116 117 // Did not exceed overhead limits 118 119 reset_gc_overhead_limit_count(); 120 121 } 122 123 }
参照&延伸阅读:
http://javaeesupportpatterns.blogspot.com/2012/01/gc-overhead-limit-exceeded-understand.html
http://www.oracle.com/technetwork/java/javase/gc-tuning-6-140523.html
http://reins.altervista.org/java/gc1.4.2_example.html
http://stackoverflow.com/questions/2129044/java-heap-terminology-young-old-and-permanent-generations
http://book.51cto.com/art/201306/399236.htm
https://blogs.oracle.com/jonthecollector/entry/presenting_the_permanent_generation
转自http://www.cnblogs.com/hucn/p/3572384.html
[转]java.lang.OutOfMemoryError:GC overhead limit exceeded
标签:
原文地址:http://www.cnblogs.com/makai/p/4877648.html