一:背景

1. 讲故事

前几天有位朋友在 B站 加到我,说他的程序出现了 线程数 爆高的问题,让我帮忙看一下怎么回事,截图如下:

说来也奇怪,这些天碰到了好几起关于线程数无缘无故的爆高,不过那几个问题比这一篇要复杂的多,主要涉及到非托管层面,分享这一篇的目的主要是它很有代表性,很有必要。

闲话不多说,既然线程数爆高,那就上 windbg 说话。

二:WinDbg 分析

1. 线程数真的高吗

既然说线程数高,那到底有多少呢? 我们可以用 !t 命令看一下。


  1. 0:000> !t
  2. ThreadCount: 109
  3. UnstartedThread: 0
  4. BackgroundThread: 104
  5. PendingThread: 0
  6. DeadThread: 1
  7. Hosted Runtime: no
  8. Lock
  9. ID OSID ThreadOBJ State GC Mode GC Alloc Context Domain Count Apt Exception
  10. 0 1 2970 00581020 26020 Preemptive 0294AE60:00000000 0057a5f0 0 STA
  11. 2 2 1d2c 00590670 2b220 Preemptive 00000000:00000000 0057a5f0 0 MTA (Finalizer)
  12. 5 4 3388 0063a9b8 102a220 Preemptive 00000000:00000000 0057a5f0 0 MTA (Threadpool Worker)
  13. 6 5 265c 0063b458 1020220 Preemptive 00000000:00000000 0057a5f0 0 Ukn (Threadpool Worker)
  14. 7 7 3370 07100fa8 202b220 Preemptive 00000000:00000000 0057a5f0 0 MTA
  15. ...
  16. 113 41 4af4 0a85a490 8029220 Preemptive 0294F918:00000000 0057a5f0 0 MTA (Threadpool Completion Port)
  17. 114 75 4b9c 0a83d818 8029220 Preemptive 00000000:00000000 0057a5f0 0 MTA (Threadpool Completion Port)
  18. 115 76 4ba0 0a83d2d0 8029220 Preemptive 02B53AC4:00000000 0057a5f0 0 MTA (Threadpool Completion Port)

从卦象看,当前有 115 个托管线程,从主线程的 STA 模式看 应该是一个 WinForm/WPF 程序,桌面程序这个线程数说多也不多,说少也不少,下一步的思路就是看下这些线程都在做什么。

2. 这些线程都在做什么

要探究每个线程都在做什么,可以用 ~*e !clrstack 调出所有线程栈,然后仔细耐心的观察这些线程。


  1. 0:000> ~*e !clrstack
  2. OS Thread Id: 0x488c (109)
  3. Child SP IP Call Site
  4. 114de760 7704018d [GCFrame: 114de760]
  5. 114de90c 7704018d [GCFrame: 114de90c]
  6. 114de8bc 7704018d [HelperMethodFrame: 114de8bc] System.Threading.Monitor.ReliableEnter(System.Object, Boolean ByRef)
  7. 114de94c 6dfe2767 System.Threading.Monitor.Enter(System.Object, Boolean ByRef)
  8. 114de95c 056107e3 CSRedis.Internal.IO.RedisIO.Write(Byte[])
  9. 114de998 05cb338c CSRedis.Internal.RedisConnector.Write(CSRedis.RedisCommand)
  10. 114de9dc 05cb32fc CSRedis.Internal.RedisListener`1[[System.__Canon, mscorlib]].Write[[System.__Canon, mscorlib]](CSRedis.RedisCommand`1<System.__Canon>)
  11. 114de9f0 05cb3263 CSRedis.Internal.SubscriptionListener.Send(CSRedis.Internal.Commands.RedisSubscription)
  12. 114dea0c 050c4ffd CSRedis.RedisClient.Unsubscribe(System.String[])
  13. 114dea24 050c01e3 CSRedis.CSRedisClient+SubscribeObject+c__DisplayClass13_0.b__1(System.Object)
  14. 114deab4 6e026471 System.Threading.TimerQueueTimer.CallCallbackInContext(System.Object)
  15. 114deab8 6dfe2925 System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
  16. 114deb24 6dfe2836 System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
  17. 114deb38 6e026377 System.Threading.TimerQueueTimer.CallCallback()
  18. 114deb6c 6e0261fe System.Threading.TimerQueueTimer.Fire()
  19. 114debac 6e02612f System.Threading.TimerQueue.FireNextTimers()
  20. 114debec 6e025ff1 System.Threading.TimerQueue.AppDomainTimerCallback()
  21. 114dee10 6f38eaf6 [DebuggerU2MCatchHandlerFrame: 114dee10]
  22. ...

从卦象看,线程特征非常明显,有 86 个线程卡在 Monitor.ReliableEnter 处,它就是我们C#中的 监视锁 ,既然是监视锁,那就好办了,查看它的 同步块表,看看谁在 lock 里赖着不出来导致其他线程等待,使用 windbg 的 !syncblk 命令。


  1. 0:000> !syncblk
  2. Index SyncBlock MonitorHeld Recursion Owning Thread Info SyncBlock Owner
  3. 72 005ef1f0 87 1 07176838 12c8 13 028374e4 System.Object
  4. 75 005efd1c 87 1 07176d80 32c0 14 028368ec System.Object
  5. -----------------------------
  6. Total 84
  7. CCW 0
  8. RCW 1
  9. ComClassFactory 0
  10. Free 17

从表中看,当前有两个 lock 对象,并且线程 1314 在 lock 区内不出来,导致各自有 43 个线程在等待,接下来思路就很清晰了,我们查看这两个线程到底在干嘛?

3. 持有线程正在做什么

我们就从 13 号线程入手,看看它正在做什么。


  1. 0:013> !clrstack
  2. OS Thread Id: 0x12c8 (13)
  3. Child SP IP Call Site
  4. 0971eb84 7703f901 [InlinedCallFrame: 0971eb84]
  5. 0971eb80 6c5b940f DomainBoundILStubClass.IL_STUB_PInvoke(IntPtr, Byte*, Int32, System.Net.Sockets.SocketFlags)
  6. 0971eb84 6c55b11d [InlinedCallFrame: 0971eb84] System.Net.UnsafeNclNativeMethods+OSSOCK.recv(IntPtr, Byte*, Int32, System.Net.Sockets.SocketFlags)
  7. 0971ebbc 6c55b11d System.Net.Sockets.Socket.Receive(Byte[], Int32, Int32, System.Net.Sockets.SocketFlags, System.Net.Sockets.SocketError ByRef)
  8. 0971ebec 6c55b00e System.Net.Sockets.Socket.Receive(Byte[], Int32, Int32, System.Net.Sockets.SocketFlags)
  9. 0971ec10 6c55af43 System.Net.Sockets.NetworkStream.Read(Byte[], Int32, Int32)
  10. 0971ec40 6e05add8 System.IO.Stream.ReadByte()
  11. 0971ec50 05610d2c CSRedis.Internal.IO.RedisIO.ReadByte()
  12. 0971ec8c 05610c5a CSRedis.Internal.IO.RedisReader.ReadType()
  13. 0971ecb0 05610a9e CSRedis.Internal.IO.RedisReader.ExpectType(CSRedis.RedisMessage)
  14. 0971ed28 05cb3696 CSRedis.Internal.Commands.RedisSubscription.Parse(CSRedis.Internal.IO.RedisReader)
  15. 0971ed90 05cb35bd CSRedis.Internal.RedisConnector.Read[[System.__Canon, mscorlib]](System.Func`2<CSRedis.Internal.IO.RedisReader,System.__Canon>)
  16. 0971ede0 05cb3487 CSRedis.Internal.RedisListener`1[[System.__Canon, mscorlib]].Listen(System.Func`2<CSRedis.Internal.IO.RedisReader,System.__Canon>)
  17. 0971ee34 05cb32b9 CSRedis.Internal.SubscriptionListener.Send(CSRedis.Internal.Commands.RedisSubscription)
  18. 0971ee50 05cb3156 CSRedis.RedisClient.Subscribe(System.String[])
  19. 0971ee68 05cb255a CSRedis.CSRedisClient+SubscribeObject.Subscribe(System.Object)
  20. 0971ef98 6dfb6063 System.Threading.ThreadHelper.ThreadStart_Context(System.Object)
  21. 0971efa4 6dfe2925 System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
  22. 0971f010 6dfe2836 System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
  23. 0971f024 6dfe27f1 System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object)
  24. 0971f03c 6e036ebe System.Threading.ThreadHelper.ThreadStart(System.Object)
  25. 0971f180 6f38eaf6 [GCFrame: 0971f180]
  26. 0971f364 6f38eaf6 [DebuggerU2MCatchHandlerFrame: 0971f364]

从线程栈看,是这位朋友使用了 CSRedis 的订阅功能,最后在 CSRedis.Internal.IO.RedisIO.ReadByte() 方法处迟迟出不来,问题点找到了,接下来就可以看下它的源码。

4. 查看源码

看源码的话,可以用 ILSpy 工具,编译后的代码如下:

其实这地方用 lock 锁不太稳妥,一旦出现网络波动,持有线程就会一直等待,如果这个线程是由 ThreadPool 提供,那就会导致 ThreadPool 中的线程数暴增,从 Waiting 的线程上追查,发现这些线程数都是由 Timer 提供,线程栈和截图如下:


  1. OS Thread Id: 0x40e8 (67)
  2. Child SP IP Call Site
  3. 0e7af608 7704018d [GCFrame: 0e7af608]
  4. 0e7af7b4 7704018d [GCFrame: 0e7af7b4]
  5. 0e7af764 7704018d [HelperMethodFrame: 0e7af764] System.Threading.Monitor.ReliableEnter(System.Object, Boolean ByRef)
  6. 0e7af7f4 6dfe2767 System.Threading.Monitor.Enter(System.Object, Boolean ByRef)
  7. 0e7af804 056107e3 CSRedis.Internal.IO.RedisIO.Write(Byte[])
  8. 0e7af840 05cb338c CSRedis.Internal.RedisConnector.Write(CSRedis.RedisCommand)
  9. 0e7af884 05cb32fc CSRedis.Internal.RedisListener`1[[System.__Canon, mscorlib]].Write[[System.__Canon, mscorlib]](CSRedis.RedisCommand`1<System.__Canon>)
  10. 0e7af898 05cb3263 CSRedis.Internal.SubscriptionListener.Send(CSRedis.Internal.Commands.RedisSubscription)
  11. 0e7af8b4 050c4ffd CSRedis.RedisClient.Unsubscribe(System.String[])
  12. 0e7af8cc 050c01e3 CSRedis.CSRedisClient+SubscribeObject+c__DisplayClass13_0.b__1(System.Object)
  13. 0e7af95c 6e026471 System.Threading.TimerQueueTimer.CallCallbackInContext(System.Object)

三:总结

整体分析下来,这应该算是 CSRedis 的一个 Bug,这种问题我能做的就是让朋友升级到最新版本看看,不过既然是 Bug 那其他人肯定也会遇到,看了下 CSRedis.dll 程序集给的 github 地址。


  1. [assembly: CompilationRelaxations(8)]
  2. [assembly: RuntimeCompatibility(WrapNonExceptionThrows = true)]
  3. [assembly: Debuggable(DebuggableAttribute.DebuggingModes.Default | DebuggableAttribute.DebuggingModes.DisableOptimizations | DebuggableAttribute.DebuggingModes.IgnoreSymbolStoreSequencePoints | DebuggableAttribute.DebuggingModes.EnableEditAndContinue)]
  4. [assembly: TargetFramework(".NETFramework,Version=v4.5", FrameworkDisplayName = ".NET Framework 4.5")]
  5. [assembly: AssemblyCompany("CSRedisCore")]
  6. [assembly: AssemblyConfiguration("Debug")]
  7. [assembly: AssemblyDescription("CSRedis 是 redis.io 官方推荐库,支持 redis-trib集群、哨兵、私有分区与连接池管理技术,简易 RedisHelper 静态类。")]
  8. [assembly: AssemblyFileVersion("3.6.6.0")]
  9. [assembly: AssemblyInformationalVersion("3.6.6")]
  10. [assembly: AssemblyProduct("CSRedisCore")]
  11. [assembly: AssemblyTitle("CSRedisCore")]
  12. [assembly: AssemblyMetadata("RepositoryUrl", "https://github.com/2881099/csredis")]
  13. [assembly: AssemblyVersion("3.6.6.0")]

果然在 Issueshttps://github.com/2881099/csredis/issues/414 ) 中找到了同样的问题, 很可惜作者没给解答。

说一个有意思的事情,我看了下提问者的昵称 thicktao 好像很熟悉,在微信上好像有这位朋友。

我去,他去年就曾今找过我,.NET圈子真小,缘分哈。。。

记一次 .NET 某工控数据采集平台 线程数 爆高分析的更多相关文章

  1. 记一次 .NET 某工控视觉软件 非托管泄漏分析

    一:背景 1.讲故事 最近分享了好几篇关于 非托管内存泄漏 的文章,有时候就是这么神奇,来求助的都是这类型的dump,一饮一啄,莫非前定.让我被迫加深对 NT堆, 页堆 的理解,这一篇就给大家再带来一 ...

  2. 记一次 .NET 某电商交易平台Web站 CPU爆高分析

    一:背景 1. 讲故事 已经连续写了几篇关于内存暴涨的真实案例,有点麻木了,这篇换个口味,分享一个 CPU爆高 的案例,前段时间有位朋友在 wx 上找到我,说他的一个老项目经常收到 CPU > ...

  3. 记一次 .NET 某工控自动化控制系统 卡死分析

    一:背景 1. 讲故事 前段时间遇到了好几起关于窗体程序的 进程加载锁 引发的 程序卡死 和 线程暴涨 问题,这种 dump 分析难度较大,主要涉及到 Windows操作系统 和 C++ 的基础知识, ...

  4. 记一次 .NET 某机械臂智能机器人控制系统MRS CPU爆高分析

    一:背景 1. 讲故事 这是6月中旬一位朋友加wx求助dump的故事,他的程序 cpu爆高UI卡死,问如何解决,截图如下: 在拿到这个dump后,我发现这是一个关于机械臂的MRS程序,哈哈,在机械臂这 ...

  5. 记一次 .NET 某市附属医院 Web程序 偶发性CPU爆高分析

    一:背景 1. 讲故事 这个月初,一位朋友加微信求助他的程序出现了 CPU 偶发性爆高,希望能有偿解决一下. 从描述看,这个问题应该困扰了很久,还是医院的朋友给力,开门就是 100块 红包 ,那既然是 ...

  6. 开源纯C#工控网关+组态软件(七)数据采集与归档

    一.   引子 在当前自动化.信息化.智能化的时代背景下,数据的作用日渐凸显.而工业发展到如今,科技含量和自动化水平均显著提高,但对数据的采集.利用才开始起步. 对工业企业而言,数据采集日益受到重视, ...

  7. 开源纯C#工控网关+组态软件(十)移植到.NET Core

    一.   引子 写这个开源系列已经十来篇了.自从十年前注册博客园以来,关注了张善友.老赵.xiaotie.深蓝色右手等一众大牛,也围观了逗比的吉日嘎啦.精密顽石等形形色色的园友.然而整整十年一篇文章都 ...

  8. 开源纯C#工控网关+组态软件(八)表达式编译器

    一.   引子 监控画面的主要功能之一就是跟踪下位机变量变化,并将这些变化展现为动画.大部分时候,界面上一个图元组件的某个状态,与单一变量Tag绑定,比如电机的运行态,绑定一个MotorRunning ...

  9. Wireshark工控协议

    Wireshark是一个强大开源流量与协议分析工具,除了传统网络协议解码外,还支持众多主流和标准工控协议的分析与解码. 序号 协议类型 源码下载 简介 1 Siemens S7 https://git ...

随机推荐

  1. 2021.07.17 P3177 树上染色(树形DP)

    2021.07.17 P3177 树上染色(树形DP) [P3177 HAOI2015]树上染色 - 洛谷 | 计算机科学教育新生态 (luogu.com.cn) 重点: 1.dp思想是需要什么,维护 ...

  2. 微服务状态之python巡查脚本开发

    背景 由于后端微服务架构,于是各种业务被拆分为多个服务,服务之间的调用采用RPC接口,而Nacos作为注册中心,可以监听多个服务的状态,比如某个服务是否down掉了.某个服务的访问地址是否改变.以及流 ...

  3. Python实现双X轴双Y轴绘图

    诈尸人口回归.这一年忙着灌水忙到头都掉了,最近在女朋友的提醒下终于想起来博客的账号密码,正好今天灌水的时候需要画一个双X轴双Y轴的图,研究了两小时终于用Py实现了.找资料的过程中没有发现有系统的文章, ...

  4. 通过源码了解Java的自动装箱拆箱

    什么叫装箱 & 拆箱? 将int基本类型转换为Integer包装类型的过程叫做装箱,反之叫拆箱. 首先看一段代码 public static void main(String[] args) ...

  5. PostgreSQL培训认证讲师招募

    中国PostgreSQL考试认证中心 以"知"之名,携手共进!不蒂于知识共享,技术传承,更愿为讲师耕织嫁衣,助您成为PostgreSQL圈的意见领袖,用知识改变世界! 一.入选讲师 ...

  6. jstl操作session

    1.jstl操作session(添加.删除session中的值)

  7. 1.4 类UNIX系统是什么鬼?

    上节<UNIX和Linux的区别>中讲到了 UNIX 系统的历史,UNIX 是操作系统的开山鼻祖,是操作系统的发源地,后来的 Windows 和 Linux 都参考了 UNIX. 有人说, ...

  8. ZooKeeper 基本原理你懂了么?

    点击上方"开源Linux",选择"设为星标" 回复"学习"获取独家整理的学习资料! 作者:阿凡卢来源:cnblogs.com/luxiaox ...

  9. go ants源码分析

    golang ants 源码分析 结构图 poolwithfunc与pool相差不大,这里我们只分析ants默认pool的流程 文件 作用 ants.go 定义常量.errors显示.默认建一个大小为 ...

  10. OpenStack平台调度策略优化

    OpenStack平台报错分析 在OpenStack平台经历大并发的时候,比如同一个平台,大量的用户同时创建云主机(单个用户创建大量云主机不会触发此种现象),会达到云平台的性能瓶颈,导致创建云主机报错 ...