【深度揭秘】Caffeine 緩存引發的內存泄漏全攻略：從根源到解決方案 Detail - 緩存,後端,java,內存泄漏,解決方案異常君 Blog

前言

大家好！今天我要和你們分享一個在 Java 開發中常見但又容易被忽視的問題：Caffeine 緩存引起的內存泄漏。作為目前 Java 生態中性能最強的本地緩存庫，Caffeine 被廣泛應用於各種項目中。但是，如果使用不當，它可能會變成你係統中的"內存黑洞"。

在這篇文章中，我會用通俗易懂的語言，結合實際案例，深入分析 Caffeine 緩存可能導致的內存泄漏問題，並提供針對性的解決方案。無論你是剛接觸 Caffeine 的新手，還是已經在項目中大量使用的老手，這篇文章都值得一讀。

Caffeine 簡介

Caffeine 是一個高性能的 Java 緩存庫，它提供了近乎最優的命中率，同時具有出色的讀寫性能。它的設計靈感來源於 Google 的 Guava Cache，但在性能和功能上有了顯著提升。

graph TD
    A[應用程序] -->|讀/寫| B[Caffeine緩存]
    B -->|命中| A
    B -->|未命中| C[數據源]
    C -->|加載數據| B
    B -->|過期/驅逐| D[GC回收]

Caffeine 的核心特性包括：

自動加載
基於大小、時間和引用的驅逐策略
統計和監控功能
異步刷新
寫入傳播

內存泄漏的根本原因

在討論具體案例前，我們先來理解一下，為什麼使用 Caffeine 會導致內存泄漏？

內存泄漏本質上是指那些不再需要的對象無法被垃圾回收器回收，從而佔用着寶貴的內存空間。當使用緩存時，我們主動將對象保留在內存中，這本身就與垃圾回收的目標相悖。

graph LR
    A[正常對象] -->|不再使用| B[可回收]
    C[緩存對象] -->|仍被緩存引用| D[不可回收]
    D -->|緩存滿/過期| B
    D -->|緩存配置不當| E[內存泄漏]

使用 Caffeine 時，以下幾種情況容易導致內存泄漏：

緩存無上限且沒有合理的過期策略
鍵值對象設計不當，導致意外的引用保留
緩存的生命週期管理不當
線程本地緩存未正確清理

接下來，我們通過具體案例來分析這些問題。

案例一：無上限緩存導致的內存泄漏

問題描述

小王在開發一個用户信息查詢系統時，為了提高性能，使用了 Caffeine 緩存用户數據。他的實現代碼如下：

// 錯誤示例
Cache<String, UserInfo> userCache = Caffeine.newBuilder()
    .build();

public UserInfo getUserInfo(String userId) {
    return userCache.get(userId, key -> loadUserFromDatabase(key));
}

系統上線後，隨着用户量增加，應用服務器的內存使用率不斷攀升，最終導致了 OutOfMemoryError。

問題分析

小王的代碼看似簡單，但埋下了嚴重的內存隱患：

沒有設置緩存大小上限
沒有設置過期策略
沒有任何驅逐機制

隨着越來越多的用户數據被加載到緩存中，內存不斷增長，而沒有任何機制能夠清理這些緩存項，最終導致內存溢出。

graph TD
    A[用户請求] -->|查詢用户| B[Caffeine緩存]
    B -->|緩存未命中| C[數據庫]
    C -->|加載數據| D[添加到緩存]
    D -->|無上限| E[緩存持續增長]
    E -->|內存耗盡| F[OutOfMemoryError]

解決方案

修改緩存配置，添加合理的大小限制和過期策略：

// 正確示例
Cache<String, UserInfo> userCache = Caffeine.newBuilder()
    .maximumSize(10000)           // 設置緩存大小上限
    .expireAfterWrite(1, TimeUnit.HOURS)  // 寫入一小時後過期
    .recordStats()                // 記錄統計信息，便於監控
    .build();

public UserInfo getUserInfo(String userId) {
    return userCache.get(userId, key -> loadUserFromDatabase(key));
}

這樣配置後，緩存會自動控制大小，並且過期的項會被自動清理，有效防止內存無限增長。

案例二：大對象作為鍵導致的內存泄漏

問題描述

小李開發了一個文檔處理系統，使用 Caffeine 緩存處理結果。為了提高緩存命中率，他使用文檔對象作為緩存鍵：

// 有問題的代碼
Cache<Document, ProcessResult> resultCache = Caffeine.newBuilder()
    .maximumSize(1000)
    .build();

public ProcessResult processDocument(Document doc) {
    return resultCache.get(doc, this::processDocumentInternal);
}

系統運行一段時間後，發現內存使用異常，即使設置了緩存大小，內存使用仍不斷增長。

問題分析

問題的本質在於使用了包含大量數據的 Document 對象作為緩存鍵。即使 Document 類正確實現了 equals 和 hashCode 方法：

public class Document {
    private String id;
    private String title;
    private byte[] content; // 可能很大，例如幾MB的文檔內容

    @Override
    public boolean equals(Object obj) {
        if (obj instanceof Document) {
            return ((Document) obj).id.equals(this.id);
        }
        return false;
    }

    @Override
    public int hashCode() {
        return id.hashCode();
    }
}

這裏的根本問題是：緩存會持有對鍵對象的強引用。當每次調用processDocument方法時，都會創建一個新的 Document 實例作為鍵。雖然由於 equals/hashCode 的實現，緩存能夠識別出這些 Document 對象邏輯上是相同的（相同 id），但緩存依然會持有這些對象的引用，阻止它們被垃圾回收。

隨着時間推移，大量包含文檔內容的 Document 對象在內存中積累，儘管從緩存邏輯上看只有 1000 個條目，但實際上可能有成千上萬個 Document 對象無法被回收。

graph TD
    A[新Document對象] -->|作為緩存鍵| B[Caffeine緩存]
    C[另一個Document對象] -->|相同id| B
    D[更多Document對象...] -->|相同id| B
    B -->|持有強引用| E[大量Document對象滯留]
    E -->|每個包含大量數據| F[內存泄漏]

解決方案

有兩種解決方法：

使用文檔 ID 作為緩存鍵，而不是整個 Document 對象：

// 方案一：使用ID作為鍵
Cache<String, ProcessResult> resultCache = Caffeine.newBuilder()
    .maximumSize(1000)
    .build();

public ProcessResult processDocument(Document doc) {
    return resultCache.get(doc.getId(), id -> processDocumentInternal(doc));
}

如果必須使用 Document 對象的更多信息作為鍵，創建輕量級的鍵對象：

// 方案二：使用輕量級對象作為鍵
public class DocumentKey {
    private final String id;
    private final String title; // 如需使用title作為鍵的一部分

    public DocumentKey(Document doc) {
        this.id = doc.getId();
        this.title = doc.getTitle();
    }

    @Override
    public boolean equals(Object obj) {
        if (obj instanceof DocumentKey) {
            DocumentKey other = (DocumentKey) obj;
            return this.id.equals(other.id) && this.title.equals(other.title);
        }
        return false;
    }

    @Override
    public int hashCode() {
        return Objects.hash(id, title);
    }
}

Cache<DocumentKey, ProcessResult> resultCache = Caffeine.newBuilder()
    .maximumSize(1000)
    .build();

public ProcessResult processDocument(Document doc) {
    DocumentKey key = new DocumentKey(doc);
    return resultCache.get(key, k -> processDocumentInternal(doc));
}

這兩種方案都避免了在緩存鍵中包含大量數據（如文檔內容），從而大大減少了內存佔用。

案例三：值引用管理不當導致的內存泄漏

問題描述

小張在開發一個圖像處理系統，使用 Caffeine 緩存處理後的大型圖像：

// 有問題的代碼
Cache<String, ProcessedImage> imageCache = Caffeine.newBuilder()
    .maximumSize(100)
    .build();

public ProcessedImage getProcessedImage(String imageId) {
    return imageCache.get(imageId, id -> {
        Image originalImage = loadOriginalImage(id);
        return processImage(originalImage);
    });
}

儘管設置了緩存大小限制，系統運行一段時間後仍然出現內存問題。

問題分析

問題出在 ProcessedImage 類的實現上：

public class ProcessedImage {
    private Image originalImage;  // 引用了原始圖像
    private byte[] processedData; // 處理後的數據

    public ProcessedImage(Image originalImage, byte[] processedData) {
        this.originalImage = originalImage;  // 持有原始圖像的引用
        this.processedData = processedData;
    }

    // 其他方法...
}

ProcessedImage 對象不僅包含處理後的數據，還持有對原始圖像的引用。這意味着即使緩存控制了 ProcessedImage 對象的數量，每個緩存項仍然間接引用了大量內存（原始圖像數據）。

graph TD
    A[緩存] -->|存儲| B[ProcessedImage]
    B -->|引用| C[原始Image對象]
    B -->|包含| D[處理後數據]
    C -->|包含| E[原始圖像數據]
    F[內存佔用] -->|來自| D
    F -->|來自| E

解決方案

修改 ProcessedImage 類，不再持有原始圖像的引用：

// 改進的ProcessedImage類
public class ProcessedImage {
    private byte[] processedData; // 僅保存處理後的數據

    public ProcessedImage(byte[] processedData) {
        this.processedData = processedData;
    }

    // 其他方法...
}

// 改進的緩存使用
public ProcessedImage getProcessedImage(String imageId) {
    return imageCache.get(imageId, id -> {
        Image originalImage = loadOriginalImage(id);
        byte[] processedData = processImage(originalImage);
        return new ProcessedImage(processedData);
        // originalImage可以被垃圾回收
    });
}

這樣，當緩存方法返回後，原始圖像對象就可以被垃圾回收，大大減少了內存佔用。

案例四：線程本地緩存未正確清理

問題描述

小趙在開發一個高併發處理系統，為了避免線程間的緩存競爭，他為每個線程創建了專屬的 Caffeine 緩存：

// 有問題的代碼
private static final ThreadLocal<Cache<String, ExpensiveObject>> THREAD_LOCAL_CACHE =
    ThreadLocal.withInitial(() -> Caffeine.newBuilder()
        .maximumSize(1000)
        .build());

public ExpensiveObject processData(String key) {
    Cache<String, ExpensiveObject> cache = THREAD_LOCAL_CACHE.get();
    return cache.get(key, this::loadExpensiveObject);
}

系統測試中發現，即使負載降低，內存佔用卻持續增長，服務器長時間運行後最終出現 OOM 錯誤。特別是在使用線程池的環境中，線程池中的線程會被重用，若不清理 ThreadLocal，緩存實例會隨着線程長期存活，導致內存累積。

問題分析

問題在於使用了 ThreadLocal 來存儲 Caffeine 緩存實例，但是沒有正確清理這些實例。在使用線程池的環境中（如應用服務器），線程不會結束，而是會被重用。因此，每個線程都會持有一個 Caffeine 緩存實例，隨着時間推移，這些緩存實例會累積大量數據。

graph TD
    A[線程池] -->|包含| B[線程1]
    A -->|包含| C[線程2]
    A -->|包含| D[線程N]
    B -->|持有| E[ThreadLocal<Cache>]
    C -->|持有| F[ThreadLocal<Cache>]
    D -->|持有| G[ThreadLocal<Cache>]
    E -->|引用| H[Caffeine緩存實例1]
    F -->|引用| I[Caffeine緩存實例2]
    G -->|引用| J[Caffeine緩存實例N]
    H -->|存儲| K[大量緩存項]
    I -->|存儲| L[大量緩存項]
    J -->|存儲| M[大量緩存項]

即使單個緩存實例設置了大小限制，但當有大量線程時，總的內存佔用仍然會很高。而且，如果線程處理完某個任務後被放回線程池，其 ThreadLocal 中的緩存不會被清理，導致緩存數據長期存在。

解決方案

推薦以下兩種解決方法：

每次使用後清理 ThreadLocal：

// 方案一：使用後清理（推薦）
public ExpensiveObject processData(String key) {
    try {
        Cache<String, ExpensiveObject> cache = THREAD_LOCAL_CACHE.get();
        return cache.get(key, this::loadExpensiveObject);
    } finally {
        // 使用後清理
        THREAD_LOCAL_CACHE.remove();
    }
}

使用共享緩存，而非線程本地緩存：

// 方案二：使用併發安全的共享緩存（推薦）
private static final Cache<String, ExpensiveObject> SHARED_CACHE =
    Caffeine.newBuilder()
        .maximumSize(5000) // 適當增加大小限制
        .build();

public ExpensiveObject processData(String key) {
    return SHARED_CACHE.get(key, this::loadExpensiveObject);
}

定期清理所有線程的緩存（僅供參考，實際實現複雜且可能不可靠）：

// 方案三：定期清理（僅示意，實際中需結合具體場景設計）
private static final ScheduledExecutorService CLEANER =
    Executors.newSingleThreadScheduledExecutor();

static {
    // 每小時清理一次
    CLEANER.scheduleAtFixedRate(() -> {
        // 注意：實際實現中，通過反射訪問所有線程的ThreadLocal是複雜且不可靠的
        // 在生產環境中，應優先考慮方案一或方案二
    }, 1, 1, TimeUnit.HOURS);
}

建議避免使用 ThreadLocal 存儲緩存實例，改用共享緩存。如果確實需要線程隔離，應確保在使用後及時清理。線程本地緩存應只用於數據具有強線程隔離性且生命週期短於線程的場景。

案例五：自定義加載器導致的內存泄漏

問題描述

小陳實現了一個數據分析系統，使用 Caffeine 緩存分析結果。他使用了自定義的 CacheLoader：

// 有問題的代碼
LoadingCache<String, AnalysisResult> analysisCache = Caffeine.newBuilder()
    .maximumSize(500)
    .build(new CacheLoader<String, AnalysisResult>() {
        private final DataProcessor processor = new ExpensiveDataProcessor();

        @Override
        public AnalysisResult load(String key) {
            Data data = fetchData(key);
            return processor.analyze(data);
        }
    });

系統運行後內存佔用異常高，即使在緩存項被驅逐後也沒有釋放預期的內存量。

問題分析

問題在於使用了非靜態內部類（匿名內部類）作為 CacheLoader。非靜態內部類會隱式持有對外部類實例的引用。此外，DataProcessor 是一個重量級對象，包含大量資源：

public class ExpensiveDataProcessor {
    private final byte[] largeBuffer = new byte[100 * 1024 * 1024]; // 100MB緩衝區
    private final Map<String, Object> processingState = new HashMap<>();

    // 其他字段和方法...
}

即使緩存項被驅逐，CacheLoader 對象仍然存在，它引用的 ExpensiveDataProcessor 也無法被垃圾回收，導致內存泄漏。

graph TD
    A[Caffeine緩存] -->|持有| B[CacheLoader<br>非靜態內部類]
    B -->|隱式引用| C[外部類實例]
    B -->|包含| D[ExpensiveDataProcessor]
    D -->|包含| E[100MB緩衝區]
    D -->|包含| F[處理狀態Map]

解決方案

有三種方案可以解決這個問題：

使用 Lambda 表達式（不會持有外部類引用）：

// 方案一：使用Lambda表達式
LoadingCache<String, AnalysisResult> analysisCache = Caffeine.newBuilder()
    .maximumSize(500)
    .build(key -> {
        // 只在需要時創建處理器
        DataProcessor processor = new ExpensiveDataProcessor();
        Data data = fetchData(key);
        return processor.analyze(data);
        // 方法結束後，局部變量processor會自動超出作用域，允許GC回收
    });

使用靜態內部類（不持有外部類引用）：

// 方案二：使用靜態內部類
private static class AnalysisLoader implements CacheLoader<String, AnalysisResult> {
    @Override
    public AnalysisResult load(String key) {
        // 只在需要時創建處理器
        DataProcessor processor = new ExpensiveDataProcessor();
        Data data = fetchData(key);
        return processor.analyze(data);
        // 方法結束後，processor可以被垃圾回收
    }
}

LoadingCache<String, AnalysisResult> analysisCache = Caffeine.newBuilder()
    .maximumSize(500)
    .build(new AnalysisLoader());

使用獨立類（與內部類分離）：

// 方案三：使用獨立類
public class AnalysisLoader implements CacheLoader<String, AnalysisResult> {
    @Override
    public AnalysisResult load(String key) {
        DataProcessor processor = new ExpensiveDataProcessor();
        Data data = fetchData(key);
        return processor.analyze(data);
    }
}

LoadingCache<String, AnalysisResult> analysisCache = Caffeine.newBuilder()
    .maximumSize(500)
    .build(new AnalysisLoader());

這些方案都避免了緩存長期持有對大型資源的引用，從而防止內存泄漏。

如何檢測和監控 Caffeine 內存泄漏

發現和定位 Caffeine 相關的內存泄漏，可以使用以下技術：

1. JVM 內存監控

使用工具如 VisualVM、JConsole 或 Java Mission Control 來監控 JVM 內存使用情況。觀察內存使用趨勢，特別是老年代的增長情況。

graph LR
    A[應用運行] -->|產生| B[內存使用數據]
    B -->|監控| C[VisualVM/JConsole]
    C -->|分析| D[內存趨勢]
    D -->|識別| E[潛在泄漏]

2. 堆轉儲分析

當懷疑存在內存泄漏時，生成堆轉儲並使用如 MAT(Memory Analyzer Tool)等工具分析：

// 在代碼中觸發堆轉儲
java.lang.management.ManagementFactory.getMemoryMXBean().dumpHeap("leak.hprof");

// 或使用jmap命令
// jmap -dump:format=b,file=heap.bin <pid>

在 MAT 中尋找 Caffeine 緩存相關的對象，檢查它們的保留大小和引用鏈。

3. 啓用 Caffeine 統計

Caffeine 提供了內置的統計功能，可以幫助你瞭解緩存的使用情況：

Cache<Key, Value> cache = Caffeine.newBuilder()
    .maximumSize(10_000)
    .recordStats()
    .build();

// 獲取統計信息
CacheStats stats = cache.stats();
System.out.println("緩存大小: " + cache.estimatedSize());
System.out.println("命中率: " + stats.hitRate());
System.out.println("驅逐次數: " + stats.evictionCount());

觀察緩存大小、命中率和驅逐次數，可以幫助你判斷緩存是否按預期工作。

4. 添加 JMX 監控

將 Caffeine 緩存暴露為 JMX MBean，便於實時監控：

// 首先定義一個MXBean接口
public interface CacheStatsMXBean {
    long getSize();
    double getHitRate();
    long getEvictionCount();
    // 其他需要暴露的統計方法...
}

// 實現該接口
public class CacheStatsBean implements CacheStatsMXBean {
    private final Cache<?, ?> cache;

    public CacheStatsBean(Cache<?, ?> cache) {
        this.cache = cache;
    }

    @Override
    public long getSize() {
        return cache.estimatedSize();
    }

    @Override
    public double getHitRate() {
        return cache.stats().hitRate();
    }

    @Override
    public long getEvictionCount() {
        return cache.stats().evictionCount();
    }
    // 其他實現...
}

// 註冊MBean
MBeanServer mBeanServer = ManagementFactory.getPlatformMBeanServer();
ObjectName name = new ObjectName("com.example:type=Cache,name=userCache");
StandardMBean mbean = new StandardMBean(new CacheStatsBean(cache), CacheStatsMXBean.class);
mBeanServer.registerMBean(mbean, name);

// 定期更新統計信息
ScheduledExecutorService executor = Executors.newSingleThreadScheduledExecutor();
executor.scheduleAtFixedRate(() -> {
    // 統計信息會自動更新，無需額外操作
}, 1, 1, TimeUnit.MINUTES);

預防 Caffeine 內存泄漏的策略

1. 合理配置緩存大小

始終設置最大緩存大小，基於預期的使用場景和可用內存：

Cache<Key, Value> cache = Caffeine.newBuilder()
    .maximumSize(10_000)  // 硬性限制
    // 或基於權重
    .maximumWeight(10_000_000)
    .weigher((key, value) -> value.getSize())
    .build();

2. 使用合適的過期策略

根據數據的新鮮度需求，配置適當的過期策略：

Cache<Key, Value> cache = Caffeine.newBuilder()
    .expireAfterWrite(10, TimeUnit.MINUTES)    // 寫入後過期
    .expireAfterAccess(5, TimeUnit.MINUTES)    // 訪問後過期
    .expireAfter(new Expiry<Key, Value>() {    // 自定義過期策略
        @Override
        public long expireAfterCreate(Key key, Value value, long currentTime) {
            return value.getExpirationNanos();
        }
        // 其他方法...
    })
    .build();

3. 使用弱引用

當緩存項的生命週期應該與外部對象相關聯時，使用弱引用：

Cache<Key, Value> cache = Caffeine.newBuilder()
    .weakKeys()       // 當鍵不再被外部引用時，緩存項可以被回收
    .weakValues()     // 當值不再被外部引用時，緩存項可以被回收
    .build();

弱引用詳解

重要提示：弱引用不應該是解決內存問題的主要策略，應優先考慮合理的大小限制和過期策略。弱引用應作為補充機制使用。
弱鍵（weakKeys）：當鍵對象在緩存外部沒有強引用時，相應的緩存項將在下一次 GC 時被回收，即使該緩存未達到大小限制或未過期。適用於鍵對象生命週期由外部控制的場景，例如當鍵是臨時對象或由其他組件管理的對象時。
弱值（weakValues）：當值對象在緩存外部沒有強引用時，相應的緩存項將在下一次 GC 時被回收。適用於希望緩存不影響值對象正常生命週期的場景，例如當緩存是對象的"次要"引用來源時。
使用注意：
- 弱引用的回收時機由 GC 決定，不保證即時清理
- 弱引用會增加 GC 壓力
- 弱鍵對象仍需正確實現equals/hashCode，以確保緩存鍵的唯一性和正確性

graph TD
    A[Caffeine緩存] -->|強引用| B[普通鍵/值]
    A -->|弱引用| C[弱鍵/值]
    D[外部引用] -->|強引用| B
    D -.->|移除引用| B
    E[外部引用] -->|強引用| C
    E -.->|移除引用| F[GC回收]
    F -->|回收| C

4. 定期手動清理

對於長時間運行的應用，可以定期手動清理緩存：

// 定期執行清理
ScheduledExecutorService executor = Executors.newSingleThreadScheduledExecutor();
executor.scheduleAtFixedRate(() -> {
    cache.cleanUp();
}, 1, 1, TimeUnit.HOURS);

5. 使用輕量級鍵和值對象

設計專用的緩存鍵和值對象，避免無意中引用大對象：

// 輕量級緩存鍵
public class UserCacheKey {
    private final String userId;

    public UserCacheKey(String userId) {
        this.userId = userId;
    }

    // equals和hashCode實現...
}

// 使用
Cache<UserCacheKey, UserData> cache = Caffeine.newBuilder()
    .maximumSize(10_000)
    .build();

總結

下面通過表格總結本文的主要內容：

問題類型	表現症狀	原因分析	解決方案
無上限緩存	內存持續增長，最終 OOM	未設置大小限制和過期策略	設置 maximumSize 和過期時間
大對象作為鍵	內存使用超出預期	緩存持有大對象鍵的強引用	使用輕量級鍵（如 ID）替代大對象
值引用管理不當	內存使用超出預期	緩存值對象引用了其他大對象	重新設計值對象，避免不必要引用
線程本地緩存未清理	線程池環境下內存持續增長	ThreadLocal 中的緩存未被釋放	使用後清理或改用共享緩存
非靜態內部類加載器	緩存驅逐後內存未釋放	內部類隱式持有外部類引用	使用 Lambda、靜態內部類或獨立類

通過本文的學習，你應該能夠更好地理解和避免 Caffeine 緩存中的內存泄漏問題。緩存是把雙刃劍，用好了可以大幅提升性能，用不好則可能引入難以排查的內存問題。希望這篇文章對你有所幫助！

感謝您耐心閲讀到這裏！如果覺得本文對您有幫助，歡迎點贊 👍、收藏 ⭐、分享給需要的朋友，您的支持是我持續輸出技術乾貨的最大動力！

如果想獲取更多 Java 技術深度解析，歡迎點擊頭像關注我，後續會每日更新高質量技術文章，陪您一起進階成長～

異常君 Blog

@chen_67f9ccbe6f07b

Tags

後端 (616)

JAVA (556)

數據庫 (310)

MySQL (192)

Linux (168)

算法 (135)

springboot (120)

spring (87)

SQL (72)

性能優化 (53)

設計模式 (50)

多線程 (43)

Stories

【深度揭秘】Caffeine 緩存引發的內存泄漏全攻略：從根源到解決方案 - Stories Detail

前言

Caffeine 簡介

內存泄漏的根本原因

案例一：無上限緩存導致的內存泄漏

問題描述

問題分析

解決方案

案例二：大對象作為鍵導致的內存泄漏

問題描述

問題分析

解決方案

案例三：值引用管理不當導致的內存泄漏

問題描述

問題分析

解決方案

案例四：線程本地緩存未正確清理

問題描述

問題分析

解決方案

案例五：自定義加載器導致的內存泄漏

問題描述

問題分析

解決方案

如何檢測和監控 Caffeine 內存泄漏

1. JVM 內存監控

2. 堆轉儲分析

3. 啓用 Caffeine 統計

4. 添加 JMX 監控

預防 Caffeine 內存泄漏的策略

1. 合理配置緩存大小

2. 使用合適的過期策略

3. 使用弱引用

弱引用詳解

4. 定期手動清理

5. 使用輕量級鍵和值對象

總結

Add a new Comments