简介：Windows刷CPU使用率工具是一款面向开发者、系统管理员与硬件爱好者的轻量级压力测试小工具，针对Windows平台设计，通过浏览器即可按需设定CPU占用比例与持续时间，模拟高负载运行场景，适用于性能调优、稳定性验证与散热能力检验。整个资源包仅34KB，内含2个文件：一个负责交互的HTML操作页面和一个基于jQuery的JS脚本；无需安装、无需命令行，解压后浏览器打开即可使用，操作门槛极低。目前已有716人学习/下载，在同类小工具中属于轻量又好用的方案。借助它，读者可以快速模拟系统在不同CPU负载下的真实表现，辅助排查因高占用引发的卡顿、延迟或散热问题，为代码优化和硬件评估提供直观数据；测试完成后关闭页面即自动停止模拟，不会残留后台进程。需要注意的是，长时间保持高占用可能导致设备过热，建议在散热条件良好的环境中使用，并避开重要任务时段。 想必不少人都遇到过这种需求：远程上去一台Windows机器，发现CPU使用率像心电图一样乱跳，想让任务管理器里的那根曲线稳定在某个数值；或者做性能演示、压测前想先制造一个可控的高负载环境；又或者临时需要让低负载机器“看起来在干活”。于是“Windows刷CPU使用率工具”这种小玩意就成了桌面运维和测试人员手里的常备物件。说白了，这类工具的本质就是一套人为制造CPU负载并精确控制其大小的桌面程序，做起来不难，但要在“能跑”和“跑得像样”之间拉开差距，里面的门道其实不少。这篇文章就从原理到实现，把我这些年折腾这类工具的经验完整摊开讲一遍。
1. 使用率那根跳动曲线，背后其实是个“算账”过程
先搞清楚一件事：任务管理器里的CPU使用率，不是“测”出来的，是“算”出来的。Windows的每个逻辑处理器上都挂着一个优先级最低的Idle线程，系统空闲时就跑它。当一个程序需要CPU时，调度器就会把时间片分给对应线程，挤掉Idle线程的时间片。
Windows内核靠时钟中断来推进调度，每个时钟周期都会累计当前这段CPU时间到底是花在系统线程上还是Idle线程上。任务管理器这类工具则通过查询内核累计的时间计数来推算使用率。具体到代码上，通常是调用GetSystemTimes这个API，拿到空闲时间、内核时间、用户时间三组64位计数，然后隔一小段时间再采一次，用两次采样值的差值计算周期内的忙碌占比。
公式长这样：
总时间 = kernelTime + userTime 忙碌时间 = 总时间 - idleTime CPU使用率 = 忙碌时间 / 总时间 × 100%这里有个非常容易踩的坑：kernelTime本身已经包含了idleTime，所以千万别再用idle除以kernel，那样算出来永远是错误的。kernelTime是内核态累计时间，userTime是用户态累计时间，只有把两者加起来才是真正的时间总量。
搞懂这个机制之后，“刷CPU使用率”这个概念就变成了一道很清晰的题目：只要想办法给某个逻辑处理器制造一段忙碌时间，再让它休息一段时间，两者比例合适，任务管理器看到的曲线就能稳定在你想要的数值附近。这和快递站统计一天里真正在搬货的时间占比是一个道理——只要你知道一天总时长，再知道休息了多久，忙碌率就算出来了。
所以从本质上说，刷使用率工具的底层操作就两个：让线程忙等一段精确时间，然后睡眠一段精确时间。核心逻辑简单，但实际落地时牵扯到多核调度、睡眠精度、采样周期等问题，这就引出了不同实现路线之间的取舍。
2. 三种“刷”法的本质差别：脚本空转、压测工具、自绘程序
搜索框里输入“Windows刷CPU使用率工具”，你能找到的无非三大类方案。把它们的差别理清楚，才知道哪种适合自己，也才能判断别人写的工具到底靠不靠谱。
2.1 脚本空转法：最快，但只能“凑合”
最简单的方法，开几个命令行窗口跑死循环，一个cmd窗口就能占满一个逻辑核心。PowerShell写法是这样：
Start-Process -FilePath "powershell" -ArgumentList "-NoExit -Command while($true){}"批处理也可以，原理都一样，只是借一个大循环把线程钉在CPU上。实测下来，开N个窗口就烧N个逻辑核心，肉眼能看到任务管理器的使用率冲上去，但问题也很明显：无法精确控制到比如37%这种数值，只能满核运转；窗口开多了桌面会很乱，而且这些进程很容易被用户手滑关掉。临时演示五分钟，脚本空转法够用；但凡要点“表演效果”，它就翻车。
2.2 现成压测工具法：真实有力，但控制不了幅度
Prime95、HeavyLoad、AIDA64这类压力测试软件，设计目标是把CPU榨干，用来验证散热或者稳定性。跑起来之后确实能让使用率顶到100%，也能通过限制线程数来降低占用，但它们的思维模型是“压测”，不是“设定一个目标使用率”。想在界面上输入“70%”让它稳定停在70%，基本做不到，因为这类工具根本不关心百分比控制。如果你只是为了快速让机器满载看散热或稳定性，它们是首选。
2.3 自绘程序法：要什么效果自己说了算
既想要指定百分比，又想要多核独立控制，还想要实时读取当前使用率并画一条曲线，脚本和压测工具都给不了，那就只能自己写。一个大约几百行的C#小程序就能做到：每个逻辑核心跑一个工作线程，根据目标百分比动态调整忙等和睡眠的时间比；界面用滑块或数字框设定目标值，再用GetSystemTimes读取系统实时使用率回传到界面。
三种方案的差异用一张表就能说清：
| 方案 | 是否能指定百分比 | 多核控制粒度 | 实时读取系统使用率 | 睡眠和忙等精度 | 适合场景 |
|---|---|---|---|---|---|
| 脚本空转 | 不可控 | 一个窗口一个核 | 无 | 极差 | 临时撑起负载 |
| 压测工具 | 不可控，基本满核 | 线程数可调 | 无 | 不关心 | 散热/稳定性验证 |
| 自绘程序 | 可控 | 按逻辑核心独立开关 | 有 | 较好 | 演示、复现故障、精确负载模拟 |
我第一次写这类工具就是因为脚本法出了洋相：想给一个测试环境刷到30%负载观察现象，结果开了几个窗口后忘了关，过了半小时整台机器风扇狂转，还被旁边的同事提醒“你在挖什么矿”。所以从那以后，只要有超过五分钟的使用需求，我都是直接掏出自绘的程序，宁可花半小时把参数调好，也别事后收拾烂摊子。
3. 自绘一个轻量CPU使用率工具：核心代码与实现逻辑
下面是我在Visual Studio里用C#写WinForms程序来做这个工具的一套完整思路，整个项目大概也就七八百行，核心就三块：工作线程、系统使用率读取、UI控制。
3.1 工作线程：忙等和睡眠的精确配比
每个逻辑核心对应一个独立工作线程。线程的循环逻辑很简单：忙等一小段时间，再睡眠一小段时间。目标使用率定在50%时，忙等和睡眠各占一半时间周期即可。
private static void CpuWorker(object? state) { var token = (CancellationToken)state!; var sw = new Stopwatch(); int periodMs = 100; while (!token.IsCancellationRequested) { int busyMs = periodMs * TargetPercent / 100; int idleMs = periodMs - busyMs; sw.Restart(); while (sw.ElapsedMilliseconds < busyMs) { // 忙等，把CPU时间片占住 } if (idleMs > 0) { Thread.Sleep(idleMs); } else { Thread.Yield(); } } }这里TargetPercent是一个程序中对外暴露的属性，我一般用volatile int保存，这样修改目标值时，线程在下一次循环就能读到新值，不用加锁。
有几个细节必须注意。首先，周期不要小于100ms，是因为Windows下Thread.Sleep的默认定时精度是15.625ms左右，你要是把周期设成20ms，忙等和睡眠的时间片会被定时器粒度打碎，实际使用率横跳得厉害。100ms周期下，想看波动曲线也有足够分辨率。
其次，使用率为0时要直接睡眠整个周期，使用率为100%时不要Sleep，而是用Thread.Yield把时间片让给同优先级的其他线程，否则调度器可能因为你把核心跑满导致其他线程饿死。
3.2 读取系统实时使用率：GitHub上能看到的最常见方案
前面说了，任务管理器画的曲线是基于两次采样的差值。工具自身也要做同样的事情，才能一边刷负载一边验证结果。我采用的是直接P/Invoke调用GetSystemTimes，它比PerformanceCounter方案轻量得多，后者每次计数还会拖出一个后台进程，得不偿失。
[StructLayout(LayoutKind.Sequential)] private struct FILETIME { public uint DateTimeLow; public uint DateTimeHigh; } [DllImport("kernel32.dll")] private static extern bool GetSystemTimes(out FILETIME idleTime, out FILETIME kernelTime, out FILETIME userTime); private static double GetCpuUsage() { GetSystemTimes(out var idle1, out var kernel1, out var user1); Thread.Sleep(500); GetSystemTimes(out var idle2, out var kernel2, out var user2); ulong idleDelta = ToUInt64(idle2) - ToUInt64(idle1); ulong kernelDelta = ToUInt64(kernel2) - ToUInt64(kernel1); ulong userDelta = ToUInt64(user2) - ToUInt64(user1); ulong totalDelta = kernelDelta + userDelta; if (totalDelta == 0) { return 0; } return (double)(totalDelta - idleDelta) / totalDelta * 100.0; } private static ulong ToUInt64(FILETIME ft) { return ((ulong)ft.DateTimeHigh << 32) | ft.DateTimeLow; }GetSystemTimes采样间隔我固定为500ms，这个值兼顾了响应速度和精度。任务管理器默认的“总使用率”视图大约有2秒的平滑窗口，所以本工具的瞬时读数比任务管理器曲线跳得更灵敏，这属于正常现象，不是程序算错。
3.3 UI部分：数据回显和波形绘制
界面布局不复杂：顶部放一个NumericUpDown输入目标百分比，一个CheckBox控制“按核独立开关”，一个按钮启动/停止。下面用一个PictureBox绘制最近30秒的使用率折线。
自己在PictureBox的Paint事件里画线就行，不需要引入体积庞大的Chart控件：
private void pictureBox_Paint(object sender, PaintEventArgs e) { var g = e.Graphics; g.SmoothingMode = System.Drawing.Drawing2D.SmoothingMode.AntiAlias; g.Clear(Color.White); for (int i = 1; i < _history.Count; i++) { int x1 = (i - 1) * (pictureBox.Width / HistoryCapacity); int x2 = i * (pictureBox.Width / HistoryCapacity); int y1 = pictureBox.Height - (int)(_history[i - 1] / 100f * pictureBox.Height); int y2 = pictureBox.Height - (int)(_history[i] / 100f * pictureBox.Height); g.DrawLine(Pens.SteelBlue, x1, y1, x2, y2); } }_history是一个固定容量的队列，每次定时器触发时读取一次GetCpuUsage并压入队列，再调用Invalidate触发重绘。这样一个完整的工具就跑起来了。发布时用单文件模式打包成exe，拷到任何机器上双击就能用：
dotnet publish -c Release -r win-x64 -p:PublishSingleFile=true --self-contained true4. 实测中反复出现的细节问题：毛刺、超线程、采样偏差
工具写出来之后，你会发现“能跑”和“跑得像样”之间差着好多次实测调参。这些细节我在多个版本的迭代里逐一踩过，这里集中复盘。
4.1 曲线为什么会有毛刺
设定70%的目标，任务管理器里曲线却经常在60%到80%之间抖，这不是代码算错，而是Windows的调度和采样特性决定的。Thread.Sleep并不能保证精确睡眠到指定毫秒数，默认定时器粒度的存在让每次睡眠都可能多了十几毫秒；再加上系统里其他后台进程（杀毒、索引、系统更新）随时会插入CPU时间片，两条因素叠加，曲线自然会有波动。
实测一组数据供参考：
| 目标使用率 | 实测范围（1分钟内） | 曲线稳定性 |
|---|---|---|
| 30% | 25% ~ 36% | 抖动较明显 |
| 50% | 46% ~ 55% | 可接受 |
| 75% | 70% ~ 80% | 较稳定 |
| 100% | 97% ~ 100% | 最稳定 |
如果一定要让波动更小，可以引入动态校准：每隔几秒根据实际读数反向微调busy和idle的比例，形成一个负反馈。但绝大多数场景下没必要，任务管理器那根曲线本来就是平滑过的，读者看起来差不多就足够。
4.2 超线程环境下的“核数幻觉”
Environment.ProcessorCount拿到的是逻辑处理器数量，在有超线程的机器上，表现为物理核心数的两倍。这时如果你按逻辑核心数开8个线程刷100%，任务管理器显示8个核心全部满载——但物理上只有4个计算单元在被压榨。
更隐蔽的问题是线程迁移。默认情况下Windows调度器会把线程在各个核心之间搬来搬去，导致曲线毛刺加剧。要想钉住某个核心，可以用ProcessThread.ProcessorAffinity设置亲和性：
var process = Process.GetCurrentProcess(); var affinity = 1L << coreIndex; foreach (ProcessThread thread in process.Threads) { if (thread.Id == workerThreadId) { thread.ProcessorAffinity = (IntPtr)affinity; } }注意别对整个进程设置亲和性，否则UI线程也会被钉在一个核心上，窗口拖拽都会卡顿。正确做法是拿到工作线程的Id，只给对应的ProcessThread设置。
4.3 工具读数和任务管理器对不上
这是最容易让人怀疑程序写错的问题。实际原因有三层：一是任务管理器默认视图有平滑处理，曲线会滞后；二是任务管理器里看到的百分比是基于最近的采样窗口，而本工具为了反应快，采样间隔短，自然跳得更勤；三是Windows任务管理器在“性能”页签里按逻辑处理器分成好几个小图，每个小图各自独立采样，与全系统汇总值之间存在时间差。
遇到对比差异时，我的判断标准是：看30秒内的平均值，而不是某一瞬间的最大偏差。平均值在目标值上下5个百分点以内，这个工具就是合格的。
4.4 虚拟机和笔记本上的特殊表现
在VMware或Hyper-V虚拟机里刷使用率，经常出现想刷100%却只有80%多的情况。原因是虚拟CPU的时间片还要经过宿主机调度，客户机看到的“忙碌”不一定能完整映射为物理CPU的忙碌。这属于虚拟化层的正常损耗，不是工具缺陷。
笔记本则要留意节能策略。插入电源和拔掉电源时，Windows会切换电源计划，CPU频率会动态变化，同样的忙等和睡眠比例在高频率下产生的使用率会偏高。我实测遇到过同一目标值在插电和电池状态下相差近10个百分点的情况。所以给笔记本演示时，先固定电源计划再刷使用率，否则曲线会漂移。
5. 能刷百分比不等于能压测：使用边界和几个隐蔽坑
最后必须泼一盆冷水：这类工具适合制造“看起来像那么回事”的使用率，但它和真正的性能压测完全是两码事。
忙等待循环不访问内存、不产生磁盘I/O、不涉及系统调用，它只是把CPU的整数运算流水线跑起来而已。这种负载模式下，CPU的浮点单元、缓存、内存控制器基本都是空闲的，功耗和发热远低于跑Prime95或视频转码。所以千万别拿这种工具做散热验证，否则你会得出“散热系统完全没问题”的错误结论。我见过有人用这类工具刷出100%使用率就以为完成了压力测试，结果一跑真实应用就过热降频，这就是工具选错场景的典型教训。
再提醒几个容易被忽略的坑：
- 杀毒软件可能报毒。程序频繁创建线程、持续烧CPU的特征，容易触发行为检测。解决方法是给exe签名，或者提交给主流杀软厂家做误报申诉，自己写的小工具被报毒是可以解决的。
- 别用刷CPU的方式去防止远程桌面掉线。正确做法是调用SetThreadExecutionState声明系统需要保持唤醒，而不是让CPU白白烧电。用CPU空转保活不仅风扇噪音大，还会让云服务器产生不必要的资源账单。
- 退出逻辑要做得干净。工作线程必须响应取消信号，否则点关闭按钮后进程还在后台跑，界面关了风扇还在狂转。我习惯用CancellationTokenSource统一管理，收到关闭事件时先取消再等待线程结束，最后再真正退出进程。
这套工具我目前仍然会在两种场合拿出来用：一种是压测前需要把系统负载撑到一个指定水平，观察业务程序在这个负载下的表现；另一种是给别人演示远程桌面或系统调优效果时，制造一个可预期的使用率波形。它很有用，但你得清楚它到底能做什么、不能做什么。回到本质，它只是一个精确控制忙等和睡眠比例的小程序，理解了任务管理器那根曲线的算法逻辑，这个工具就不再神秘，你完全可以按自己的需求去调整它的行为。
本文还有配套的精品资源，点击获取
