用 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<t>.Enqueue</t>、
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 <pid>在 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 <pid>分析锁关系：
dotnet-dump analyze <dump-file> -c "threads -s" | findstr "Lock"找出状态为
Waiting on lock的线程 对任一线程 ID（如
0x1a），执行：
dumpheap -stat+
dumpobj <lock-object-address>确认该对象是否被其他线程
Monitor.Enter后未释放 特别注意
ConcurrentDictionary<tkey tvalue></tkey>的分段锁：若多个线程反复操作同一 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实例。
