一、背景
早上在B站看到了下面这个视频
然后想起自己上一年处理了公司某个项目的同样的问题，于是就来总结一下使用SetPriorityClass将进程设置为PROCESS_MODE_BACKGROUND_BEGIN后的相关问题。
二、代码
下面是一个demo代码，我们先来看下代码的正常运行情况下在procexp下的表现。procexp在下面链接里面
Sysinternals Suite - Sysinternals | Microsoft Learn
#include <Windows.h>
#include <vector>
#include <algorithm>
int main()
{
std::vector<char> v;
v.resize(200 * 1024 * 1024, 'c'); // 申请200MiB内存
std::sort(v.begin(), v.end());
system("pause");
return 0;
}运行程序的时候，procexp下程序的属性如图所示
我们可以看到CPU Priority的值是8，Memory Priority的值是5，I/O Priority的值是Normal，并且Working Set的值是200MiB左右。
而当我们在demo代码的main函数中增加设置进程为PROCESS_MODE_BACKGROUND_BEGIN后，就会看到以下的现象
#include <Windows.h>
#include <vector>
#include <algorithm>
int main()
{
SetPriorityClass(::GetCurrentProcess(), PROCESS_MODE_BACKGROUND_BEGIN);
std::vector<char> v;
v.resize(200 * 1024 * 1024, 'c'); // 申请200MiB内存
std::sort(v.begin(), v.end());
system("pause");
return 0;
}
CPU Priority的值是4，Memory Priority的值是1，I/O Priority的值是Very Low，并且Working Set的值是32MiB左右。
也就是说设置为PROCESS_MODE_BACKGROUND_BEGIN同时修改了CPU Priority、Memory Priority、I/O Priority、Working Set。
三、问题
主要问题是修改Working Set，也就是一个程序的工作集。
工作集 - Win32 apps | Microsoft Learn
可以看到demo代码在设置PROCESS_MODE_BACKGROUND_BEGIN前，Page Faults在52597；设置PROCESS_MODE_BACKGROUND_BEGIN后，Page Faults在97073，Page Faults增加了84%以上。
设置为PROCESS_MODE_BACKGROUND_BEGIN后，工作集被强制限制为了32MiB。当程序需要分配大量的内存并且所持有的内存超过32MiB后，就会频繁地触发Page Faults来申请更多的虚拟内存，并且访问内存时需要跟外存进行页面交换，进一步拖慢了程序的运行速度。
但是，这时候CPU的占比却是居高不下的，违背了PROCESS_MODE_BACKGROUND_BEGIN所说的，“不会对前台的活动产生重大影响”。
四、处理方法
我这边最后的处理方法是，不再使用PROCESS_MODE_BACKGROUND_BEGIN。而是通过
- 使用SetPriorityClass将进程优先级设置为IDLE_PRIORITY_CLASS，只影响CPU Priority，而不影响Memory Priority、I/O Priority、Working Set。
- 通过SetProcessWorkingSetSize函数手动设置Working Set在合理的大小，防止后台进程占用过多的内存（但肯定不是跟PROCESS_MODE_BACKGROUND_BEGIN一样设置为32MiB这么小）
最后的话，后台进程的运行速度的确得到了大幅度的提高，运行耗时降低了60%左右。
五、总结
所以说，微软的文档是真的坑，
setPriorityClass 函数 (processthreadsapi.h) - Win32 apps | Microsoft Learn
通篇上下都没有提到过会将Working Set设置为32MiB的字样。还说“不会对前台的活动产生重大影响”，与最后的运行情况大相径庭。
大家在通过微软的文档来使用新的API的时候，不妨先自己多点去尝试一下，不要盲目相信微软的文档比较好。