.NET|.NET webapi某化妆品直播卡死分析 .NETwebapi某化妆品直播卡死分析

一：背景

1. 讲故事

二：Windbg 分析

1. 线程们都怎么了
2. 单例写法真的没问题吗
3. 验证我的想法
4. 后续

三：总结

一：背景
1. 讲故事
10月份星球里的一位老朋友找到我，说他们公司的程序在一个网红直播带货下给弄得无响应了，无响应期间有大量的 RabbitMQ 超时，寻求如何找到根源，聊天截图我就不发了。
既然无响应了，那必然是程序的大量线程被主动或者被动的挂起，朋友也很及时的从程序上抽了一管血下来，接下来就上 windbg 一起探究下到底发生了什么？

二：Windbg 分析
1. 线程们都怎么了
要想看所有线程，还是老命令 !t 。

0:000> !tThreadCount:5221UnstartedThread:0BackgroundThread: 5199PendingThread:0DeadThread:21Hosted Runtime:noLock DBGIDOSID ThreadOBJState GC ModeGC Alloc ContextDomainCount Apt Exception20174e4 00000276CB778180202a020 Preemptive0000000000000000:0000000000000000 00000276cb77c9d0 -00001 MTA 31242cc 00000276CB6CA8302b220 Preemptive0000000000000000:0000000000000000 00000276cb77c9d0 -00001 MTA (Finalizer) 3232b40 00000276CB85D1B0102a220 Preemptive0000000000000000:0000000000000000 00000276cb77c9d0 -00001 MTA (Threadpool Worker) 26bccc 00000276CBA5D2F020220 Preemptive0000000000000000:0000000000000000 00000276cb77c9d0 -00001 Ukn 3397224 00000276CBA5C0C03029220 Preemptive0000000000000000:0000000000000000 00000276cb77c9d0 -00001 MTA (Threadpool Worker) System.IO.IOException 00000279ccc56cd092329e0 0000027BD86FD18020220 Preemptive0000000000000000:0000000000000000 00000276cb77c9d0 -00001 Ukn ...

从简要信息看，当前有 5000+ 的线程，太牛了，一般一台机器的所有进程的线程加起来也没这么多。。。不过我目前看到最多的是 1w + 的线程，就是那种不用线程池，直接用 Thread 造成的一种线程垃圾。
可以看到线程列表中的 9号线程抛了托管异常，接下来看看是个啥错误, 使用 !wpe 00000279ccc56cd0 命令。

0:000> !wpe 00000279ccc56cd0Address: 00000279ccc56cd0Exception Type: System.IO.IOExceptionMessage: Unable to read data from the transport connection: 远程主机强迫关闭了一个现有的连接。.Inner Exception: 00000279ccc56b20 System.Net.Sockets.SocketException 远程主机强迫关闭了一个现有的连接。Stack:SPIPFunction000000791b88c970 00007ffd844a1b31 System.Net.Sockets.NetworkStream.Read(Byte[], Int32, Int32)000000791b88ee80 00007ffd849e6f8a System.IO.BufferedStream.ReadByteSlow()000000791b88eeb0 00007ffd8312950a RabbitMQ.Client.Impl.InboundFrame.ReadFrom(System.IO.Stream, Byte[])000000791b88ef40 00007ffd849e6d7d RabbitMQ.Client.Framing.Impl.Connection.MainLoopIteration()000000791b88efa0 00007ffd8312832f RabbitMQ.Client.Framing.Impl.Connection.MainLoop()HResult: 80131620

从堆栈信息来看，程序做了一个远程访问 RabbitMQ，结果 tcp 连接被对方关闭了，貌似和朋友说的有大量 RabbitMQ 超时有关。
接下来就是查看各个线程栈，研究下此时这些线程都在干什么，使用 ~*e !clrstack 命令，通过仔细研读线程栈，我发现有大量的方法卡在 xxx.RabbitMq.RabbitMqConnection.GetInstance 方法处。

Child SPIP Call Site0000008B8A9ED6A8 00007ffdf5246594 [HelperMethodFrame_1OBJ: 0000008b8a9ed6a8] System.Threading.Monitor.ReliableEnter(System.Object, Boolean ByRef)0000008B8A9ED800 00007ffd84a6a4a9 xxx.RabbitMq.RabbitMqConnection.GetInstance(Microsoft.Extensions.Options.IOptions`1, Microsoft.Extensions.Logging.ILogger`1)0000008B8A9ED860 00007ffd84a6a317 xxx.RabbitMq.RabbitMqProducer..ctor(Microsoft.Extensions.Options.IOptionsSnapshot`1, Microsoft.Extensions.Logging.ILogger`1)0000008B8A9ED8A0 00007ffd8334817b DynamicClass.ResolveService(ILEmitResolverBuilderRuntimeContext, Microsoft.Extensions.DependencyInjection.ServiceLookup.ServiceProviderEngineScope)0000008B8A9ED930 00007ffd83347d76 DynamicClass.ResolveService(ILEmitResolverBuilderRuntimeContext, Microsoft.Extensions.DependencyInjection.ServiceLookup.ServiceProviderEngineScope)0000008B8A9EDE90 00007ffd844f3cb3 Microsoft.Extensions.DependencyInjection.ActivatorUtilities.GetService(System.IServiceProvider, System.Type, System.Type, Boolean) [/_/src/libraries/Common/src/Extensions/ActivatorUtilities/ActivatorUtilities.cs @ 173]DynamicClass.lambda_method196(System.Runtime.CompilerServices.Closure, System.IServiceProvider, System.Object[])0000008B8A9EDF20 00007ffd84a0fc9c Microsoft.AspNetCore.Mvc.Controllers.ControllerFactoryProvider+c__DisplayClass5_0.g__CreateController|0(Microsoft.AspNetCore.Mvc.ControllerContext)0000008B8A9EDF70 00007ffd8452ce7f Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.Next(State ByRef, Scope ByRef, System.Object ByRef, Boolean ByRef) [/_/src/Mvc/Mvc.Core/src/Infrastructure/ControllerActionInvoker.cs @ 285]0000008B8A9EE030 00007ffd84a0fac8 Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.InvokeInnerFilterAsync() [/_/src/Mvc/Mvc.Core/src/Infrastructure/ControllerActionInvoker.cs @ 490]0000008B8A9EE0B0 00007ffd845346cd Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.Next(State ByRef, Scope ByRef, System.Object ByRef, Boolean ByRef) [/_/src/Mvc/Mvc.Core/src/Infrastructure/ResourceInvoker.cs @ 883]0000008B8A9EE240 00007ffd84a0f9ad Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.InvokeNextExceptionFilterAsync() [/_/src/Mvc/Mvc.Core/src/Infrastructure/ResourceInvoker.cs @ 1024]0000008B8A9EE2C0 00007ffd84534272 Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.Next(State ByRef, Scope ByRef, System.Object ByRef, Boolean ByRef) [/_/src/Mvc/Mvc.Core/src/Infrastructure/ResourceInvoker.cs @ 883]0000008B8A9EE450 00007ffd84a0f850 Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.InvokeNextResourceFilter() [/_/src/Mvc/Mvc.Core/src/Infrastructure/ResourceInvoker.cs @ 976]...

从调用栈信息看，源头是一个http请求，然后在 GetInstance 下的 lock 处被冻结，这就激发了我很大的好奇心，接下来根据 IP 导出源码看看。

public sealed class RabbitMqConnection{public static RabbitMqConnection GetInstance(IOptions options, ILogger logger){if (_uniqueInstance == null || _uniqueInstance.Connection == null || !_uniqueInstance.Connection.IsOpen){lock (_objLock){if (_uniqueInstance == null || _uniqueInstance.Connection == null || !_uniqueInstance.Connection.IsOpen){_uniqueInstance = new RabbitMqConnection(options.Value, logger); }}}return _uniqueInstance; } private RabbitMqConnection(RabbitMqConfig config, ILogger logger) {Policy.Handle().Or().WaitAndRetry(6, (int retryAttempt) => TimeSpan.FromSeconds(1.0), delegate (Exception ex, TimeSpan time, int retryCount, Context content){if (6 == retryCount){throw ex; }_logger.LogError(ex, $"{retryCount}:{ex.Message}"); }).Execute(delegate{Connection = factory.CreateConnection(); }); }}

从代码逻辑看，朋友用了双检锁来给 RabbitMQ 实例做单例化，如果实例创建失败还会有 6 次 1s 的尝试，这种写法乍一看没什么问题。

2. 单例写法真的没问题吗
如果单例写法没问题的话，为什么有大量的线程卡在 lock 处呢？既然是单例那肯定是 rabbitmq 第一次被实例化后，后人直接乘凉就好了哈，带着这个疑问再次检查双检索写法，尼玛，在判断单例的时候居然做了 _uniqueInstance.Connection.IsOpen 判断，大家知道这意味着什么吗？
这意味着，一旦 rabbitmq 在某个时刻挂掉了，单例条件就被破防了，无数的线程排队来做 RabbimtMQ 的实例化，要知道这都是些不实例出来不罢休的勇士，继而导致程序挂死...

3. 验证我的想法
既然从源码中推出了这个代码缺陷，但口说无凭，我得拿出证据，要想验证很简单，到托管堆寻找 RabbitMqConnection 实例，看下此时它的 IsOpen 是不是 false 即可, 通过 ILSpy 查看源码发现它是用 CloseReason==null 来判断的。

文章图片

接下来看看 CloseReason 不为空即可。

0:000> !dumpheap -type RabbitMqConnectionAddressMTSize00000277cbd7aa68 00007ffd831f15703200000277ccb13068 00007ffd831f1570320:000> !DumpObj /d 00000277cbd7b858Name:RabbitMQ.Client.Framing.Impl.AutorecoveringConnectionMethodTable: 00007ffd83235db0EEClass:00007ffd83242898Size:200(0xc8) bytesFile:G:\xxx\RabbitMQ.Client.dllFields:MTFieldOffsetType VTAttrValue Name00007ffd823972384000180bcSystem.Boolean1 instance0 _disposed00007ffd82390c6840001818System.Object0 instance 00000277cbd7b920 _eventLock00007ffd831fc230400018210 ...g.Impl.Connection0 instance 00000277cbd7d5f8 _delegate0:000> !DumpObj /d 00000277cbd7d5f8Name:RabbitMQ.Client.Framing.Impl.ConnectionMethodTable: 00007ffd831fc230EEClass:00007ffd8322cd70Size:232(0xe8) bytesFile:G:\xxx\RabbitMQ.Client.dllFields:MTFieldOffsetType VTAttrValue Name00007ffd823972384000198b8System.Boolean1 instance0 _disposed00007ffd82390c6840001998System.Object0 instance 00000277cbd7d6e0 _eventLock00007ffd82d93d00400019a10 ...ualResetEventSlim0 instance 00000277cbd7d6f8 _appContinuation00007ffd83276028400019b18 ...ShutdownEventArgs0 instance 00000279ccc56e28 _closeReason0:000> !do 00000277ccb13068Name:xxx.RabbitMq.RabbitMqConnectionMethodTable: 00007ffd831f1570EEClass:00007ffd831eb920Size:32(0x20) bytesFile:G:\xxx\xxx.dllFields:MTFieldOffsetType VTAttrValue Name00007ffd831f13f8400001f8 ...Private.CoreLib]]0 instance 00000278cbe4c2a0 _logger00007ffd831f2ab0400002010 ...lient.IConnection0 instance 0000000000000000 k__BackingField00007ffd831f1570400001d8 ...abbitMqConnection0static 00000277cbd7aa68 _uniqueInstance00007ffd82390c68400001e10System.Object0static 00000277cbd7aa50 _objLock

从输出信息中可以很清楚的看到当前托管堆有两个 RabbitMqConnection 对象，其中一个果然是失败了(_closeReason=00000279ccc56e28)，还有一个正在努力的new k__BackingField=0000000000000000，这也就验证了假设。

4. 后续
有了这些信息，和朋友做了下沟通，建议再优化一下 IsOpen=false 时的异常处理逻辑，比如 return 或者 throw new，或者干脆不要用懒检测，千万不要硬着来。
至于造成 RabbitMQ 不响应的一系列诱因，朋友通过参考的开源项目，发现将别人的 AddSingleton 改成了 AddScoped。

文章图片

这也就造成了每一次Http请求都要试探性的判断单例逻辑, 别人的解法是一旦上层单例化了，下层就不会再次处理了，也就不会走 IsOpen 逻辑。

三：总结造成本次程序卡死的事故，主要有两点：

RabbitMQ 生成单例化中的 IsOpen 判断问题，建议改用自动重连属性 AutomaticRecoveryEnabled 和 TopologyRecoveryEnabled，或者用静态构造函数替代双检锁。
过多的 http 请求对单例逻辑的试探，按照朋友的改发将 Scoped 改成 Singleton 来规避。

【.NET|.NET webapi某化妆品直播卡死分析】以上就是.NET webapi化妆品直播卡死分析的详细内容，更多关于.NET webapi直播卡死的资料请关注脚本之家其它相关文章！