jvm堆外内存一直涨(jvm内存溢出故障排查)

---

一、美团面试：说说OOM三大场景和解决方案？

美团面试题：深入剖析JavaOOM三大场景及解决方案

在编程中，当程序突然崩溃并抛出OutOfMemoryError时，我们称之为内存溢出，请求Java应用程序内存超过JVM限制。oom通常是由于内存分配不当或内存泄漏造成的。接下来，我们将讨论三种典型的JavaOOM场景和应对策略。

场景1：堆内存溢出

这是最常见的oom场景，当JVM尝试分配新的对象空间，但堆内存不足时，就会发生这种情况。例如，执行某些内存密集型代码可能会导致堆溢出。解决方案包括实时监控内存使用情况、对堆文件进行在线和离线分析、调整JVM参数捕获堆heap以及使用jmap等命令行工具。

场景2：元空间溢出（MetaspaceOOM）

元空间是存储类元数据的区域，它与堆分开。当大量的动态类生成导致元空间不断增长而GC无法释放它时，就会发生OOM。元空间的大小受系统限制，可以通过配置MaxMetaspaceSize来设置。避免元空间OOM的关键是控制动态类的生成。

场景3：堆外OOM（Off-HeapOOM）

JavaNIO库使用的堆外内存，如果用于高性能缓存，如果没有妥善管理。提供足够的堆外内存并正确分配和释放内存是避免此问题的关键。

为了有效预防和应对OOM，我们应该定期监控内存使用情况、分析批处理文件并根据当前场景调整JVM配置。请记住在项目上线之前进行适当的内存管理优化。

---

二、深入浅出JavaFileChannel的堆外内存使用我们从一个在线系统OOM出发，通过解决用户反映的IoTDB查询卡顿问题，深入探讨了JavaFileChannel中堆外内存的使用。
首先，让我们了解一些背景知识。FileChannel是JavaNIO提供的文件通道类，允许对文件进行读写操作。堆外内存是指直接在系统内存中分配的、不受Java堆管理的内存区域。
FileChannel之所以使用堆外内存，是为了提高性能。使用DirectByteBuffer时，数据已经在堆外内存中，因此I/O操作时没有复制过程。这称为“零拷贝”。然而，操作系统需要将堆上的数据复制到堆外内存进行I/O操作，因为操作系统通过内存地址与数据进行交互。
当JVM执行垃圾收集（GC）时，可能会导致内存地址发生变化，影响正在执行的I/O操作。因此，将数据从堆复制到堆外内存可以保证I/O过程中数据地址保持不变。
在JDK源码分析中，我们发现了DirectByteBuffer的分配和回收机制。DirectByteBuffer在分配时创建的Cleaner对象用于回收堆外内存。当DirectByteBuffer仅被Cleaner引用时，它可以在任何GC周期内被回收。这样，虽然堆外内存并非完全不受GC控制，但通过Cleaner实现了有效的回收机制。
FileChannel在读写过程中使用DirectByteBuffer进行数据操作。在分配和回收临时DirectByteBuffer时，考虑到系统资源限制，适当调整TEMP_BUF_POOL_SIZE的值可以避免OOM问题。
回到一开始提到的线上问题，用户在使用IoTDB时遇到了OOM。通过源码分析，我们发现MAX_CACHED_BUFFER_SIZE配置不当，导致额外分配的堆外内存缓存过大，最终导致OOM。通过调整配置解决了这个问题。
JavaFileChannel使用堆外内存提高了I/O操作的性能，但也需要合理的配置和管理，避免资源浪费和内存泄漏，保证系统的稳定运行。