dotnet-counters 能否直接监控线程池和 GC？
可以，但前提是目标进程已启用
EventPipe事件流（.NET Core 3.0+ 默认开启），且运行时加载了对应性能计数器提供程序。线程池（
System.Threading.ThreadPool）和垃圾回收（
System.Runtime）的指标都属于 .NET 运行时内置的性能计数器，无需额外 NuGet 包或代码修改。
关键限制：必须用
dotnet-countersv5.0.0+（推荐 v7.0.0 或更高），旧版本不支持部分线程池计数器（如
ThreadPool.QueueLength）；且被监控进程不能是发布为
Self-contained并禁用诊断的场景（例如带
--no-restore --no-build启动且未配置
DOTNET_STARTUP_HOOKS的极简部署）。
启动监控前要确认的三件事
避免“明明跑了却看不到数据”的常见失败：
dotnet-counters版本 ≥ 5.0.0：
dotnet-counters --version目标进程是 .NET 5/6/7/8 应用（非 .NET Framework），且未设置环境变量
DOTNET_NOLOGO=1或
DOTNET_DISABLE_DIAGNOSTICS=1你有权限附加到该进程：Linux/macOS 需同用户或 root；Windows 通常无限制，但若进程以
SYSTEM身份运行（如 Windows Service），需用管理员权限启动
dotnet-counters
实时监控线程池活动的关键命令
线程池核心指标集中在
System.Threading.ThreadPool提供程序下，重点关注排队任务、活跃线程与完成率： 查看所有线程池计数器：
dotnet-counters monitor -p <pid> --providers System.Threading.ThreadPool只显示关键指标（减少干扰）：
dotnet-counters monitor -p <pid> --providers "System.Threading.ThreadPool:0:1:EventCounterIntervalSec=1"（
EventCounterIntervalSec=1表示每秒刷新一次） 重点关注字段：
ThreadPool.QueueLength：当前排队等待执行的工作项数量（持续 > 0 可能意味着吞吐瓶颈）
ThreadPool.ActiveThreads：当前正在执行任务的线程数（突增可能触发线程饥饿或 GC 压力）
ThreadPool.CompletedItemsPerSecond：每秒完成工作项数（衡量实际吞吐能力）
同步观察 GC 活动并关联线程池压力
GC 和线程池常相互影响：频繁 GC 会暂停线程执行，导致任务排队；高并发任务又会加速内存分配，触发 GC。建议合并监控：
同时订阅两个提供程序：dotnet-counters monitor -p <pid> --providers "System.Runtime:0:1:EventCounterIntervalSec=1","System.Threading.ThreadPool:0:1:EventCounterIntervalSec=1"重点交叉观察： 当
System.Runtime#GenXCollectionCount（如
Gen2CollectionCount）突增时，检查
ThreadPool.QueueLength是否同步上升；
System.Runtime#TimeInGc占比 > 10% 且
ThreadPool.ActiveThreads波动剧烈，大概率存在 GC 导致的线程阻塞；
System.Runtime#AllocatedBytesPerSecond持续偏高（如 > 10MB/s）而
ThreadPool.CompletedItemsPerSecond下降，说明分配压力已拖慢处理速度
注意：
dotnet-counters不显示 GC 暂停时间明细（如 STW 时间），需用
dotnet-trace录制
GCTrigger事件进一步分析。
