Exchanger 仅协调两线程交换数据，不控制线程绑定；亲和性需在工作线程启动后、调用 exchange() 前，通过 JNA（Java）或 pthread_setaffinity_np（C++）绑定至非超线程对位的物理核，并校验 NUMA 节点一致性与调度稳定性。
核心思路是：Exchanger 本身不控制线程绑定，它只负责协调两个线程在同步点交换数据；真正需要亲和性控制的是执行 exchange() 的那两个工作线程——必须在它们启动后、进入计算主循环前，就将其分别固定到独占的物理核心上，避免因调度漂移导致缓存失效、延迟抖动，进而拖慢交换节奏。
明确 Exchanger 线程与亲和性的责任边界
Exchanger 是协作原语，不是调度器。它不创建线程、不管理线程生命周期，也不干预 CPU 分配。所谓“Exchanger 线程上下文漂移”，本质是调用 exchange() 的两个 Java 线程（或 C++ worker）被 OS 调度器迁移到不同物理核上运行，造成：
- L1/L2 缓存频繁失效，中间数组/累加变量重载变慢
- 跨核通信引入总线争用，exchange() 配对等待时间不稳定
- 在 NUMA 多插槽系统中，若线程与内存不在同一节点，延迟翻倍
Java 侧：在 Thread 启动后立即绑定物理核（需 JNI 或 JNA 辅助）
Java 标准库无直接 setAffinity 接口，但可通过以下方式落地：
- 使用 JNA 调用 Linux sched_setaffinity：在 new Thread(Runnable) 启动后、首次调用 exchange() 前，从 Runnable 内部执行绑定
- 关键代码节选（JNA 封装）：注意必须在目标线程上下文中调用，不能由主线程代劳
- 为两个 Exchanger 参与线程分配**非超线程对位的物理核**，例如：线程 A → CPU 0，线程 B → CPU 2（跳过 CPU 1，避免共享执行单元）
- 若运行在容器中，确认 cgroups v1/v2 未限制 cpuset，否则 sched_setaffinity 会失败
C++ 侧：在线程池 worker_loop 开头强绑定，与 Java 线程配对对齐
当 Java 线程通过 JNI 调用 C++ 计算模块（如矩阵归约、SIMD 扫描），且该模块也参与 Exchanger 协作流程时：
立即学习“Java免费学习笔记（深入）”；
- 在 C++ worker 线程函数首行调用 pthread_setaffinity_np，绑定至与 Java 线程对应的物理核（如 CPU 4）
- 确保 Java 和 C++ 两端的物理核编号空间一致（通过 lscpu /sys/devices/system/cpu/topology/ 验证）
- 禁用该物理核上的非关键中断（如 via kernel boot param isolcpus=4），减少干扰
- 若使用 C++26，可统一用 std::this_thread::set_affinity({4})，更简洁安全
混合场景下的协同校验与防错
Java + C++ 共同构成一个双阶段计算流水线（如 Java 做任务分发 + C++ 做密集计算），Exchanger 在两者间交换中间结果。此时需：
- 用 perf record -e sched:sched_migrate_task 检查两线程是否真正在目标核上稳定运行
- 在 exchange() 前后插入 rdtscp 指令（C++）或 Unsafe.getLong(0)（Java，触发轻量屏障），观测时间戳差值是否收敛
- 避免将 Exchanger 实例本身放在堆外内存或跨 NUMA 分配——它虽小，但高频访问，应与线程同节点
- 若某端异常退出，另一端 exchange() 会永久阻塞，务必配合超时重载 exchange(v, timeout, unit)
