WithDegreeOfParallelism 是建议而非强制，PLINQ 可能因数据量小、操作轻量或资源紧张而降级为单线程；实际并行度需用 Thread.ManagedThreadId 验证，且受分区策略影响远大于数值设置。
WithDegreeOfParallelism 设置后不生效？先看它是否被忽略
PLINQ 的 WithDegreeOfParallelism 不是强制约束，而是一种“建议”。当 PLINQ 判定当前查询不适合并行（比如源集合太小、操作太轻量），或系统资源紧张时，它可能自动降级为单线程执行，甚至完全忽略你设的值。
常见现象：.AsParallel().WithDegreeOfParallelism(8).Select(...) 跑起来 CPU 占用率很低，任务管理器里只看到 1–2 个核心活跃。
- 确保数据源足够大（通常 > 10,000 项才值得并行）
- 避免在
Select中做纯内存计算（如x => x * 2），这种开销远小于调度成本，PLINQ 会主动串行化 - 检查是否调用了
ToList()或ToArray()等强制立即执行方法——它们本身不阻断并行度，但若上游被优化掉，就白设了
如何验证实际并行度是否达到预期
不能只看 CPU 使用率。最直接的方式是在线程敏感上下文中埋点，比如用 Thread.CurrentThread.ManagedThreadId 记录参与运算的线程 ID 分布。
var threadIds = data
.AsParallel()
.WithDegreeOfParallelism(4)
.Select(x => Thread.CurrentThread.ManagedThreadId)
.Distinct()
.ToArray();
Console.WriteLine($"实际使用线程数：{threadIds.Length}，ID 列表：{string.Join(", ", threadIds)}");注意：PLINQ 可能复用线程池线程，Distinct() 结果数 ≤ 设定值才算正常；如果恒为 1，说明根本没并行。
- 不要在
Where或Select中做Console.WriteLine—— I/O 会严重干扰线程调度，导致假性串行 - 避免在 lambda 中捕获外部锁（如
lock(obj)），这会强制排队，让并行度失效 -
WithExecutionMode(ParallelExecutionMode.ForceParallelism)可配合使用，强制启用并行（但不保证线程数精确匹配）
设置过高反而拖慢性能？看这几个关键因素
盲目设成 Environment.ProcessorCount * 2 很危险。PLINQ 默认并行度就是 Environment.ProcessorCount，多数场景下已是最优起点。
- CPU 密集型任务：设为
Environment.ProcessorCount通常最佳；超过后线程切换开销 > 计算收益 - I/O 密集型任务（如含
HttpClient调用）：PLINQ 不适合——它无法感知异步等待，会把线程卡死在等待上；该用Task.WhenAll+async/await - 内存带宽瓶颈场景（如大量数组拷贝）：并行度越高，争抢内存总线越严重，实测速度可能下降 30%+
- 调试时设为 1 或 2，可让断点行为可预测；发布前再调回合理值
和 ThreadPool.SetMinThreads 的关系要不要调？
完全无关。WithDegreeOfParallelism 控制的是 PLINQ 内部划分的“工作分区数”，不是线程池大小。它依赖线程池提供线程，但不会主动扩容线程池。
如果你发现高并行度下大量任务排队（ThreadPool.GetAvailableThreads 返回可用线程极少），那问题不在 PLINQ 设置，而在：
- 线程被长期阻塞（如同步 I/O、死锁、长时间
Thread.Sleep） - 其他代码大量调用
ThreadPool.QueueUserWorkItem挤占资源 - 确实需要提高最小线程数（极少见），应通过
ThreadPool.SetMinThreads(200, 200)调整，而非改 PLINQ 参数
真正容易被忽略的是：PLINQ 分区策略（Partitioning）对性能影响常大于并行度本身。默认的 range partitioning 在数据处理逻辑不均一时，会导致部分线程空转、部分过载——这时换用 WithMergeOptions(ParallelMergeOptions.NotBuffered) 或手写自定义分区器，效果比调数字更明显。
