香香甜甜圈你有没有遇到过这种情况：电脑配置明明不差，跑一个老程序或者某个后台服务时却卡成幻灯片，打开任务管理器一看，CPU总占用率只有百分之二三十，但旁边一堆核心已经顶满了，剩下几颗性能最强的大核反而在那里“打盹”。这种问题在 Intel 12/13/14 代酷睿、以及部分移动端芯片普及“大小核”架构之后非常常见——系统默认调度器把任务塞给了能效核心，而性能核心却闲着。解决这个问题的核心手段，就是今天要聊的 CPU 亲和性（CPU Affinity）。
这篇文章适合谁？普通办公用户可以用它让老软件恢复流畅，开发者可以用它优化自己写的程序的运行位置，运维也可以用它压榨多核服务器的单线程性能。我会从大小核架构的底层逻辑讲起，给你 Windows 和 Linux 两边都能直接抄的实操方案，最后把我在实际踩坑中遇到的各种诡异问题也一并整理给你。
1. 大小核架构的现状：为什么大核会“闲着”
1.1 从“大小核是什么”说起
先说基础。所谓大核小核，指的是 CPU 内部有两类物理核心：高性能核心（Performance Core，简称 P-core，也就是常说的“大核”）和高能效核心（Efficient Core，简称 E-core，也就是“小核”）。大核主频高、缓存大、单线程执行能力强，适合跑游戏、编译、数据处理这类吃单核性能的负载；小核主频低、功耗低、面积小，适合挂后台、跑轻量并发任务。Intel 从 12 代酷睿开始把这套“混合架构”带进消费级市场，实测下来，能效比确实香，多核跑分也好看，但调度问题成了绕不开的坎。
AMD 那边的 Ryzen 7000/9000 系列目前没有物理大小核，纯大核设计，调度相对省心；不过 Intel 在台式机和笔记本上，P-core + E-core 已经是主流形态。这也就意味着，你在 Windows 或 Linux 上运行程序，只要稍微老一点、没有针对新调度器做优化，就很可能被系统“安排”到小核上去。
1.2 系统默认调度的“坑”在哪里
现代操作系统的调度器已经非常聪明，Windows 11 针对 Intel Hybrid 架构做了专门的调度优化：前台高频交互的程序，尽量放 P-core；后台负载，优先放 E-core；不合理的迁移会触发评分惩罚，避免线程到处乱跳。这个机制大部分时候是好的，但它有一个前提——程序得“符合现代审美”。
问题恰恰出在那些老程序身上：没有用新指令集、没有适配 Windows 11 的调度提示、或者自身线程模型比较老旧，调度器拿不到足够的特征信息，就会按“后台任务”或“通用任务”把它扔到 E-core 上去。我实测遇到的典型场景有：
- 老游戏（比如魔兽争霸、星际争霸、老牌模拟器）：帧数低，但 P 核占用率很低，E 核全程满载。
- 某些 Java 服务端程序：垃圾回收线程和业务线程全被压在小核上，明明大核有空，响应时间就是降不下来。
- 视频转码/渲染工具，比如 x265、After Effects 早期版本的某些渲染模块。
- 浏览器网页播放高码率视频时，解码线程被分配到小核，页面卡顿。
你打开任务管理器观察一下就会发现，CPU 总占用率看着很低，可实际体验很卡，锅不在 CPU 不够强，而在“强的那部分没用上”。
1.3 先泼盆冷水：这不是“CPU 占用率 100%”的通用药
动手之前必须把边界说清楚：设置 CPU 亲和性解决的是“任务分布不均”问题，不是让你强行降占用率的工具。如果你的程序本身就吃满全部核心还不满足，或者是有进程异常占用 CPU，那要排查的是代码效率、死循环、病毒木马等方向，绑核帮不了你。
换句话说，CPU 亲和性做的是一件非常精准的事：告诉操作系统“这个进程/线程，只能在指定的核心上跑”，相当于给程序限定活动范围，让它去大核干活，而不是默认被发配到小核。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 核心原理：CPU 亲和性到底做了什么
2.1 亲和性的底层模型
CPU 亲和性，英文叫 CPU Affinity，原理上就是给线程或者进程设置一个“允许运行的 CPU 集合”。操作系统在调度时，只会从这个集合里选核心，不会把任务迁移到集合之外。
实现上一般用位掩码（bitmask）来表示这个集合。比如一个 32 核 CPU，逻辑处理器编号是 0 到 31，那么：
0x000F（二进制00000000 00000000 00000000 00001111）表示只允许跑在 CPU 0/1/2/3 这四个逻辑处理器上。0xFF00（十六进制）表示二进制从第 8 位到第 15 位都为 1，也就是只允许跑在 CPU 8 到 CPU 15。
对用户来说，你不需要真的去背 bit 位计算，但要理解一件事：你填的掩码，决定了程序允许出现在哪些核心上。填错了，程序可能直接启动不了，或者绑到了更差的小核上，欲哭无泪。
2.2 判断哪几个逻辑 CPU 是“大核”
这是整个操作里最关键的步骤，没有之一。不同 CPU 的“逻辑处理器编号”和“物理核心”的对应关系并不统一，但绝大多数 Intel 混合架构桌面平台遵循一条经验规律：
- 逻辑处理器编号靠前的，先分配给大核的超线程线程。
- 大核超线程线程分配完后，再按顺序分配给小核。
举个例子：
- i5-13600K：6 个大核（12 个逻辑线程）+ 8 个小核（8 个逻辑线程），总共 20 线程。普遍情况下，CPU 0~11 是大核的 12 个逻辑线程，CPU 12~19 是小核的 8 个逻辑线程。
- i9-13900K：8 个大核（16 个逻辑线程）+ 16 个小核（16 个逻辑线程），总共 32 线程。普遍情况下，CPU 0~15 是大核的逻辑线程，CPU 16~31 是小核的逻辑线程。
- i7-12700K：8 个大核（16 个逻辑线程）+ 4 个小核（4 个逻辑线程），CPU 0~15 是大核，CPU 16~19 是小核。
但这里我必须强调，这个规律不是百分之百可靠，尤其是笔记本平台和开了特殊 BIOS 设置之后，编号顺序可能完全不同。最稳妥的确认方法其实不复杂：
- 打开任务管理器，切到“性能”页，点 CPU。
- 右键右侧的 CPU 使用率图表，选择“更改图形为” -> “逻辑处理器”。
- 你能看到所有逻辑处理器的独立占用图，每个小格子底部会标注
CPU 0、CPU 1这样的编号。 - 跑一个单线程压力测试（比如 CPU-Z 的“单核基准”，或者随便写个循环占满一个核），同时观察哪个编号的使用率顶到 100%，把那个编号记下来。
用这个方法，你可以确认你的机器上真正的大核编号区间，后面填掩码的时候就不会翻车。
2.3 两个系统都支持，只是叫法不同
Windows 和 Linux 都有成熟的 CPU 亲和性机制。Windows 上，可以用任务管理器、start /affinity 命令、PowerShell、或者代码里的 SetProcessAffinityMask / SetThreadAffinityMask 设置；Linux 上，可以用 taskset 命令、sched_setaffinity 系统调用，或者 cgroup / systemd 的方式。核心思想完全一致，只是接口不同。下面我按 Windows 和 Linux 两条线，把能落地的方案都过一遍。
3. Windows 下强制程序跑大核的四种实操方案
3.1 任务管理器图形化设置：临时查看与手动测试最方便
如果你只是临时想验证某个程序跑在大核上是不是真的变快，任务管理器是最快捷的方式。
操作步骤：
- 先启动目标程序，让它保持运行状态。
- 打开任务管理器，切到“详细信息”标签页。
- 找到对应进程，右键，选择“设置相关性”。
- 在弹窗中取消勾选小核对应的逻辑 CPU，只保留大核区间，点击确定。
这个操作会立即生效，对这个程序当前运行的所有线程都起作用。但它有一个时间窗口的问题：如果程序已经跑在小核上，你再改相关性，新设置只对未来的线程调度生效，已经跑着的线程可能不会立刻迁移过去。所以更稳的做法是：先设置相关性，再重启这个程序，让它在启动那一刻就被限制在大核范围内。
任务管理器这种方式适合偶尔用一次，不适合每次启动都手动折腾一遍，也不适合开机自启的服务。
3.2 一条命令搞定：start /affinity 是启动时锁核的最快方法
Windows 的命令提示符自带一个非常实用的参数：start /affinity。它可以在程序启动的那一刻，就给这个程序套上亲和性掩码。
语法是这样的：
cmd复制start /affinity 掩码 "程序路径"
这里的掩码用十六进制表示。如果你想让程序只跑在 CPU 0 到 CPU 7，这 8 个逻辑处理器上，掩码就是 0xFF（8 个 bit 全为 1），命令这么写：
cmd复制start /affinity FF "C:\Program Files\MyApp\myapp.exe"
注意，FF 前面不用加 0x，start 会自动把它当作十六进制解析。如果你想锁 CPU 0~15，那就是 16 个 bit 全为 1，十六进制是 FFFF：
cmd复制start /affinity FFFF "C:\Program Files\MyApp\myapp.exe"
这个方法有一个显而易见的优点：你可以在桌面上创建一个 .bat 批处理，以后双击这个批处理，程序就会以锁好大核的状态启动，不用每次手动开任务管理器。比如：
bat复制@echo off
start /affinity FF "D:\Tools\oldgame.exe"
把这段保存为 start_game.bat，下次想玩这个老游戏，直接双击它就行。实测下来，很多用户反馈老游戏用这种方式锁定大核之后，帧数稳了很多，关键是卡顿感消失了。
3.3 PowerShell 对运行中的进程临时指定亲和性
如果你要修改的程序已经在运行了，不想重启，可以用 PowerShell 的 ProcessorAffinity 属性。这是 Windows 进程对象的一个属性，直接对应系统 API SetProcessAffinityMask。
打开管理员权限的 PowerShell，先拿到进程对象，然后给 ProcessorAffinity 赋值：
powershell复制$process = Get-Process -Name notepad
$process.ProcessorAffinity = 0xFF
这里 0xFF 表示只允许跑在 CPU 0~7。赋值之后，进程的亲和性掩码就被改了。你还可以读取当前值，确认是否生效：
powershell复制(Get-Process -Name notepad).ProcessorAffinity
输出会是一个整数，比如 255（对应十六进制 0xFF），你根据这个数反推 bit 位，就能确认被允许的核心范围。
需要注意的是，ProcessorAffinity 属性设置的是进程级亲和性，进程内所有线程都会受到约束。如果你需要精确控制某个线程，那就得走代码方案，用 SetThreadAffinityMask 去指定了。
3.4 开机自启和常驻管理：批处理或者第三方工具
如果你希望每次开机，某个程序都自动锁在大核上，可以做两件事。
第一，把启动命令写进批处理，然后放进“启动”文件夹。按 Win + R，输入 shell:startup，回车，会打开启动文件夹。把 .bat 文件放进去，开机就会自动执行。适合那种“每天开机就要挂着”的程序，比如服务器软件、虚拟机、常驻后台的开发服务。
第二，用第三方工具。Personal 圈子比较常见的有个刚需工具叫 Process Lasso，免费版就够用，它能常驻后台，对指定进程持久化应用亲和性规则，还能防止程序自己把亲和性改回去。它的原理和上面的命令完全一样，只是把设置做成了图形化，并且能按进程名自动匹配新实例。如果你要管理的程序很多，或者要给别人部署机器，Process Lasso 确实省事。
这三种方式怎么选，我按照需求场景给你整理了一个对照：
| 方式 | 适用场景 | 优点 | 缺点 |
|---|---|---|---|
| 任务管理器“设置相关性” | 临时验证、一次性调试 | 操作直观，无需命令 | 进程多实例时要逐个设置，重启后失效 |
start /affinity 批处理 |
固定程序每次启动锁核 | 启动即生效，稳定可复现 | 要先算掩码，程序路径最好写绝对路径 |
PowerShell ProcessorAffinity |
对正在运行的进程动态调整 | 无需重启程序，脚本可控 | 管理员权限有时是硬性要求，不够直观 |
| Process Lasso 常驻管理 | 多程序、多实例、长期部署 | 图形化，自动匹配新进程，可持久化 | 多了一层后台服务，额外占用一点点资源 |
4. 代码级控制：让程序自己把线程钉在大核上
如果你不是普通用户，而是开发者，或者你经常要帮别人优化软件，那么光靠外部命令还不够。很多时候，你希望程序一启动，就把自己的关键线程绑定到大核，不依赖外部工具。这时候就要写代码了。
4.1 Windows 下的 C/C++ 方案：两个 API 就够
Windows 上最常用的两个 API 是 SetProcessAffinityMask 和 SetThreadAffinityMask。前者管整个进程，后者管当前线程。
进程级：
cpp复制#include <windows.h>
#include <iostream>
int main() {
// 假设逻辑处理器编号 0~7 都是大核
DWORD_PTR mask = 0xFF;
if (SetProcessAffinityMask(GetCurrentProcess(), mask)) {
std::cout << "进程亲和性设置成功，允许CPU 0~7" << std::endl;
} else {
std::cout << "设置失败，错误码: " << GetLastError() << std::endl;
}
// 业务逻辑...
return 0;
}
线程级：
cpp复制#include <windows.h>
#include <iostream>
DWORD WINAPI WorkerThread(LPVOID param) {
// 把这个线程锁到 CPU 3
DWORD_PTR mask = 1ULL << 3;
SetThreadAffinityMask(GetCurrentThread(), mask);
// 实际工作...
return 0;
}
int main() {
CreateThread(nullptr, 0, WorkerThread, nullptr, 0, nullptr);
Sleep(5000);
return 0;
}
这里有个常见的坑：SetThreadAffinityMask 只会影响当前线程，如果你的业务线程是线程池创建的，那你需要在每个工作线程的执行函数开头都调用一次，或者在创建线程时通过传入的参数去设置。另外，进程亲和性掩码必须包含线程亲和性掩码，否则线程设置会失败。也就是说，你先把进程限制在 CPU 0~7，然后再把某个线程指定到 CPU 3，这是允许的；但如果你把进程限制在 CPU 0~7，却想把线程指定到 CPU 8，设置就会返回 0，失败。
4.2 PowerShell 也能封装成管理脚本
PowerShell 除了对已有进程设置，也可以配合启动命令在启动时就传入掩码。比如：
powershell复制$psi = New-Object System.Diagnostics.ProcessStartInfo
$psi.FileName = "C:\Program Files\MyApp\myapp.exe"
$process = [System.Diagnostics.Process]::Start($psi)
$process.ProcessorAffinity = 0xFF
这种写法适合做成工具脚本，批量管理多个进程。注意，Process 类要求 ProcessorAffinity 的类型是 IntPtr，赋值时用十六进制整数是可以直接转换的，但如果你非要写变量，注意类型转换：
powershell复制$process.ProcessorAffinity = [IntPtr]0xFF
4.3 Linux 下的 taskset 和 sched_setaffinity
Linux 上的做法和 Windows 类似，不过命令行工具更好用。
启动时指定 CPU 集合：
bash复制taskset -c 0,1,2,3 ./myapp
对正在运行的进程修改：
bash复制taskset -pc 0-3 PID
查看进程当前允许的 CPU 集合：
bash复制taskset -p PID
查看进程当前实际运行在哪个 CPU 上：
bash复制ps -o pid,psr,comm -p PID
需要注意的是 psr 列输出的是“进程当前正在使用的 CPU 编号”，这个每次调度都可能变。如果你想更精确地看到线程粒度，可以用 ps -eLo pid,tid,psr,comm 过滤。
如果要在 C 程序里写死亲和性，Linux 用的是 sched_setaffinity：
c复制#define _GNU_SOURCE
#include <sched.h>
#include <stdio.h>
#include <unistd.h>
int main() {
cpu_set_t set;
CPU_ZERO(&set);
// 假设逻辑 CPU 0~7 是大核
for (int i = 0; i < 8; i++) {
CPU_SET(i, &set);
}
if (sched_setaffinity(0, sizeof(set), &set) == -1) {
perror("sched_setaffinity");
return 1;
}
// 业务逻辑...
return 0;
}
Linux 下判断哪个逻辑 CPU 是大核，一般看 lscpu -e 输出的 CORE 列。在 Intel 大小核平台上，小核的 CORE 编号会明显比大核靠后。比如 13900K 的典型输出里，大核的逻辑 CPU 0~15 对应 CORE 0~7（每核两个逻辑线程），小核逻辑 CPU 16~31 对应 CORE 8~23。但和 Windows 一样，不要盲信经验值，建议结合 lscpu -e 对照查看。
4.4 其他语言场景怎么处理
- Python：可以使用
psutil库，直接调用p.cpu_affinity([0,1,2,3])设置进程亲和性，Linux/Windows 都支持。 - C#：可以用
Process.GetCurrentProcess().ProcessorAffinity属性，和 PowerShell 类似。 - Java：JVM 本身没有直接公开设置亲和性的 API，通常做法是在启动脚本里用
taskset（Linux）或start /affinity（Windows）做外层限制，或者通过 JNA 调用系统 API。 - Go：可以用
golang.org/x/sys/windows包调用 Windows API，Linux 下用syscall.SchedSetaffinity。
我的个人建议是：能用启动命令解决的，就不要在程序里写死亲和性。因为亲和性设置和硬件拓扑强相关，写死只会让这个程序换到另一台机器上跑的时候，绑到错误的核上，反而更慢。只有在架构强相关、运行环境可控的场景（比如嵌入式设备、固定型号服务器）才值得写死。
5. 实战效果与问题排查实录
5.1 我实际测试的几个典型案例
案例一：老游戏。我手头有一个老款 PCE 模拟器，默认启动后只用了 CPU 16~19 四个小核，帧率在 45~50 浮动。用 start /affinity FFFF 把它锁到 CPU 0~15（大核逻辑线程）之后，帧率直接稳定在 60，而且加载大场景时候的瞬时卡顿明显减少。这种提升主要来源于大核更高的单核性能和更大的 L2 缓存。
案例二：视频编码。我用 x265 转一个 4K 片源，默认调度器会把大量编码线程分散到全部核心。手动把进程限制在大核逻辑线程 CPU 0~15（也就是 8 个 P-core 的逻辑线程）之后，转同一段素材的速度反而比“全部 32 线程都允许”时快了一些。原因是 x265 每个线程之间同步开销量很大，在小核上跑的一些线程拖慢了全局帧进度，宁可让大核多干活。
案例三：IDE 索引。某主流 IDE 在做项目索引时，有多个后台进程会被调度到小核。把它们绑到大核后，索引耗时确实缩短了，但注意，此时整个系统的大核空间被 IDE 占住，如果你同时干别的重活，反而会觉得整体更卡。所以要结合场景取舍，不是无脑绑核。
5.2 设置了亲和性之后反而变慢，怎么回事
这是实操里最让人憋屈的情况：明明给程序绑了大核，性能反而下降。根据我的经验，绝大多数情况下是下面几个原因：
第一，绑的“大核”其实已经被其他程序占满了。大核数量有限，比如 13600K 只有 6 个大核 12 个线程，如果你一边打游戏，一边又把视频编码锁到大核，两个程序在同一个 12 个逻辑线程里抢资源，互相拖慢。解决方法是先看每个大核的当前占用率，再决定锁哪几个编号。
第二，笔记本的功耗墙。锁大核会让大核电压电流快速飙高，如果你的笔记本散热压不住，CPU 温度一到阈值就会降频，整体性能反而被拉低。这时候小核混跑的总吞吐量可能反而更高。我见过不止一台笔记本用户锁核之后，风扇起飞、频率减半，帧数不升反降。
第三，线程迁移开销和缓存局部性。默认调度器会在核心之间动态迁移线程，争取更均衡的负载。你强行锁核之后，线程不敢乱跑，但如果这个线程原来的数据正好在另一个核的 L2/L3 里，跨核访问和缓存未命中会增加。不过对于大多数场景，这种开销比小核瓶颈小得多，所以影响有限。
第四，掩码包含超线程兄弟核心导致互相干扰。同一个物理大核的两个逻辑线程共享执行单元，你如果允许程序同时使用同一物理核的 CPU 0 和 CPU 1，两个线程会抢发射端口，可能不如一个线程独占一个核。对单线程性能敏感的程序，可以考虑一个物理核只留一个逻辑线程。
5.3 三个高频翻车现场
我以前帮人排查这类问题，见了太多次类似的错误，先写出来给你避坑：
错误一：掩码算错。想绑 CPU 0~3，结果填了 0xF0，实际绑的是 CPU 4~7，正好全是小核。验证方法是设置之后，打开任务管理器逻辑处理器视图，看程序活跃时是哪些编号的占用率上涨。
错误二：编号映射搞错。不少人是照着网上某个帖子抄的掩码，但你的 CPU 型号、BIOS 设置、笔记本平台可能完全不同。同一个 i7-13700H 在不同品牌笔记本上，逻辑编号分布可能都不一样。一定要用自己的机器实测一遍，别直接抄 13900K 的 FFFF。
错误三：忘了考虑 32 位和 64 位程序的差异。start /affinity 对绝大多数程序都有效，但有些非常老的 32 位程序在 Windows 上尝试设置超过 32 个逻辑 CPU 的掩码时可能失败，因为老的进程初始化时只支持 32 位掩码。解决方案是先用任务管理器设置相关性看看，能不能正常勾选。
5.4 怎么判断锁核真的生效
最后给你一套低成本验证流程，就几分钟搞定：
- 设置亲和性之后，重启目标程序，确保设置从启动那一刻就生效。
- 打开任务管理器，切到“性能”-> CPU，右键将图形改为“逻辑处理器”。
- 观察程序跑起来时，允许的那几个 CPU 编号占用率是否被拉起来，同时被禁止的编号是否几乎为零。
- 用 PowerShell 验证：
(Get-Process -Name 进程名).ProcessorAffinity，确认输出值和预期掩码一致。 - 如果用的是 Linux，直接
taskset -p PID，输出会列出允许的 CPU 列表。
我个人在实际操作中最深刻的体会是：别一把梭把所有程序都强绑大核。小核存在的意义是承担后台负载，为单位功耗提供更多吞吐量。你只应该针对那些“明显受单核性能影响、又被调度器乱分配”的程序做定向锁定，其他程序让系统默认调度最好。每次绑定之前都用任务管理器确认一下大核编号，设置完再观察一下占用分布，这套流程跑顺了，你会发现很多原来卡得莫名其妙的场景，其实真的就是调度问题。
最后再分享一个小技巧：锁核优化不适合“一劳永逸”。如果你换了 CPU、更新了 BIOS、或者从台式平台换到了笔记本平台，一定要重新确认一次逻辑编号映射，否则你手里的掩码可能已经不是当年的大核了。多花两分钟看下任务管理器，永远是最稳妥的习惯。