Windows CPU占用率可控负载工具：从死循环到C#多线程压测

简介：Windows刷CPU使用率工具通过浏览器即可模拟指定CPU负载，面向系统管理员、开发者和硬件爱好者，用于压力测试、性能评估与系统稳定性验证。资源包内含2个文件，分别为页面文件与jQuery脚本，整体仅34KB，无需安装复杂环境，打开HTML即可使用，并可自定义CPU占用百分比与持续时长，测试完成后关闭页面自动恢复，避免长期高负载影响日常操作。已有718人学习下载。该工具虽小，但针对CPU占用模拟场景提供了即开即用的完整实现，读者既能快速上手进行压力测试，也可基于HTML与JS代码理解CPU负载模拟原理，自行调整参数或扩展出更复杂的性能测试脚本，适用于日常调试、装机验收、教学演示及硬件散热评估等场景。

1. Windows 刷 CPU 使用率工具：一个可控的负载发生器

工具名听着玩闹，实际干的是正经活：在 Windows 上制造可控的 CPU 高负载，让散热压测、降压稳定性、虚拟机调度和脚本性能评估都有统一的压力来源。适合三类人：装机后想验证散热和降频曲线的 DIY 用户，模拟业务高峰的运维，以及想确认自己多线程程序到底吃满几个核心的开发者。先把一个反直觉的结论放在这：占用率不是“刷”出来的，是忙等待时长与睡眠时长的比值算出来的；同一份负载工具，在物理机、笔记本和虚拟机里的读数可以差三倍，而这些差异不解决，后面所有压测结论都会失真。

2. 两条实现路线：批处理死循环与 C# 多线程忙等待

负载工具的第一步是“让 CPU 真正忙起来”。Windows 上没有现成的压力测试命令行，但原理很朴素——只要有一个线程在逻辑处理器上持续执行、不进入睡眠，系统就会判定该核心处于忙碌状态。两条实现路线分别对应两个目标：批处理最快跑通，C# 能精确控制。先走通简单的，再上可控的。

2.1 批处理死循环：单核打满的最小可运行方案

创建一个idle_worker.bat，内容只有三行：

@echo off :loop goto loop

这段代码让 cmd.exe 不停地在:loop和goto loop之间跳转，永不退出。cmd.exe 自身是一个用户态进程，它持续占用一个逻辑处理器的时间片，任务管理器里对应核心的占用率会逼近 100%。再写一个burn.cmd负责按核心数拉起多个 worker：

@echo off setlocal enabledelayedexpansion rem burn.cmd [核心数] - 默认打满4个逻辑核心 set /a cores=4 if not "%1"=="" set /a cores=%1 set /a mask=1 for /L %%i in (1,1,%cores%) do ( start /affinity !mask! /high cmd /c "call idle_worker.bat" set /a mask=mask*2 ) echo 已在 %cores% 个逻辑核心上启动负载进程。

逻辑说明：循环从 1 到 cores 逐个拉起子进程，/affinity指定新进程运行在哪个逻辑核心上，/high把进程优先级设为高。mask 从 1 开始每轮乘 2，依次对应核心 0、1、2、3 的亲和掩码。批处理里set /a输出的是十进制整数，而/affinity接受十六进制掩码；因为这里每次都乘 2，所以掩码永远是 2 的幂次，十进制 1、2、4、8 和十六进制 1、2、4、8 数值恰好一致，第 10 个核心的掩码 512 传进去对应的就是 0x200，可以直接混用，不需要手动换算。

参数说明：cores 指要打满的逻辑核心数，不是物理核心数。在 4 核 8 线程的超线程处理器上，cores=8 才能把任务管理器总占用率刷到接近 100%。mask 每轮翻倍，最终对应当前进程要绑定的那个核心，这是批处理里最简单的核分配方式。运行burn.cmd 4，任务管理器性能页会看到前四个逻辑核心各自冲到满格。

这条路的局限也很明显：只能打满，不能指定占用率。想让 CPU 稳定在 60%，批处理只能靠 ping 延迟、timeout 或随机 sleep 来“蒙”，粒度粗糙到没法用于量化测试。它适合快速确认散热风扇有没有转、机器能不能扛住满载，但做不了负载曲线测试。

2.2 C# 多线程忙等待：多核协同与进程级控制

要精确控制占用率，就得换成能操作线程的编译型程序。C# 在 Windows 上生态最省事，用 .NET SDK 或 Developer PowerShell 里的 csc 都能编译。下面这个版本是“打满”思路的多核实现：

using System; using System.Diagnostics; using System.Runtime.InteropServices; using System.Threading; namespace CpuLoadSimulator { class Program { [DllImport("kernel32.dll")] static extern IntPtr GetCurrentThread(); [DllImport("kernel32.dll")] static extern IntPtr SetThreadAffinityMask(IntPtr hThread, IntPtr dwThreadAffinityMask); static void Main(string[] args) { int threadCount = args.Length > 0 ? int.Parse(args[0]) : Environment.ProcessorCount; for (int i = 0; i < threadCount; i++) { int coreIndex = i; Thread t = new Thread(() => { // 让线程只跑在指定的逻辑核心上 SetThreadAffinityMask(GetCurrentThread(), new IntPtr(1 << coreIndex)); while (true) { } }); t.Start(); } Console.WriteLine($"已启动 {threadCount} 个忙等待线程, 按任意键退出..."); Console.ReadKey(); } } }

逻辑说明：Main 里按传入线程数创建 Thread，每个线程先通过 SetThreadAffinityMask 绑定到1 << coreIndex对应的逻辑核心，再进入 while(true) 忙等待。GetCurrentThread 拿的是调用线程的句柄，SetThreadAffinityMask 把它固定到指定的逻辑核心上。threadCount 默认取 Environment.ProcessorCount，在超线程机器上就是逻辑处理器总数，保证每个逻辑核都有线程在跑。

编译方式：dotnet new console -n CpuLoadSimulator建工程，替换 Program.cs 后执行dotnet build -c Release；用 csc 直接编也可以，但我建议 Release 而不是 Debug，Debug 版本里 JIT 和附加调试信息会带来额外开销，让负载曲线不够平稳。

参数说明：threadCount 是启动的忙等待线程数，建议等于逻辑处理器数；明显小于逻辑核心数时，会出现一部分核空闲。coreIndex 从 0 开始，对应掩码 1 左移 coreIndex 位，第 5 个线程绑定到掩码 0x10 的逻辑核心。若机器是 4 物理核 8 逻辑核，绑定到逻辑核 0 和 1 的两个线程共享同一物理核的执行单元，总占用率不会简单叠加，这一点在第 4 章避坑里细说。

到这里“打满”已经完成，但从“打满”到“能指定百分比”还差一个关键算法——时间片分割。

3. 可控负载的关键参数：时间片分割、核心绑定与优先级

3.1 时间片分割算法：用“忙闲比”把占用率拉成指定值

原理一句话：一个固定周期内，忙等待时间和睡眠时间各占多少，决定了这段时间的平均占用率。周期取 100ms，目标 60% 就是忙 60ms、空 40ms。代码如下，替换上一章 while(true) 空循环即可：

using System.Diagnostics; using System.Runtime.InteropServices; [DllImport("winmm.dll")] static extern uint timeBeginPeriod(uint uMilliseconds); static void BurnWithTimeSlice(int percent, int intervalMs) { int busyMs = intervalMs * percent / 100; int idleMs = intervalMs - busyMs; Stopwatch sw = new Stopwatch(); while (true) { sw.Restart(); while (sw.ElapsedMilliseconds < busyMs) { // 忙等待: 把当前周期内的高占用时段耗完 } sw.Stop(); Thread.Sleep(idleMs); } }

调用侧先执行timeBeginPeriod(1)，把系统全局计时器精度从默认的 15.6ms 提到 1ms，再创建 N 个线程，每个线程传入 percent 和 intervalMs。逻辑说明：busyMs 等于周期乘目标百分比，忙等待段用 Stopwatch 计时到预定时长，然后睡眠空闲段。Stopwatch 在 Windows 上底层走 QueryPerformanceCounter，是微秒级精度，不受 Sleep 分辨率影响；而 Thread.Sleep(idleMs) 在 timeBeginPeriod(1) 之后才能把 40ms 睡成 40ms。

参数说明：intervalMs 取 100 的好处是每 1% 占用率对应 1ms，便于脑内验算。interval 太短（比如 10ms），线程切换和 Stopwatch 调用的开销占比上升，实际占用率会系统性偏高；interval 太长（比如 1000ms），负载曲线会有肉眼可见的锯齿，任务管理器里像在呼吸。我最常用的组合是 interval=100、percent=50～90，波动控制在 ±3 个点以内。

补充一个很多人忽略的事：timeBeginPeriod(1) 是全系统全局生效的，会把所有进程的定时器精度都拉高，直接后果是笔记本续航小幅下降。工具跑完退出影响不大；要是做成常驻后台程序，记得最终调用 timeEndPeriod(1) 恢复，否则会干扰系统里其他程序的 Sleep 行为。

3.2 线程亲和性：把负载压到指定的逻辑核心上

在多核机器上不设置亲和性，Windows 调度器会把线程在不同核心之间来回搬运。表面看总占用率没差，但线程迁移会破坏缓存热度，负载曲线出现额外抖动；更麻烦的是你无法确认“哪一个核心的真实压力是多少”。所以第 2 章里才把 SetThreadAffinityMask 放到线程开头：

SetThreadAffinityMask(GetCurrentThread(), new IntPtr(1 << coreIndex));

逻辑说明：参数 dwThreadAffinityMask 的每个 bit 对应一个逻辑处理器，bit 为 1 表示该线程可以被调度到这个处理器上；只设一个 bit 就是把线程钉死在一个逻辑核上。注意必须在线程内部调用，因为亲和性是线程级属性，不是进程级属性；虽然进程级有 ProcessorAffinity 可用，但直接在 Thread 回调里调用 kernel32 更干净，也省去 ProcessThread 与托管线程映射的麻烦。

参数说明：coreIndex 不要超过 63，超过的话1 << coreIndex会溢出；64 逻辑核以上的机器要换用IntPtr(1L << coreIndex)。另一个容易踩的细节是超线程：逻辑核 0 和 1 共享同一个物理核的执行单元，如果只刷核心 0 和核心 1，物理核资源已经吃满，但任务管理器总占用率只有 25%（4 物理核场景），这不是工具坏了，是超线程折算的正常表现。

3.3 优先级与 Windows 调度：为什么“高”够用、“实时”是翻车现场

负载线程默认优先级是 Normal，会被同优先级的业务线程抢时间片，负载曲线会被拉低。所以工具里通常要把进程优先级提到 High：

Process.GetCurrentProcess().PriorityClass = ProcessPriorityClass.High;

逻辑说明：PriorityClass 影响进程内所有线程的基准优先级。High 对应线程优先级 15 级左右，高于大多数普通应用，低于 Windows 内核关键线程。设成 High 之后，负载线程能稳定拿到调度优先权，目标占用率更容易贴近设定值。

参数说明：还有个 Realtime 选项，对应优先级 24 级。听起来更“狠”，但副作用是可能压过键盘、鼠标输入设备的内核处理线程，实际操作中很容易出现鼠标飘、ping 不通、任务管理器打不开，最后只能硬重启。我的血泪经验是：压测工具一律用 High，不上 Realtime；需要跟其他高优先级进程抢资源时，用 ProcessThread.PriorityLevel 单独调负载线程，而不是动整个进程。

到这里，可控负载的基本盘已经齐了：时间片分割控制占用率、亲和性控制核心分布、优先级控制调度权重。接下来讲真正拉开差距的部分——同样是刷 CPU，为什么有人刷出来是一条直线，有人刷出来是一床心电图。

4. 避坑与排查：占用率虚低、读数不准和降频翻车

这一章只记实际踩过的坑，每条都按“现象 → 原因 → 解决”三段写，按出现的频率排序。

4.1 任务管理器 50% 之谜

现象：跑起来后任务管理器总占用率只有 50% 上下，图形上不去，但风扇已经在呼呼转。

原因拆成两层。第一层：线程数小于逻辑核心数，Windows 调度器又把负载线程轮流分给多个核心，每个核心瞬时占用都不满，平均到总占用率就更低。第二层：任务管理器“性能”页默认显示的是“总占用率”，是所有逻辑核心忙闲比例的平均值；单线程在任意时刻只能占住一个逻辑核心，所以它最多把总占用率推到 1/N——N 是逻辑核心数。4 核机器单线程打满，总占用率大约 25% 而不是 100%。

解决：先确认线程数等于逻辑核心数，然后右键任务管理器性能页的 CPU 图，把图形切换为“逻辑处理器”，逐个核对每个逻辑核是不是都在跳。总占用率是一条直线但逻辑核有高有低，说明没有做到线程均匀绑定；逻辑核都是满格但总占用率只有 50% 多，是超线程折算或节能状态引起的读数口径差异，需要看下一节更底层的计数器。

4.2 Sleep 睡出 15 毫秒和优先级被抢占

现象：设定 70% 占用率，实际任务管理器只有 45%～50%，而且数值波动得厉害，几十秒内上蹿下跳。

原因有两个。第一个是定时器分辨率：Windows 默认计时器精度是 15.6ms，代码里 Thread.Sleep(1) 实际睡掉约 15ms，忙 70ms 空 15ms，忙占比从 70% 掉到 70/(70+15)≈82%？不对，实际是睡眠时长被拉长，忙占比显著低于设定值；再叠加调度器其他线程的影响，读数自然乱跳。这是 Windows 上写负载工具最经典的坑。第二个是优先级：负载线程保持 Normal，一旦有磁盘、网络等 IO 操作触发系统按优先级提升机制，业务线程瞬时抢过高优先级线程的时间片，负载曲线周期性塌陷。

解决：调用 timeBeginPeriod(1) 把全局计时精度提到 1ms，忙等待段改用 Stopwatch 计量；同时把进程 PriorityClass 设为 High。改完后实测 70% 目标的误差能压到 ±3 个点。还有一个常见做法是把空闲段做成动态补偿：每个周期结束后用实际 elapsed 更新 busyMs，公式是 busyMs = clamp(busyMs + (target - actual) * 0.2, 0, intervalMs)，把这段放进循环里，负载能在 20 秒左右收敛到设定值，适合长时间稳定性测试。

4.3 满载降频和虚拟机读数失真

现象：跑 100% 满载半个小时后，占用率自己掉到 60%，任务管理器里频率从 4.5GHz 降到 2.5GHz。

原因：温度墙或功耗墙被触发，CPU 主动降频自保。负载工具本身没坏，是散热能力不够。而降频反过来会压低占用率——CPU 在更短的时间内完成了同样的指令数，系统统计出的占用比例反而下降。如果不看频率只看占用率，极易误判“工具不稳定”。

解决：区分使用目标。做散热验证时，100% 满载跑 20 分钟足够看温升曲线；做长期稳定性测试时，把目标定在 80%，给 CPU 留出频率余量。监测频率和温度，Windows 下可以用 OpenHardwareMonitor 这类读 SMBus 的程序，或者笔记本厂商自带的性能监视工具。核心原则是看“频率 × 占用率”联动，而不是只看一个数。

另一个翻车现场在虚拟机里：VMware/Hyper-V 中刷 100% 占用，Guest 系统显示满了，宿主机任务管理器却只有 20%——或者反过来，Guest 只有 60%，宿主机已经快满了。原因很简单：虚拟 CPU 由 hypervisor 调度到物理核心上，Guest 看到的是虚拟 CPU 自己的统计，跟物理核心真实负载没有直接关系；Hyper-V 还会在宿主机多个逻辑处理器间动态迁移虚拟 CPU。所以虚拟机环境里要用宿主机计数器实测为准；如果目标是验证宿主机压力，直接在宿主机上跑工具，别隔着 Guest 读数。

5. 验证负载真实性的三个手段：性能计数器、核心分布和频温联动

工具做好了，怎么确定不是“看起来 100%”而是真的压到位？我一般用三个手段交叉验证，这三件事能暴露任务管理器视图看不到的问题。

第一，用性能计数器校准读数。任务管理器的 CPU 百分比来自% Processor Time，它基于时钟中断折算，受节能状态影响；更接近真实功耗的是% Processor Utility，它考虑了频率和空闲状态切换。PowerShell 这样采样：

$counter = "\Processor Information(_Total)\% Processor Utility" $sample = (Get-Counter -Counter $counter -SampleInterval 1 -MaxSamples 10).CounterSamples $vals = $sample | ForEach-Object { $_.CookedValue } $avg = ($vals | Measure-Object -Average).Average Write-Host "10秒平均 CPU Utility: $avg%"

逻辑说明：CounterSamples 的 CookedValue 才是格式化后的百分比值，10 个每秒采样平均后能过滤瞬时波动。SampleInterval 设 1 秒，MaxSamples 设 10，得到 10 秒窗口的均值；要分钟级平滑度，把 MaxSamples 改成 60 即可。跑负载工具时把这个脚本挂旁边，如果 Utility 读数和任务管理器差超过 5 个点，说明线程分布或定时器精度有问题。

第二，检查核心分布是否均匀。注意不要只盯 _Total，在性能监视器里添加多实例计数器看每个逻辑核心的 Utility。可以加个表格做对比：

如果某些逻辑核心长期 0% 而另一些 100%，说明亲和性设置没全覆盖；如果所有核都在跳但没有一个稳定在目标值附近，多半是 Sleep 精度问题没根治。

第三，频温联动记录。同时记录频率和占用率，负载工具跑 30 分钟，观察是否出现占用率仍高但频率下滑的段——那就是散热瓶颈。这个习惯帮我找回过两台“跑分正常但满载降频”的笔记本。

从那以后，我每次给机器或脚本做压测前，都强制先跑一遍这三个验证手段，再开始记录数据。坑都是踩过才长的记性：第一版工具用了默认定时器精度，读数偏差大到我不敢信；后来养成习惯，跑任何负载工具之前先挂 perfmon，再决定要不要信任务管理器。希望帮到你。

本文还有配套的精品资源，点击获取