Environment.ProcessorCount 返回逻辑处理器数而非物理核心数，如8核16线程机器返回16；它仅表示硬件并发上限，不等于最优并行度，I/O密集型任务应设为4～8，计算密集型才宜用该值。
Environment.ProcessorCount 返回的是逻辑处理器数，不是物理核心数
Environment.ProcessorCount 返回的是操作系统报告的**逻辑处理器数量**，即启用了超线程（Hyper-Threading）的 CPU 会把每个物理核心暴露为两个逻辑处理器。比如一台 8 核 16 线程的机器，该值就是 16，而非 8。
这个值常被误当作“最佳并行度”，但它只反映硬件并发能力上限，不等于实际吞吐最优值。I/O 密集型任务用 16 个并行线程可能反而引发大量上下文切换和锁争用。
- 纯计算密集型任务（如矩阵运算、图像编码）通常适合设为
Environment.ProcessorCount - 混合型或 I/O 密集型任务（如 HTTP 批量请求、文件读写）应显著低于该值，常见设为
4～8 - 若应用本身已存在高竞争资源（如共享
ConcurrentQueue<t></t>或数据库连接池），盲目拉高并行度会放大争用，降低整体吞吐
Parallel.ForEach 和 PLINQ 的默认并行度就是 Environment.ProcessorCount
当你没显式指定时，Parallel.ForEach 和 AsParallel() 默认使用 Environment.ProcessorCount 作为最大并行度。这意味着：
- 在 64 核服务器上，默认可能启动 64 个线程处理一个
Parallel.ForEach—— 即使你的数据只有 100 条，且每项只需几毫秒 - PLINQ 的
WithDegreeOfParallelism(n)是唯一可控入口；不调用它，就按ProcessorCount走 -
Task.Run或ThreadPool.QueueUserWorkItem不受此值约束，它们走线程池调度，行为更动态
示例：强制限制 PLINQ 并行度为 4，避免过度调度
var result = source.AsParallel()
.WithDegreeOfParallelism(4)
.Select(x => ExpensiveCompute(x))
.ToList();
手动设置 ParallelOptions.MaxDegreeOfParallelism 时，0 和负数会被忽略
ParallelOptions.MaxDegreeOfParallelism 是 Parallel.ForEach / Parallel.For 的关键控制参数。注意它的取值规则：
- 设为
0：等价于不设，回退到默认行为（即Environment.ProcessorCount） - 设为负数（如
-1）：运行时不报错，但被静默忽略，同样回退到默认值 - 设为正整数（如
2）：严格限制最大并发线程数，哪怕机器有 64 核也只用 2 个 - 该值**不是最小保证数**——如果数据量少于设定值（如
MaxDegreeOfParallelism=8但只迭代 3 次），实际只启 3 个线程
正确写法示例：
var options = new ParallelOptions
{
MaxDegreeOfParallelism = 4 // 必须是 > 0 的整数才生效
};
Parallel.ForEach(items, options, item => Process(item));
别把 ProcessorCount 当作性能调优终点
真实瓶颈往往不在 CPU 数量，而在内存带宽、GC 压力、锁粒度或外部依赖（如数据库连接数）。例如：
- 在 .NET 6+ 中启用
ThreadPool.SetMinThreads(100, 100)可能比调高MaxDegreeOfParallelism更有效，尤其对短时高频任务 - 用
ValueTask+ 异步 I/O 替代同步并行，通常比增加线程数更能提升吞吐 -
Environment.ProcessorCount在容器环境（如 Docker）中可能返回宿主机核数，而非 cgroups 限制的可用核数 —— 此时需结合/sys/fs/cgroup/cpu.max或DOTNET_PROCESSOR_COUNT环境变量校准
最易被忽略的一点：ProcessorCount 是进程启动时读取的静态值，热插拔 CPU（极少见）或容器配额变更后不会自动更新。需要重启进程或手动缓存刷新逻辑。
