一个static和面试官扯了一个小时舌战加强版

最近也是奇怪，在社区里看到好几篇文章聊 static 的玩法以及怎么拿这个和面试官扯半个小时，有点意思，点进去看都是 java 版的，这就没意思了，怎么也得有一篇和面试官扯 C# 中的 static 用法撒，既然没有人开这个头，那我就献丑了。。。，下面以 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 不回收它？这里我有两个个人观点：

clr 在启动 gc 组件进行回收前，会先在堆中找几类 root 对象，从而开启标记引用链之路，常见的 root 对象有：

第一个：方法的局部变量，这个 JIT 在编译方法的时候最清楚，它通过维护一个表给 GC 参谋。

第二个：static 变量，这是天然的 root 根，与 AppDomain 共存亡。

第三个：其他乱七八糟的 root 根。

这句话的证据在哪里呢？在 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 对象是在托管堆上分配的，不要搞混淆了。

面试官看了看手表，已经快一个小时了，此时面试官心里有了答案，按照职场潜规则，万不可录取，不然我的位置往哪搁呢？

一个static和面试官扯了一个小时舌战加强版

一：背景

1. 讲故事

二：QA 环节

<1> clr 的底层机制决定的

<2> static 地址是在启动堆，而不是在托管堆，理应不受 GC 管控

三：后续