Parallel类迭代执行时线程上下文切换相关技术疑问

我想理解线程上下文切换对Parallel.For/ForEach迭代过程的影响。我启动了多个高优先级进程把CPU占满到100%，但没观察到Parallel迭代里的Thread.CurrentThread.ManagedThreadId有变化。

操作及代码说明 #

• 模拟高CPU占用：启动多个高优先级进程，包含参考示例程序
• 待观察线程切换的代码：

Parallel.For(0, 3, (index, i) =>
{
    var firstId = Thread.CurrentThread.ManagedThreadId;
    while (true)
    {
        var rnd = new Random(index);
        checkIds(firstId, Thread.CurrentThread.ManagedThreadId);
        var digits = new List<int>();
        for (int j = 0; j < 10000; j++)
        {
            digits.Add(rnd.Next());
            if (continueWriteLine)
                Console.WriteLine($"ID: = {Thread.CurrentThread.ManagedThreadId}");
        }

        if (continueWriteLine)
            digits.ForEach(Console.WriteLine);
    }
});

• 检测线程切换的代码片段：

if (firstId != currentId)
{
    continueWriteLine = false;
    Thread.Sleep(1000);
    Console.WriteLine($"{firstId} - {currentId}");
}

技术疑问 #

1. 在Parallel类的迭代执行过程中，是否会因Thread.Sleep、lock语句、Mutex等原因发生线程切换？
2. 若确实发生线程切换，会对ManagedThreadId属性产生何种影响？
3. 将ManagedThreadId作为ConcurrentDictionary的唯一键，用于存储当前操作（如文件读取的当前行、目标读取对象、已读取对象等上下文信息）是否安全？

补充说明：考虑用第三种方案是因为不想在文件读取处理的各方法间传递大量上下文数据；也考虑过传递一个包含所有上下文的FileProcessingInfo对象，但不确定哪种更优。

解答 #

1. Parallel迭代中是否会因Sleep/lock/Mutex发生线程切换？ #

会。Parallel类基于.NET的线程池实现，线程池线程在遇到阻塞操作（比如Thread.Sleep、等待lock持有的锁、等待Mutex）时，操作系统会触发线程上下文切换：当前线程被挂起，调度器会选择其他就绪线程执行。

你之前CPU占满没观察到切换，是因为你的Parallel迭代逻辑是纯CPU密集型的，线程一直在执行计算，没有触发阻塞，所以调度器不会主动切换（或者切换后仍回到同一个线程执行迭代，因为线程池会尽量复用线程处理同一个迭代任务）。

2. 线程切换对ManagedThreadId的影响 #

ManagedThreadId是CLR分配给托管线程的唯一标识，同一个托管线程的ID不会改变。但如果你的迭代任务被线程池调度到另一个托管线程上执行（比如原线程被长期阻塞，线程池分配新线程接管任务），那此时Thread.CurrentThread.ManagedThreadId会变成新线程的ID。

注意：线程上下文切换分两种：

• 操作系统级的上下文切换：同一个托管线程在不同CPU核心间切换，此时ManagedThreadId不变；
• 线程池任务调度切换：迭代任务从一个托管线程转移到另一个托管线程执行，此时ManagedThreadId会变化。

3. 用ManagedThreadId作为ConcurrentDictionary的键是否安全？ #

不安全，原因有两点：

• 线程池会复用线程：一个线程执行完你的迭代任务后，可能被线程池分配给其他任务（甚至是其他Parallel迭代的任务），此时同一个ManagedThreadId会对应完全不同的上下文，导致数据混乱；
• 迭代任务可能被转移到其他线程：如前文所说，阻塞后任务可能被调度到新线程，此时原线程ID对应的上下文会和当前任务不匹配。

方案对比：ThreadLocal vs 传递上下文对象 #

• 传递FileProcessingInfo对象：这是更可靠的方案。上下文数据和任务强绑定，不会因为线程复用或调度出现混乱，代码可读性和可维护性也更高，适合大多数场景；
• 如果确实不想传递对象，可以用ThreadLocal<T>存储上下文，但要注意：在任务结束时必须清理ThreadLocal的数据，避免线程复用时残留旧数据，且仅适用于任务和线程绑定的场景（但Parallel的任务不一定和线程绑定）。

内容的提问来源于stack exchange，提问作者KKomrade