多核心大内存系统中.NET线程创建触发OutOfMemoryException问题排查

针对你的猜想的验证分析 #

• 猜想1：内存外其他资源耗尽
  Windows系统中，进程启动和线程创建会消耗内核级资源，常见瓶颈点包括：

  • 桌面堆（Desktop Heap）：即使是后台进程，部分也会关联桌面堆资源，当进程数量过多时，非交互式桌面堆可能耗尽，导致线程创建失败。
  • 内核句柄配额：每个进程的句柄数量有默认限制，若进程中打开大量文件、套接字或内核对象，总句柄数可能触达阈值。
  • 虚拟地址空间（针对32位进程）：32位进程默认只有2GB虚拟地址空间，线程栈（默认1MB）、代码段、堆内存等会快速占满空间，导致无法分配新线程所需的栈内存。

• 猜想2：进程实际线程数远超预期
  .NET 4.8的线程池默认最小线程数为核心数，但仅当代码主动使用线程池（如Task.Run、ThreadPool.QueueUserWorkItem）时才会启动这些线程。如果你的代码仅显式创建一个计算线程，每个进程的线程数应该只有主线程+计算线程+CLR默认线程（垃圾回收、终结器等，约3-5个），总线程数远低于系统限制。但仍需确认是否存在第三方库或隐式调用线程池的情况。

• 猜想3：内存碎片导致无法分配连续内存
  64位系统的虚拟地址空间极大，线程栈的分配仅需虚拟内存连续（物理内存无需连续），因此几乎不可能出现找不到1MB连续块的情况。若进程是32位，虚拟内存碎片化可能是诱因，但64位环境下该猜想可直接排除。

具体排查步骤 #

1. 确认进程位数 #

打开任务管理器→详细信息，查看工作进程的“平台”列：

• 若为32位：立即切换项目编译平台为x64，32位进程的2GB虚拟地址空间是最可能的瓶颈。
• 若为64位：继续排查其他资源问题。

2. 检查内核资源使用 #

• 桌面堆：使用Process Explorer查看系统信息中的桌面堆占用情况，或修改注册表HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\SubSystems\Windows的SharedSection值，将第三个参数（非交互式桌面堆大小，单位KB）从默认512调整为1024，重启后测试。
• 内核句柄：打开资源监视器→进程标签，查看总句柄数是否接近系统默认限制（16384），若接近可调整注册表GDIProcessHandleQuota和USERProcessHandleQuota增大配额。
• 虚拟内存：在资源监视器中查看每个进程的“虚拟内存大小”，若32位进程接近2GB，可确认是虚拟地址空间耗尽。

3. 验证进程线程数 #

用Process Explorer查看每个工作进程的线程列表，确认线程数是否符合预期（主线程+1个计算线程+3-5个CLR线程）。若发现大量线程池线程，检查代码中是否存在隐式使用线程池的逻辑（如未同步的async/await、第三方库调用），必要时通过ThreadPool.SetMinThreads降低最小线程数。

4. 采集内存快照 #

在异常发生时，使用Windows性能监视器（perfmon）或dotMemory采集进程内存快照，分析虚拟内存的分配情况，重点查看线程栈的占用是否异常。也可在代码中添加日志，记录进程启动时的虚拟内存、已用内存数据，对比正常与失败进程的差异。

5. 调整线程栈大小（可选） #

若确认是虚拟内存空间问题，可在创建线程时指定更小的栈大小（需确保计算逻辑不会栈溢出）：

var calcThread = new Thread(CalculationLogic, 256 * 1024); // 设置256KB栈
calcThread.Start(taskParam);

临时缓解方案 #

• 暂时将同时运行的进程数限制在100以内，确认问题与进程数量的相关性。
• 若为32位进程，优先切换到64位编译，这是最直接的解决手段。

内容的提问来源于stack exchange，提问作者Sjoerd van Kreel