【发布时间】:2016-08-12 01:55:14
【问题描述】:
我们看到很多像下面这样的调用堆栈,我可以知道什么条件\情况会发生这种情况吗?
OS Thread Id: 0x48654 (559)
Current frame: ntdll!NtWaitForSingleObject+0xa
Child-SP RetAddr Caller, Callee
00000020a76cf480 00007fffd4ea1118 KERNELBASE!WaitForSingleObjectEx+0x94, calling ntdll!NtWaitForSingleObject
00000020a76cf520 00007fffce50ce66 clr!CLRSemaphore::Wait+0x8a, calling kernel32!WaitForSingleObjectEx
00000020a76cf5e0 00007fffce50d247 clr!ThreadpoolMgr::UnfairSemaphore::Wait+0x109, calling clr!CLRSemaphore::Wait
00000020a76cf620 00007fffce50d330 clr!ThreadpoolMgr::WorkerThreadStart+0x1b9, calling clr!ThreadpoolMgr::UnfairSemaphore::Wait
00000020a76cf6c0 00007fffce5de8b6 clr!Thread::intermediateThreadProc+0x7d
00000020a76cfb40 00007fffce5de89f clr!Thread::intermediateThreadProc+0x66, calling clr!_chkstk
00000020a76cfb80 00007fffd60613d2 kernel32!BaseThreadInitThunk+0x22
00000020a76cfbb0 00007fffd7be5454 ntdll!RtlUserThreadStart+0x34
OS Thread Id: 0x3bd4c (560)
Current frame: ntdll!NtWaitForSingleObject+0xa
Child-SP RetAddr Caller, Callee
00000020a774e910 00007fffd4ea1118 KERNELBASE!WaitForSingleObjectEx+0x94, calling ntdll!NtWaitForSingleObject
00000020a774e9b0 00007fffce50ce66 clr!CLRSemaphore::Wait+0x8a, calling kernel32!WaitForSingleObjectEx
00000020a774ea70 00007fffce50d247 clr!ThreadpoolMgr::UnfairSemaphore::Wait+0x109, calling clr!CLRSemaphore::Wait
00000020a774eab0 00007fffce50d330 clr!ThreadpoolMgr::WorkerThreadStart+0x1b9, calling clr!ThreadpoolMgr::UnfairSemaphore::Wait
00000020a774eb50 00007fffce5de8b6 clr!Thread::intermediateThreadProc+0x7d
00000020a774ec30 00007fffd7c00c75 ntdll!RtlpLowFragHeapAllocFromContext+0x355, calling ntdll!memset
【问题讨论】:
-
0:030> !do 0000001fc0a80fe8 名称:System.Runtime.Remoting.Contexts.Context MethodTable:00007fffcd2ae6c8 EEClass:00007fffccd74ad8 大小:104(0x68) 字节文件:C:\Windows\Microsoft.Net\ assembly\GAC_64\mscorlib\v4.0_4.0.0.0__b77a5c5619 BTW,我们还看到线程上下文是 System.Runtime.Remoting.Contexts.Context
-
仅根据调用堆栈中的函数名称,看起来就像一个空闲的工作线程——一个等待工作到达的线程。
-
对于线程池线程来说这是一个完全正常的状态,它正在等待工作。如果您看到其中很多,那么之前出现了问题,您有太多的线程池请求需要很长时间才能完成。活动 TP 线程数的上限非常高。除了更好地平衡工作负载之外,理想的解决方案当然是 Q&D 修复是调用 ThreadPool.SetMaxThreads()。
标签: c# multithreading debugging threadpool windbg