弹簧靴2执行器jvm.gc.memory.allocated公制

如何解决弹簧靴2执行器jvm.gc.memory.allocated公制

我正在使用Spring Boot 2.2.5，并通过Spring Boot执行器和Grafana监视我的应用程序指标。

我的应用程序与Docker（OpenJdk11）打包在一起，并配置有4GB内存

我的gc暂停时间较长，大约需要1-2秒，并且与 jvm.gc.memory.allocated 相关联。

jvm.gc.memory。分配的指标有时会达到 30GB

有人可以解释 jvm.gc.memory.allocated 指标吗？是什么意思？

解决方法

如果您问我，这是一个相当奇怪的指标（从某种意义上来说，掌握起来并不容易）。让我们慢慢来。

首先，它是由micrometer here生成的，如果您阅读了它的说明，则：

增加一个GC之后到下一个GC之前的年轻一代内存池的大小

对您来说也可能毫无意义。我不得不看一下计算它的代码，以了解它的作用。

如果您了解GC和look at this code的工作原理，那么实际上很简单。

世代的垃圾收集器（如G1）将堆划分为个区域（young和old）。新对象的分配发生在较年轻的区域（除非humongous，但我不会参与），尤其是在Eden space中。触发GC后，将清除Eden，然后可以再次进行分配。这是相当简化的，并不是完全正确的（major/mixed集合的情况稍有不同）。

现在已经有了该理论，您可以从：

看一下isYoungGenPool是什么。

if (youngGenPoolName != null) {
      final long youngBefore = before.get(youngGenPoolName).getUsed();
      final long youngAfter = after.get(youngGenPoolName).getUsed();
      final long delta = youngBefore - youngGenSizeAfter.get();
      youngGenSizeAfter.set(youngAfter);
      if (delta > 0L) {
           allocatedBytes.increment(delta);
      }
}

具体来说，它的定义是here：

... endsWith（“伊甸园空间”）

这样，这段代码拍摄了快照-Used Space中GC周期之前{em> 和 的快照，计算了Eden Space，并将所有这些增量添加到单个值中。这就是delta。

---

这种方法衡量应用程序在其生命周期中分配的数量，但只能通过 young 空间来分配。恕我直言，因为：：p

• 它不跟踪庞大的分配（对此有不同的度量标准）

• 它仅适用于分代垃圾收集器（例如jvm.gc.memory.allocated不是这样的收集器）