乐趣区

关于c#:对-精致码农大佬-说的-TaskRun-会存在-内存泄漏-的思考

一:背景

1. 讲故事

这段时间我的项目延期,加班比拟厉害,博客就略微停了停,不过还是得继续的技术输入呀!园子里最近挺冷落的,粗劣码农大佬分享了三篇文章:

  • 为什么要小心应用 Task.Run [https://www.cnblogs.com/willi…]
  • 小心应用 Task.Run 续篇 [https://www.cnblogs.com/willi…]
  • 小心应用 Task.Run 终篇解惑 [https://mp.weixin.qq.com/s/IM…]

外围代码如下:


    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

退出移动版