對精致碼農大佬說的 Task.Run 會存在記憶體泄漏的思考-有解無憂

一：背景

1. 講故事

這段時間專案延期，加班比較厲害，博客就稍微停了停，不過還是得持續的技術輸出呀！園子里最近挺熱鬧的，精致碼農大佬分享了三篇文章：

為什么要小心使用 Task.Run [https://www.cnblogs.com/willick/p/14078259.html]
小心使用 Task.Run 續篇 [https://www.cnblogs.com/willick/p/14100973.html]
小心使用 Task.Run 終篇解惑 [https://mp.weixin.qq.com/s/IMPgSsxTW0LGArfPP7rQXw]

核心代碼如下：


    class Program
    {
        static void Main(string[] args)
        {
            Test();
            Console.ReadLine();
        }

        static void Test()
        {
            var myClass = new MyClass();

            myClass.Foo();
        }
    }

    public class MyClass
    {
        private int _id = 10;

        public Task Foo()
        {
            return Task.Run(() =>
            {
                Console.WriteLine($"Task.Run is executing with ID {_id}");
            });
        }
    }

大意是： Test() 方法執行完之后, myClass 本該銷毀，結果發現 Foo() 方法參考了 _id ,導致 GC 放棄了對 myClass 的回收，從而導致記憶體泄漏，

如果我的理解有誤，請大家幫忙指正，挺有意思，評論區也是熱鬧非凡，總體看下來發現還是有很多朋友對 閉包, 記憶體泄漏,GC 等概念的認知比較模糊，同樣作為技術博主，得要蹭點熱度??????，這篇我準備從這三個方面闡述下我的認知，然后大家再回頭看一下精致大佬的文章，

二：對閉包的認知

1. 什么是閉包

我最早接觸閉包的概念是在 js 中，關于閉包的概念，懂得人自然懂，不懂的人得要撓會頭，我準備不從概念而從代碼入手，幫你梳理下，先看核心代碼：


    public class MyClass
    {
        private int _id = 10;

        public Task Foo()
        {
            return Task.Run(() =>
            {
                Console.WriteLine($"Task.Run is executing with ID {_id}");
            });
        }
    }

我發現很多人迷惑就迷惑在 Task.Run 委托中的 _id，因為它拿的是 MyClass 中的 _id，貌似實作了時空穿越，其實仔細想想很簡單哈, Task.Run 委托中要拿 MyClass._id，就必須把 MyClass 自身的 this 指標作為引數傳遞給委托，既然有了這個this，啥值還拿不出來哈？？？遺憾的是 Run 不接受任何 object 引數，所以偽代碼如下：


        public Task Foo()
        {
            return Task.Run((obj) =>
            {
                var self = obj as MyClass;

                Console.WriteLine($"Task.Run is executing with ID {self._id}");
            },this);
        }

上面的代碼我相信大家都看的很清楚了，有些朋友要說了，空口無憑，憑什么你說的就是對的？？？沒關系，我從 windbg 讓你眼見為實就好啦，，，

2. 使用 windbg 驗證

想驗證其實很簡單，用 windbg 在這條陳述句 Console.WriteLine($"Task.Run is executing with ID {_id}"); 上放一個斷點，命中之后看一下這個方法的引數串列就好了，

這句代碼在我檔案的第 35 行，使用命令 !bpmd Program.cs:35 設定斷點，


0:000> !bpmd Program.cs:35
0:000> g
JITTED ConsoleApp4!ConsoleApp4.MyClass.<Foo>b__1_0()
Setting breakpoint: bp 00007FF83B2C4480 [ConsoleApp4.MyClass.<Foo>b__1_0()]
Breakpoint 0 hit
00007ff8`3b2c4480 55              push    rbp

上面的 <Foo>b__1_0() 方法就是所謂的委托方法，接下來可以用 !clrstack -p 查看這個方法的引數串列，


0:009> !clrstack -p
OS Thread Id: 0x964c (9)
        Child SP               IP Call Site
000000BF6DB7EF58 00007ff83b2c4480 ConsoleApp4.MyClass.b__1_0() [E:\net5\ConsoleApp1\ConsoleApp4\Program.cs @ 34]
    PARAMETERS:
        this (<CLR reg>) = 0x0000025c26f8ac60

可以看到，這個方法有一個引數 this, 地址是: 0x0000025c26f8ac60，接下來可以用 !do 0x0000025c26f8ac60 試著列印一下，看看到底是什么？


0:009> !do 0x0000025c26f8ac60
Name:        ConsoleApp4.MyClass
MethodTable: 00007ff83b383548
EEClass:     00007ff83b3926b8
Size:        24(0x18) bytes
File:        E:\net5\ConsoleApp1\ConsoleApp4\bin\Debug\netcoreapp3.1\ConsoleApp4.dll
Fields:
              MT    Field   Offset                 Type VT     Attr            Value Name
00007ff83b28b1f0  4000001        8         System.Int32  1 instance               10 _id

觀察上面輸出，哈哈，果然不出所料，0x0000025c26f8ac60 就是 ConsoleApp4.MyClass，現在對閉包是不是已經有了新的認識啦？？？

二：對記憶體泄漏的認識

1. 何為記憶體泄漏

英文中有一個詞組叫做 Out of Control，對，就是失去控制了，要想釋放只能 自殺式襲擊 了，比如說：kill 行程，關機器，

好了，再回到這個例子上來，代碼如下：


        static void Test()
        {
            var myClass = new MyClass();

            myClass.Foo();
        }

當 Test 方法執行完成之后，myClass 的堆疊上參考地址肯定會被抹掉的，有意思的是此時 Task.Run 中的委托方法肯定還沒有得到執行緒調度，我又發現很多人在這一塊想不通了，以為 記憶體泄漏 了，對吧 ??????

如果你明白了上一節我所說的，那就很好理解啦，哎，很長時間沒有畫圖分析了，破例了，

可以很清晰的看出，當執行完 myClass.Foo(); 陳述句后，此時有兩個地方參考了堆上的 MyClass，當 Test 方法執行完后， A 參考 會被抹掉，但此時還有 B 參考 存在，所以這時你不管怎么 GC，堆上的 MyClass 肯定不會被回收，如果說這種情況也算 記憶體泄漏 的話...

還是那句話，空口無憑，我得拿出證據來，上 windbg 說話，

2. 使用 windbg 查找 B 參考

要想驗證 B 參考的存在，思路很簡單，讓匿名委托方法得不到退出，然后到托管堆找一下 MyClass 到底還在被誰參考即可，接下來稍微修改一下代碼，


    class Program
    {
        static void Main(string[] args)
        {
            Test();

            Console.WriteLine("主執行緒全部執行完畢！");
            Console.ReadLine();  
        }

        static void Test()
        {
            var myClass = new MyClass();

            myClass.Foo();
        }
    }

    public class MyClass
    {
        private int _id = 10;

        public Task Foo()
        {
            return Task.Run(() =>
            {
                Console.WriteLine($"Task.Run is executing with ID {_id}");

                Thread.Sleep(int.MaxValue);   //故意不讓方法退出
            });
        }
    }

用 !dumpheap -stat -type MyClass 查看堆上的 MyClass 實體，然后用 !gcroot 查看它的參考鏈即可，


0:000> !dumpheap -stat -type MyClass
Statistics:
              MT    Count    TotalSize Class Name
00007ff839d23548        1           24 ConsoleApp4.MyClass
Total 1 objects
0:000> !DumpHeap /d -mt 00007ff839d23548
         Address               MT     Size
00000284e248ac90 00007ff839d23548       24     
0:000> !gcroot 00000284e248ac90
Thread 4eb0:
    0000009CD68FED60 00007FF839C646A6 ConsoleApp4.MyClass.<Foo>b__1_0() [E:\net5\ConsoleApp1\ConsoleApp4\Program.cs @ 39]
        rbp+10: 0000009cd68feda0
            ->  00000284E248AC90 ConsoleApp4.MyClass

果然不出所料，MyClass 的參考正在 <Foo>b__1_0() 方法中，這也就驗證了 B 參考的存在，

三：對GC的認知

除了大物件堆，小物件主要還是采用三代機制的老方法，沒啥好說的，不過有一點要注意了，GC 也不會動不動就出來回收的，畢竟作業站模式的GC 在 64 bit 機器上默認有 256M 的記憶體大小，這 256 M 會分配給 0代 + 1代，說小也不小，如下圖：

其實我想表達的意思是，即使當前有 A,B 兩個參考，實際上 99 % 的情況下都會在同一代中被回收，比如說：第 0 代，

現在都過了十多分鐘了，可以看下 MyClass 的地址 (00000284e248ac90) 當前有沒有被送到第 1 代？用 !eeheap -gc 把托管堆的地址段打出來，


0:000> !eeheap -gc
Number of GC Heaps: 1
generation 0 starts at 0x00000284E2481030
generation 1 starts at 0x00000284E2481018
generation 2 starts at 0x00000284E2481000

可以看到，即使過了十多分鐘，當前 MyClass(00000284e248ac90) 還是在 0 代堆上，

三：總結

好了，這三個概念： 閉包, 記憶體泄漏,GC 差不多就介紹完了，不知道可否解開了大家的疑團，最后感謝 精致大佬 的精彩博文，

更多高質量干貨：參見我的 GitHub: dotnetfly

轉載請註明出處，本文鏈接：https://www.uj5u.com/net/232236.html

標籤：C#

上一篇：撰寫一個矩形類，在此基礎上定義一個長方體類，使用基于在矩形類與長方體類的基礎上完成對矩形的面積及周長的計算和長方體類的體積及表面積的計算

下一篇：ASP .Net Core WebSocket 如何增加Token驗證機制呢?

對 精致碼農大佬 說的 Task.Run 會存在 記憶體泄漏 的思考