一:背景
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