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

一:靠山

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玩的挺溜,那请回覆一下静态变量是存在哪的,有什么证据吗?

剖析:转变思绪,最先证据先行了。

Spring Boot 集成 Swagger 构建接口文档

码农: 犹记得 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元数据。

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

可以看到确实有 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工具是在托管堆上分配的,不要搞混淆了。

三:后续

面试官看了看手表,已经快一个小时了,此时面试官心里有了谜底,根据职场潜规则,万不能录取,否则我的位置往哪搁呢?

原创文章,作者:admin,如若转载,请注明出处:https://www.2lxm.com/archives/14356.html