对精致码农大佬说的 Task.Run 会存在内存泄漏的思考-51CTO.COM

一：背景

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

上面的 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 的引用正在 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 代堆上。

本文转载自微信公众号「一线码农聊技术」，可以通过以下二维码关注。转载本文请联系一线码农聊技术公众号。

对 精致码农大佬 说的 Task.Run 会存在 内存泄漏 的思考

对精致码农大佬说的 Task.Run 会存在内存泄漏的思考