Java堆外內存溢出的緊急處理技巧
更新時間：2025年06月22日 10:57:29 作者：程序員岳彬
在高并發(fā)的Java應用場景中,堆外內存溢出往往是最難排查的問題之一,當SpringBoot項目出現內存異常時,傳統(tǒng)的堆內存分析工具常常束手無策,因為堆外內存不受JVM堆內存管理機制的直接控制,本文將通過一個真實的電商緩存服務案例,完整展示從問題發(fā)現到定位再到解決的全流程
引言
在高并發(fā)的Java應用場景中，堆外內存溢出往往是最難排查的問題之一。當Spring Boot項目出現內存異常時，傳統(tǒng)的堆內存分析工具常常束手無策，因為堆外內存不受JVM堆內存管理機制的直接控制。本文將通過一個真實的電商緩存服務案例，完整展示從問題發(fā)現到定位再到解決的全流程，幫助開發(fā)者掌握堆外內存溢出的緊急處理技巧。
一、Spring Boot電商緩存服務案例復現
1.1 業(yè)務場景與技術選型背景
在現代電商系統(tǒng)中，商品緩存服務是支撐高并發(fā)訪問的核心組件。我設計的這個案例模擬了一個典型的商品數據緩存場景：通過Redis存儲商品基礎信息，當用戶請求商品列表時，服務需要批量從Redis獲取數據并進行快速響應。選擇使用堆外內存存儲緩存數據，主要基于以下考慮：
- 減少GC壓力：堆外內存不受JVM堆內存垃圾回收機制直接管理，大對象存儲時可降低Full GC頻率
- 提高IO效率：直接內存(Direct Memory)在NIO操作時可減少內核空間與用戶空間的拷貝次數
- 內存隔離：避免堆內內存溢出導致的JVM崩潰，提供一定的容錯能力
1.2 項目構建與依賴配置
首先創(chuàng)建一個標準的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作為后續(xù)內存池方案的依賴。
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());
// 關鍵問題：此處未釋放分配的堆外內存！
// 隨著請求頻繁調用，內存會持續(xù)泄漏
}
return "Products retrieved successfully, count: " + productList.size();
}
}
}
這段代碼的核心問題在于：每次處理請求時都會為每個商品數據分配堆外內存，但沒有執(zhí)行對應的釋放操作。ByteBuffer.allocateDirect方法會在Java堆外直接分配內存，這部分內存需要開發(fā)者顯式管理，否則就會導致內存泄漏。在高并發(fā)場景下，這種泄漏會迅速耗盡系統(tǒng)內存資源。
二、堆外內存溢出現象的具體表現
2.1 系統(tǒng)資源監(jiān)控異常
當我們啟動上述服務并通過壓測工具持續(xù)調用/products接口時，首先會觀察到系統(tǒng)級的資源異常。通過SSH登錄到服務器執(zhí)行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的速度持續(xù)增長，當物理內存耗盡后，系統(tǒng)開始使用Swap空間（如上面輸出中的Swap已用2GB）。此時系統(tǒng)整體響應變得極為緩慢，SSH連接甚至可能出現卡頓。
2.2 JVM堆內存回收異常
很多開發(fā)者在遇到內存問題時會首先檢查JVM堆內存情況，但堆外內存溢出的典型特征是堆內內存回收正常但系統(tǒng)內存持續(xù)減少。我們可以通過以下命令觀察堆內存狀態(tài)：
# 假設通過jps命令獲取到的進程ID為56789 jstat -gcutil 56789 1000
執(zhí)行后會看到類似以下的輸出（每隔1秒刷新一次）：
S0 S1 E O M CCS YGC YGCT FGC FGCT GCT 0.00 12.34 89.56 76.23 98.76 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
分析這些數據可以發(fā)現：
- 年輕代(Eden區(qū)S0/S1)和老年代(Old區(qū))的占用率雖然在波動，但整體保持穩(wěn)定
- 垃圾回收次數(YGC/FGC)沒有明顯增加，回收耗時(YGCT/FGCT)也在正常范圍內
- 最重要的一點：系統(tǒng)內存持續(xù)減少，但JVM堆內存使用情況卻沒有對應增長
這種矛盾的現象正是堆外內存溢出的典型特征，說明內存泄漏發(fā)生在JVM堆之外的區(qū)域。
2.3 服務響應性能急劇下降
隨著堆外內存的持續(xù)泄漏，服務性能會出現以下階梯式退化：
- 初始階段：接口響應時間從正常的50ms逐漸增加到100-200ms
- 中期階段：部分請求開始出現超時（超過1秒），錯誤率上升到5%左右
- 嚴重階段：90%以上的請求超時，服務基本不可用，返回504 Gateway Timeout
通過curl -w "%{time_total}\n" -o /dev/null -s http://localhost:8080/products命令持續(xù)測試響應時間，會看到時間從正常的0.05s逐漸增長到1.5s以上，最終出現連接超時。這是因為當系統(tǒng)內存不足時，Linux內核會觸發(fā)OOM Killer機制，開始選擇性地殺死進程，同時剩余進程的內存分配操作會被阻塞，導致服務響應緩慢。
三、Linux命令定位堆外內存溢出的完整流程
3.1 第一步：使用top鎖定異常進程
當發(fā)現系統(tǒng)變慢或服務響應異常時，首先執(zhí)行top命令：
top
在交互界面中按P鍵（大寫）以CPU使用率排序，或按M鍵以內存使用率排序。通常會看到一個Java進程的RES列持續(xù)增長，如：
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確認堆內內存狀態(tài)
確認異常進程后，使用jstat命令觀察JVM堆內存回收情況：
jstat -gcutil 56789 1000
如前所述，正常的堆內內存回收數據與系統(tǒng)內存持續(xù)減少的矛盾，是判斷堆外內存問題的關鍵依據。如果發(fā)現以下情況，基本可以確定是堆外內存問題：
- 堆內各區(qū)域(Young/Old/Metaspace)占用率穩(wěn)定
- Full GC頻率沒有顯著增加
- 系統(tǒng)內存(通過free -h命令查看)持續(xù)下降
3.3 第三步：pmap分析進程內存映射
pmap命令可以查看進程的內存映射情況，這是定位堆外內存泄漏的核心工具：
pmap 56789
正常情況下，Java進程的內存映射主要包括：
- JVM堆內存（連續(xù)的一大塊空間，通常標記為
[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分配的直接內存。如果看到大量這樣的塊持續(xù)增加，且沒有對應的釋放，就可以確認存在堆外內存泄漏。
3.4 第四步：strace追蹤內存分配系統(tǒng)調用
strace命令可以追蹤進程的系統(tǒng)調用，對于確認內存分配行為非常有用：
strace -f -e "brk,mmap,munmap" -p 56789
執(zhí)行后會看到類似以下的輸出：
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f2a9c000000 mmap(NULL, 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 ... (持續(xù)輸出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.DirectByteBuffer 2: 67890 8912640 [B 3: 12345 4567800 java.lang.String
如果DirectByteBuffer的實例數量和占用字節(jié)數持續(xù)增長，進一步驗證了堆外內存泄漏的判斷。
四、堆外內存溢出的解決方案與優(yōu)化實踐
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對象并執(zhí)行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);
// 執(zhí)行內存清理
cleaner.clean();
System.out.println("釋放堆外內存：" + buffer.capacity() + "字節(jié)");
} catch (NoSuchFieldException | IllegalAccessException e) {
System.err.println("內存釋放失敗：" + e.getMessage());
e.printStackTrace();
}
}
}
實現原理說明：
- DirectByteBuffer內部通過Cleaner對象關聯(lián)堆外內存的釋放操作，Cleaner是基于虛引用(PhantomReference)實現的清理機制
- 正常情況下，當DirectByteBuffer對象被垃圾回收時，Cleaner會被觸發(fā)從而釋放堆外內存
- 但在高并發(fā)場景下，GC可能無法及時回收對象，導致堆外內存累積，因此需要顯式調用clean方法
注意事項：
- 反射調用Sun內部API存在兼容性風險，在OpenJDK 9+中可能需要調整訪問方式
- 這種方法適合緊急修復，但不是最優(yōu)雅的解決方案，推薦配合內存池使用
4.2 進階方案：使用內存池管理堆外內存
更專業(yè)的解決方案是引入內存池來管理堆外內存，以下是完整的實現步驟：
4.2.1 內存池核心類實現
首先創(chuàng)建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對象的創(chuàng)建、回收和管理
*/
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的默認大小(字節(jié))
*/
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 + "字節(jié)");
}
/**
* 從內存池獲取ByteBuffer對象
*/
public ByteBuffer borrowObject() throws Exception {
ByteBuffer buffer = objectPool.borrowObject();
// 清空緩沖區(qū)以便重用
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對象工廠，負責創(chuàng)建新的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創(chuàng)建堆外內存
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 {
// 創(chuàng)建全局內存池實例，初始大小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("處理商品數據時發(fā)生異常：" + e.getMessage());
e.printStackTrace();
} finally {
// 確保歸還到內存池，即使發(fā)生異常
if (buffer != null && buffer.capacity() == byteBufferPool.getClass().getDeclaredField("DEFAULT_BLOCK_SIZE").getInt(null)) {
byteBufferPool.returnObject(buffer);
} else if (buffer != null) {
// 臨時分配的內存需要顯式釋放
ByteBufferPool.cleanDirectBuffer(buffer);
}
}
}
return "Products processed successfully, count: " + productList.size();
} catch (Exception e) {
System.err.println("接口處理異常：" + e.getMessage());
return "Error: " + e.getMessage();
}
}
}
4.3 生產環(huán)境優(yōu)化實踐
4.3.1 結合JVM參數限制堆外內存
在生產環(huán)境中，建議通過JVM參數顯式限制堆外內存使用量，避免無限制分配：
# 在啟動命令中添加以下參數 java -jar -Xmx2g -Xms2g -XX:MaxDirectMemorySize=1g product-cache-service.jar
-Xmx2g -Xms2g：設置JVM堆內存大小-XX:MaxDirectMemorySize=1g：限制堆外內存最大使用1GB
4.3.2 實現內存泄漏監(jiān)控
可以結合Micrometer實現堆外內存使用情況的監(jiān)控：
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);
}
}
}
}
這些監(jiān)控指標可以通過Prometheus采集，Grafana展示，當堆外內存使用量超過閾值時觸發(fā)報警。
4.3.3 編寫內存泄漏測試用例
為了防止類似問題再次發(fā)生，建議編寫專門的內存泄漏測試：
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);
// 顯式釋放測試中創(chuàng)建的buffer
for (ByteBuffer buffer : bufferList) {
if (buffer != null) {
// 釋放堆外內存
ByteBufferPool.cleanDirectBuffer(buffer);
}
}
}
@Test
void testHeapOutOfMemory() throws Exception {
// 模擬1000次并發(fā)請求
CountDownLatch latch = new CountDownLatch(1000);
for (int i = 0; i < 1000; i++) {
executorService.submit(() -> {
try {
// 這里模擬業(yè)務代碼中的堆外內存使用
ByteBuffer buffer = ByteBuffer.allocateDirect(1024 * 1024); // 1MB
bufferList.add(buffer);
// 模擬業(yè)務處理
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都有對應的釋放操作
- 使用內存池：在高并發(fā)場景下，內存池能顯著提高內存復用率，降低分配開銷
- 設置上限：通過JVM參數限制堆外內存使用量，避免無限制分配導致系統(tǒng)OOM
- 實時監(jiān)控：建立堆外內存使用情況的監(jiān)控體系，設置合理的報警閾值
5.2 緊急排查流程總結
遇到疑似堆外內存溢出問題時，可按以下流程快速定位：
- 使用
top命令鎖定內存持續(xù)增長的Java進程 - 通過
jstat -gcutil確認堆內內存回收正常 - 執(zhí)行
pmap <PID>查看內存映射，尋找異常的[direct map]塊 - 用
strace -f -e "brk,mmap,munmap" -p <PID>追蹤內存分配系統(tǒng)調用 - 結合
jmap -histo:live <PID>查看DirectByteBuffer對象數量
以上就是Java堆外內存溢出的緊急處理技巧的詳細內容，更多關于Java堆外內存溢出的資料請關注腳本之家其它相關文章！
相關文章
這篇文章主要為大家詳細介紹了Java SE實現多人聊天室功能，文中示例代碼介紹的非常詳細，具有一定的參考價值，感興趣的小伙伴們可以參考一下2019-01-01
解析Java的InputStream類并借助其讀取ppt文件
這篇文章主要介紹了Java的InputStream類并借助其讀取ppt文件,講到了InputStream類中一些常用的方法的問題,需要的朋友可以參考下2015-11-11
如何在Java SpringBoot項目中配置動態(tài)數據源你知道嗎
這篇文章主要介紹了SpringBoot如何在運行時動態(tài)添加數據源,文中通過示例代碼介紹的非常詳細，對大家的學習或者工作具有一定的參考學習價值,需要的朋友可以參考下2021-09-09
這篇文章主要介紹了Java?網絡編程?——?Socket?相關知識，本文通過示例代碼給大家介紹的非常詳細，對大家的學習或工作具有一定的參考借鑒價值,需要的朋友可以參考下2023-05-05
Springfox是Spring框架的API文檔工具,集成Swagger規(guī)范,自動生成文檔并支持多語言/版本,模塊化設計便于擴展,但存在版本兼容性、性能開銷及對WebFlux支持不足等缺點,適合傳統(tǒng)SpringMVC項目,本文介紹Springfox使用,感興趣的朋友一起看看吧2025-06-06
這篇文章主要介紹了Java如何使用正則表達式從字符串中提取數字問題,具有很好的參考價值,希望對大家有所幫助,如有錯誤或未考慮完全的地方,望不吝賜教2023-12-12
Maven是圍繞著構建生命周期的核心概念為原型，整個項目的創(chuàng)建和部署都是圍繞著生命周期展開的，一個生命周期由若干個生命周期階段組成。下面通過本文給大家介紹Maven 配置文件 生命周期 常用命令詳解，一起看看吧2017-11-11
這篇文章主要為大家詳細介紹了SpringBoot如何整合Hmily實現TCC分布式事務,文中的示例代碼講解詳細,感興趣的小伙伴可以跟隨小編一起學習一下2024-11-11
本篇文章是對如何在NDK中呼叫Java的class進行了詳細的分析介紹，需要的朋友參考下2013-05-05
SpringMVC中使用@PathVariable綁定路由中的數組的方法
這篇文章主要介紹了SpringMVC中使用@PathVariable綁定路由中的數組的方法，文中通過示例代碼介紹的非常詳細，對大家的學習或者工作具有一定的參考學習價值，需要的朋友們下面隨著小編來一起學習學習吧2019-07-07