记一次 .NET 某设备监控系统死锁分析

开发 前端
因为是窗体程序,所以看主线程的线程栈就好了,如果卡在 用户态​ 那这个问题相对容易解决,如果卡在 内核态 这个问题就比较复杂了,需要开启 WinDbg 的本机内核调试或者双机调试才能找到最终的问题。

​一:背景

1. 讲故事

上周看了一位训练营朋友的dump,据朋友说他的程序卡死了,看完之后发现是一例经典的死锁问题,蛮有意思,这个案例算是学习 .NET高级调试 入门级的案例,这里和大家分享一下。

二:WinDbg 分析

1. 程序为什么会卡死

因为是窗体程序,所以看主线程的线程栈就好了,如果卡在 用户态​ 那这个问题相对容易解决,如果卡在 内核态 这个问题就比较复杂了,需要开启 WinDbg 的本机内核调试或者双机调试才能找到最终的问题。

既然已经说了是入门级,那肯定是卡在 用户态​ 层面啦,我们用 !clrstack 命令观察下主线程的线程栈即可,输出如下:

0:000:x86> !clrstack
OS Thread Id: 0x31d8 (0)
Child SP IP Call Site
00f9ec28 00e9e108 [GCFrame: 00f9ec28]
00f9ed08 00e9e108 [GCFrame: 00f9ed08]
00f9ed24 00e9e108 [HelperMethodFrame_1OBJ: 00f9ed24] System.Threading.Monitor.ReliableEnter(System.Object, Boolean ByRef)
00f9eda0 70c08468 System.Threading.Monitor.Enter(System.Object, Boolean ByRef) [f:\dd\ndp\clr\src\BCL\system\threading\monitor.cs @ 62]
00f9edb0 0ce916c7 xxxx.GetAlarmCount(xxx)
00f9ee28 0961f41f xxx.xxx()
00f9ef04 0961d60a xxxx.xxx(System.Object, System.EventArgs)
00f9ef50 6de03dc9 System.Windows.Forms.Timer.OnTick(System.EventArgs)
00f9ef58 6de053d9 System.Windows.Forms.Timer+TimerNativeWindow.WndProc(System.Windows.Forms.Message ByRef)
00f9ef64 6ddd38d0 System.Windows.Forms.NativeWindow.Callback(IntPtr, Int32, IntPtr, IntPtr)
00f9f1b0 0130d5d4 [InlinedCallFrame: 00f9f1b0]
00f9f1ac 6de375bd DomainBoundILStubClass.IL_STUB_PInvoke(MSG ByRef)
00f9f1b0 6dde44e3 [InlinedCallFrame: 00f9f1b0] System.Windows.Forms.UnsafeNativeMethods.DispatchMessageW(MSG ByRef)
00f9f1e4 6dde44e3 System.Windows.Forms.Application+ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop(IntPtr, Int32, Int32)
00f9f1e8 6dde40d1 [InlinedCallFrame: 00f9f1e8]
00f9f270 6dde40d1 System.Windows.Forms.Application+ThreadContext.RunMessageLoopInner(Int32, System.Windows.Forms.ApplicationContext)
00f9f2c0 6dde3f23 System.Windows.Forms.Application+ThreadContext.RunMessageLoop(Int32, System.Windows.Forms.ApplicationContext)
00f9f2ec 6ddbc83d System.Windows.Forms.Application.Run(System.Windows.Forms.Form)
00f9f300 01350a6e CleanControl.Program.Main(System.String[])
00f9f4ec 71d00556 [GCFrame: 00f9f4ec]
...

从卦中看,主线程卡在 Monitor.Enter​ 处,也就表明当前线程在 GetAlarmCount() 方法的一个 lock 处等待。

2. 谁在持有锁

要想找到谁在持有锁,需要理解 lock​ 的底层机制,它是建立在 AutoResetEvent + ObjectHeader​ 基础之上的一种锁玩法,在 CLR 层面使用 SyncBlk 的 class 来承载的,参考如下代码:

class SyncBlock
{
// ObjHeader creates our Mutex and Event
friend class ObjHeader;
friend class SyncBlockCache;
friend struct ThreadQueue;
#ifdef DACCESS_COMPILE
friend class ClrDataAccess;
#endif
friend class CheckAsmOffsets;
protected:
AwareLock m_Monitor; // the actual monitor
SLink m_Link;
DWORD m_dwHashCode;
WCHAR m_BSTRTrailByte;
}

要想观察这些 SyncBlk​ 信息,可以用 WinDbg 提供的快捷命令 !syncblk 来观察。

0:000:x86> !syncblk
Index SyncBlock MonitorHeld Recursion Owning Thread Info SyncBlock Owner
180 0b86e8e8 3 1 01452a08 3728 24 039da140 System.Object
-----------------------------
Total 339
CCW 5
RCW 2
ComClassFactory 0
Free 4

从卦中看,当前持有 lock 的线程是 24​ 号,那这个线程为什么迟迟不退出锁呢?这就需要到这个线程栈上找原因了, 使用命令 ~24s; !clrstack 即可。

0:004:x86> ~24s
ntdll_779a0000!NtWaitForMultipleObjects+0xc:
77a11b2c c21400 ret 14h
0:024:x86> !clrstack
OS Thread Id: 0x3728 (24)
Child SP IP Call Site
0e99e504 0000002b [HelperMethodFrame_1OBJ: 0e99e504] System.Threading.WaitHandle.WaitOneNative(System.Runtime.InteropServices.SafeHandle, UInt32, Boolean, Boolean)
0e99e5e8 70bdd952 System.Threading.WaitHandle.InternalWaitOne(System.Runtime.InteropServices.SafeHandle, Int64, Boolean, Boolean) [f:\dd\ndp\clr\src\BCL\system\threading\waithandle.cs @ 243]
0e99e600 70bdd919 System.Threading.WaitHandle.WaitOne(Int32, Boolean) [f:\dd\ndp\clr\src\BCL\system\threading\waithandle.cs @ 194]
0e99e614 6e4aa4a8 System.Windows.Forms.Control.WaitForWaitHandle(System.Threading.WaitHandle)
0e99e654 6e8585af System.Windows.Forms.Control.MarshaledInvoke(System.Windows.Forms.Control, System.Delegate, System.Object[], Boolean)
0e99e658 6e4acc4f [InlinedCallFrame: 0e99e658]
0e99e6e0 6e4acc4f System.Windows.Forms.Control.Invoke(System.Delegate, System.Object[])
...
0e99e83c 0f46512c xxx.AddAlarmQueue(xxx)
...
0e99ea84 0d3f2783 xxx.Func()
0e99ead8 70be2e01 System.Threading.ThreadHelper.ThreadStart_Context(System.Object) [f:\dd\ndp\clr\src\BCL\system\threading\thread.cs @ 74]
...

从卦中看,其中的 MarshaledInvoke 方法很刺眼,它表示工作线程通过 Invoke 向主线程的控件推送数据,因为主线程迟迟没有响应它,导致它一直在等待,而恰恰它又持有了 lock 锁,不赶巧主线程因为获取lock在迟迟等待又无法响应工作线程的 MarshaledInvoke 请求,导致一种死锁状态,如果要画个图大概是这样的。

图片

3. 如何化解

寻得化解之法,需要看下程序中是怎么持有 lock 锁的,仔细观察代码之后,终于找到了 lock 代码处,截图如下:

图片

对代码敏感得朋友相信一眼就能看出,这 lock 的粒度真tmd的大,只要 lock 中有一处调用了 Invoke,如果不凑巧主线程刚好在等待 lock ,那就死锁了,正如本篇中的 死锁。

三:总结

这次卡死事故,本质上来说是程序员对锁的使用没有一个好的习惯,没有遵循锁的尽早释放原则。

其实这一块关系型数据库做的特别好,锁的粒度分的很细,诸如:行锁,RID锁,Key锁,页锁,表锁,在必要的时候还会涉及到锁的升级,将性能,锁开销,一致性 做到了极致,非常值得我们研究和学习。

责任编辑:武晓燕 来源: 一线码农聊技术
相关推荐

2024-03-15 15:15:53

.NETCPU系统

2023-09-27 07:23:10

.NET监控软件

2024-03-28 12:56:36

2023-03-26 20:24:50

ERP网站系统

2024-03-26 00:44:53

.NETCIM系统

2022-01-17 21:28:36

管理系统.NET

2023-06-29 17:55:00

.NET日志WinDbg

2021-11-02 07:54:41

内存.NET 系统

2023-06-26 00:12:46

2022-10-13 18:40:05

.NETOA后端

2023-07-06 10:11:38

.NET模式dump

2022-10-25 14:17:01

.NET代码程序

2021-10-27 07:30:32

.NETCPU论坛

2023-10-07 13:28:53

.NET软件账本

2023-05-15 11:15:50

.NET门诊语句

2023-11-01 10:46:12

.NET线程同步

2023-05-08 08:25:52

2022-10-09 10:47:37

NET视觉软件

2022-10-24 07:48:37

.NETCPUGC

2023-05-12 17:42:22

CPUMES系统
点赞
收藏

51CTO技术栈公众号