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<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 地址。
使用 Azure AI 项目 Python SDK (azure-ai-projects) 构建 AI 应用。适用于处理 Foundry 项目客户端、使用 PromptAgentDefinition 创建版本化代理、运行评估、管理连接/部署/数据集/索引，或使用 OpenAI 兼容客户端。这是高级 Foundry SDK - 如需低级代理操作，请使用 azure-ai-agents-python 技能。
- 生成 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 实例。
