当Windows的CPU核数超过64以后， Windows会自动分组。以下是我在Windows 2016系统测试到的行为:
1.在多CPU分组环境下，一个进程默认只能在一个CPU分组里运行。至于分配到哪个分组，由系统决定，不固定分配。
2.一个进程只能绑定一个CPU分组， 线程则没有限制。意味着通过控制，可以让一个进程使用到多个CPU分组的资源。
3.进程设置CPU分组，取决于第一个线程所绑定的CPU分组， 如果要设置进程到某个CPU分组，则需要改变第一个线程的CPU分组，再设置进程affinitity。
4.当设置过线程group与进程group不同组以后， 任务管理器查看进程相关性就会不可用。
5.当设置过进程affinitity，而又设置了线程在同一个分组的进程affinitity以外的核心， 则之前设置的进程affinitity就会失效。
SetThreadAffinityMask, SetProcessAffinityMask, SetThreadGroupAffinity的对比
SetThreadAffinitityMask是设置线程的相关性，SetProcessAffinitity则是设置进程的相关性。 以上两个函数都无法改变CPU分组。只有SetThreadGroupAffinitity可以改变CPU分组。在多CPU分组的系统上，设置线程的分组以及相关性，可以同时允许一个进程里的不同线程分配到不同的CPU里运行，提供更灵活的控制。
以上函数的affinitity_mask参数类型是指针，意味着在32位程序，affinitity_mask参数是32位，也就是说最多只能控制使用前面32个核。64位程序affinitity_mask参数是64位的，可以设置到任意一个核，因为CPU分组的核数不会超过64。在32位程序有个硬伤，就是无法控制线程或者进程使用32核以后的核。
有一个技巧，可以让32位程序的进程相关性设置能用到32位以后的核，那就是写一个专门设置进程相关性的64位程序B， 监听某个端口，32位程序通过socket把自己的进程pid以及需要设置的64位相关性发送给B程序，由B程序帮它设置，因为其他进程可以通过进程pid获得进程句柄来调用SetProcessAffinitity函数。但是同样的方法，对线程就无能为力，因为我找不到， 进程能获得另外一个进程里的线程句柄的有效方法，把句柄值直接传过去？觉得挺危险的，后面的就没试了，改成64位是趋势。
