Runtime.ProcessorCount 在容器中返回 K8s CPU limit 值（如 limits.cpu: "4" → 返回 4），依据 cgroups cpu.cfs_quota_us / cpu.cfs_period_us 向下取整；未设 limit 时退回到宿主机核数，易致线程池过载。
Runtime.ProcessorCount 返回值怎么被 K8s CPU Limit 动了手脚？
C# .NET Core 3.0+ 的 Runtime.ProcessorCount（替代旧版 Environment.ProcessorCount）在容器中运行时，**会读取 Linux cgroups 的 CPU 配额**，而不是宿主机物理核数。这和现代 Java JVM 的行为逻辑一致——但前提是你的 .NET 运行时版本够新、且没被手动覆盖。
关键路径是：/sys/fs/cgroup/cpu/cpu.cfs_quota_us ÷ /sys/fs/cgroup/cpu/cpu.cfs_period_us → 向下取整为整数 → 成为 ProcessorCount 的返回值。
- 若 K8s 设置
resources.limits.cpu: "4"，cgroups 通常设为quota=400000, period=100000→ 计算得 4 →ProcessorCount == 4 - 若未设
limits.cpu（只设requests），cgroups 不启用 CFS quota →ProcessorCount退回到宿主机总核数（比如 64）→ 线程池极易过载 - .NET 5+ 默认启用容器感知；.NET Core 2.1/3.1 需确保使用较新 patch 版本（如 3.1.30+），否则可能 fallback 到宿主机核数
ThreadPool.SetMinThreads / DefaultThreadFactory 怎么被“骗”了？
.NET 默认线程池（ThreadPool）的初始最小线程数不直接依赖 ProcessorCount，但它影响很多间接决策：比如 TaskScheduler.Default 的并发调度策略、Parallel.ForEach 的默认分区数、以及第三方库（如 gRPC、Kestrel）内部基于核数的线程数推导。
更隐蔽的是：Kestrel 的 ThreadPool.ThreadCount（非公开 API）和 HTTP/2 流复用逻辑，会参考 ProcessorCount 调整连接处理线程倾向；而 ParallelOptions.MaxDegreeOfParallelism 若设为 -1（默认），底层也用 ProcessorCount 做上限。
- 现象：Pod 限制为 2 核，但日志显示
ThreadPool.GetAvailableThreads()返回 1000+ 可用线程 → 实际调度时大量线程争抢 2 个 CPU 时间片，context switches/sec暴涨 - 错误做法：在代码里硬编码
ThreadPool.SetMinThreads(32, 32)—— 容器重启或扩缩后失效，且掩盖资源错配本质 - 正确做法：让线程池“自适应”，只在必要时（如 IO 密集型长任务）显式调用
ThreadPool.SetMinThreads，且数值应 ≤ K8slimits.cpu× 2（保守起见）
为什么你设了 limits.cpu: "2"，却看到 8 个 Kestrel Worker 线程？
Kestrel 默认使用 ThreadPool，但它的 ListenOptions.ThreadCount（已弃用）或当前的 HttpServerOptions 并不直读 ProcessorCount；真正作祟的是 底层 epoll/kqueue 调度模型 + .NET 对高并发连接的预分配策略。当容器内存充足、CPU limit 较低时，Kestrel 可能创建较多 worker 线程来应对连接队列积压——但这不是线程池“主动扩容”，而是事件循环阻塞后被动唤醒更多线程的结果。
- 典型症状：CPU usage 在 Grafana 中显示为“锯齿状尖峰”，
rate(process_cpu_seconds_total[5m])波动剧烈，但平均不到 limit 值 → 说明线程频繁阻塞/唤醒，而非真正在计算 - 验证方式：进容器执行
cat /sys/fs/cgroup/cpu/cpu.stat，关注nr_throttled和throttled_time—— 若持续增长，说明 CPU 被 cgroups 强制限频，线程在排队等时间片 - 缓解建议：对 Kestrel 显式限流，例如
options.Limits.MaxConcurrentConnections = 200；或改用ThreadPool.UnsafeQueueUserWorkItem控制任务入队节奏，避免突发流量打满线程池
别忘了内存限制也在暗中掐住线程池脖子
K8s memory.limit 不只防 OOM，它还决定你能创建多少线程——每个 .NET 线程默认栈空间约 1MB（Windows）或 2MB（Linux）。假设容器 memory.limit: 2Gi，JVM 堆那种“堆外内存挤压”问题在 .NET 同样存在：若线程池开到 2000 个，仅栈就吃掉 4GB，直接触发 OOMKilled。
- 危险组合：
limits.cpu: "1"+limits.memory: "512Mi"+ThreadPool.SetMaxThreads(1000, 1000)→ Pod 启动即被 Kill - 安全做法：用
dotnet-counters monitor --process-id 1观察System.Runtime/Thread Count指标；将maxThreads上限设为(memory.limit bytes / 2_000_000) * 0.7（留 30% 给堆、GC、native 内存） - 终极提醒：.NET 的 GC（尤其是 Server GC）也会根据
ProcessorCount启动多个 GC 线程 —— 如果 CPU limit 是 1，却因旧 runtime 误报为 64，那 63 个 GC 线程会把唯一可用核彻底占满
.NET 在容器里对 CPU limit 的响应比 Java 更“安静”，没有明显报错，但线程池行为偏移往往更难定位——因为问题藏在调度延迟、GC 抖动、连接堆积这些次生现象里，而不是一眼可见的 OutOfMemoryError 或 Context Switching 告警。
