JVM源码剖析之Caused by: java.lang.OutOfMemoryError: GC overhead limit exceeded异常

最新推荐文章于 2024-08-16 08:24:01 发布

程序员李哈

最新推荐文章于 2024-08-16 08:24:01 发布

阅读量937

点赞数

分类专栏：源码解读 Java底层文章标签： java jvm GC垃圾回收

本文链接：https://blog.csdn.net/qq_43799161/article/details/132211664

版权

源码解读同时被 2 个专栏收录

69 篇文章 13 订阅

订阅专栏

Java底层

26 篇文章 1 订阅

订阅专栏

本文详细解释了Java中OutOfMemoryError:GCoverheadLimitExceeded异常的产生原因，涉及全GC时间过长、可用空间不足以及垃圾回收器行为。还提供了如何解决该问题的建议，包括检查堆大小、内存泄漏、优化大对象和使用工具进行分析。源码分析揭示了垃圾回收器的决策过程和设置选项来避免该异常。

摘要由CSDN通过智能技术生成

写在前面：

版本信息：

jdk版本：jdk8u40
垃圾回收器：ParallelScavenge new/old

最近在群里看到有一位老哥拿着异常信息到处问，而发生的就是java.lang.OutOfMemoryError: GC overhead limit exceeded异常，恰好看到经常有人询问关于这个异常的问题，如何发生的，要如何解决呢？所以促使我写下这篇文章，此文章分为3大块，出现的原因，如何解决，源码论证。

异常出现的原因

full gc回收时间大于98%（这里是一个算法，可以忽略，只需要明白最近一直花大量时间在GC），并且回收后可用空间小于总空间的2%。这样的情况下，达到5次就会抛出java.lang.OutOfMemoryError: GC overhead limit exceeded异常。

总而言之：我们首先要明白，GC的过程是需要STW(STOP-THE-WORD) 也即业务线程是需要停止工作，而GC过程中消耗大量时间回收空间，而回收后的可使用空间仅仅只有总空间的2%，往往下次new对象的时候又去GC了，周而复始，给用户的体验是当前系统已经完全卡死了～

所以在种种因素下JVM认为你已经没必要去GC了，GC也是毫无意义的事情了，完全卡死的情况下，还不如我给你抛出java.lang.OutOfMemoryError: GC overhead limit exceeded异常，开发者好好去排查一下问题～

如何解决

仅供参考，还是需要分析自身系统环境做出不同的策略。

堆空间是否设置的太少？可以在启动时添加-Xms -Xmx参数设置堆大小
分析是否存在内存泄露？
如果项目庞大，是否需要提升硬件？
启动时添加-XX:+HeapDump0n0ut0fMemoryError -XX:HeapDumpPath= "路径" 参数下次发生OOM时便可分析
分析项目中经常使用的大对象，是否可以优化一下空间？
是否可以把项目中非重要的缓存数据设置成软、弱引用对象
以上的分析可以使用阿里开源的 "Arthas" 工具
还有很多笔者暂时没有考虑到的.......

源码论证

由于大部分的公司还是停留在Java8，并且垃圾回收器也是默认的ParallelScavenge new/old，所以直接给出ParallelScavenge new/old垃圾回收器的部分核心源码

src/share/vm/gc_interface/collectedHeap.inline.cpp 文件中， common_mem_allocate_noinit方法，此方法尝试开辟对象，如果开辟不成功，就会根据当前不同OOM异常种类Dump和抛出对应的异常

HeapWord* CollectedHeap::common_mem_allocate_noinit(KlassHandle klass, size_t size, TRAPS) {

  bool gc_overhead_limit_was_exceeded = false;

  // 尝试在堆空间开辟对象
  result = Universe::heap()->mem_allocate(size,
                                          &gc_overhead_limit_was_exceeded);

  // 根据gc_overhead_limit_was_exceeded参数区分是那种OOM异常。
  if (!gc_overhead_limit_was_exceeded) {
    
    // -XX:+HeapDumpOnOutOfMemoryError and -XX:OnOutOfMemoryError support
    // 英文注释特别明显了，如果设置了dump参数，就导出
    report_java_out_of_memory("Java heap space");

    // 抛出OOM：Java heap space
    THROW_OOP_0(Universe::out_of_memory_error_java_heap());
  } else {      
    // -XX:+HeapDumpOnOutOfMemoryError and -XX:OnOutOfMemoryError support
    // 英文注释特别明显了，如果设置了dump参数，就导出
    report_java_out_of_memory("GC overhead limit exceeded");

    // 抛出OOM：GC overhead limit exceeded
    THROW_OOP_0(Universe::out_of_memory_error_gc_overhead_limit());
  }
}

而我们关心的是GC overhead limit exceeded异常，而这里是根据gc_overhead_limit_was_exceeded变量来做区分，而gc_overhead_limit_was_exceeded变量传入mem_allocate方法，所以我们接着看mem_allocate方法src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.cpp 文件中mem_allocate方法，此方法也是开辟对象的过程。

HeapWord* ParallelScavengeHeap::mem_allocate(
                                     size_t size,
                                     bool* gc_overhead_limit_was_exceeded) {

  // 尝试在young_gen空间创建对象
  HeapWord* result = young_gen()->allocate(size);
  
  // 在年轻代没有创建出对象。
  while (result == NULL) {
    {
      // 因为存在锁的原因，所以下面又在年轻代尝试了一次。
      MutexLocker ml(Heap_lock);
      gc_count = Universe::heap()->total_collections();
      result = young_gen()->allocate(size);
      if (result != NULL) {
        return result;
      }

      // 年轻代开辟不了，老年代尝试一下。
      result = mem_allocate_old_gen(size);
      if (result != NULL) {
        return result;
      }

      // 超过允许尝试的次数，直接返回
      if (gclocker_stalled_count > GCLockerRetryAllocationCount) {
        return NULL;
      }
    }

    // 需要触发GC，回收空间后再尝试开辟对象
    if (result == NULL) {
      // 触发GC回收空间
      VM_ParallelGCFailedAllocation op(size, gc_count);
      VMThread::execute(&op);

      if (op.prologue_succeeded()) {

        // 是否达到次数，是否清空软引用了
        const bool limit_exceeded = size_policy()->gc_overhead_limit_exceeded();
        const bool softrefs_clear = collector_policy()->all_soft_refs_clear();

        if (limit_exceeded && softrefs_clear) {
          // 设置为true，代表抛出GC overhead limit exceeded异常
          *gc_overhead_limit_was_exceeded = true;   
          size_policy()->set_gc_overhead_limit_exceeded(false);
          return NULL;
        }

        return op.result();
      }
    }
  }

  return result;
}

我们看到后续GC回收后，判断limit_exceeded 和 softrefs_clear，如果都为true就把gc_overhead_limit_was_exceeded设置为true。

而softrefs_clear变量是清空软引用，我们知道，在JVM中，内存实在不足的时候会清空软引用

而我们看到limit_exceeded变量的设置即可。看何时把他设置为true即可。

src/share/vm/gc_implementation/share/adaptiveSizePolicy.cpp 文件中check_gc_overhead_limit方法

void AdaptiveSizePolicy::check_gc_overhead_limit(
                                          size_t young_live,
                                          size_t eden_live,
                                          size_t max_old_gen_size,
                                          size_t max_eden_size,
                                          bool   is_full_gc,
                                          GCCause::Cause gc_cause,
                                          CollectorPolicy* collector_policy) {


  // 当前eden空闲大小
  const size_t free_in_eden = max_eden_size > live_in_eden ?
    max_eden_size - live_in_eden : 0;
  // 当前老年代空闲大小
  const size_t free_in_old_gen = (size_t)(max_old_gen_size - avg_old_live()->average());
  // 当前堆空间空闲大小
  const size_t total_free_limit = free_in_old_gen + free_in_eden;
  // 堆空间的总大小
  const size_t total_mem = max_old_gen_size + max_eden_size;

  // GCHeapFreeLimit是2
  // 所以这里是算出比例，2%
  const double mem_free_limit = total_mem * (GCHeapFreeLimit/100.0);
  const double mem_free_old_limit = max_old_gen_size * (GCHeapFreeLimit/100.0);
  const double mem_free_eden_limit = max_eden_size * (GCHeapFreeLimit/100.0);

  // GCTimeLimit是98
  // 所以这里是算出比例，98%
  const double gc_cost_limit = GCTimeLimit/100.0;

  // 如果是fullgc
  if (is_full_gc) {
    // 如果GC时长超过98%
    // 并且回收后可用空间小于总空间的2%
    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) {

      inc_gc_overhead_limit_count();    // 自增一次

      // 如果开启了次数限制
      if (UseGCOverheadLimit) {
        // 如果次数大于等于5次。
        if (gc_overhead_limit_count() >=
            AdaptiveSizePolicyGCTimeLimitThreshold){
          // 设置为true，到时候就会抛出GC overhead limit exceeded异常
          // 并且清空次数
          set_gc_overhead_limit_exceeded(true);   
          reset_gc_overhead_limit_count();
        } 
      }

    }
  }

  // 如果设置了UseGCOverheadLimit的情况下， 不会响应此异常
  if (UseGCOverheadLimit && PrintGCDetails && Verbose) {
    if (gc_overhead_limit_exceeded()) {
      reset_gc_overhead_limit_count();
    } 
  }
}

这里算出了堆总空间的百分之2，gc回收时间的百分之98。然后算出了GC后空闲空间的占比，GC的回收时间。最后通过比较，如果GC回收时间大于98%，并且回收后可用空间小于总空间的2% 情况下计数器+1，如果计数器达到5次就通过set_gc_overhead_limit_exceeded方法设置为true，最终抛出java.lang.OutOfMemoryError: GC overhead limit exceeded异常。

所以看了源码后，解决GC overhead limit exceeded异常，还可以通过设置

-XX:-UseGCOverheadLimit 或者 -XX:AdaptiveSizePolicyGCTimeLimitThreshold = "设置很大的数值" 都能让JVM不抛出 GC overhead limit exceeded异常。但是没任何意义，因为会一直触发GC，一直STW暂停，用户一直是卡死的状态～