ASP.NET Core內(nèi)存泄漏排查實(shí)錄：我用3天踩的坑你別再踩

作者：conan 2025-04-02 08:17:42

在開發(fā)ASP.NET Core應(yīng)用程序時(shí)，內(nèi)存泄漏是一個(gè)令人頭疼的問(wèn)題，它可能悄無(wú)聲息地出現(xiàn)，逐漸消耗服務(wù)器資源，導(dǎo)致應(yīng)用程序性能下降甚至崩潰。最近，我就遭遇了這樣一場(chǎng)噩夢(mèng)，經(jīng)過(guò)整整3天的艱苦排查，終于找到了問(wèn)題所在。在此，我想將這段經(jīng)歷分享出來(lái)，希望能幫助大家避免重蹈我的覆轍。

噩夢(mèng)初現(xiàn)：性能驟降

一切始于一次用戶反饋，他們發(fā)現(xiàn)我們的ASP.NET Core應(yīng)用程序在長(zhǎng)時(shí)間運(yùn)行后變得異常緩慢。我起初并未在意，以為只是偶爾的網(wǎng)絡(luò)波動(dòng)或服務(wù)器負(fù)載問(wèn)題。但當(dāng)我親自測(cè)試時(shí)，發(fā)現(xiàn)情況遠(yuǎn)比想象中嚴(yán)重。應(yīng)用程序的響應(yīng)時(shí)間從原本的幾十毫秒延長(zhǎng)到了數(shù)秒，甚至在某些復(fù)雜操作下直接超時(shí)。我立即查看服務(wù)器資源監(jiān)控，發(fā)現(xiàn)內(nèi)存使用率持續(xù)攀升，短短幾個(gè)小時(shí)就接近了服務(wù)器的物理內(nèi)存上限。這明顯是內(nèi)存泄漏的跡象，一場(chǎng)與時(shí)間的賽跑就此開始。

初次排查：毫無(wú)頭緒

我首先想到的是檢查代碼中可能存在的資源未釋放問(wèn)題。我仔細(xì)審查了所有涉及數(shù)據(jù)庫(kù)連接、文件讀取以及網(wǎng)絡(luò)請(qǐng)求的代碼段，確保所有的IDisposable對(duì)象都在合適的時(shí)機(jī)被正確釋放。例如，在數(shù)據(jù)庫(kù)訪問(wèn)層，所有的DbContext對(duì)象都使用using語(yǔ)句包裹，以確保在作用域結(jié)束時(shí)自動(dòng)釋放資源：

using (var context = new MyDbContext())
{
    var data = context.Users.ToList();
    // 處理數(shù)據(jù)
}

在文件讀取操作中，也遵循同樣的原則：

using (var stream = new FileStream("example.txt", FileMode.Open))
{
    using (var reader = new StreamReader(stream))
    {
        var content = reader.ReadToEnd();
        // 處理文件內(nèi)容
    }
}

然而，經(jīng)過(guò)一番仔細(xì)檢查，并沒(méi)有發(fā)現(xiàn)明顯的資源泄漏問(wèn)題。我開始感到困惑，難道問(wèn)題出在其他地方？

借助工具：發(fā)現(xiàn)線索

既然手動(dòng)排查無(wú)果，我決定借助專業(yè)工具來(lái)定位問(wèn)題。我使用了Visual Studio的Performance Profiler，這是一個(gè)強(qiáng)大的性能分析工具，可以幫助我們深入了解應(yīng)用程序的運(yùn)行時(shí)行為。我啟動(dòng)了性能分析會(huì)話，模擬用戶的操作場(chǎng)景，讓應(yīng)用程序運(yùn)行一段時(shí)間。

分析結(jié)果出來(lái)后，我重點(diǎn)關(guān)注了內(nèi)存使用情況。在內(nèi)存分配圖表中，我發(fā)現(xiàn)有一個(gè)特定的類型MyLargeObject的實(shí)例數(shù)量在持續(xù)增加，而且沒(méi)有減少的趨勢(shì)。這是一個(gè)重大線索！我立即查看代碼中MyLargeObject的定義和使用情況。MyLargeObject是一個(gè)自定義的數(shù)據(jù)結(jié)構(gòu)，用于存儲(chǔ)大量的業(yè)務(wù)數(shù)據(jù)，它本身并沒(méi)有實(shí)現(xiàn)IDisposable接口，因?yàn)樗恢苯庸芾硗獠抠Y源。但我發(fā)現(xiàn)，在一個(gè)服務(wù)類中，有一個(gè)靜態(tài)字典用于緩存MyLargeObject實(shí)例：

public class MyService
{
    private static readonly Dictionary<int, MyLargeObject> _cache = new Dictionary<int, MyLargeObject>();

    public MyLargeObject GetObject(int key)
    {
        if (!_cache.TryGetValue(key, out var obj))
        {
            obj = new MyLargeObject();
            // 初始化obj
            _cache.Add(key, obj);
        }
        return obj;
    }
}

這個(gè)緩存機(jī)制的初衷是為了提高性能，避免重復(fù)創(chuàng)建MyLargeObject實(shí)例。但現(xiàn)在看來(lái)，它可能是導(dǎo)致內(nèi)存泄漏的罪魁禍?zhǔn)住Ｈ绻鸐yLargeObject實(shí)例一直被緩存，而沒(méi)有被清理，隨著時(shí)間的推移，內(nèi)存占用必然會(huì)不斷增加。

深入分析：?jiǎn)栴}根源

為了進(jìn)一步確認(rèn)問(wèn)題，我需要了解MyLargeObject實(shí)例在緩存中的生命周期。我在MyService類中添加了一些日志記錄代碼，記錄每次向緩存中添加和移除MyLargeObject實(shí)例的操作。經(jīng)過(guò)再次運(yùn)行應(yīng)用程序并觀察日志，我發(fā)現(xiàn)一旦一個(gè)MyLargeObject實(shí)例被添加到緩存中，就再也沒(méi)有被移除過(guò)。這是因?yàn)槲覀兊臉I(yè)務(wù)邏輯中，沒(méi)有明確的機(jī)制來(lái)清理緩存。隨著新的MyLargeObject實(shí)例不斷被添加，緩存越來(lái)越大，最終導(dǎo)致內(nèi)存泄漏。

解決方案：清理緩存

找到問(wèn)題根源后，解決起來(lái)就相對(duì)簡(jiǎn)單了。我決定引入一個(gè)緩存過(guò)期機(jī)制，定期清理緩存中的MyLargeObject實(shí)例。我使用了System.Threading.Timer來(lái)實(shí)現(xiàn)這個(gè)功能：

public class MyService
{
    private static readonly Dictionary<int, MyLargeObject> _cache = new Dictionary<int, MyLargeObject>();
    private static readonly Timer _cacheCleanupTimer;

    static MyService()
    {
        _cacheCleanupTimer = new Timer(CleanupCache, null, TimeSpan.Zero, TimeSpan.FromMinutes(10));
    }

    private static void CleanupCache(object state)
    {
        var keysToRemove = _cache.Where(kvp => IsObjectExpired(kvp.Value)).Select(kvp => kvp.Key).ToList();
        foreach (var key in keysToRemove)
        {
            _cache.Remove(key);
        }
    }

    private static bool IsObjectExpired(MyLargeObject obj)
    {
        // 根據(jù)對(duì)象的創(chuàng)建時(shí)間或其他業(yè)務(wù)邏輯判斷是否過(guò)期
        return obj.CreationTime < DateTime.Now.AddMinutes(-30);
    }

    public MyLargeObject GetObject(int key)
    {
        if (!_cache.TryGetValue(key, out var obj))
        {
            obj = new MyLargeObject();
            // 初始化obj
            _cache.Add(key, obj);
        }
        return obj;
    }
}

通過(guò)上述代碼，每10分鐘會(huì)觸發(fā)一次緩存清理操作，移除那些創(chuàng)建時(shí)間超過(guò)30分鐘的MyLargeObject實(shí)例。

驗(yàn)證修復(fù)：大功告成

在實(shí)現(xiàn)緩存清理機(jī)制后，我再次使用Visual Studio的Performance Profiler進(jìn)行性能分析。這次，內(nèi)存分配圖表顯示MyLargeObject實(shí)例的數(shù)量在經(jīng)過(guò)一段時(shí)間的增加后，開始穩(wěn)定下來(lái)，并且隨著緩存清理操作的執(zhí)行，數(shù)量逐漸減少。應(yīng)用程序的響應(yīng)時(shí)間也恢復(fù)到了正常水平，內(nèi)存使用率保持在合理范圍內(nèi)。經(jīng)過(guò)幾天的觀察，內(nèi)存泄漏問(wèn)題再也沒(méi)有出現(xiàn)，這場(chǎng)艱難的排查之旅終于畫上了圓滿的句號(hào)。

總結(jié)教訓(xùn)：避免重蹈覆轍

通過(guò)這次經(jīng)歷，我深刻認(rèn)識(shí)到在開發(fā)ASP.NET Core應(yīng)用程序時(shí)，內(nèi)存管理的重要性。以下是一些總結(jié)的經(jīng)驗(yàn)教訓(xùn)，希望能幫助大家避免類似的內(nèi)存泄漏問(wèn)題：

及時(shí)釋放資源：確保所有實(shí)現(xiàn)了IDisposable接口的對(duì)象都在合適的時(shí)機(jī)被正確釋放，使用using語(yǔ)句是一個(gè)很好的實(shí)踐方式。
謹(jǐn)慎使用緩存：如果使用緩存機(jī)制，一定要有相應(yīng)的緩存清理策略，避免緩存無(wú)限增長(zhǎng)導(dǎo)致內(nèi)存泄漏。
善用工具：Visual Studio的Performance Profiler等性能分析工具是排查內(nèi)存泄漏的有力武器，要學(xué)會(huì)熟練使用它們來(lái)發(fā)現(xiàn)問(wèn)題。
定期審查代碼：定期對(duì)代碼進(jìn)行審查，尤其是那些可能涉及資源管理和內(nèi)存操作的部分，及時(shí)發(fā)現(xiàn)潛在的問(wèn)題。

希望我的經(jīng)歷能為大家在ASP.NET Core開發(fā)中遇到內(nèi)存泄漏問(wèn)題時(shí)提供一些參考和幫助，讓大家少走一些彎路。

責(zé)任編輯：武曉燕來(lái)源：程序員編程日記