成人免费xxxxx在线视频软件_久久精品久久久_亚洲国产精品久久久_天天色天天色_亚洲人成一区_欧美一级欧美三级在线观看

程序內存一直在泄漏，原來是異步死循環了 !

作者：一線碼農聊技術
存儲 存儲軟件
根據朋友描述，程序運行一段時間后，內存就炸了，應該沒造成人員傷亡，不然也不會跟我wx聊天了，這里可以用 .time 看看當前的 process 跑了多久。

[[437425]]

一、背景

1. 講故事

上個月有位朋友找到我，說他的程序出現了內存泄漏，不知道如何進一步分析，截圖如下：

朋友這段話已經說的非常言簡意賅了，那就上 windbg 說話吧。

二、Windbg 分析

1. 到底是哪一方面的泄漏

根據朋友描述，程序運行一段時間后，內存就炸了，應該沒造成人員傷亡，不然也不會跟我wx聊天了，這里可以用 .time 看看當前的 process 跑了多久。

  1. 0:000> .time 
  2. Debug session time: Thu Oct 21 14:54:39.000 2021 (UTC + 8:00) 
  3. System Uptime: 6 days 4:37:27.851 
  4. Process Uptime: 0 days 0:40:14.000 
  5.   Kernel time: 0 days 0:01:55.000 
  6.   User time: 0 days 0:07:33.000 

看的出來，這個 dump 是在程序跑了 40min 之后抓的，接下來我們比較一下 process 的內存和 gc堆 占比, 看看到底是哪一塊的泄漏。

  1. 0:000> !address -summary 
  2.  
  3. --- State Summary ---------------- RgnCount ----------- Total Size -------- %ofBusy %ofTotal 
  4. MEM_FREE                                327     7dfc`c665a000 ( 125.987 TB)           98.43% 
  5. MEM_RESERVE                             481      201`e91a2000 (   2.007 TB)  99.74%    1.57% 
  6. MEM_COMMIT                             2307        1`507f4000 (   5.258 GB)   0.26%    0.00% 
  7.  
  8. 0:000> !eeheap -gc 
  9. Number of GC Heaps: 2 
  10. ------------------------------ 
  11.  
  12. GC Allocated Heap Size:    Size: 0x139923528 (5260850472) bytes. 
  13. GC Committed Heap Size:    Size: 0x13bf23000 (5300695040) bytes. 

2. 到底是什么占用了如此大的內存

知道是 托管層 的泄漏，感覺一下子就幸福起來了，接下來用 !dumpheap -stat 看看有沒有什么大對象可挖。

  1. 0:000> !dumpheap -stat 
  2. Statistics: 
  3.               MT    Count    TotalSize Class Name 
  4. 00007ffdeb1fc400  5362921    128710104 xxxBLLs.xxx.BundleBiz+<>c__DisplayClass20_0 
  5. 00007ffdeaeff140  5362929    171613728 System.Collections.Generic.List`1[[xxx.xxx, xxx]] 
  6. 00007ffdeaeff640  5362957    171615272 xxx.BLLs.Plan.Dto.xxx[] 
  7. 00007ffde8171e18 16146362    841456072 System.String 
  8. 00007ffdeb210098  5362921   1415811144 System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1+AsyncStateMachineBox`1[[System.Threading.Tasks.VoidTaskResult, System.Private.CoreLib],[xxx.BundleBiz+<DistributionBundle>d__20, xxx]] 
  9. 00007ffdea9ca260  5362921   2359685240 xxx.Bundle              

從輸出看，內存主要被 xxx.Bundle 和 AsyncTaskMethodBuilder 兩大類對象給吃掉了，數量都高達 536w，這里有一個非常有意思的地方，如果你了解異步，我相信你一看就能看出 AsyncTaskMethodBuilder + VoidTaskResult 是干嘛的，按照經驗，這位朋友應該誤入了 異步無限遞歸 ，那怎么去挖呢?接著往下看。

3. 尋找問題代碼

看到上面的 xxx.BundleBiz+d__20 了嗎?這個正是異步操作所涉及到的類和方法，接下來用 ILSpy 反射出 BundleBiz 下的匿名類 d__20 , 如下圖所示：

雖然找到了源碼，但代碼是 ILSpy 反編譯出來的異步狀態機，接下來的一個問題是，如何根據狀態機代碼反向尋找到 await ，async 代碼呢?在 ILSpy 中有一個 used by 功能，在這里可以用起來了。

雙擊 used by 就能看到真正的調用代碼，簡化后如下：

  1. public async Task DistributionBundle(List<Bundle> list, List<xxx> bwdList, xxx item, List<xxx> sumDetails, List<xxx> details, BundleParameter bundleParameter, IEnumerable<dynamic> labels) 
  2. { 
  3.  int num = 0; 
  4.  foreach (xxx detail in sumDetails) 
  5.  { 
  6.   IEnumerable<xxx> woDetails = details.Where((xxx w) => w.Size == detail.Size && w.Color == detail.Color); 
  7.   foreach (xxx item2 in woDetails) 
  8.   { 
  9.             xxx 
  10.   } 
  11.   woDetails = woDetails.OrderBy((xxx s) => s.Seq).ToList(); 
  12.   num++; 
  13.         xxx 
  14.   Bundle bundle = new Bundle(); 
  15.   Bundle bundle2 = bundle; 
  16.   bundle2.BundleId = await _repo.CreateBundleId(); 
  17.    
  18.   foreach (xxx item3 in woDetails) 
  19.   { 
  20.    item3.TaskQty = item3.WoQty + Math.Ceiling(item3.WoQty * item3.OverCutRate); 
  21.    decimal value = default(decimal); 
  22.   } 
  23.  
  24.   await DistributionBundle(list, bwdList, item, sumDetails, details, bundleParameter, labels); 
  25.  } 
  26. } 

仔細看上面這段代碼, 我去， await DistributionBundle(list, bwdList, item, sumDetails, details, bundleParameter, labels); 又調用了自身，看樣子是某種條件下陷入了一個死遞歸。

有些朋友可能要問，除了經驗之外，能從 dump 中分析出來嗎?當然可以，從 500w+ 中抽一個看看它的 !gcroot 即可。

  1. 0:000> !DumpHeap /d -mt 00007ffdeb210098 
  2.          Address               MT     Size 
  3. 000001a297913a68 00007ffdeb210098      264      
  4. 000001a297913b70 00007ffdeb210098      264   
  5.  
  6. 0:000> !gcroot 000001a297913a68 
  7. Thread 5ac: 
  8.     000000470B1EE4E0 00007FFE45103552 System.Threading.Tasks.Task.SpinThenBlockingWait(Int32, System.Threading.CancellationToken) [/_/src/System.Private.CoreLib/shared/System/Threading/Tasks/Task.cs @ 2922] 
  9.         rbp+10: 000000470b1ee550 
  10.             ->  000001A297A25D88 System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1+AsyncStateMachineBox`1[[System.Threading.Tasks.VoidTaskResult, System.Private.CoreLib],[Microsoft.Extensions.Hosting.HostingAbstractionsHostExtensions+<RunAsync>d__4, Microsoft.Extensions.Hosting.Abstractions]] 
  11.             ->  000001A29796D8C0 Microsoft.Extensions.Hosting.Internal.Host 
  12.             ... 
  13.             ->  000001A298213248 System.Data.SqlClient.TdsParserStateObjectNative 
  14.             ->  000001A32E6AB700 System.Threading.Tasks.TaskFactory`1+<>c__DisplayClass38_0`1[[System.Data.SqlClient.SqlDataReader, System.Data.SqlClient],[System.Data.CommandBehavior, System.Data.Common]] 
  15.             ->  000001A32E6AB728 System.Threading.Tasks.Task`1[[System.Data.SqlClient.SqlDataReader, System.Data.SqlClient]] 
  16.             ->  000001A32E6ABB18 System.Threading.Tasks.StandardTaskContinuation 
  17.             ->  000001A32E6ABA80 System.Threading.Tasks.ContinuationTaskFromResultTask`1[[System.Data.SqlClient.SqlDataReader, System.Data.SqlClient]] 
  18.             ->  000001A32E6AB6C0 System.Action`1[[System.Threading.Tasks.Task`1[[System.Data.SqlClient.SqlDataReader, System.Data.SqlClient]], System.Private.CoreLib]] 
  19.             ->  000001A32E6AB428 System.Data.SqlClient.SqlCommand+<>c__DisplayClass130_0 
  20.             ... 
  21.             ->  000001A32E6ABC08 System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1+AsyncStateMachineBox`1[[System.String, System.Private.CoreLib],[Dapper.SqlMapper+<QueryRowAsync>d__34`1[[System.String, System.Private.CoreLib]], Dapper]] 
  22.             ->  000001A32E6ABD20 System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1+AsyncStateMachineBox`1[[System.String, System.Private.CoreLib],[xxx.DALs.xxx.BundleRepo+<CreateBundleId>d__12, xxx]] 
  23.             ->  000001A32E6ABD98 System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1+AsyncStateMachineBox`1[[System.Threading.Tasks.VoidTaskResult, System.Private.CoreLib],[xxx.BundleBiz+<DistributionBundle>d__20, xxx]] 
  24.             ->  000001A32E6A6BD8 System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1+AsyncStateMachineBox`1[[System.Threading.Tasks.VoidTaskResult, System.Private.CoreLib],[xxx.BundleBiz+<DistributionBundle>d__20, xxx]] 
  25.             ->  000001A433250520 System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1+AsyncStateMachineBox`1[[System.Threading.Tasks.VoidTaskResult, System.Private.CoreLib],[xxx.BundleBiz+<DistributionBundle>d__20, xxx]] 
  26.             ->  000001A32E69E0F8 System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1+AsyncStateMachineBox`1[[System.Threading.Tasks.VoidTaskResult, System.Private.CoreLib],[xxx.BundleBiz+<DistributionBundle>d__20, xxx]] 
  27.             ->  000001A433247D28 System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1+AsyncStateMachineBox`1[[System.Threading.Tasks.VoidTaskResult, System.Private.CoreLib],[xxx.BundleBiz+<DistributionBundle>d__20, xxx]] 
  28.             ->  000001A433246330 System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1+AsyncStateMachineBox`1[[System.Threading.Tasks.VoidTaskResult, System.Private.CoreLib],[xxx.BundleBiz+<DistributionBundle>d__20, xxx]] 
  29.             ->  000001A32E69A568 System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1+AsyncStateMachineBox`1[[System.Threading.Tasks.VoidTaskResult, System.Private.CoreLib],[xxx.BundleBiz+<DistributionBundle>d__20, xxx]] 
  30.             ->  000001A433245408 System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1+AsyncStateMachineBox`1[[System.Threading.Tasks.VoidTaskResult, System.Private.CoreLib],[xxx.BundleBiz+<DistributionBundle>d__20, xxx]] 
  31.             ... 

從調用棧來看，代碼貌似是從數據庫讀取記錄的過程中陷入死循環的。

4. 為什么沒有出現棧溢出

一看到無限循環，我相信很多朋友肯定要問，為啥沒出現堆棧溢出，畢竟默認的線程?？臻g僅僅 1M 而已，從 !gcroot 上看，這些引用都是掛在 5ac 線程上，也就是下面輸出的 主線程 ,而且主線程棧也非常干凈。

  1. 0:000> !t 
  2. ThreadCount:      30 
  3. UnstartedThread:  0 
  4. BackgroundThread: 24 
  5. PendingThread:    0 
  6. DeadThread:       5 
  7. Hosted Runtime:   no 
  8.                                                                                                             Lock   
  9.  DBG   ID     OSID ThreadOBJ           State GC Mode     GC Alloc Context                  Domain           Count Apt Exception 
  10.    0    1      5ac 000001A29752CDF0  202a020 Preemptive  0000000000000000:0000000000000000 000001a29754c570 0     MTA  
  11.    4    2     1e64 000001A29752A490    2b220 Preemptive  0000000000000000:0000000000000000 000001a29754c570 0     MTA (Finalizer)  
  12. ... 
  13.  
  14.  
  15. 0:000> !clrstack  
  16. OS Thread Id: 0x5ac (0) 
  17.         Child SP               IP Call Site 
  18. 000000470B1EE1D0 00007ffe5eb30544 [GCFrame: 000000470b1ee1d0]  
  19. 000000470B1EE318 00007ffe5eb30544 [HelperMethodFrame_1OBJ: 000000470b1ee318] System.Threading.Monitor.ObjWait(Boolean, Int32, System.Object) 
  20. 000000470B1EE440 00007ffe45103c25 System.Threading.ManualResetEventSlim.Wait(Int32, System.Threading.CancellationToken) 
  21. 000000470B1EE4E0 00007ffe45103552 System.Threading.Tasks.Task.SpinThenBlockingWait(Int32, System.Threading.CancellationToken) [/_/src/System.Private.CoreLib/shared/System/Threading/Tasks/Task.cs @ 2922] 
  22. 000000470B1EE550 00007ffe451032cf System.Threading.Tasks.Task.InternalWaitCore(Int32, System.Threading.CancellationToken) [/_/src/System.Private.CoreLib/shared/System/Threading/Tasks/Task.cs @ 2861] 
  23. 000000470B1EE5D0 00007ffe45121b04 System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(System.Threading.Tasks.Task) [/_/src/System.Private.CoreLib/shared/System/Runtime/CompilerServices/TaskAwaiter.cs @ 143] 
  24. 000000470B1EE600 00007ffe4510482d System.Runtime.CompilerServices.TaskAwaiter.GetResult() [/_/src/System.Private.CoreLib/shared/System/Runtime/CompilerServices/TaskAwaiter.cs @ 106] 
  25. 000000470B1EE630 00007ffe4de36595 Microsoft.Extensions.Hosting.HostingAbstractionsHostExtensions.Run(Microsoft.Extensions.Hosting.IHost) [/_/src/Hosting/Abstractions/src/HostingAbstractionsHostExtensions.cs @ 49] 
  26. 000000470B1EE660 00007ffde80f3b4b xxx.Program.Main(System.String[]) 
  27. 000000470B1EE8B8 00007ffe47c06c93 [GCFrame: 000000470b1ee8b8]  
  28. 000000470B1EEE50 00007ffe47c06c93 [GCFrame: 000000470b1eee50]  

如果你稍微了解一點異步的玩法，你應該知道這其中有一個 IO完成端口 的概念，它可以實現 句柄 和 ThreadPool 的綁定，無限遞歸只不過是進了 IO完成端口 的待回調隊列中而已，理論上和?？臻g沒什么關系，也就不會出現棧溢出了。

三、總結

本次內存泄漏的事故主要還是因為程序員的大意，也許是長期的 996 給弄恍惚了 ??????，有了這些信息，修正起來相信會非常簡單。

本文轉載自微信公眾號「一線碼農聊技術」，可以通過以下二維碼關注。轉載本文請聯系一線碼農聊技術公眾號。

責任編輯：武曉燕 來源： 一線碼農聊技術
內存異步死循環
相關推薦

2021-02-11 09:14:36

內存虛擬機數據

2012-05-18 00:01:07

JVMJavaJVM平臺

2022-09-26 08:30:41

黑客網絡攻擊隱私

2009-03-10 12:42:45

2025-02-17 09:22:16

MySQLSQL語句

2021-02-02 09:13:11

索引SQL數據庫

2020-03-23 08:30:12

程序員男友感受

2017-07-06 11:08:12

開源云計算EasyStack

2023-09-13 11:19:49

2023-09-13 17:08:31

2024-12-02 00:00:02

Svelte 5effect?數據

2019-12-02 15:22:34

硬件 游戲顯存

2020-05-26 08:52:36

Java JVM多態

2021-12-15 10:20:08

緩存架構開發

2025-04-03 10:39:56

2011-03-25 15:35:55

ARM微軟處理器架構

2018-03-21 18:00:15

NestJS

2016-07-20 17:19:21

SDN軟件定義網絡SDN商用

2019-11-28 14:14:16

微信QQ騰訊
點贊
收藏

51CTO技術棧公眾號

主站蜘蛛池模板： 99精品免费视频 | 日韩在线观看一区二区三区 | 美女亚洲一区 | 午夜一级大片 | 久久久久久国产精品久久 | 韩国主播午夜大尺度福利 | 欧美一级一区 | jav成人av免费播放 | 亚洲国产一区二区三区 | 中文字字幕在线中文乱码范文 | av在线免费看网址 | 国产精品久久视频 | 中文在线一区 | 精品欧美乱码久久久久久 | 91中文在线观看 | 美女福利视频 | 亚洲精品久久久久久下一站 | 亚洲精品福利视频 | 99re视频 | 欧美综合一区二区三区 | 可以免费观看的av | 午夜在线 | 日韩一区二区三区精品 | 日韩一区二区三区精品 | 国产黄色在线观看 | 日本一区二区高清视频 | 亚洲精品视频在线播放 | 成人精品免费视频 | 国产精品久久久久久久久久三级 | 欧美午夜精品久久久久久浪潮 | 国产精品一区二区欧美黑人喷潮水 | 久久亚洲一区二区三 | 亚洲国产一区二区视频 | 黄色一级片在线播放 | 黄色在线免费观看视频 | 天堂三级 | 中文字幕一区二区三区在线观看 | 精品一区二区久久 | 日韩欧美大片在线观看 | 成人性视频免费网站 | 日韩av免费在线观看 |