clr 面试_一个static和面试官扯了一个小时,舌战加强版
一:背景
1. 講故事
最近也是奇怪,在社區(qū)里看到好幾篇文章聊static?的玩法以及怎么拿這個和面試官扯半個小時,有點意思,點進去看都是java版的,這就沒意思了,怎么也得有一篇和面試官扯C# 中的?static用法撒,既然沒有人開這個頭,那我就獻丑了。。。,下面以QA的方式記述,大家可以代入一下能回答幾個問題。
二:QA環(huán)節(jié)
面試官:請問您都是在什么場景下用static的?
? ? ? ? ?解析:可能面試官潛意識的想問問你會不會使用本地緩存。
碼農(nóng):先不說我的場景,縱觀C#的底層FCL源碼,你會發(fā)現(xiàn)很多的?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?就是一個靜態(tài)隊列,不僅如此還有Quartz底層自研的線程池,還有web中的Session,Application,無非就是想用static做一個池化技術(shù)和AppDomain級的本地緩存,所以我的應(yīng)用場景也無非是這些了。
面試官:您會幾種實現(xiàn)單例的方式?
? ? ? ? 解析:既然面試官想和你扯static,就是想看看你會不會用?static cctor靜態(tài)構(gòu) ? ? ? ? ? ? ? ? ? ? ? ?造器構(gòu)建單例!
碼農(nóng):實不相瞞,不管是用懶漢式還是餓漢式,大體上也就這幾種?雙檢鎖,?static cctor,?Lazy, 不知道您想讓我細說哪一種?
面試官:那就說一下靜態(tài)構(gòu)造函數(shù)為什么可以實現(xiàn)單例?
? ? ? ? 解析:可能覺得碼農(nóng)回答的有點拽,問深一點看看是不是唬人的。
碼農(nóng):說到單例,每一個人都會提到在多線程場景下的并發(fā)問題導(dǎo)致多個單例的尷尬,所以有了給代碼加上各種花哨的鎖,比如剛才我提到的雙檢索,所以說沒有鎖。。。這個問題是搞不定的,換句話說?靜態(tài)構(gòu)造函數(shù)?也是用了鎖機制。
面試官:你確定用到了鎖?有證據(jù)嗎?
? ? ? ? ?解析:有戲了,對你產(chǎn)生感興趣了,愿聽其詳。
碼農(nóng):既然要證據(jù),那我先構(gòu)思一段如下代碼:
class Program{
static void Main(string[] args){
Person person = new Person();
Console.ReadLine();
}
}
class Person{
static Person(){
Console.WriteLine("正在處理靜態(tài)函數(shù)");
Console.ReadLine();
}
}
然后抓一個dump文件,用`windbg` 看一下主線程的托管和非托管堆棧。
``` C#
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
仔細看上面的代碼,你會發(fā)現(xiàn)有很多處?ListLockEntry,這就和鎖扯上了關(guān)系哈,這算證據(jù)不?
面試官:小伙子windbg玩的挺溜,那請回答一下靜態(tài)變量是存在哪的,有什么證據(jù)嗎?
? ? ? ? ?解析:轉(zhuǎn)變思路,開始證據(jù)先行了???。
碼農(nóng):猶記得?CLR via C#?中說靜態(tài)變量是存放在類型對象中,這就好辦了,我去挖一下不就可以了哈,其實CLR內(nèi)部用了兩個數(shù)據(jù)結(jié)構(gòu)來表示?類型對象?和?對象類型,一個叫做?EEClass一個叫做?方法表,下面我定義一個?lockMe?的靜態(tài)變量,代碼如下:
{
public static object lockMe = new object();
static Person(){
Console.WriteLine("正在處理靜態(tài)函數(shù)");
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,就是那本書中所說的類型對象存儲的靜態(tài)字段。
面試官:那既然 static 屬于類型對象,為什么GC不回收它呢?
? ? ? ? 解析:開啟三連擊,看你沉浮有多深?
碼農(nóng):為什么GC不回收它?這里我有兩個個人觀點:
<1> clr的底層機制決定的
clr在啟動gc組件進行回收前,會先在堆中找?guī)最恟oot對象,從而開啟標記引用鏈之路,常見的root對象有:
第一個:方法的局部變量,這個JIT在編譯方法的時候最清楚,它通過維護一個表給GC參謀。
第二個:static變量,這是天然的root根,與AppDomain共存亡。
第三個:其他亂七八糟的root根。
<2> static地址是在啟動堆,而不是在托管堆,理應(yīng)不受GC管控
這句話的證據(jù)在哪里呢?在?C# via CLR?那本書中說,JIT開始編譯方法內(nèi)代碼的時候,會判斷當(dāng)前的類型Pereson是否已經(jīng)在AppDomain中加載了,如果沒有很顯然會拋異常,如果有此類型,那就從程序集的元數(shù)據(jù)中找到該類型的所有描述構(gòu)建Person的?EEClass數(shù)據(jù)結(jié)構(gòu)。
使用?ILDasm?查看程序集中關(guān)于構(gòu)建EEClass的Person元數(shù)據(jù)。
可以看到確實有?lockMe?的元數(shù)據(jù)表示,有了這些EEClass就可以構(gòu)建出來,然后JIT編譯器可以將其分配在加載堆和AppDomain綁定,接下來的問題是怎么去看是在加載堆???用什么命令去看,當(dāng)然是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#應(yīng)用程序會有三個應(yīng)用程序域:?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哈,還可以繼續(xù)dump module看元數(shù)據(jù)啥的。
總之你讓我找到lockme在啟動堆上的地址,目前還沒這個能力,不過要知道的是,lockMe?引用的object地址是在啟動堆上分配,而object對象是在托管堆上分配的,不要搞混淆了。
三:后續(xù)
面試官看了看手表,已經(jīng)快一個小時了,此時面試官心里有了答案,按照職場潛規(guī)則,萬不可錄取,不然我的位置往哪擱呢?
超強干貨來襲 云風(fēng)專訪:近40年碼齡,通宵達旦的技術(shù)人生總結(jié)
以上是生活随笔為你收集整理的clr 面试_一个static和面试官扯了一个小时,舌战加强版的全部內(nèi)容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 四代内存频率为何如此低?揭秘三大原因
- 下一篇: 内存对比:A厂家速度最快,B厂家稳定性最