核心思路是让关键工作线程长期驻留同一物理CPU核心以避免调度迁移带来的缓存失效、TLB刷新、JIT退化等开销；Java用ThreadAffinity库绑定，C++用POSIX或C++26接口绑定，需确保物理核ID准确、JNI调用时主动继承亲和性、共享内存NUMA本地化，并通过taskset、perf、JVM编译日志验证生效。
核心思路是：让每个关键工作线程长期驻留在同一个物理CPU核心上，避免操作系统调度器将其迁移到其他核，从而消除因迁移引发的L1/L2缓存失效、TLB刷新、JIT优化退化、伪共享加剧等隐性开销。
Java侧：用ThreadAffinity库强制绑定到物理核
Java本身不提供标准API设置亲和性，需依赖Java-Thread-Affinity这类轻量级封装库。它通过JNI调用Linux的sched_setaffinity或Windows的SetThreadAffinityMask，实现跨平台绑定。
- 初始化时隔离专用核心（如用
isolcpus=内核参数或systemd-cpuset），避免被其他进程干扰 - 为每个计算线程分配唯一物理核ID（注意区分逻辑核与超线程核，优先选物理核0、2、4…）
- 在线程启动前调用
AffinityLock.acquireLock(physicalCoreId)，并确保try-finally释放 - 禁用JVM的
-XX:+UseContainerSupport（若在容器中）防止cgroup干扰亲和性生效
C++侧：用POSIX或C++26原生接口绑定
对C++线程，推荐两种方式：
-
POSIX兼容写法（当前最稳定）：在
pthread_create前用pthread_attr_setaffinity_np设置属性；或在线程函数开头调用pthread_setaffinity_np(pthread_self(), ...) -
C++26草案接口（面向未来）：使用
std::this_thread::set_affinity({core_id})，底层自动适配Linux/Windows/macOS系统调用，无需条件编译
关键细节：传入的核心ID必须是物理拓扑ID，不是/proc/cpuinfo中顺序排列的逻辑ID。建议用hwloc库获取物理核映射，避免超线程兄弟核误配。
JavaStoryDevelop
下载
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
立即学习“Java免费学习笔记（深入）”；
混合调用时的协同要点
当Java线程调用JNI进入C++计算函数时，亲和性不会自动继承——C++线程默认由OS调度，可能跳到别的核。
- JNI入口函数第一行应主动调用C++绑定逻辑（如
bind_thread_to_core(get_physical_core_id())） - 避免在Java层频繁创建/销毁JNI线程；改用线程池+固定绑定，使每个JNI worker长期绑定同一核
- 若使用
java.util.concurrent.ForkJoinPool，需配合ForkJoinWorkerThread子类重写onStart()，注入亲和性设置 - 所有共享内存（如DirectByteBuffer）应分配在对应NUMA节点上，用
numactl --membind或mbind()确保本地性
验证是否真正生效
不能只看代码写了绑定，要实测确认：
- Linux下用
taskset -p <pid>查进程默认掩码，用ps -o pid,psr,comm -T -p <pid>看各线程实际运行核（psr列） - 用
perf stat -e cycles,instructions,cache-misses,tlb-load-misses对比绑定前后指标：cache-misses应下降30%+，cycles/instruction更稳定 - Java中开启
-XX:+PrintCompilation，观察热点方法是否持续以C2编译版本执行（而非反复退回到C1或解释模式）
