JAVA线程池核心线程不回收导致堆外内存泄漏原因与解决指南

JAVA线程池核心线程不回收导致堆外内存泄漏原因与解决指南

各位同学，大家好。今天我们来深入探讨一个在Java并发编程中比较棘手的问题：Java线程池核心线程不回收导致的堆外内存泄漏。很多开发者在使用线程池时，往往只关注任务的提交和执行，而忽略了线程池本身的资源管理，特别是核心线程的回收机制。如果处理不当，很容易导致堆外内存的持续增长，最终引发OOM（OutOfMemoryError）错误。

一、线程池基本原理回顾

为了更好地理解问题，我们先来简单回顾一下Java线程池的工作原理。Java提供了ExecutorService接口及其实现类ThreadPoolExecutor来支持线程池。

ThreadPoolExecutor的核心参数包括：

• corePoolSize (核心线程数): 线程池中始终保持存活的线程数量。即使这些线程处于空闲状态，也不会被回收，除非设置了allowCoreThreadTimeOut。
• maximumPoolSize (最大线程数): 线程池允许创建的最大线程数量。
• keepAliveTime (保持存活时间): 当线程池中的线程数量超过corePoolSize时，多余的空闲线程在终止前等待新任务的最长时间。
• unit (时间单位): keepAliveTime的时间单位。
• workQueue (阻塞队列): 用于保存等待执行的任务的队列。
• threadFactory (线程工厂): 用于创建新线程的工厂。
• handler (拒绝策略): 当任务无法提交到队列中时，使用的拒绝策略。

线程池的工作流程大致如下：

1. 当有新任务提交时，线程池首先检查当前线程数是否小于corePoolSize。如果是，则创建一个新的线程来执行任务。
2. 如果当前线程数已经等于或大于corePoolSize，则将任务提交到workQueue中。
3. 如果workQueue已满，并且当前线程数小于maximumPoolSize，则创建一个新的线程来执行任务。
4. 如果workQueue已满，并且当前线程数已经等于或大于maximumPoolSize，则根据handler指定的拒绝策略来处理任务。

核心线程的存在是为了减少频繁创建和销毁线程的开销，从而提高程序的性能。但是，如果核心线程执行的任务中存在资源泄漏，那么这些资源将一直被核心线程持有，无法释放，最终导致堆外内存泄漏。

二、堆外内存泄漏的常见原因

堆外内存是指JVM堆之外的内存，例如DirectByteBuffer分配的内存、本地方法分配的内存等。线程池核心线程不回收导致的堆外内存泄漏通常与以下几个方面有关：

1. DirectByteBuffer使用不当:

   DirectByteBuffer是Java NIO中用于直接操作堆外内存的类。它允许Java程序直接读写操作系统底层的内存，避免了Java堆内存和本地内存之间的数据拷贝，提高了I/O性能。但是，DirectByteBuffer的内存回收依赖于System.gc()的调用，而JVM并不能保证System.gc()会立即执行。如果DirectByteBuffer分配的内存没有及时释放，就会导致堆外内存泄漏。

   示例代码：

   import java.nio.ByteBuffer;
   
   public class DirectByteBufferLeak {
       public static void main(String[] args) throws InterruptedException {
           for (int i = 0; i < 100000; i++) {
               ByteBuffer buffer = ByteBuffer.allocateDirect(1024 * 1024); // 分配1MB的堆外内存
               // 模拟使用ByteBuffer
               buffer.put((byte) 1);
   
               // 缺少释放ByteBuffer的代码
               // buffer = null; // 尝试设置为null，但GC不一定会立即回收
               // ((sun.nio.ch.DirectBuffer)buffer).cleaner().clean(); // 强制释放DirectByteBuffer，但不推荐直接使用sun.*包
               Thread.sleep(1); // 模拟任务执行时间
           }
       }
   }

   在这个例子中，每次循环都会分配1MB的堆外内存，但是没有显式地释放ByteBuffer对象。即使将buffer设置为null，GC也不一定会立即回收，导致堆外内存持续增长。

2. JNI调用导致的内存泄漏:

   Java Native Interface (JNI) 允许Java程序调用本地代码（例如C/C++代码）。如果在本地代码中分配了堆外内存，并且没有及时释放，就会导致堆外内存泄漏。JNI泄漏往往更难排查，需要深入理解本地代码的内存管理机制。

   示例代码 (Java):

   public class JNIExample {
       static {
           System.loadLibrary("native"); // 加载本地库
       }
   
       public native void allocateMemory(int size); // 本地方法，分配堆外内存
       public native void freeMemory(); // 本地方法，释放堆外内存
   
       public static void main(String[] args) throws InterruptedException {
           JNIExample example = new JNIExample();
           for (int i = 0; i < 100000; i++) {
               example.allocateMemory(1024 * 1024); // 分配1MB的堆外内存
               // 模拟使用内存
               Thread.sleep(1);
               example.freeMemory(); // 释放内存
           }
       }
   }

   示例代码 (C++):

   #include <jni.h>
   #include <iostream>
   
   jlong nativeMemory = 0;
   
   extern "C" JNIEXPORT void JNICALL Java_JNIExample_allocateMemory(JNIEnv *env, jobject obj, jint size) {
       nativeMemory = (jlong) malloc(size);
       if (nativeMemory == 0) {
           std::cerr << "Failed to allocate memory" << std::endl;
       }
       std::cout << "Allocated memory at address: " << nativeMemory << std::endl;
   }
   
   extern "C" JNIEXPORT void JNICALL Java_JNIExample_freeMemory(JNIEnv *env, jobject obj) {
       if (nativeMemory != 0) {
           free((void*)nativeMemory);
           nativeMemory = 0;
           std::cout << "Freed memory" << std::endl;
       }
   }

   在这个例子中，Java代码通过JNI调用C++代码分配和释放堆外内存。如果C++代码中的free()函数没有被调用，或者在分配和释放之间出现了错误，就会导致堆外内存泄漏。

3. Netty等框架的Bug或配置不当:

   许多高性能的Java框架，例如Netty，也使用了堆外内存来提高I/O性能。如果这些框架存在Bug，或者配置不当，也可能导致堆外内存泄漏。例如，Netty中的PooledByteBufAllocator会缓存ByteBuf对象，如果ByteBuf对象没有及时释放，就会导致堆外内存泄漏。

4. 内存映射文件(Memory-mapped files)未正确关闭:

   Java NIO提供的 FileChannel.map() 方法可以将文件的一部分或者全部映射到内存中，从而实现高效的文件读写。如果没有正确关闭MappedByteBuffer对应的FileChannel，会导致文件句柄泄漏，进而可能引发堆外内存泄漏。

   示例代码:

   import java.io.IOException;
   import java.nio.MappedByteBuffer;
   import java.nio.channels.FileChannel;
   import java.nio.file.Paths;
   import java.nio.file.StandardOpenOption;
   
   public class MappedByteBufferLeak {
   
       public static void main(String[] args) throws IOException {
           String filePath = "test.txt";
           long fileSize = 1024 * 1024 * 100; // 100MB
   
           try (FileChannel fileChannel = FileChannel.open(Paths.get(filePath), StandardOpenOption.READ, StandardOpenOption.WRITE, StandardOpenOption.CREATE)) {
               MappedByteBuffer buffer = fileChannel.map(FileChannel.MapMode.READ_WRITE, 0, fileSize);
               // 使用buffer进行读写操作
               for (int i = 0; i < 10; i++) {
                   buffer.put(i, (byte) i);
               }
               //缺少 unmapping 操作
               //Unmapper.unmap(buffer);  //需要自己实现或者使用反射
           } catch (IOException e) {
               e.printStackTrace();
           }
   
           //fileChannel会自动关闭，但是MappedByteBuffer相关的内存映射未释放
           System.out.println("FileChannel Closed.  ByteBuffer still mapped.");
   
           //休眠一段时间，模拟应用继续运行
           try {
               Thread.sleep(60000);
           } catch (InterruptedException e) {
               e.printStackTrace();
           }
       }
   
       //辅助类，使用反射方式强制unmapping. 生产环境不推荐
       // static class Unmapper {
       //     private static final sun.misc.Unsafe UNSAFE;
       //     private static final Method CLEANER_INVOKE;
       //
       //     static {
       //         try {
       //             Field theUnsafeField = sun.misc.Unsafe.class.getDeclaredField("theUnsafe");
       //             theUnsafeField.setAccessible(true);
       //             UNSAFE = (sun.misc.Unsafe) theUnsafeField.get(null);
       //             CLEANER_INVOKE = Class.forName("java.nio.DirectByteBuffer").getMethod("cleaner");
       //         } catch (Exception e) {
       //             throw new RuntimeException(e);
       //         }
       //     }
       //
       //     public static void unmap(MappedByteBuffer buffer) {
       //         try {
       //             Object cleaner = CLEANER_INVOKE.invoke(buffer);
       //             Method cleanMethod = cleaner.getClass().getMethod("clean");
       //             cleanMethod.invoke(cleaner);
       //         } catch (Exception e) {
       //             throw new RuntimeException(e);
       //         }
       //     }
       // }
   }

   在这个例子中，FileChannel虽然在try-with-resources中自动关闭了，但是MappedByteBuffer底层的内存映射仍然存在，需要额外手段进行unmapping.

三、如何诊断堆外内存泄漏

诊断堆外内存泄漏是一个比较复杂的过程，需要使用多种工具和技术。以下是一些常用的方法：

1. JVM监控工具:

   • jstat: 用于监控JVM的各种运行指标，包括堆内存的使用情况、GC的频率等。可以通过jstat -gcutil <pid>命令来查看GC的统计信息。
   • jmap: 用于生成堆转储快照（heap dump），可以分析堆内存的使用情况。可以通过jmap -dump:format=b,file=heapdump.bin <pid>命令来生成堆转储快照。
   • jcmd: 一个功能强大的JVM诊断工具，可以执行各种诊断命令，例如查看线程信息、GC信息、堆内存信息等。
   • VisualVM/JConsole: 图形化的JVM监控工具，可以实时监控JVM的运行状态，并进行线程dump、堆dump等操作。

2. Native Memory Tracking (NMT):

   NMT是JDK 7u40及以上版本提供的一个功能，可以跟踪JVM的堆外内存使用情况。可以通过以下步骤启用NMT：

   • 在JVM启动参数中添加-XX:NativeMemoryTracking=summary或-XX:NativeMemoryTracking=detail。
   • 使用jcmd <pid> VM.native_memory summary或jcmd <pid> VM.native_memory detail命令来查看NMT的报告。

   NMT的报告可以帮助我们定位堆外内存泄漏的来源。例如，可以查看internal、Direct Buffers、malloc等区域的内存使用情况。

3. Heap Dump分析工具:

   可以使用MAT (Memory Analyzer Tool) 或 JProfiler 等工具来分析堆转储快照。这些工具可以帮助我们找到占用大量内存的对象，并分析对象的引用链，从而找到内存泄漏的根源。虽然堆转储快照主要用于分析堆内存，但在某些情况下，也可以帮助我们发现堆外内存泄漏的线索，例如DirectByteBuffer对象。

4. 代码审查和日志分析:

   仔细审查代码，特别是涉及到DirectByteBuffer、JNI调用、Netty等框架的部分，检查是否存在资源未释放的情况。同时，分析日志文件，查找可能导致内存泄漏的异常信息。

5. 操作系统工具:

   可以使用操作系统的工具来监控进程的内存使用情况。例如，在Linux系统上，可以使用top、ps、pmap等命令来查看进程的内存使用情况。

四、解决堆外内存泄漏的方案

找到堆外内存泄漏的原因后，就可以采取相应的措施来解决问题。以下是一些常用的解决方案：

1. 显式释放DirectByteBuffer:

   DirectByteBuffer的内存回收依赖于System.gc()的调用，但是JVM并不能保证System.gc()会立即执行。因此，我们需要显式地释放DirectByteBuffer的内存。

   • 使用Cleaner: DirectByteBuffer有一个cleaner()方法，可以返回一个Cleaner对象。调用Cleaner.clean()方法可以释放DirectByteBuffer的内存。但是，Cleaner是sun.misc包下的类，不建议直接使用。
   • 使用反射: 可以通过反射的方式调用Cleaner.clean()方法。但是，这种方式的性能较差，并且可能会受到安全限制。
   • 使用第三方库: 可以使用第三方库，例如netty，来管理DirectByteBuffer的内存。netty提供了PooledByteBufAllocator，可以缓存ByteBuf对象，并自动释放ByteBuf的内存。

   示例代码 (使用反射释放DirectByteBuffer):

   import java.lang.reflect.Method;
   import java.nio.ByteBuffer;
   
   public class DirectByteBufferCleaner {
       public static void clean(ByteBuffer buffer) {
           if (buffer.isDirect()) {
               try {
                   Method cleanerMethod = buffer.getClass().getMethod("cleaner");
                   cleanerMethod.setAccessible(true);
                   Object cleaner = cleanerMethod.invoke(buffer);
                   Method clean = cleaner.getClass().getMethod("clean");
                   clean.invoke(cleaner);
               } catch (Exception e) {
                   e.printStackTrace();
               }
           }
       }
   
       public static void main(String[] args) {
           ByteBuffer buffer = ByteBuffer.allocateDirect(1024);
           // 使用buffer
           clean(buffer); // 释放DirectByteBuffer的内存
       }
   }

2. 正确管理JNI内存:

   如果在JNI调用中分配了堆外内存，必须确保在不再需要使用这些内存时及时释放。可以使用C/C++的malloc()和free()函数来分配和释放内存。同时，需要注意处理异常情况，避免内存泄漏。

   示例代码 (C++):

   #include <jni.h>
   #include <stdlib.h>
   
   extern "C" JNIEXPORT jlong JNICALL Java_com_example_JNIExample_allocateMemory(JNIEnv *env, jobject obj, jint size) {
       jlong ptr = (jlong) malloc(size);
       if (ptr == 0) {
           // 处理内存分配失败的情况
           return 0;
       }
       return ptr;
   }
   
   extern "C" JNIEXPORT void JNICALL Java_com_example_JNIExample_freeMemory(JNIEnv *env, jobject obj, jlong ptr) {
       if (ptr != 0) {
           free((void*)ptr);
       }
   }

3. 升级框架版本和配置:

   如果使用的框架存在Bug，可以尝试升级到最新版本。同时，仔细检查框架的配置，确保配置正确，避免内存泄漏。例如，对于Netty，可以调整PooledByteBufAllocator的参数，例如maxOrder、pageSize等，来优化内存管理。

4. 正确关闭MappedByteBuffer:

   确保在使用完 MappedByteBuffer后，及时关闭对应的 FileChannel。虽然try-with-resources会自动关闭FileChannel，但MappedByteBuffer的底层映射仍然存在，需要手动进行unmapping。可以使用反射的方式，或者引入第三方库来实现unmapping。

5. 设置allowCoreThreadTimeOut:

   可以设置ThreadPoolExecutor的allowCoreThreadTimeOut属性为true，允许核心线程在空闲一段时间后被回收。这样可以减少核心线程持有的资源，降低堆外内存泄漏的风险。但是，设置allowCoreThreadTimeOut可能会导致频繁创建和销毁线程，降低程序的性能。需要根据实际情况进行权衡。

   示例代码:

   import java.util.concurrent.LinkedBlockingQueue;
   import java.util.concurrent.ThreadPoolExecutor;
   import java.util.concurrent.TimeUnit;
   
   public class ThreadPoolExample {
       public static void main(String[] args) {
           ThreadPoolExecutor executor = new ThreadPoolExecutor(
                   5, // corePoolSize
                   10, // maximumPoolSize
                   60, // keepAliveTime
                   TimeUnit.SECONDS, // unit
                   new LinkedBlockingQueue<Runnable>() // workQueue
           );
           executor.allowCoreThreadTimeOut(true); // 允许核心线程超时
           // 提交任务
       }
   }

五、预防胜于治疗

预防堆外内存泄漏比解决堆外内存泄漏更加重要。以下是一些预防措施：

1. 代码规范:

   制定严格的代码规范，要求开发人员在使用DirectByteBuffer、JNI调用、Netty等框架时，必须注意资源管理，确保资源及时释放。

2. 代码审查:

   定期进行代码审查，检查是否存在潜在的内存泄漏风险。

3. 单元测试和集成测试:

   编写单元测试和集成测试，模拟各种场景，检测是否存在内存泄漏。

4. 监控和告警:

   建立完善的监控和告警机制，实时监控JVM的堆外内存使用情况，及时发现内存泄漏。

5. 使用内存分析工具:

   定期使用内存分析工具，例如MAT或JProfiler，分析堆内存的使用情况，及时发现潜在的内存泄漏。

六、表格总结常用工具和方法

工具/方法	描述	优点	缺点
jstat	监控JVM的各种运行指标，包括堆内存的使用情况、GC的频率等。	简单易用，可以实时监控JVM的运行状态。	只能提供一些基本的统计信息，无法深入分析内存泄漏的原因。
jmap	生成堆转储快照（heap dump），可以分析堆内存的使用情况。	可以生成堆转储快照，方便使用内存分析工具进行分析。	生成堆转储快照会暂停JVM，对程序的性能有一定影响。
jcmd	一个功能强大的JVM诊断工具，可以执行各种诊断命令，例如查看线程信息、GC信息、堆内存信息等。	功能强大，可以执行各种诊断命令。	学习成本较高。
VisualVM/JConsole	图形化的JVM监控工具，可以实时监控JVM的运行状态，并进行线程dump、堆dump等操作。	图形化界面，易于使用。	功能相对简单，无法深入分析内存泄漏的原因。
Native Memory Tracking (NMT)	跟踪JVM的堆外内存使用情况。	可以跟踪JVM的堆外内存使用情况，帮助我们定位堆外内存泄漏的来源。	需要在JVM启动参数中启用，对程序的性能有一定影响。
MAT/JProfiler	分析堆转储快照。	可以深入分析堆内存的使用情况，找到占用大量内存的对象，并分析对象的引用链，从而找到内存泄漏的根源。	学习成本较高，需要一定的经验。
代码审查/日志分析	仔细审查代码，特别是涉及到DirectByteBuffer、JNI调用、Netty等框架的部分，检查是否存在资源未释放的情况。同时，分析日志文件，查找可能导致内存泄漏的异常信息。	可以发现潜在的内存泄漏风险。	需要一定的经验和耐心。
操作系统工具	使用操作系统的工具来监控进程的内存使用情况，例如top、ps、pmap等命令。	可以监控进程的内存使用情况。	无法深入分析内存泄漏的原因。

七、关于堆外内存泄漏的经验总结

堆外内存泄漏是一个复杂而棘手的问题，需要我们深入理解Java线程池的工作原理、堆外内存的分配和回收机制，并熟练掌握各种诊断工具和技术。只有这样，我们才能及时发现并解决堆外内存泄漏问题，保证程序的稳定性和性能。希望今天的分享能给大家带来一些帮助。

最终的解决思路

核心线程不回收导致堆外内存泄漏，本质上是核心线程执行的任务中持有的堆外资源没有被及时释放。解决的关键在于：

1. 定位泄漏点： 使用工具（NMT, jmap, profiler）找到哪个任务或代码块分配了堆外内存而没有释放。
2. 显式释放资源： 在任务执行完成后，确保释放所有持有的堆外资源，例如 DirectByteBuffer, JNI 分配的内存等。
3. 资源池化： 对于频繁使用的堆外资源，可以使用资源池来管理，避免频繁分配和释放，降低泄漏风险。
4. 监控和告警： 建立完善的监控体系，实时监控堆外内存使用情况，及时发现并处理泄漏。