自拍偷在线精品自拍偷,亚洲欧美中文日韩v在线观看不卡

又一起.NET程序掛死, 用 Windbg 抽絲剝繭式的真實(shí)案例分析

作者：一線碼農(nóng)聊技術(shù)
開(kāi)發(fā) 前端
為了理解為啥底層會(huì)創(chuàng)建那么多線程，我特意還查了下串口類 SerialPort，說(shuō)串口發(fā)送方送過(guò)來(lái)的數(shù)據(jù)，接收方可以主動(dòng)接收，可以被動(dòng)接收，被動(dòng)就是這種 事件模式，接收方收到發(fā)送方送來(lái)的數(shù)據(jù)時(shí)，操作系統(tǒng)會(huì)讓 CLR 通過(guò) Thread 來(lái)處理這段回調(diào)事件，所以從卦象上看就是典型的接收方處理能力不足造成的大量 lock 等待。

 [[394026]]

本文轉(zhuǎn)載自微信公眾號(hào)「一線碼農(nóng)聊技術(shù)」，作者一線碼農(nóng)聊技術(shù)。轉(zhuǎn)載本文請(qǐng)聯(lián)系一線碼農(nóng)聊技術(shù)公眾號(hào)。

一：背景

1. 講故事

前天有位粉絲朋友在后臺(tái)留言讓我?guī)兔纯此?Winform程序 UI無(wú)響應(yīng) + 410線程 到底是啥情況，如下圖：

說(shuō)實(shí)話，能看到這些真實(shí)案例我是特別喜歡的 ，就像醫(yī)生看病，光停留在理論和那些 demo 上，那是沒(méi)有前途的，如果有朋友在這塊搞不定的話，我可以免費(fèi)幫你解讀 dump，再附送一篇博客詳述。

好了，言歸正傳，既然粉絲朋友已經(jīng)提到了高達(dá) 410 線程，我本能反應(yīng)就是要么高負(fù)載，要么野線程，后者大多是無(wú)數(shù)新出現(xiàn)的線程卡在某個(gè)鎖上。

WinForm 出現(xiàn)高負(fù)載的情況，我至今還是沒(méi)遇到??????，如果說(shuō)卡在某個(gè)鎖上，基本都屬于這類，有了這個(gè)先入為主的思路，接下來(lái)就可以祭出 windbg 一探究竟了。

二：windbg 分析

1. 查找 CLR 同步塊表

十個(gè)人用鎖，八個(gè)人會(huì)用 lock, 所以先用 !syncblk 看看程序的鎖情況。

  1. 0:000> !syncblk 
  2. Index         SyncBlock MonitorHeld Recursion Owning Thread Info          SyncBlock Owner 
  3.    76   070e5fa4           67         1 17367570 15e8 218   03e6dd68 System.IO.Ports.SerialStream 
  4. ----------------------------- 
  5. Total           789 
  6. CCW             39 
  7. RCW             2 
  8. ComClassFactory 1 
  9. Free            535 

我去，從卦象上來(lái)看情況很不好，我來(lái)簡(jiǎn)單分析下。

  • MonitorHeld = 67

這個(gè) 67 表示當(dāng)前有 1 個(gè)線程持有鎖，有 33 個(gè)線程在等待鎖，肯定有朋友想問(wèn)怎么算的?很簡(jiǎn)單：當(dāng)一個(gè)線程持有了鎖的時(shí)候 MonitorHeld+1 ，當(dāng)一個(gè)線程在等待鎖的時(shí)候 MonitorHeld+2 ，所以表達(dá)式就是: 67= [1 + 66=(33*2)]。

  • Owning Thread Info = 17367570 15e8 218

上面三個(gè)信息都表示當(dāng)前持有線程，可以看最后的 218，它是 windbg 映射出來(lái)的線程ID，如果不信的話，可以用 !t 來(lái)一探究竟。

  1. 0:000> !t 
  2. ThreadCount:      315 
  3. UnstartedThread:  0 
  4. BackgroundThread: 302 
  5. PendingThread:    0 
  6. DeadThread:       0 
  7. Hosted Runtime:   no 
  8.                                                                          Lock   
  9.        ID OSID ThreadOBJ    State GC Mode     GC Alloc Context  Domain   Count Apt Exception 
  10.    0    1  c64 00cc3de0     24220 Preemptive  042E1884:00000000 00cbc0a0 0     STA  
  11.  214  240 1398 16702b90   1029220 Preemptive  00000000:00000000 00cbc0a0 0     MTA (Threadpool Worker)  
  12.  215  323  b5c 12ab7260   1029220 Preemptive  00000000:00000000 00cbc0a0 0     MTA (Threadpool Worker)  
  13.  216  290 1858 16c21c98   1029220 Preemptive  00000000:00000000 00cbc0a0 0     MTA (Threadpool Worker)  
  14.  218  117 15e8 17367570   1029220 Preemptive  00000000:00000000 00cbc0a0 1     MTA (Threadpool Worker)  
  15.  ... 

對(duì)，就是 218 這個(gè)罪魁禍?zhǔn)自诔钟辛随i，導(dǎo)致 33 個(gè)線程在無(wú)辜的等待它。。。

  • SyncBlock Owner = System.IO.Ports.SerialStream

也許你會(huì)好奇，到底 lock 持有的是哪一個(gè)對(duì)象呢?從 SyncBlock Owner 上看就是 SerialStream， ????，原來(lái)老兄在玩串口編碼，我先膜拜一下。

2. 查看線程棧

知道是 218 惹的禍，接下來(lái)可以看看它的線程棧，到底都在干什么?

關(guān)于上面的調(diào)用棧，可能有些朋友看不明白，我畫(huà)了一張簡(jiǎn)圖：

從圖中看，來(lái)自于 ThreadPool 的線程在用戶自定義的 DataReceived 方法上卡住了，為了方便我就用 !DumpIL 看看這個(gè)方法的 IL 代碼。

  1. 0:218> !name2ee *!xxx.TYAComYB.DataReceived 
  2. Module:      03b10cc4 
  3. Assembly:    YKit.dll 
  4. Token:       06000108 
  5. MethodDesc:  08533584 
  6. Name:        xxx.TYAComYB.DataReceived(System.Object, System.IO.Ports.SerialDataReceivedEventArgs) 
  7. JITTED Code Address: 08644dc0 
  8.  
  9. 0:218> !dumpil 08533584 
  10. ilAddr = 05dc2dd8 
  11. IL_0000: nop  
  12. IL_0001: nop  
  13. IL_0002: nop  
  14. IL_0003: ret  

這代碼居然藏了鉤子，用 !dumpil 居然看不到代碼，難怪在線程棧上看到了類似混淆的方法：xxx.TYAComYB.EYLlXL2bKH()，不過(guò)看反匯編是沒(méi)有問(wèn)題的,簡(jiǎn)化如下：

  1. 0:218> !U /d 08644edf 
  2. 08644ddd e86edaffff      call    08642850 (xxxx.com.ComPort.get_isOpen(), mdToken: 060004b6) 
  3. 08644df4 e807deffff      call    08642c00 (xxxx.YBComParam.get_DataPacketLen(), mdToken: 0600010c) 
  4. 08644dfb b92a3e136e      mov     ecx,offset mscorlib_ni!System.GC.ReRegisterForFinalize(System.Object) <PERF> (mscorlib_ni+0x3e2a) (6e133e2a) 
  5. 08644e00 e80fd460f8      call    00c52214 (JitHelp: CORINFO_HELP_NEWARR_1_VC) 
  6. 08644e15 e8e6ddffff      call    08642c00 (xxx.YBComParam.get_DataPacketLen(), mdToken: 0600010c) 
  7. 08644e22 e8edac4d68      call    System_ni+0x13fb14 (70b1fb14) (System.IO.Ports.SerialPort.Read(Byte[], Int32, Int32), mdToken: 06004173) 
  8. 08644e2e ff153836b103    call    dword ptr ds:[3B13638h] (xxxx.LogKit.WriteLine(System.Exception), mdToken: 06000183) 
  9. 08644e59 e8a2ddffff      call    08642c00 (xxxx.YBComParam.get_DataPacketLen(), mdToken: 0600010c) 
  10. 08644e64 ff1580355308    call    dword ptr ds:[8533580h] (xxxx.TYAComYB.EYLlXL2bKH(), mdToken: 06000107) 
  11. 08644e9b ff15a4265308    call    dword ptr ds:[85326A4h] (xxxx.YBComParam.get_DataPacketStart(), mdToken: 0600010e) 
  12. 08644ea8 e837e34e66      call    mscorlib_ni!System.Convert.ToByte(System.String, Int32) (6eb331e4) 
  13. 08644ed9 ff1580355308    call    dword ptr ds:[8533580h] (xxxx.TYAComYB.EYLlXL2bKH(), mdToken: 06000107) 

反正做的事情挺多，我就懶得分析了。

接下來(lái)看看那 33 個(gè)線程怎么就卡在 SerialStream 上呢?可以用 ~*e !clrstack 掃一下所有的 threads，抽幾個(gè)看看。

  1. 0:218> ~*e !clrstack 
  2. OS Thread Id: 0xc64 (0) 
  3. Child SP       IP Call Site 
  4. OS Thread Id: 0x13d8 (330) 
  5. Child SP       IP Call Site 
  6. 1b1aec90 77c8016d [GCFrame: 1b1aec90]  
  7. 1b1aee30 77c8016d [GCFrame: 1b1aee30]  
  8. 1b1aede0 77c8016d [HelperMethodFrame: 1b1aede0] System.Threading.Monitor.ReliableEnter(System.Object, Boolean ByRef) 
  9. 1b1aee70 710d6b54 System.IO.Ports.SerialPort.CatchReceivedEvents(System.Object, System.IO.Ports.SerialDataReceivedEventArgs) 
  10. 1b1aeeac 710d9520 System.IO.Ports.SerialStream+EventLoopRunner.CallReceiveEvents(System.Object) 
  11. 1b1aeec0 6e45e356 System.Threading.QueueUserWorkItemCallback.WaitCallback_Context(System.Object) 
  12. 1b1aeec8 6e43da07 System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean) 
  13. 1b1aef34 6e43d956 System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean) 
  14. 1b1aef48 6e45f120 System.Threading.QueueUserWorkItemCallback.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem() 
  15. 1b1aef5c 6e45e929 System.Threading.ThreadPoolWorkQueue.Dispatch() 
  16. 1b1aefac 6e45e7d5 System.Threading._ThreadPoolWaitCallback.PerformWaitCallback() 
  17. 1b1af1d4 71382552 [DebuggerU2MCatchHandlerFrame: 1b1af1d4]  

我去，居然都卡在 System.IO.Ports.SerialPort.CatchReceivedEvents 這里了，而且還是 framework 提供的，這就很困惑了。

3. 分析 SerialPort 源碼

要想看 SerialPort 類的源碼，可以用 ILSpy，如下圖所示:

看到這里，再結(jié)合我剛才畫(huà)的圖，思路是不是就清晰多了，究其原因就是 dataReceived(this, e); 觸發(fā)的用戶回調(diào)函數(shù)遲遲得不到結(jié)束，導(dǎo)致底層大量的線程在 lock 處等待。

三：總結(jié)

為了理解為啥底層會(huì)創(chuàng)建那么多線程，我特意還查了下串口類 SerialPort，說(shuō)串口發(fā)送方送過(guò)來(lái)的數(shù)據(jù)，接收方可以主動(dòng)接收，可以被動(dòng)接收，被動(dòng)就是這種 事件模式，接收方收到發(fā)送方送來(lái)的數(shù)據(jù)時(shí)，操作系統(tǒng)會(huì)讓 CLR 通過(guò) Thread 來(lái)處理這段回調(diào)事件，所以從卦象上看就是典型的接收方處理能力不足造成的大量 lock 等待。

大概提兩點(diǎn)優(yōu)化措施：

  • 提升 xxx.TYAComYB.DataReceived 方法中業(yè)務(wù)邏輯的處理能力。
  • 增加蓄水池，讓底層的 lock (serialStream) 盡快得到釋放。

 

 

責(zé)任編輯：武曉燕 來(lái)源： 一線碼農(nóng)聊技術(shù)
Windbg程序.NET
相關(guān)推薦

2015-06-09 11:13:18

2021-06-16 07:56:21

Redis分布式鎖

2021-06-11 18:27:10

LinuxLinux內(nèi)核

2022-07-11 11:28:45

數(shù)據(jù)分析業(yè)務(wù)消費(fèi)

2024-04-01 00:07:20

LinuxeBPF源碼

2022-07-05 21:31:21

索引SQL分庫(kù)分表

2022-01-17 17:55:29

Python變量交換開(kāi)發(fā)

2020-05-06 08:01:39

黑客惡意攻擊網(wǎng)絡(luò)安全

2024-01-03 16:39:07

2017-09-15 09:18:27

JavaSQLDBA

2022-04-01 15:18:42

Web 框架網(wǎng)絡(luò)通信

2018-09-13 15:21:36

CTO訓(xùn)練營(yíng)

2020-06-11 16:15:25

Java線程池代碼

2012-12-17 10:14:47

Wi-Fiwifi無(wú)線網(wǎng)絡(luò)

2020-02-26 08:00:20

惡意刪庫(kù)拘留

2023-06-27 13:47:00

分布式事務(wù)本地事務(wù)

2024-11-15 16:52:23

C#棧邊界?；?/a>

2024-07-26 00:00:12

2023-09-15 06:56:01

RC.NET 6Release

2020-11-24 09:45:17

刪庫(kù)程序員代碼
點(diǎn)贊
收藏

51CTO技術(shù)棧公眾號(hào)