java - "GC overhead limit exceeded"是失败的次要原因吗？

Question

根据这个问题的动机:Error java.lang.OutOfMemoryError: GC overhead limit exceeded

最近我和某人就这个错误进行了辩论。

在我的理解中，这个错误本身不能被视为 JVM 失败的“首要”原因。

我的意思是，广泛的垃圾收集本身并不是失败的原因。大量的垃圾收集总是由非常少的可用内存量引起的，这会导致频繁的 GC 调用(核心原因可能是内存泄漏)。

如果我正确理解了对手的立场，他认为系统中产生了很多符合GC条件的小对象，导致它们被频繁回收，导致了这个错误。所以问题不是内存泄漏或低内存限制，而是 GC 调用频率本身。

这里是我们有不同观点的地方。

在我看来，您的流程产生多少符合 GC 条件的小对象并不重要(即使它不是一个好的设计，您可能应该尽可能减少这个数量)。如果你有足够的内存，并且没有明显的内存泄漏，那么在某个时候 GC 会收集大部分这样的对象，所以这应该不是问题。至少这不会导致系统崩溃。

简要回顾一下我的立场:如果您GC overhead limit exceeded，那么要么是内存泄漏，要么只是需要增加内存限制。

简要回顾一下我的对手的立场:如果你产生了很多符合 GC 条件的小对象，这已经是一个问题，因为它本身会导致 GC 开销限制超出。

我是不是错了，错过了什么？

Answer 1

- 部分回答 -

请注意，我使用 OpenJDK (JDK 9) 源作为基础来评论这个问题。这个答案不依赖于任何类型的文档或已发布的规范，并且包含一些来 self 对源代码的理解和解释的推测。

GC overhead limit exceeded 在 VM 中被视为内存不足错误的子类型，并在尝试分配内存失败后生成(参见 (a))。

本质上，VM 跟踪完全垃圾收集 的发生次数，并将其与为完全 GC 强制执行的限制进行比较(可以使用 -XX:GCTimeLimit= 在 Hotspot 上配置，参见 Garbage Collector Ergonomics )。

如何跟踪完整 GC 计数的实现以及检测到 GC 开销限制时背后的逻辑在一个地方可用，在 hotspot/src/share/vm/gc/shared/adaptiveSizePolicy.cpp 中。 .如您所见，为了满足 GC 开销限制的标准，需要满足老年代和伊甸园中可用内存的两个附加条件:

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) {
  ...
  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 {
        ...
      }

(a) GC overhead limit exceeded 错误何时产生？

它实际上不会在收集过程中发生，但是当 VM 尝试分配内存时 - 您可以在 hotspot/src/share/vm/gc/shared/collectedHeap.inline.hpp 中找到这些语句的理由。 :

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);
    ...
    // Failure cases
   if (!gc_overhead_limit_was_exceeded) {
       report_java_out_of_memory("Java heap space");
       ...
    } else {
       report_java_out_of_memory("GC overhead limit exceeded");
       ...
    }

(b) 关于G1实现的注意事项

查看 G1 实现的方法 mem_allocate(可以在 g1CollectedHeap.cpp 中找到)，看起来 boolean 值 gc_overhead_limit_was_exceeded 是不再使用了。如果启用 G1 GC，我不会很快得出这样的结论:GC 内存开销错误不会再发生 - 我需要检查一下。

结论

• 看来你是对的，这个错误确实是内存耗尽造成的；

• 根据收集小对象的次数可以产生这个错误的论点对我来说似乎不正确，因为

  1. 我们看到 VM 确实需要耗尽内存才能发生此错误；
  2. 独立于第一个原因，无论如何我们都需要进一步完善声明 - 尤其是对小对象的引用。我们只是在谈论年轻一代集合吗？如果是这样，这些集合不会包含在根据限制检查的 GC 计数中，因此永远不会有机会卷入此错误，无论 VM 是否运行 OOM。