一個static和麵試官扯了一個小時,舌戰加強版

一線碼農發表於2020-06-07

一:背景

1. 講故事

最近也是奇怪,在社群裡看到好幾篇文章聊static 的玩法以及怎麼拿這個和麵試官扯半個小時,有點意思,點進去看都是java版的,這就沒意思了,怎麼也得有一篇和麵試官扯C# 中的 static用法撒,既然沒有人開這個頭,那我就獻醜了。。。,下面以QA的方式記述,大家可以代入一下能回答幾個問題。

二:QA環節

面試官: 請問您都是在什麼場景下用static的?

解析: 可能面試官潛意識的想問問你會不會使用本地快取。

碼農: 先不說我的場景,縱觀C#的底層FCL原始碼,你會發現很多的 static修飾的集合,如ThreadPool:


	[SecurityCritical]
	private static bool QueueUserWorkItemHelper(WaitCallback callBack, object state, ref StackCrawlMark stackMark, bool compressStack)
	{
		QueueUserWorkItemCallback callback = new QueueUserWorkItemCallback(callBack, state, compressStack, ref stackMark);
		ThreadPoolGlobals.workQueue.Enqueue(callback, forceGlobal: true);
		result = true;
	}

其中的 workQueue 就是一個靜態佇列,不僅如此還有Quartz底層自研的執行緒池,還有web中的Session,Application,無非就是想用static做一個池化技術和AppDomain級的本地快取,所以我的應用場景也無非是這些了。

面試官: 您會幾種實現單例的方式?

解析:既然面試官想和你扯static,就是想看看你會不會用 static cctor靜態構造器構建單例!

碼農: 實不相瞞,不管是用懶漢式還是餓漢式,大體上也就這幾種 雙檢鎖, static cctor, Lazy<T>, 不知道您想讓我細說哪一種?

面試官: 那就說一下靜態建構函式為什麼可以實現單例?

解析: 可能覺得碼農回答的有點拽,問深一點看看是不是唬人的。

碼農:說到單例,每一個人都會提到在多執行緒場景下的併發問題導致多個單例的尷尬,所以有了給程式碼加上各種花哨的鎖,比如剛才我提到的雙檢索,所以說沒有鎖。。。這個問題是搞不定的,換句話說 靜態建構函式 也是用了鎖機制。

面試官: 你確定用到了鎖? 有證據嗎?

解析: 有戲了,對你產生感興趣了,願聽其詳。

碼農: 既然要證據,那我先構思一段如下程式碼:


    class Program
    {
        static void Main(string[] args)
        {
            Person person = new Person();
            Console.ReadLine();
        }
    }

    class Person
    {
        static Person()
        {
            Console.WriteLine("正在處理靜態函式");
            Console.ReadLine();
        }
    }

然後抓一個dump檔案,用windbg 看一下主執行緒的託管和非託管堆疊。


0:000> ~0s
ntdll!NtReadFile+0x14:
00007ff8`8d2eaa64 c3              ret
0:000> !dumpstack 
OS Thread Id: 0x4ac0 (0)
Current frame: ntdll!NtReadFile+0x14
Child-SP         RetAddr          Caller, Callee
000000c119bfdcd0 00007ff817090957 (MethodDesc 00007ff816f85aa8 +0x37 ConsoleApp6.Person..cctor()), calling (MethodDesc 00007ff8741140b8 +0 System.Console.ReadLine())
000000c119bfdd10 00007ff8765e6c93 clr!CallDescrWorkerInternal+0x83
000000c119bfdd18 00007ff87660a51c clr!ListLockEntry::FinishDeadlockAwareEnter+0x40, calling clr!GetThread
000000c119bfdd50 00007ff8765e6b79 clr!CallDescrWorkerWithHandler+0x4e, calling clr!CallDescrWorkerInternal
000000c119bfdd80 00007ff87390d663 clrjit+0x1d663, calling clrjit+0x1be60
000000c119bfdd90 00007ff87660c56b clr!DispatchCallDebuggerWrapper+0x1f, calling clr!CallDescrWorkerWithHandler
000000c119bfddf0 00007ff87660c535 clr!DispatchCallSimple+0x93, calling clr!DispatchCallDebuggerWrapper
000000c119bfde40 00007ff87660a5b9 clr!MethodTable::EnsureInstanceActive+0x110, calling clr!DomainFile::EnsureLoadLevel
000000c119bfde90 00007ff87660bf65 clr!MethodTable::RunClassInitEx+0x111, calling clr!DispatchCallSimple
000000c119bfdec0 00007ff88d350119 ntdll!RtlDebugFreeHeap+0x2a9, calling ntdll!RtlLeaveCriticalSection
000000c119bfdee0 00007ff88d2b77a2 ntdll!RtlInitializeCriticalSection+0xa2, calling ntdll!_security_check_cookie
000000c119bfdf80 00007ff87660a51c clr!ListLockEntry::FinishDeadlockAwareEnter+0x40, calling clr!GetThread
000000c119bfdfc0 00007ff87660c15c clr!MethodTable::DoRunClassInitThrowing+0x3b9, calling clr!MethodTable::RunClassInitEx
000000c119bfe810 00007ff8765f08b4 clr!ListLockEntry::`scalar deleting destructor'+0xd4, calling clr!operator delete
000000c119bfff10 00007ff88d044034 KERNEL32!BaseThreadInitThunk+0x14, calling KERNEL32!guard_dispatch_icall_nop
000000c119bfff40 00007ff88d2c3691 ntdll!RtlUserThreadStart+0x21, calling ntdll!guard_dispatch_icall_nop

仔細看上面的程式碼,你會發現有很多處 ListLockEntry,這就和鎖扯上了關係哈,這算證據不?

面試官: 小夥子windbg玩的挺溜,那請回答一下靜態變數是存在哪的,有什麼證據嗎?

解析:轉變思路,開始證據先行了???。

碼農: 猶記得 CLR via C# 中說靜態變數是存放在型別物件中,這就好辦了,我去挖一下不就可以了哈,其實CLR內部用了兩個資料結構來表示 型別物件物件型別,一個叫做 EEClass一個叫做 方法表,下面我定義一個 lockMe 的靜態變數,程式碼如下:

    class Person
    {
        public static object lockMe = new object();

        static Person()
        {
            Console.WriteLine("正在處理靜態函式");
            Console.ReadLine();
        }
    }

然後祭出殺器 windbg ,用 name2ee 找到Person的EEClass將它打出來。


0:000> !name2ee ConsoleApp6.exe!ConsoleApp6.Person
Module:      00007ff816fb4140
Assembly:    ConsoleApp6.exe
Token:       0000000002000003
MethodTable: 00007ff816fb5ae8
EEClass:     00007ff816fb2558
Name:        ConsoleApp6.Person

0:000> !DumpClass /d 00007ff816fb2558
Class Name:      ConsoleApp6.Person
mdToken:         0000000002000003
File:            C:\dream\Csharp\ConsoleApp1\ConsoleApp6\bin\x64\Debug\ConsoleApp6.exe
Parent Class:    00007ff873f52f68
Module:          00007ff816fb4140
Method Table:    00007ff816fb5ae8
Vtable Slots:    4
Total Method Slots:  6
Class Attributes:    0  
Transparency:        Critical
NumInstanceFields:   0
NumStaticFields:     1
              MT    Field   Offset                 Type VT     Attr            Value Name
00007ff873f75dd8  4000001        8        System.Object  0   static 0000020ae5c42d90 lockMe

可以看到最後一行的 lockMe,就是那本書中所說的型別物件儲存的靜態欄位。

面試官: 那既然 static 屬於型別物件,為什麼GC不回收它呢?

解析: 開啟三連擊,看你沉浮有多深?

碼農: 為什麼GC不回收它? 這裡我有兩個個人觀點:

<1> clr的底層機制決定的

clr在啟動gc元件進行回收前,會先在堆中找幾類root物件,從而開啟標記引用鏈之路,常見的root物件有:

第一個: 方法的區域性變數,這個JIT在編譯方法的時候最清楚,它通過維護一個表給GC參謀。

第二個: static變數,這是天然的root根,與AppDomain共存亡。

第三個: 其他亂七八糟的root根。

<2> static地址是在啟動堆,而不是在託管堆,理應不受GC管控

這句話的證據在哪裡呢? 在 C# via CLR 那本書中說,JIT開始編譯方法內程式碼的時候,會判斷當前的型別Pereson是否已經在AppDomain中載入了,如果沒有很顯然會拋異常,如果有此型別,那就從程式集的後設資料中找到該型別的所有描述構建Person的 EEClass資料結構。

使用 ILDasm 檢視程式集中關於構建EEClass的Person後設資料。

可以看到確實有 lockMe 的後設資料表示,有了這些EEClass就可以構建出來,然後JIT編譯器可以將其分配在載入堆和AppDomain繫結,接下來的問題是怎麼去看是在載入堆???用什麼命令去看,當然是windbg啦,用 !eeheap -loader 即可。


0:000> !eeheap -loader
Loader Heap:
--------------------------------------
System Domain:     00007ff877002af0
LowFrequencyHeap:  00007ff816f80000(3000:3000) Size: 0x3000 (12288) bytes.
HighFrequencyHeap: 00007ff816f84000(9000:1000) Size: 0x1000 (4096) bytes.
StubHeap:          00007ff816f8d000(3000:2000) Size: 0x2000 (8192) bytes.
Total size:        Size: 0xa000 (40960) bytes.
--------------------------------------
Shared Domain:     00007ff877002520
LowFrequencyHeap:  00007ff816f80000(3000:3000) Size: 0x3000 (12288) bytes.
HighFrequencyHeap: 00007ff816f84000(9000:1000) Size: 0x1000 (4096) bytes.
StubHeap:          00007ff816f8d000(3000:2000) Size: 0x2000 (8192) bytes.
Total size:        Size: 0xa000 (40960) bytes.
--------------------------------------
Domain 1:          000001246cae21f0
LowFrequencyHeap:  00007ff816f90000(3000:3000) Size: 0x3000 (12288) bytes.
HighFrequencyHeap: 00007ff816f93000(a000:3000) Size: 0x3000 (12288) bytes.
StubHeap:          Size: 0x0 (0) bytes.
Total size:        Size: 0x6000 (24576) bytes.
--------------------------------------
Total LoaderHeap size:   Size: 0x1a000 (106496) bytes.
=======================================

從上圖中可以看到,C#應用程式會有三個應用程式域: System Domain,Shared Domain, Domain1,每一個AppDomain都有自己的私有載入堆,我們的 Person 型別不出意外就是在 Domain 1 上了哈,如果你好奇可以看看這個AppDomain都有啥。


0:000> !DumpDomain /d 000001246cae21f0
--------------------------------------
Domain 1:           000001246cae21f0
LowFrequencyHeap:   000001246cae29e8
HighFrequencyHeap:  000001246cae2a78
StubHeap:           000001246cae2b08
Stage:              OPEN
SecurityDescriptor: 000001246cae4870
Name:               ConsoleApp6.exe
Assembly:           000001246cb7f990 [C:\WINDOWS\Microsoft.Net\assembly\GAC_64\mscorlib\v4.0_4.0.0.0__b77a5c561934e089\mscorlib.dll]
ClassLoader:        000001246cb7fae0
SecurityDescriptor: 000001246cb7e230
  Module Name
00007ff873f51000            C:\WINDOWS\Microsoft.Net\assembly\GAC_64\mscorlib\v4.0_4.0.0.0__b77a5c561934e089\mscorlib.dll

Assembly:           000001246cb954c0 [C:\dream\Csharp\ConsoleApp1\ConsoleApp6\bin\x64\Debug\ConsoleApp6.exe]
ClassLoader:        000001246cb95610
SecurityDescriptor: 000001246cb933f0
  Module Name
00007ff816f94140            C:\dream\Csharp\ConsoleApp1\ConsoleApp6\bin\x64\Debug\ConsoleApp6.exe

程式集下就是 Module,如你看到的 ConsoleApp6.exe就是一個module哈,還可以繼續dump module看後設資料啥的。

總之你讓我找到lockme在啟動堆上的地址,目前還沒這個能力,不過要知道的是,lockMe 引用的object地址是在啟動堆上分配,而object物件是在託管堆上分配的,不要搞混淆了。

三:後續

面試官看了看手錶,已經快一個小時了,此時面試官心裡有了答案,按照職場潛規則,萬不可錄取,不然我的位置往哪擱呢?


如您有更多問題與我互動,掃描下方進來吧~


圖片名稱

相關文章