17370845950

Visual Studio CPU 使用率工具可定位并发争用：勾选收集争用数据，按 Blocked Time 排序，关注 Monitor.Enter 等锁调用栈；dotnet-trace + PerfView 分析线程池队列堆积；dotnet-dump 查锁持有链；避免将异步等待误判为瓶颈。

用 Visual Studio 的 CPU 使用率工具定位并发线程争用

Visual Studio 自带的 CPU 使用率 工具（非第三方 Profiler）是排查 C# 并发瓶颈最直接的方式。它能显示线程状态（Running / Blocked / Waiting）、调用堆栈、以及哪些方法在锁上卡住。关键不是看“谁耗 CPU 高”，而是找大量线程长期处于 Wait 或 Blocked 状态的热点。

• 启动时勾选 Collect .NET allocation and contention data（否则看不到锁等待和线程阻塞详情）
• 重现高并发场景后，切换到 Threads 视图，按 Blocked Time (ms) 降序排列，重点关注 Monitor.Enter、ConcurrentQueue.Enqueue、SpinWait.SpinOnce 等调用栈
• 若看到多个线程在同一个 object 实例上调用 Monitor.Enter，说明存在锁争用；若堆栈指向 lock (_syncRoot) 或 Monitor.Enter(_locker)，且 _locker 是共享实例，就是瓶颈点

用 dotnet-trace + PerfView 分析 ThreadPool 饱和与队列堆积

当并发请求激增但吞吐不升反降，常因线程池任务排队过长，而非 CPU 不够。此时 dotnet-trace 可捕获 Microsoft-Extensions-Logging 和 Microsoft-DotNet-ILCompiler 之外的关键 provider：Microsoft-DotNet-ThreadPool。

• 命令行采集：

  dotnet-trace collect --providers Microsoft-DotNet-ThreadPool:0x1000000000000000:4,Microsoft-DotNet-ThreadPool:0x2000000000000000:4 --process-id 

• 在 PerfView 中打开 ThreadPool > WorkerThreadQueueLength 计数器，观察是否持续 > 0；若平均值 > 5，说明任务提交速率远超线程处理能力
• 检查 ThreadPool > WorkerThreadStart 事件间隔：若新线程启动延迟 > 100ms，说明系统已接近线程池上限（默认 max worker threads = min(1000, #cores × 500)），需调用 ThreadPool.SetMaxThreads 或改用 Task.Run + 自定义 TaskScheduler

用 dotnet-dump 查看运行时线程锁持有链

当应用挂起或响应极慢，且怀疑死锁或长持锁，dotnet-dump 比实时 Profiler 更可靠——它能抓取完整托管堆和线程上下文，包括每个线程当前持有的 Monitor 和正在等待的 obj 地址。

• 生成 dump：

  dotnet-dump collect -p 

• 分析锁关系：

  dotnet-dump analyze  -c "threads -s" | findstr "Lock"

  找出状态为 Waiting on lock 的线程
• 对任一线程 ID（如 0x1a），执行：

  dumpheap -stat

  +

  dumpobj 

  确认该对象是否被其他线程 Monitor.Enter 后未释放
• 特别注意 ConcurrentDictionary 的分段锁：若多个线程反复操作同一 key（尤其 hash 冲突高时），可能挤在同一个 segment 上，表现为单个 object 被频繁 Monitor.Enter

避免误判：别把异步 I/O 等待当成并发瓶颈

await Task.Delay、await httpClient.GetAsync 或 EF Core 的 ToListAsync 等操作，在 Profiler 中常显示为线程“空闲”或“未运行”，但这不是瓶颈——它们本就不该占 CPU。真正要盯的是那些本该异步却用了同步阻塞的调用。

• 检查是否误用 .Result 或 .Wait()：Profiler 中会显示线程在

  

  Task.InternalWait 或 ThreadPool.WaitCallback 上长时间 Blocked
• 确认数据库连接是否复用：若每个请求都新建 SqlConnection 且未及时 Dispose，连接池耗尽会导致后续请求在 SqlConnection.Open 上无限等待（表现类似锁争用，但根源是资源池）
• 警惕 ValueTask 误用：重复 await 同一个已完成的 ValueTask 会抛 InvalidOperationException，某些 Profiler 会将其归类为“异常开销”，掩盖真实问题

并发瓶颈往往不在代码写法多炫酷，而在共享状态的粒度是否合理、线程资源是否被隐式耗尽、以及同步/异步边界是否被无意打破。跑一次 dotnet-trace + dotnet-dump 组合，比读十篇锁优化文章更能定位你进程里那个卡住的 object 实例。