如何用 ProcessThread.ProcessorAffinity
设置线程亲和性
在 C# 中，.NET 并不直接暴露“为任意托管线程设置 CPU 亲和性”的 API，但可以通过
System.Diagnostics.ProcessThread对当前进程的**原生线程句柄**进行绑定。关键限制是：只能对已启动的线程（如主线程、
ThreadPool外显式创建的
Thread）操作，且必须在该线程进入长时间运行前设置。
实操要点：
ProcessorAffinity是一个
IntPtr类型的位掩码，每一位代表一个逻辑 CPU 核心（从最低位开始，bit 0 = CPU 0，bit 1 = CPU 1……） 需先调用
thread.GetNativeHandle()获取句柄，再通过
Process.Threads查找对应
ProcessThread必须以管理员权限运行，否则会抛出
AccessViolationException或静默失败 不适用于
Task或
async/await启动的逻辑——它们可能被调度到任意线程池线程上，且生命周期不可控
var t = new Thread(() =>
{
// 长时间计算任务
while (true) { /* ... */ }
});
t.Start();
<p>// 等待线程启动后，再设亲和性
System.Threading.Thread.Sleep(10);
var proc = System.Diagnostics.Process.GetCurrentProcess();
var pt = proc.Threads.Cast<System.Diagnostics.ProcessThread>()
.FirstOrDefault(x => x.Id == t.ManagedThreadId);
if (pt != null)
{
pt.ProcessorAffinity = (IntPtr)0x01; // 绑定到 CPU 0
}为什么 Thread.BeginThreadAffinity()
不是设置亲和性的方法
Thread.BeginThreadAffinity()和
EndThreadAffinity()是 .NET Framework 时代为 COM 互操作设计的辅助机制，与操作系统级 CPU 绑定完全无关。它只影响 CLR 内部的线程调度偏好（例如避免跨 STA 切换），不会修改
SetThreadAffinityMask系统调用行为。
常见误解场景：
调用了BeginThreadAffinity()就以为线程“锁死”在某个核上 → 实际毫无效果 在
async方法中调用它 → 编译器警告 CS4014，且后续 await 可能跳转到其他线程，亲和性上下文丢失 误以为它能替代
ProcessorAffinity设置 → 它甚至不接受任何 CPU 掩码参数
设置亲和性后的真实影响：缓存、中断与 NUMA
强制绑定线程到固定核心，主要影响三方面：
L1/L2 缓存局部性：反复在同核执行可提升指令与数据缓存命中率，对高频小循环敏感；但若该核被其他高优先级进程抢占，反而更差 中断干扰：Windows 默认将硬件中断（如网卡、磁盘）分散到多个核，若业务线程和中断服务例程（ISR）挤在同一核，会导致延迟毛刺 NUMA 节点内存访问：多路服务器中，跨 NUMA 节点访问内存延迟高；仅靠亲和性无法控制内存分配位置，还需配合VirtualAllocExNuma或
SetThreadIdealProcessor（已过时）等手段
典型副作用：
系统整体吞吐下降：尤其当负载不均衡时，其他空闲核无法分担压力ThreadPool行为异常：线程池会尝试复用被锁定的线程，导致队列堆积或虚假饥饿 调试困难：性能分析器（如 dotTrace、PerfView）显示的线程迁移路径断裂，掩盖真实瓶颈
什么情况下真该用亲和性？
绝大多数 C# 应用不需要手动设置亲和性。真正适用的场景极少，且通常伴随底层协作：
实时音频/视频处理：要求确定性延迟（sub-millisecond），且已隔离出专用 CPU 核（通过 Windows 的Start-Process -Affinity或组策略禁用其他服务） 与硬实时设备驱动协同：驱动要求回调必须在指定核执行，否则 DMA 同步失败 HPC 计算密集型内核（如自定义矩阵乘法）：已用
unsafe+ SIMD 优化，且确认跨核迁移是主要开销来源
容易被忽略的一点：设置亲和性后，你同时承担了 CPU 资源编排责任——包括预留核心、屏蔽中断、约束进程内存节点、监控热节流。这些远超 C# 代码本身，需要系统级配置配合。
