"GC overhead limit exceeded" 是失败的次要原因吗？
Is "GC overhead limit exceeded" a secondary reason for failing?
根据这个问题的动机：Error java.lang.OutOfMemoryError: GC overhead limit exceeded
最近我和某人就这个错误进行了辩论。
根据我的理解，这个错误本身不能被视为 JVM 失败的 "primary" 原因。
我的意思是，广泛的垃圾收集本身并不是失败的原因。大量的垃圾收集总是由非常少的可用内存量引起的，这会导致频繁的 GC 调用（核心原因可能是内存泄漏）。
如果我正确理解了对手的立场，他认为是系统中产生了很多符合GC条件的小对象，导致它们被频繁回收，才导致这个错误。所以魔鬼不是内存泄漏或低内存限制，而是 GC 调用频率本身。
这里是我们有不同观点的地方。
根据我的理解，您的进程产生多少符合 GC 条件的小对象并不重要（即使它不是一个好的设计，您可能应该尽可能减少这个数量）。如果你有足够的内存，并且没有明显的内存泄漏，那么在某个时候 GC 会收集大部分这样的对象，所以这应该不是问题。至少这样不会造成系统崩溃
简要回顾我的立场：如果你有GC overhead limit exceeded，那么要么你有某种内存泄漏，要么你只需要增加你的内存限制.
简要回顾一下我对手的立场：如果你产生了很多符合GC条件的小对象，这已经是一个问题，因为它本身会导致GC overhead limit exceeded.
我是不是错了，漏了什么？
- 部分答案 -
请注意，我使用 OpenJDK (JDK 9) 来源作为对此问题发表评论的基础。这个答案不依赖于任何类型的文档或已发布的规范，并且包含一些来自我对源代码的理解和解释的推测。
GC overhead limit exceeded 在 VM 中被视为内存不足错误的子类型，并在尝试分配内存失败后生成（请参阅 (a)）。
本质上，VM 会跟踪 完全垃圾 collection 的出现次数，并将其与对完全 GC 强制执行的限制（可以在 Hotspot 上配置）进行比较使用 -XX:GCTimeLimit=，比照 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 错误？
它实际上不会在 collection 本身期间发生，但是当 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 中找到），布尔值 gc_overhead_limit_was_exceeded 似乎不再使用。我不会很快得出结论，如果启用了 G1 GC，GC 内存开销错误就不会再发生 - 我需要检查一下。
结论
看来你是对的，这个错误确实是内存耗尽造成的；
这个错误可以根据小 objects 被收集的次数产生的说法对我来说似乎不正确，因为
- 我们看到 VM 确实需要 运行 内存不足才会发生此错误；
- 独立于第一个原因，无论如何我们都需要进一步完善声明 - 尤其是对 small objects 的引用。我们只是在谈论 年轻一代 collection 吗？如果是这样，这些 collection 不包含在根据限制检查的 GC 计数中，因此永远不会有机会参与此错误，VM 运行 OOM 与否。
根据这个问题的动机：Error java.lang.OutOfMemoryError: GC overhead limit exceeded
最近我和某人就这个错误进行了辩论。
根据我的理解，这个错误本身不能被视为 JVM 失败的 "primary" 原因。
我的意思是，广泛的垃圾收集本身并不是失败的原因。大量的垃圾收集总是由非常少的可用内存量引起的，这会导致频繁的 GC 调用（核心原因可能是内存泄漏）。
如果我正确理解了对手的立场，他认为是系统中产生了很多符合GC条件的小对象，导致它们被频繁回收，才导致这个错误。所以魔鬼不是内存泄漏或低内存限制，而是 GC 调用频率本身。
这里是我们有不同观点的地方。
根据我的理解，您的进程产生多少符合 GC 条件的小对象并不重要（即使它不是一个好的设计，您可能应该尽可能减少这个数量）。如果你有足够的内存，并且没有明显的内存泄漏，那么在某个时候 GC 会收集大部分这样的对象，所以这应该不是问题。至少这样不会造成系统崩溃
简要回顾我的立场：如果你有GC overhead limit exceeded，那么要么你有某种内存泄漏，要么你只需要增加你的内存限制.
简要回顾一下我对手的立场：如果你产生了很多符合GC条件的小对象，这已经是一个问题，因为它本身会导致GC overhead limit exceeded.
我是不是错了，漏了什么？
- 部分答案 -
请注意，我使用 OpenJDK (JDK 9) 来源作为对此问题发表评论的基础。这个答案不依赖于任何类型的文档或已发布的规范，并且包含一些来自我对源代码的理解和解释的推测。
GC overhead limit exceeded 在 VM 中被视为内存不足错误的子类型，并在尝试分配内存失败后生成（请参阅 (a)）。
本质上，VM 会跟踪 完全垃圾 collection 的出现次数，并将其与对完全 GC 强制执行的限制（可以在 Hotspot 上配置）进行比较使用 -XX:GCTimeLimit=，比照 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 错误？
它实际上不会在 collection 本身期间发生，但是当 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 中找到），布尔值 gc_overhead_limit_was_exceeded 似乎不再使用。我不会很快得出结论，如果启用了 G1 GC，GC 内存开销错误就不会再发生 - 我需要检查一下。
结论
看来你是对的，这个错误确实是内存耗尽造成的；
这个错误可以根据小 objects 被收集的次数产生的说法对我来说似乎不正确，因为
- 我们看到 VM 确实需要 运行 内存不足才会发生此错误；
- 独立于第一个原因，无论如何我们都需要进一步完善声明 - 尤其是对 small objects 的引用。我们只是在谈论 年轻一代 collection 吗？如果是这样，这些 collection 不包含在根据限制检查的 GC 计数中，因此永远不会有机会参与此错误，VM 运行 OOM 与否。