Java堆外内存溢出的紧急处理技巧

目录

• 引言
• 一、Sjavascriptpring Boot电商缓存服务案例复现
• 1.1 业务场景与技术选型背景
• 1.2 项目构建与依赖配置
• 1.3 存在内存泄漏的核心代码实现
• 二、堆外内存溢出现象的具体表现
• 2.1 系统资源监控异常
• 2.2 JVM堆内存回收异常
• 2.3 服务响应性能急剧下降
• 三、linux命令定位堆外内存溢出的完整流程
• 3.1 第一步：使用top锁定异常进程
• 3.2 第二步：用jstat确认堆内内存状态
• 3.3 第三步：pmap分析进程内存映射
• 3.4 第四步：strace追踪内存分配系统调用
• 3.5 第五步：结合jmap分析堆外内存使用情况
• 四、堆外内存溢出的解决方案与优化实践
• 4.1 立即修复：显式释放堆外内存
• 4.2 进阶方案：使用内存池管理堆外内存
• 4.2.1 内存池核心类实现
• 4.2.2 控制器代码修改
• 4.3 生产环境优化实践
• 4.3.1 结合JVM参数限制堆外内存
• 4.3.2 实现内存泄漏监控
• 4.3.3 编写内存泄漏测试用例
• 五、总结
• 5.1 堆外内存管理核心原则
• 5.2 紧急排查流程总结

引言

在高并发的Java应用场景中，堆外内存溢出往往是最难排查的问题之一。当Spring Boot项目出现内存异常时，传统的堆内存分析工具常常束手无策，因为堆外内存不受JVM堆内存管理机制的直接控制。本文将通过一个真实的电商缓存服务案例，完整展示从问题发现到定位再到解决的全流程，帮助开发者掌握堆外内存溢出的紧急处理技巧。

一、Spring Boot电商缓存服务案例复现

1.1 业务场景与技术选型背景

在现代电商系统中，商品缓存服务是支撑高并发访问的核心组件。我设计的这个案例模拟了一个典型的商品数据缓存场景：通过Redis存储商品基础信息，当用户请求商品列表时，服务需要批量从Redis获取数据并进行快速响应。选择使用堆外内存存储缓存数据，主要基于以下考虑：

• 减少GC压力：堆外内存不受JVM堆内存垃圾回收机制直接管理，大对象存储时可降低Full GC频率
• 提高IO效率：直接内存(Direct Memory)在NIO操作时可减少内核空间与用户空间的拷贝次数
• 内存隔离：避免堆内内存溢出导致的JVM崩溃，提供一定的容错能力

1.2 项目构建与依赖配置

首先创建一个标准的Spring Boot项目，在pom.XML中添加核心依赖：

<parent>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-parent</artifactId>
    <version>2.7.10</version>
    <relativePath/> <!-- lookup parent from repository -->
</parent>

<properties>
    <java.version>11</java.version>
</properties>

<dependencies>
    <!-- Spring Boot Web核心依赖 -->
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-web</artifactId>
    </dependency>
    <!-- Jedis Redis客户端 -->
    <dependency>
        <groupId>redis.clients</groupId>
        <artifactId>jedis</artifactId>
        <version>3.8.0</version>
    </dependency>
    <!-- 内存池依赖 -->
    <dependency>
        <groupId>org.apache.commons</groupId>
        <artifactId>commons-pool2</artifactId>
        <version>2.11.1</version>
    </dependency>
</dependencies>

这个配置文件中，我们引入了Spring Boot Web模块来构建REST服务，Jedis作为Redis客户端，同时预先引入了Commons Pool2作为后续内存池方案的依赖。

1.3 存在内存泄漏的核心代码实现

下面是导致堆外内存溢出的关键代码实现，注意看其中的内存分配与释放逻辑：

import redis.clients.jedis.Jedis;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;
import java.nio.ByteBuffer;
import java.util.List;

@RestController
public class ProductCacheController {

    // 商品数据获取接口，模拟从Redis批量读取数据并存储到堆外内存
    @GetMapping("/products")
    public String getProducts() {
        try (Jedis jedis = new Jedis("localhost", 6379)) {
            // 从Redis获取商品列表数据，假设存储在"product_list"键中
            List<String> productList = jedis.lrange("product_list", 0, -1);
            System.out.println("获取到" + productList.size() + "条商品数据");
            
            // 为每条商品数据分配堆外内存
            for (String product : productList) {
                // 使用allocateDirect分配直接内存，这部分内存不在JVM堆内
                ByteBuffer directBuffer = ByteBuffer.allocateDirect(product.getBytes().length);
                // 将商品数据写入堆外内存
                directBuffer.put(product.getBytes());
                // 关键问题：此处未释放分配的堆外内存！
                // 随着请求频繁调用，内存会持续泄漏
            }
            
            return "Products retrieved successfully, count: " + productList.size();
        }
    }
}

这段代码的核心问题在于：每次处理请求时都会为每个商品数据分配堆外内存，但没有执行对应的释放操作。ByteBuffer.allocateDirect方法会在Java堆外直接分配内存，这部分内存需要开发者显式管理，否则就会导致内存泄漏。在高并发场景下，这种泄漏会迅速耗尽系统内存资源。

二、堆外内存溢出现象的具体表现

2.1 系统资源监控异常

当我们启动上述服务并通过压测工具持续调用/products接口时，首先会观察到系统级的资源异常。通过SSH登录到服务器执行top命令，可以看到类似以下的输出：

top - 20:30:20 up 10 days, 23:45,  2 users,  load average: 2.56, 2.48, 2.37
Tasks: 246 total,   1 running, 245 sleeping,   0 stopped,   0 zombie
%Cpu(s):  3.2 us,  1.1 sy,  0.0 ni, 95.4 id,  0.0 wa,  0.0 hi,  0.3 si,  0.0 st
KiB Mem : 16384892 total,  123456 free, 15890740 used,  360686 buff/cache
KiB Swap: 2097148 total,        0 free, 2097148 used.  123456 avail Mem 

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
56789 root      20   0  4321456 3890740   1236 S  23.5 24.9  34:56.78 java

重点关注RES列（常驻内存大小），可以看到该Java进程的内存占用以每秒约5MB的速度持续增长，当物理内存耗尽后，系统开始使用Swap空间（如上面输出中的Swap已用2GB）。此时系统整体响应变得极为缓慢，SSH连接甚至可能出现卡顿。

2.2 JVM堆内存回收异常

很多开发者在遇到内存问题时会首先检查JVM堆内存情况，但堆外内存溢出的典型特征是堆内内存回收正常但系统内存持续减少。我们可以通过以下命令观察堆内存状态：

# 假设通过jps命令获取到的进程ID为56789
jstat -gcutil 56789 1000

执行后会看到类似以下的输出（每隔1秒刷新一次）：

  S0     S1     E      O      M     CCS    YGC     YGCT    FGC    FGCT     GCT   
  0.00  12.34  89.56  76.23  98.76python  97.45    123    12.34     5     5.67    18.01
  0.00  15.67  90.12  76.23  98.76  97.45    123    12.34     5     5.67    18.01
  0.00  18.90  91.23  76.23  98.76  97.45    123    12.34     5     5.67    18.01

分析这些数据可以发现：

• 年轻代(Eden区S0/S1)和老年代(Old区)的占用率虽然在波动，但整体保持稳定
• 垃圾回收次数(YGC/FGC)没有明显增加，回收耗时(YGCT/FGCT)也在正常范围内
• 最重要的一点：系统内存持续减少，但JVM堆内存使用情况却没有对应增长

这种矛盾的现象正是堆外内存溢出的典型特征，说明内存泄漏发生在JVM堆之外的区域。

2.3 服务响应性能急剧下降

随着堆外内存的持续泄漏，服务性能会出现以下阶梯式退化：

• 初始阶段：接口响应时间从正常的50ms逐渐增加到100-200ms
• 中期阶段：部分请求开始出现超时（超过1秒），错误率上升到5%左右
• 严重阶段：90%以上的请求超时，服务基本不可用，返回504 Gateway Timeout

通过curl -w "%{time_total}\n" -o /dev/null -s http://localhost:8080/products命令持续测试响应时间，会看到时间从正常的0.05s逐渐增长到1.5s以上，最终出现连接超时。这是因为当系统内存不足时，Linux内核会触发OOM Killer机制，开始选择性地杀死进程，同时剩余进程的内存分配操作会被阻塞，导致服务响应缓慢。

三、Linux命令定位堆外内存溢出的完整流程

3.1 第一步：使用top锁定异常进程

当发现系统变慢或服务响应异常时，首先执行top命令：

top

在交互界面中按P键（大写）以CPU使用率排序，或按M键以内存使用率排序。通常会看到一个Java进程的RES列持续增长，如：

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
56789 root      20   0  4321456 3890740   1236 S  23.5 24.9  34:56.78 java

记录下这个异常进程的PID（如56789），接下来的所有操作都将围绕这个PID展开。如果服务器上运行了多个Java进程，可能需要通过ps -ef | grep java命令结合启动参数进一步确认目标进程。

3.2 第二步：用jstat确认堆内内存状态

确认异常进程后，使用jstat命令观察JVM堆内存回收情况：

jstat -gcutil 56789 1000

如前所述，正常的堆内内存回收数据与系统内存持续减少的矛盾，是判断堆外内存问题的关键依据。如果发现以下情况，基本可以确定是堆外内存问题：

• 堆内各区域(Young/Old/MetASPace)占用率稳定
• Full GC频率没有显著增加
• 系统内存(通过free -h命令查看)持续下降

3.3 第三步：pmap分析进程内存映射

pmap命令可以查看进程的内存映射情况，这是定位堆外内存泄漏的核心工具：

pmap 56789

正常情况下，Java进程的内存映射主要包括：

• JVM堆内存（连续的一大块空间，通常标记为[heap]）
• 元空间(Metaspace)
• 代码缓存(Code Cache)
• 各种共享库(.so文件)

当存在堆外内存泄漏时，会看到大量分散的、不属于上述类别的内存块，如：

56789:   java -jar product-cache-service.jar
0000000000400000      44K r-x-- java
000000000060a000       4K r---- java
000000000060b000       8K rw--- java
0000000001000000    10240K rw---   [heap]
...
00007f2a9c000000    20480K rw---   [direct map]
00007f2a9d500000    20480K rw---   [direct map]
00007f2a9ea00000    20480K rw---   [direct map]
...
00007f2b4c000000    20480K rw---   [direct map]

注意上面输出中的[direct map]部分，这就是ByteBuffer.allocateDirect分配的直接内存。如果看到大量这样的块持续增加，且没有对应的释放，就可以确认存在堆外内存泄漏。

3.4 第四步：strace追踪内存分配系统调用

strace命令可以追踪进程的系统调用，对于确认内存分配行为非常有用：

strace -f -e "brk,mmap,munmap" -p 56789

执行后会看到类似以下的输出：

mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f2a9c000000
mmap(NULLjavascript, 20971520, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f2a9d500000
brk(0x1001000)                           = 0x1001000
mmap(NULL, 20971520, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f2a9ea00000
... (持续输出mmap调用，没有对应的munmap)

分析要点：

• mmap调用表示分配内存，munmap表示释放内存
• 正常情况下，mmap和munmap应该成对出现
• 如果看到大量mmap调用但很少或没有munmap，说明内存只分配不释放，存在泄漏

3.5 第五步：结合jmap分析堆外内存使用情况

虽然jmap主要用于分析堆内内存，但配合-histo:live参数可以查看堆内对象引用情况，帮助定位是否存在大量引用堆外内存的对象：

jmap -histo:live 56789 | head -20

在堆外内存泄漏场景中，可能会看到大量的java.nio.DirectByteBuffer对象，这些对象持有对堆外内存的引用：

 num     #instances         #bytes  class name
----------------------------------------------
   1:        123456      245760000  java.nio.DirectByteBu编程ffer
   2:         67890       8912640  [B
   3:         12345       4567800  java.lang.String

如果DirectByteBuffer的实例数量和占用字节数持续增长，进一步验证了堆外内存泄漏的判断。

四、堆外内存溢出的解决方案与优化实践

4.1 立即修复：显式释放堆外内存

针对前面案例中的问题，最直接的解决方案是显式释放分配的堆外内存。修改后的代码如下：

import redis.clients.jedis.Jedis;
import sun.misc.Cleaner;
import java.lang.reflect.Field;
import java.nio.ByteBuffer;
import java.util.List;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;

@RestController
public class ProductCacheController {

    @GetMapping("/products")
    public String getProducts() {
        try (Jedis jedis = new Jedis("localhost", 6379)) {
            List<String> productList = jedis.lrange("product_list", 0, -1);
            System.out.println("获取到" + productList.size() + "条商品数据");
            
            for (String product : productList) {
                ByteBuffer directBuffer = ByteBuffer.allocateDirect(product.getBytes().length);
                directBuffer.put(product.getBytes());
                // 关键修改：显式释放堆外内存
                cleanDirectBuffer(directBuffer);
            }
            
            return "Products retrieved successfully, count: " + productList.size();
        }
    }
    
    /**
     * 显式释放DirectByteBuffer占用的堆外内存
     * 通过反射获取Cleaner对象并执行clean操作
     * 注意：这种方式依赖Sun内部API，可能在不同JDK版本中变化
     */
    private static void cleanDirectBuffer(ByteBuffer buffer) {
        try {
            // 获取ByteBuffer类中的cleaner字段
            Field cleanerField = buffer.getClass().getDeclaredField("cleaner");
            cleanerField.setAccessible(true);
            // 获取Cleaner实例
            Cleaner cleaner = (Cleaner) cleanerField.get(buffer);
            // 执行内存清理
            cleaner.clean();
            System.out.println("释放堆外内存：" + buffer.capacity() + "字节");
        } catch (NoSuchFieldException | IllegalAccessException e) {
            System.err.println("内存释放失败：" + e.getMessage());
            e.printStackTrace();
        }
    }
}

实现原理说明：

• DirectByteBuffer内部通过Cleaner对象关联堆外内存的释放操作，Cleaner是基于虚引用(PhantomReference)实现的清理机制
• 正常情况下，当DirectByteBuffer对象被垃圾回收时，Cleaner会被触发从而释放堆外内存
• 但在高并发场景下，GC可能无法及时回收对象，导致堆外内存累积，因此需要显式调用clean方法

注意事项：

• 反射调用Sun内部API存在兼容性风险，在OpenJDK 9+中可能需要调整访问方式
• 这种方法适合紧急修复，但不是最优雅的解决方案，推荐配合内存池使用

4.2 进阶方案：使用内存池管理堆外内存

更专业的解决方案是引入内存池来管理堆外内存，以下是完整的实现步骤：

4.2.1 内存池核心类实现

首先创建ByteBufferPool类来管理DirectByteBuffer对象：

import org.apache.commons.pool2.BasePooledObjectFactory;
import org.apache.commons.pool2.PooledObject;
import org.apache.commons.pool2.impl.DefaultPooledObject;
import org.apache.commons.pool2.impl.GenericObjectPool;
import org.apache.commons.pool2.impl.GenericObjectPoolConfig;
import java.nio.ByteBuffer;

/**
 * 堆外内存池管理类
 * 负责DirectByteBuffer对象的创建、回收和管理
 */
public class ByteBufferPool {

    // 默认内存池大小
    private static final int DEFAULT_INITIAL_SIZE = 100;
    private static final int DEFAULT_MAX_SIZE = 1000;
    private static final int DEFAULT_block_SIZE = 1024; // 1KB

    private GenericObjectPool<ByteBuffer> objectPool;

    public ByteBufferPool() {
        this(DEFAULT_INITIAL_SIZE, DEFAULT_MAX_SIZE, DEFAULT_BLOCK_SIZE);
    }

    /**
     * 自定义参数的内存池构造函数
     * @param initialSize 初始池大小
     * @param maxSize 最大池大小
     * @param blockSize 每个ByteBuffer的默认大小(字节)
     */
    public ByteBufferPool(int initialSize, int maxSize, int blockSize) {
        GenericObjectPoolConfig config = new GenericObjectPoolConfig();
        config.setInitialSize(initialSize);
        config.setMaxTotal(maxSize);
        config.setMaxIdle(maxSize);
        config.setMinIdle(initialSize / 2);
        config.setBlockWhenExhausted(true);
        config.setMaxWaitMillis(5000); // 超时时间5000ms
        
        objectPool = new GenericObjectPool<>(new ByteBufferFactory(blockSize), config);
        System.out.println("ByteBufferPool初始化完成，初始大小：" + initialSize + 
                          "，最大大小：" + maxSize + "，块大小：" + blockSize + "字节");
    }

    /**
     * 从内存池获取ByteBuffer对象
     */
    public ByteBuffer borrowObject() throws Exception {
        ByteBuffer buffer = objectPool.borrowObject();
        // 清空缓冲区以便重用
        buffer.clear();
        return buffer;
    }

    /**
     * 将ByteBuffer对象归还到内存池
     */
    public void returnObject(ByteBuffer buffer) {
        try {
            objectPool.returnObject(buffer);
        } catch (Exception e) {
            System.err.println("归还内存池失败：" + e.getMessage());
        }
    }

    /**
     * 关闭内存池
     */
    public void close() {
        try {
            objectPool.close();
            System.out.println("ByteBufferPool已关闭");
        } catch (Exception e) {
            System.err.println("关闭内存池失败：" + e.getMessage());
        }
    }

    /**
     * ByteBuffer对象工厂，负责创建新的ByteBuffer实例
     */
    private static class ByteBufferFactory extends BasePooledObjectFactory<ByteBuffer> {
        private final int blockSize;

        public ByteBufferFactory(int blockSize) {
            this.blockSize = blockSize;
        }

        @Override
        public ByteBuffer create() throws Exception {
            // 使用allocateDirect创建堆外内存
            return ByteBuffer.allocateDirect(blockSize);
        }

        @Override
        public PooledObject<ByteBuffer> wrap(ByteBuffer byteBuffer) {
            return new DefaultPooledObject<>(byteBuffer);
        }

        @Override
        public void destroyObject(PooledObject<ByteBuffer> p) throws Exception {
            // 销毁对象时释放堆外内存
            ByteBuffer buffer = p.getObject();
            cleanDirectBuffer(buffer);
            super.destroyObject(p);
        }

        @Override
        public boolean validateObject(PooledObject<ByteBuffer> p) {
            // 验证对象是否可用
            ByteBuffer buffer = p.getObject();
            return buffer != null && buffer.capacity() == blockSize;
        }
    }

    /**
     * 释放DirectByteBuffer的堆外内存
     */
    private static void cleanDirectBuffer(ByteBuffer buffer) {
        try {
            if (buffer == null) {
                return;
            }
            Field cleanerField = buffer.getClass().getDeclaredField("cleaner");
            cleanerField.setAccessible(true);
            Cleaner cleaner = (Cleaner) cleanerField.get(buffer);
            cleaner.clean();
        } catch (Exception e) {
            System.err.println("释放堆外内存失败：" + e.getMessage());
        }
    }
}

4.2.2 控制器代码修改

接下来修改控制器代码，使用内存池来管理堆外内存：

import redis.clients.jedis.Jedis;
import java.nio.ByteBuffer;
import java.util.List;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;

@RestController
public class ProductCacheController {

    // 创建全局内存池实例，初始大小100，最大大小1000，块大小4KB
    private static final ByteBufferPool byteBufferPool = new ByteBufferPool(100, 1000, 4096);

    @GetMapping("/products")
    public String getProducts() {
        try (Jedis jedis = new Jedis("localhost", 6379)) {
            List<String> productList = jedis.lrange("product_list", 0, -1);
            System.out.println("获取到" + productList.size() + "条商品数据，开始处理...");
            
            for (String product : productList) {
                ByteBuffer buffer = null;
                try {
                    // 从内存池获取ByteBuffer
                    buffer = byteBufferPool.borrowObject();
                    // 确保有足够空间存储数据
                    if (product.getBytes().length > buffer.capacity()) {
                        System.out.println("数据大小超出内存池块大小，临时分配内存");
                        // 特殊情况处理：数据过大时临时分配
                        buffer = ByteBuffer.allocateDirect(product.getBytes().length);
                    }
                    buffer.put(product.getBytes());
                    // 这里可以添加数据处理逻辑
                    // ...
                } catch (Exception e) {
                    System.err.println("处理商品数据时发生异常：" + e.getMessage());
                    e.printStackTrace();
                } finally {
                    // 确保归还到内存池，即使发生异常
                    if (buffer != null && buffer.capacity() == byteBufferPool.getClass().getDeclaredField("DEFAULT_BLOCK_SIZE").getInt(null)) {
                        byteBufferPool.returnObject(buffer);
                    } else if (buffer != null) {
                   www.devze.com     // 临时分配的内存需要显式释放
                        ByteBufferPool.cleanDirectBuffer(buffer);
                    }
                }
            }
            
            return "Products processed successfully, count: " + productList.size();
        } catch (Exception e) {
            System.err.println("接口处理异常：" + e.getMessage());
            return "Error: " + e.getMessage();
        }
    }
}

4.3 生产环境优化实践

4.3.1 结合JVM参数限制堆外内存

在生产环境中，建议通过JVM参数显式限制堆外内存使用量，避免无限制分配：

# 在启动命令中添加以下参数
java -jar -Xmx2g -Xms2g -XX:MaxDirectMemorySize=1g product-cache-service.jar

• -Xmx2g -Xms2g：设置JVM堆内存大小
• -XX:MaxDirectMemorySize=1g：限制堆外内存最大使用1GB

4.3.2 实现内存泄漏监控

可以结合Micrometer实现堆外内存使用情况的监控：

import io.micrometer.core.instrument.MeterRegistry;
import io.micrometer.core.instrument.Timer;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Component;
import redis.clients.jedis.Jedis;
import java.nio.ByteBuffer;
import java.util.List;
import java.util.concurrent.TimeUnit;

@Component
public class ProductCacheService {

    private final MeterRegistry meterRegistry;
    private final ByteBufferPool byteBufferPool;

    @Autowired
    public ProductCacheService(MeterRegistry meterRegistry, ByteBufferPool byteBufferPool) {
        this.meterRegistry = meterRegistry;
        this.byteBufferPool = byteBufferPool;
    }

    public List<String> getProductList() {
        // 记录接口调用耗时
        Timer timer = Timer.start(meterRegistry);
        try (Jedis jedis = new Jedis("localhost", 6379)) {
            List<String> productList = jedis.lrange("product_list", 0, -1);
            // 记录获取到的商品数量
            meterRegistry.gauge("product.cache.count", productList.size());
            return productList;
        } finally {
            timer.stop(meterRegistry.timer("product.cache.get.time", "unit", "ms"));
        }
    }

    public void processWithBuffer(String productData) {
        ByteBuffer buffer = null;
        try {
            buffer = byteBufferPool.borrowObject();
            // 记录内存池使用情况
            meterRegistry.gauge("bytebuffer.pool.usage", byteBufferPool, 
                pool -> pool.objectPool.getNuMACtive() + "/" + pool.objectPool.getMaxTotal());
            
            if (productData.getBytes().length > buffer.capacity()) {
                meterRegistry.counter("bytebuffer.pool.overflow").increment();
                // 处理大对象情况...
            }
        } catch (Exception e) {
            meterRegistry.counter("product.process.error").increment();
        } finally {
            if (buffer != null) {
                byteBufferPool.returnObject(buffer);
            }
        }
    }
}

这些监控指标可以通过Prometheus采集，Grafana展示，当堆外内存使用量超过阈值时触发报警。

4.3.3 编写内存泄漏测试用例

为了防止类似问题再次发生，建议编写专门的内存泄漏测试：

import org.junit.jupiter.api.AfterEach;
import org.junit.jupiter.api.BeforeEach;
import org.junit.jupiter.api.Test;
import org.springframework.boot.test.context.SpringBootTest;
import java.nio.ByteBuffer;
import java.util.ArrayList;
import java.util.List;
import java.util.concurrent.CountDownLatch;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
import java.util.concurrent.TimeUnit;

@SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT)
class MemoryLeakTest {

    private ExecutorService executorService;
    private List<ByteBuffer> bufferList;

    @BeforeEach
    void setUp() {
        executorService = Executors.newFixedThreadPool(20);
        bufferList = new ArrayList<>();
    }

    @AfterEach
    void tearDown() throws Exception {
        executorService.shutdown();
        executorService.awaitTermination(5, TimeUnit.SECONDS);
        
        // 显式释放测试中创建的buffer
        for (ByteBuffer buffer : bufferList) {
            if (buffer != null) {
                // 释放堆外内存
                ByteBufferPool.cleanDirectBuffer(buffer);
            }
        }
    }

    @Test
    void testHeapOutOfMemory() throws Exception {
        // 模拟1000次并发请求
        CountDownLatch latch = new CountDownLatch(1000);
        
        for (int i = 0; i < 1000; i++) {
            executorService.submit(() -> {
                try {
                    // 这里模拟业务代码中的堆外内存使用
                    ByteBuffer buffer = ByteBuffer.allocateDirect(1024 * 1024); // 1MB
                    bufferList.add(buffer);
                    // 模拟业务处理
                    Thread.sleep(10);
                } catch (Exception e) {
                    e.printStackTrace();
                } finally {
                    // 测试中必须显式释放，避免影响其他测试
                    ByteBufferPool.cleanDirectBuffer(bufferList.remove(bufferList.size() - 1));
                    latch.countDown();
                }
            });
        }
        
        // 等待所有任务完成
        latch.await(30, TimeUnit.SECONDS);
        
        // 验证内存是否正确释放
        System.gc();
        Thread.sleep(1000);
        
        // 可以在此处添加内存使用情况的验证逻辑
        // 例如通过ManagementFactory获取内存信息
    }
}

五、总结

5.1 堆外内存管理核心原则

• 谁分配谁释放：明确内存分配的责任链，确保每个allocateDirect都有对应的释放操作
• 使用内存池：在高并发场景下，内存池能显著提高内存复用率，降低分配开销
• 设置上限：通过JVM参数限制堆外内存使用量，避免无限制分配导致系统OOM
• 实时监控：建立堆外内存使用情况的监控体系，设置合理的报警阈值

5.2 紧急排查流程总结

遇到疑似堆外内存溢出问题时，可按以下流程快速定位：

• 使用top命令锁定内存持续增长的Java进程
• 通过jstat -gcutil确认堆内内存回收正常
• 执行pmap <PID>查看内存映射，寻找异常的[direct map]块
• 用strace -f -e "brk,mmap,munmap" -p <PID>追踪内存分配系统调用
• 结合jmap -histo:live <PID>查看DirectByteBuffer对象数量

以上就是Java堆外内存溢出的紧急处理技巧的详细内容，更多关于Java堆外内存溢出的资料请关注编程客栈(www.devze.com)其它相关文章！