.NET Framework 4.8应用冻结排查：高CPU卡在内存分配函数但无实际内存分配记录

这是个非常典型又棘手的.NET性能问题，结合你提供的所有线索——GC.SustainedLowlatency模式、线程卡在clr!JIT_New/clr!JIT_NewArr1却无分配记录、GC.GetTotalMemory(false)阻塞、debugger附加暂时缓解——咱们可以从以下几个核心方向分析可能的原因：

1. GC.SustainedLowLatency模式下的内存分配阻塞 #

你提到有一个进程始终处于GC.SustainedLowlatency模式，其他进程在收到用户输入时也会切换到该模式再切回。这个模式的核心是抑制后台GC、强制前台GC延迟触发，目的是减少GC停顿，但代价是内存回收不及时，容易导致内存压力累积。

当内存压力到达临界值时，分配线程会触发GC，但SustainedLowLatency会延迟这个GC请求——此时分配线程会进入等待状态，但因为GC还未真正启动，PerfView不会记录GC.Start事件；同时，由于分配操作没有完成，自然也不会产生GC.AllocationTick。这种情况下，大量分配线程阻塞等待GC许可，就会表现为高CPU（线程自旋等待）+ 无分配记录的矛盾现象。

2. GC.GetTotalMemory(false)引发的连锁阻塞 #

你观察到有线程卡在GC.GetTotalMemory(false)，这个方法虽然标注为不强制GC，但在.NET Framework 4.8的实现中，它需要获取GC堆的全局锁来统计内存使用量。如果此时有其他线程（比如卡在分配路径上的线程）持有这个锁，或者SustainedLowLatency模式下锁的释放逻辑被延迟，就会形成连锁阻塞：

• GC.GetTotalMemory线程持有锁等待某些条件，导致所有分配线程（调用JIT_New/JIT_NewArr1）无法获取锁完成分配；
• 分配线程自旋等待锁，推高CPU使用率，但分配操作始终无法完成，因此没有AllocationTick事件。

3. 内存分配路径的锁竞争或死锁 #

JIT_New和JIT_NewArr1内部会涉及堆分配锁的获取（比如小对象堆的分配锁、大对象堆的锁）。如果某个线程意外持有了这些锁但未释放（比如异常导致锁未释放，或者SustainedLowLatency模式下锁的逻辑出现异常），所有后续分配请求都会阻塞在锁等待上：

• 线程在自旋等待锁时会占用CPU，但分配操作无法完成，所以没有实际内存分配，也就不会触发GC.AllocationTick；
• 这种场景下，debugger附加时会暂停所有线程，可能强制释放锁或触发GC，从而暂时缓解冻结。

4. 大对象分配的碎片重试逻辑 #

如果用户输入触发的逻辑涉及大对象（>85KB）或大数组分配，在SustainedLowLatency模式下，GC不会主动压缩大对象堆（LOH），导致LOH碎片严重。当分配线程试图寻找足够大的连续内存块时，会不断重试遍历LOH，这个过程会占用大量CPU，但因为始终找不到可用空间，分配操作无法完成，也就不会产生GC.AllocationTick事件。

排查建议 #

针对这些可能性，可以尝试以下步骤定位问题：

• 临时禁用GC.SustainedLowlatency模式：如果问题消失，说明该模式的内存管理逻辑是核心诱因；
• 自动抓取冻结时的dump：使用procdump -ma -t <进程ID>命令，当进程触发冻结时自动生成dump（避免手动抓dump时的缓解效应），然后用WinDbg分析线程栈的锁持有情况；
• 开启GC详细日志：设置环境变量COMPlus_GCLog="C:\gc.log"，记录GC的所有操作细节，包括是否有延迟触发的GC请求；
• 检查用户输入触发的代码路径：重点排查是否有大对象/数组的循环分配逻辑，或者频繁调用GC.GetTotalMemory的代码；
• 分析线程栈的参数：在dump中查看JIT_New/JIT_NewArr1的调用参数，确认分配对象的大小和类型，判断是否是大对象分配问题。

备注：内容来源于stack exchange，提问作者Will Nightingale