在高并发系统中，CPU突然打满、请求无响应、线程数暴涨、内存持续增长等问题往往交替出现。单靠日志和断点调试很难还原生产环境的真实状态，这时就需要借助专门的诊断工具。WinDbg和PerfView是Windows平台上最常用的组合：WinDbg擅长对进程内存转储做静态分析，能看清线程到底卡在哪个调用栈、锁被谁持有；PerfView则通过ETW采集运行时事件，呈现CPU时间消耗和垃圾回收活动。两者一个偏向事后快照，一个偏向动态追踪，结合使用可以覆盖大多数高并发故障的排查路径。
下面从线程与锁分析、CPU热点定位、内存与GC压力三个维度，介绍这两款工具的具体用法和配合思路。
一、WinDbg 线程与锁等待分析实操
进行高并发排查的第一步通常是获取故障现场。生产环境不能随意附加调试器，最安全的做法是用 dotnet-dump collect 命令按进程ID抓取内存转储，然后把dump文件复制到本地用WinDbg或 dotnet-dump analyze 打开。加载SOS扩展后，!threads 可以列出所有托管线程及其状态，!clrstack 查看当前线程的托管调用栈，而 ~*e !clrstack 能遍历所有线程输出栈信息。对于高并发场景下常见的死锁或长时间锁等待，可以先执行 !syncblk 查看同步块的持有情况，再结合各个线程的栈确认锁的竞争关系。
举一个典型的死锁例子：两个线程分别先锁住lockA和lockB，再尝试获取对方已持有的锁。
private static readonly object lockA = new object();
private static readonly object lockB = new object();
static void Main()
{
var t1 = new Thread(() =>
{
lock (lockA)
{
Thread.Sleep(100);
lock (lockB)
{
Console.WriteLine("t1");
}
}
});
var t2 = new Thread(() =>
{
lock (lockB)
{
Thread.Sleep(100);
lock (lockA)
{
Console.WriteLine("t2");
}
}
});
t1.Start();
t2.Start();
t1.Join();
t2.Join();
}
程序运行后会永久挂起。此时抓取dump，在WinDbg中执行 !syncblk 可以看到两个对象分别被两个线程持有，再执行 ~*e !clrstack 会发现线程1停在等待lockB的 Monitor.Enter 调用上，线程2停在等待lockA的同一方法上。两个栈互相印证，即可快速确认死锁。类似方法也适用于分析线程池饥饿：如果 !threads 显示大量线程处于Wait状态，而它们都在等待同一个锁或同一个任务队列，就说明并发设计上存在串行化瓶颈。
除了锁分析，WinDbg还可以检查异常对象。执行 !pe 查看当前异常信息，或者用 !dumpheap -type System.Exception 统计异常实例。在高并发下频繁抛出异常会显著消耗CPU和分配开销，从dump中统计异常类型和数量，往往能定位到被吞掉的异常或反复重试的逻辑。
二、PerfView CPU采样与线程时间线定位热点
WinDbg的dump是某一时刻的快照，而PerfView记录的是进程在一段时间内的行为，更适合定位CPU消耗热点。使用PerfView采集数据时，选择Collect菜单下的Collect，勾选CPU Sample和Thread Time等选项，设置采集时长后开始。采集完成后打开CPU Stacks视图，可以看到按调用树聚合的CPU采样数据。比如一个高并发Web服务CPU持续100%，在CPU Stacks中很可能会看到某个方法占用了大量独占时间，直接点击即可跳到对应源码或IL代码位置。
下面的代码模拟了多线程竞争同一个锁导致的CPU开销：
static int counter = 0;
static object gate = new object();
static void Worker()
{
while (true)
{
lock (gate)
{
counter++;
}
}
}
当多个线程执行 Worker 时，锁的争用会让 Monitor.Enter 在CPU采样中占据很高比例。PerfView的CPU Stacks可以按GroupPats进行分组，例如将模块或类名合并查看，把注意力集中到业务代码而不是CLR内部函数。同时，Thread Time视图能区分线程花在CPU执行上的时间和等待锁、等待IO的阻塞时间。如果发现某个线程的阻塞时间远大于CPU时间，再结合WinDbg查看该线程栈，定位它到底在等什么资源。
PerfView还能分析GC活动。在Events视图中勾选GC相关事件，可以看到Gen0、Gen1、Gen2回收的次数和耗时。如果Gen0回收非常频繁，说明应用程序在持续创建大量短生命周期对象。这时配合PerfView的GC Allocation采样，可以找到分配量最大的调用栈，从而定位到高并发路径中的不必要分配，例如字符串拼接、装箱、闭包捕获等。这一点在高吞吐服务中尤为关键，因为频繁分配会直接导致GC停顿增加，拖慢整体响应时间。
三、双工具协同：内存分配与GC压力排查
高并发问题往往不是孤立的，CPU热点可能由锁竞争引起，锁竞争又可能源于内存分配过快导致的GC压力。单独使用WinDbg或PerfView都只能看到问题的一部分，因此建议先通过PerfView采集一段时间的运行数据，从CPU、线程时间和GC事件三个角度缩小嫌疑范围，再抓取对应时刻的dump，用WinDbg做精细的对象和线程分析。
例如一个高并发队列处理程序内存持续增长，用PerfView查看GC Allocation发现 byte[] 的分配量异常高，但GC回收并不彻底。接下来抓取dump，在WinDbg中执行 !dumpheap -type System.Byte[] 可以看到大量字节数组对象仍被引用。继续执行 !gcroot 查看某个对象的引用链，发现它被一个 ConcurrentQueue<byte[]> 的实例持有，而消费者线程处理速度远低于生产者，导致队列无限堆积。问题根因就从PerfView的宏观现象直接定位到了具体的对象引用关系。
另一个协同场景是GC停顿时间过长。PerfView显示Gen2回收耗时数百毫秒，同时线程时间视图显示多个请求线程在 WaitUntilGCComplete 上阻塞。此时用WinDbg打开回收前的dump，执行 !dumpheap -stat 按类型统计对象数量，重点关注大对象堆中的数组、字符串或自定义缓存结构。通过 !eeheap -gc 查看各代堆的大小，结合 !gcroot 找到持有大量存活对象的根。两个工具的数据相互印证，可以判断是缓存设计不合理、事件未退订，还是并发集合引用未清理导致的内存膨胀。
最后需要强调，生产环境使用这些工具时要尽量降低侵入性。采集dump优先使用 dotnet-dump collect，PerfView采样时选择CPU采样而不是仪器化采集，避免对进程造成过多开销。分析的dump文件应保留在磁盘空间充足的目录，例如 C:\dumps\。WinDbg加载SOS时要注意与.NET运行时版本匹配，否则可能出现命令不可用。只要掌握了WinDbg的线程与对象分析，以及PerfView的CPU与GC追踪，大多数高并发疑难杂症都能在较短时间内找到明确线索。
