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

一个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, 不知道您想让我细说哪一种？

面试官： 那就说一下静态构造函数为什么可以实现单例？

解析： 可能觉得码农回答的有点拽，问深一点看看是不是唬人的。

码农：说到单例，每一个人都会提到在多线程场景下的并发问题导致多个单例的尴尬，所以有了给代码加上各种花哨的锁，比如刚才我提到的双检索,所以说没有锁。。。这个问题是搞不定的，换句话说 静态构造函数 也是用了锁机制。

面试官： 你确定用到了锁？ 有证据吗？

解析： 有戏了，对你产生感兴趣了，愿听其详。

码农： 既然要证据，那我先构思一段如下代码：

class Program

{

static void Main(string[] args)

{

Person person = new Person();

Console.ReadLine();

}

}

class Person

{

static Person()

{

Console.WriteLine("正在处理静态函数");

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

仔细看上面的代码，你会发现有很多处 ListLockEntry，这就和锁扯上了关系哈，这算证据不？

面试官： 小伙子windbg玩的挺溜，那请回答一下静态变量是存在哪的，有什么证据吗？

解析：转变思路，开始证据先行了

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。