java - Log4j2 中是否使用了 Java native 内存？我发现很多登录 native 内存而不是堆

Question

我们有一个通过运行 Main 函数启动的 java 应用程序，我们还在 springboot 中启动嵌入式 jetty 作为 webcontainer。我发现 java head reached max size ，但是堆使用率很低并且 java 耗尽了操作系统杀死的 native 内存

pmap中有很多64MB的内存。我转储了一些内存块，发现其中有很多日志。日志时间是多种多样的，似乎即使过去了几天，日志仍然在内存中。例如

2019-03-23T05:50:46,851 661258664 [xxxxxx] INFO
2019-03-27T06:00:12,040 1029308155 [xxxxxxxx] INFO .........

我们使用 log4j2 和 slf4j 作为日志工具。日志由名称以“qtp”开头的 jetty 线程打印。我们设置了 immediateFlush="false" 和 SizeBasedTriggeringPolicy size="10MB"

我不知道为什么日志内容不在堆中。 log4j2 在缓存或写入日志时是否使用 java native 内存？是否可能是 log4j2 内存泄漏？

Answer 1

我怀疑您看到的是 Log4j 2 一个鲜为人知的特性的副作用:garbage-free logging .

从 log4j 2.6 开始，该库在稳态日志记录期间非常小心地不分配任何临时对象(在初始化和配置期间会分配一些临时对象)。

其他没有此功能的日志记录库通常会分配许多 LogEvent 对象，以及字符串、char[] 数组和 byte[] 数组。这些通常是非常短暂的并且很快被收集，但是大量的日志记录将填满年轻一代并有助于提升。

在 HotSpot JVM 上，即使是 minor collections 也是 stop-the-world collections，具有所有当前的 GC 算法:Serial、Parallel、Concurrent、CMS 和 G1。 (这可能对 Shenandoah 和 ZGC 影响较小，但这些收集器在撰写本文时仍处于实验阶段。另请注意 Zing/Azul 有一个不间断收集器，但该工作尚未贡献给 OpenJDK。)

Log4j 2 通过在可能的情况下避免分配和重用内存来回避这一点。