多线程环境下busy/wait与自旋模式上下文切换及线程亲和性咨询

avoiding cache misses and CPU’s context switching（避免缓存未命中与CPU上下文切换）

1. 同核部署生产者/消费者线程时，自旋（busy wait/spinning）模式规避上下文切换的逻辑 #

首先纠正一个常见认知偏差：自旋模式从来不是要完全消除核心上的控制权转移，而是彻底干掉操作系统调度器主导的、伴随线程换出/换入的重型上下文切换开销。

先讲清楚常规阻塞等待的问题在哪：
如果用互斥锁、条件变量的阻塞等待接口，线程拿不到处理资源的时候会主动触发系统调用让出CPU时间片，内核会把当前线程的寄存器状态、栈信息从核心硬件刷到内存，把线程标记为睡眠态，再调度其他待运行线程占核心。等资源就绪时，内核再靠中断把之前睡眠的线程重新切回核心——这个过程的固定开销就在1~10微秒级别，还不算缓存冷启动的额外成本，切换时机完全由内核调度器决定，延迟不可控，完全达不到高频交易要求的纳秒级稳定延迟标准。

再讲自旋模式的实际运行逻辑，以及为什么不会产生重型上下文切换：

• 自旋等待的核心是，线程等资源的时候根本不调用任何会触发内核调度的系统调用，就在核心上跑紧凑的空循环（比如反复读取无锁队列的读写索引标记位），全程保持TASK_RUNNING状态。只要给线程配置了SCHED_FIFO最高实时优先级、核心提前做了隔离（把无关系统进程、后台任务从该核心挪走），内核调度器不会主动打断正在运行的线程，线程会一直占着核心，根本不会被换出，自然不存在线程级上下文切换的开销。
• 你担心的「同核两个线程互相切换」是错误实现才会出现的问题：高频交易场景下核心是极度稀缺的低延迟资源，从来不会把两个对等的、需要持续运行的线程绑在同一个核心上自旋抢资源。同核部署生产者/消费者的标准玩法是：一个核心只留一个长期驻留的主逻辑线程（比如交易决策、订单发送线程）占核自旋，另一个配套线程要么是中断上下文里跑的轻量逻辑（比如网卡收包软中断、本地时钟更新逻辑），要么是只有主逻辑主动让出极短时间窗口（比如批量写完发送队列）时才会短暂运行的辅助线程，全程主逻辑线程不会被内核强制换出，不会产生上下文切换的重型开销。
• 单核心同一时刻本来就只能跑一个执行流，自旋模式下两个执行流的交接是靠共享内存标记位做用户态协作式交接，根本不走内核调度的逻辑，控制权转移的开销只有几十纳秒级别，和内核级上下文切换差了两个数量级。

2. 未设置线程亲和性（绑核）的实际后果 #

在低延迟高频交易场景下，不做线程绑核会直接导致延迟稳定性崩盘，具体影响包括：

• 缓存大规模失效：内核调度器可能因为负载均衡逻辑，把正在运行的低延迟线程从当前核心调度到其他核心，原核心L1/L2缓存里存的热点数据、线程栈、无锁队列内容全部无法访问，线程到新核心后需要重新从内存加载数据，单次缓存冷启动的开销就在几百纳秒到几微秒，跨NUMA节点调度的话开销还要翻3~5倍。
• 不可控的抢占与切换：如果不把线程固定到隔离核心，内核可能把你的低延迟线程和操作系统后台任务、日志进程、其他业务线程挤在同一个核心上，你的线程随时可能被更高优先级的系统任务抢占，甚至被切出核心几十毫秒才被重新调度，尾延迟完全不可控。
• 跨NUMA访问开销：如果线程被调度到和它所访问的内存所属NUMA节点不同的核心，所有内存访问都要走跨NUMA互联总线，访问延迟直接翻倍，可用带宽砍半，对于依赖内存极速访问的交易逻辑来说是致命问题。
• 无意义的调度开销：内核调度器会持续在多核心之间做负载均衡计算，反复迁移线程的过程本身就会带来额外的系统开销，进一步拉长延迟。

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