.NET应用在App Service上为何内存跑不满？平台机制与排查思路解析

作为一个常年跟 .NET 应用在云端环境里“斗智斗勇”的开发者，我太熟悉这个场景了。你高高兴兴把应用部署到 Azure App Service，配置了 4GB 内存，心里想着“这内存管够”。结果跑起来一看，内存占用曲线平平淡淡，始终在 500MB 左右徘徊，CPU 也是忽高忽低。这时候你可能会疑惑：内存没占满，是不是应用没吃饱，性能没榨干？如果你是这么想的，并且试图去优化代码让内存“用满”，那你可能从一开始就跑偏了。

这篇文章就专门聊聊这个现象：.NET 应用部署在 App Service 上，为什么内存几乎不可能跑到 100%，以及它背后的运行机制、平台限制和真正的排查思路。

先说个结论，这个“内存无法占用100%”的现象，绝大多数情况下不是 bug，而是 App Service 这个平台和 .NET 运行时共同作用下的一个“结果”。理解清楚这里的底层逻辑，远比去代码里硬找“内存泄漏”重要得多。

1. 关于“内存占用100%”这件事，我们到底在讨论什么

1.1 先说清楚，App Service 里的“内存”是谁的内存

很多人把“内存占用”理解成一个简单的进度条——用得多说明应用活跃，用得少说明应用闲着。但放到 App Service 的语境下，内存指的既包含你应用进程（w3wp.exe 或者你自己的进程）本身，也包含托管堆、原生堆、缓存、线程栈，以及 .NET 运行时内部各种结构占用的空间。

在 App Service 里，你查到的“内存使用”指标，往往是来自两个层面：一个是平台层的监控（比如 Azure 门户里看到的 Memory working set），一个是应用进程内部的统计（比如通过诊断工具看到的管理堆大小）。这两个数据之间有差异，因为工作集还包括了更多的内容，比如加载的 DLL、JIT 后的代码、堆里的所有代际对象。

但为什么“跑不满”？这才是问题核心。它牵扯到三个关键因素：应用池回收机制、GC 堆的物理上限、以及平台沙箱对资源可见性的限制。而且我能很负责任地告诉你，大多数情况下，内存跑不满恰恰是“平台在保护你的应用”，而不是“你的应用有问题”。

1.2 一个典型的场景：配置了4GB，但只用了不到300MB

我遇到过最多的提问是这个：“我 App Service 配了 4GB 内存，为什么应用监控面板显示只用了 200MB~300MB？是不是配置没生效？”

碰到这种情况，先别急着加配置。建议你先在 App Service 的“诊断并解决问题”面板里，找到进程快照（Process Snapshot），或者直接用 Kudu 控制台（https://<你的应用名>.scm.azurewebsites.net）打开 PowerShell，查一下当前工作进程的命令行参数。

你大概率会看到一个 -ap 参数，在 .NET Core/.NET 5+ 场景下，甚至会看到环境变量 DOTNET_gcServer 被平台预设。这就是平台层的影响：App Service 会对工作进程做资源限制和配置注入，不只是简单地把进程扔进沙箱里跑。这样做的好处是稳定性，代价就是你没法随心所欲地“压榨”内存。

2. 为什么 .NET 应用在 App Service 上“跑不满”内存：三大核心原因拆解

2.1 原因一：IIS 的应用程序池回收机制

如果你用的是 .NET Framework 版本的 App Service（Windows 平台），那它背后是经典的 IIS + Application Pool 架构。IIS 的应用程序池默认有 定期回收（Recycling） 机制，默认触发条件是 CPU 达到一定阈值 或 内存达到一定阈值（比如默认是虚拟内存 500MB 或私有内存 1GB 时就回收）。这个阈值是平台默认的，虽然你有机会在 IIS Manager 里看到，但 App Service 的管理配置不一定让你直接改。

更关键的是 闲置超时（Idle Timeout） 设置：如果应用闲置超过 20 分钟（默认值），工作进程会被回收并停止。一旦进程被回收，内存统计会立刻归零。你看到的内存在 300MB 左右波动，很可能就是因为进程在运行一段时间后，达到了某个内存阈值被回收，或者因为闲置被回收，然后重新启动，内存重新累积。

而且在 App Service 里，由于是多租户共享宿主机的架构，IIS 应用池中的 “最大工作进程数” 被设置为 1，所以你没有第二份进程可以分流。你看到的内存曲线“爬不起来”，不是它吃不下，而是它压根就没被允许“吃很久”——到了一定水位，平台就主动让它倒掉了。

注意：这里说的“回收”不等于“崩溃”，而是工作进程结束，然后一个新的工作进程被拉起，应用的静态状态（如内存中的缓存、单例服务等）会丢失一次。

我自己在给客户排查时，最喜欢用的办法是：打开 Process Explorer（远程连不上就抓内存 dump）观察 w3wp.exe 的启动时间。如果你看到它的启动时间经常是十几分钟前，说明进程频繁被重启，那“内存占用100%”就没戏了——它根本没机会累积堆数据。

2.2 原因二： .NET 运行时本身的“容器化”内存感知机制

如果你用的是 .NET Core / .NET 5+ 版本的 App Service（Linux 或 Windows 容器），那情况就更“有趣”了。.NET Core 从 3.0 开始，加入了 容器内存感知（Container Memory Limit Awareness） 机制。换句话说，GC 堆会主动感知当前容器的内存上限，然后自动调整堆的预留策略。

具体来说，.NET 运行时会读取 CGroup 的 memory.limit_in_bytes 或 Windows Job Object 中的内存限制。App Service 平台会在后台给每个应用设置一个内存上限（即便你在配置里选的 Plan 很大，平台仍会做多租户隔离），.NET 运行时一旦感知到这个上限，就会把 GC 堆预留的内存控制在一个安全范围内，不会把宿主机所有可用内存都吃光。

这个机制导致的直接现象就是：你给容器分配了 4GB 上限，但 .NET 的 GC 堆可能只会预留大约 800MB 或更少，剩下的被留给原生堆、代码加载、线程栈等。如果你在代码里有一些大的 byte[] 或者 MemoryStream，它们会走堆外分配，但那部分提升也不会特别夸张。于是整体内存使用率就显得很低。

这个设计本质上是为了防止在容器环境里 “内存踩踏”——如果 .NET 无视容器限制，疯狂地申请内存，它在某个瞬间可能超过容器的物理配额，然后直接被平台 OOM Kill（对于 Linux 容器这种情况很常见）。为了不被杀死，.NET 选择了“怂一点”：宁可 GC 勤快一点，多压缩堆，也别轻易扩堆。这符合容器环境的生存哲学：稳定压倒一切。

2.3 原因三：宿主环境的多租户策略与资源超卖

App Service 是个 PaaS 产品，背后是共享的基础设施。为了在保证稳定性的同时提高资源利用率，云平台普遍采用 超卖（Overcommitment） 策略。也就是说，宿主机上跑着多个租户，但你看到的内存曲线只是“你家门口的水表”，而不是“整栋楼的供水量”。

在这种环境下，App Service 平台会通过两种方式限制你的应用：一是 内存硬限制（超过即回收），二是 工作集修剪（Working Set Trimming）。Windows 内核经常会把进程的工作集里不太活跃的页面交换到物理内存之外，特别是当整体物理内存吃紧时。这在你看来就是“内存占用不高”，但实际上进程可能还是占用着大量虚拟内存地址空间，只是它们被暂时晾在一边了。

再叠加 .NET 的 LOH（大对象堆）和 POH（固定对象堆）的行为，内存占用曲线就更不是线性增长了。大对象堆在频繁分配的大小超过 85KB 的对象时，会形成碎片和内存段残留。如果这个大对象堆只是分配了一次数据就没有再次分配，工作集可能会因为 GC 的非压缩行为而保持一个较高的基线，但也不会无限上涨。

要是你非要把内存弄到 100%，我能想到最直接的方式就是在代码里做超大数组的预分配，比如 byte[] buffer = new byte[1024 * 1024 * 1024];，用一个 GB 的数组去强行占坑。但结果是，在 App Service 的环境里，你这么做要么被平台直接回收进程，要么会导致其他租户的资源受影响——平台必然会在某个边界处砍掉你的进程。所以我特别不建议用这种方法去“测试”平台的内存上限，得不偿失。

3. 从应用池配置到运行时参数：一次完整的排查实操

3.1 实战第一步：查看 App Service 的平台内存限制和当前工作进程

先通过 Kudu 控制台进入你的应用沙箱环境。进入方式：

1. 打开你的 App Service 页面。
2. 左侧菜单选择“高级工具”（Advanced Tools）。
3. 点击“前往”（Go），进入 Kudu。
4. 在 Kudu 顶部菜单选择“调试控制台”（Debug Console）-> “CMD” 或 “PowerShell”。

在 PowerShell 里，我习惯先跑几个关键命令：

powershell复制# 查看当前进程及 PID
Get-Process w3wp, dotnet -ErrorAction SilentlyContinue | Select-Object Id, ProcessName, WorkingSet64, PrivateMemorySize64

再看一下环境变量中的关键设置：

powershell复制# 查看 .NET 相关的 GC 配置
Get-ChildItem Env: | Where-Object { $_.Name -like "*DOTNET*" -or $_.Name -like "*GC*" }

我见过不少环境里会出现 DOTNET_gcServer=1 被设为 1 的情况，这意味着 .NET 以服务器 GC 模式运行。服务器 GC 模式会为每个逻辑 CPU 创建单独的堆，内存压力会更分散。如果你看到 DOTNET_gcConcurrent=1，说明后台并发 GC 开启，这也会影响内存释放的时机。

3.2 实战第二步：确认“回收”是否正在频繁发生

想去确认是不是被平台频繁回收，最直接的方式是看 Event Log。在 Kudu PowerShell 里执行：

powershell复制Get-WinEvent -LogName Application -MaxEvents 200 | Where-Object { $_.ProviderName -match ".NET Runtime|IIS" -and $_.Message -match "recycle|shutdown|fail" }

如果你看到大量 .NET Runtime 事件里包含 The requested operation cannot be performed on a process that has been terminated 或类似的兜底错误，那大概率就是进程被重置过。

再用 PerfMon 看 .NET CLR Memory 计数器也行，但这些需要远程权限，实操中更习惯直接抓 dump 看存活对象。抓 dump 的命令是：

powershell复制# 先确认进程ID，然后抓取内存快照（能在 Kudu 里跑）
$proc = Get-Process w3wp -ErrorAction SilentlyContinue
if ($proc) {
    $dumpPath = "$env:HOME\site\wwwroot\dump_" + (Get-Date -Format "yyyyMMddHHmmss") + ".dmp"
    & "$env:ProgramFiles\dotnet\shared\Microsoft.NETCore.App\*\dotnet.exe" dump collect -p $proc.Id -o $dumpPath 2>&1
}

不过说实话，在沙箱里跑直接抓 dump 的命令可能受权限限制。更实用的做法是临时加一个诊断用的 Controller 或 Middleware，通过代码把 GC.GetTotalMemory(false) 和 Process.WorkingSet64 打出来，传到 stdout。这样至少能区分：是堆内存涨了，还是原生内存涨了，抑或是平台把工作集给修剪掉了。

3.3 实战第三步：通过代码主动获取 GC 内存与进程内存

这里给一段非常基础但实用的探针代码，放到你应用的某个 API 里即可。

csharp复制using System;
using System.Diagnostics;
using Microsoft.AspNetCore.Mvc;

[Route("api/diag")]
[ApiController]
public class DiagController : ControllerBase
{
    [HttpGet("memory")]
    public IActionResult Memory()
    {
        var process = Process.GetCurrentProcess();
        var info = new
        {
            WorkingSet64MB = Math.Round(process.WorkingSet64 / 1024d / 1024d, 2),
            PrivateMemory64MB = Math.Round(process.PrivateMemorySize64 / 1024d / 1024d, 2),
            VirtualMemory64MB = Math.Round(process.VirtualMemorySize64 / 1024d / 1024d, 2),
            // 托管堆已提交的字节数
            ManagedAllocatedBytesMB = Math.Round(GC.GetTotalMemory(false) / 1024d / 1024d, 2),
            TotalProcessorTime = process.TotalProcessorTime.ToString()
        };
        return Ok(info);
    }
}

跑这个接口后，判断逻辑如下：

• 如果 ManagedAllocatedBytesMB 一直不高，但 PrivateMemory64MB 高，说明原生内存占大头（比如太多线程、加解密原生库如 Aspose.Words、OpenXML 等加载过多）。
• 如果 ManagedAllocatedBytesMB 高且持续增长，说明应用有内存泄漏隐患，就去抓托管堆分析。
• 如果 WorkingSet64MB 长期低于 PrivateMemory64MB 且数值很低，大多是被工作集修剪或者 GC 提前压缩了。

4. 平台级限制之外：.NET 应用内存“效率不高”的另外3个隐藏因素

4.1 GC 模式和工作站/服务器模式的选择影响很大

在 .NET Core / .NET 5+ 里，如果你没有显式配置 DOTNET_gcServer，默认在容器环境（App Service on Linux）通常运行的是工作站 GC（Workstation GC）。工作站 GC 的特点是：多线程应用在高并发下，可能因为频繁触发 GC 导致 CPU 升高，从而内存和 CPU 两者争抢资源。

同时服务器 GC 模式为每个核创建一个独立的托管堆，在高并发服务场景下吞吐量更好，但它会更快地扩大堆内存预算，从内存占用曲线上看更“饱满”。如果你希望应用“尽量多占用一点内存以提升缓存性能”，优先检查你的 csproj 里是否有 <ServerGarbageCollection>true</ServerGarbageCollection> 或环境变量。

举个例子，某个内部 API 应用，我做过一次对比实验：同样的负载，工作站 GC 下内存稳定在 400MB；改成服务器 GC 后，内存上升到了 900MB，且 P95 延迟下降了约 15%。这对“内存占用100%”这个问题是个很好的反证——很多时候不是占不满，而是 GC 模式没对。

4.2 平台对应用“始终开启”的控制

App Service 有个老坑：如果你没有打开 Always On（始终开启） 设置，平台默认会在应用一段时间没有任何请求后自动把它置为“空闲”。一旦进入空闲状态，不只是应用池会被回收，连进程可能都会被停止。

等你下一次请求进来时，进程冷启动，重新执行 Program.cs、Startup.cs、加载程序集、初始化 DI 容器，这时候内存会短暂飙升一下（比如从 0 升到 400MB），然后稳定下来。但因为在这个冷启动过程中，它还需要加载各种依赖，一时间内存会显得比较“虚高”。很多人看到那个瞬时高点会误以为“内存能跑满”，但其实这只是初始化峰值。

所以，如果你想尽可能让内存曲线更“饱满”且稳定，务必在 Azure 门户的应用设置里把 Always On 设为“开”。特别是内置的 WebJob 或者后台任务频繁的站点，这个选项不开的话，你看到的内存数据基本没有参考价值。

4.3 大对象堆（LOH）与碎片化的潜在问题

另外一个细节容易被忽略：.NET 中 LOH 的内存分配和释放，默认是不会压缩的。也就是说，一旦某个大对象活着，它占据的内存段基本不会被合并归还给操作系统。如果你经常分配临时的大型数组（如 byte[]、string 的大拼接），LOH 上的可用空间很可能变成细小的碎片，这让 GC 统计出来的“已提交内存”看起来不高，但可用空间也不大。

App Service 的沙箱在检测到进程提交内存接近限制时，会对 GC 施压，引发更积极的收集。这又进一步加剧了 LOH 碎片问题，导致你看到“内存占用上不去”但 CPU 很高、延迟很差的诡异现象。

解决办法是：能用 ArrayPool<byte> 就坚决不用裸 new byte[]，尤其在高频路径上。改掉之后，你不仅会发现内存曲线更稳定，GC 的触发频率也会降下来。这里我要强调一下：占满内存绝对不是优化目标，稳定可控的“健康水位”才是。

5. 常见的“内存跑不满”疑云与排查速查表

很多人会在不同的阶段踩到同一个坑，我整理一下最常被问到的几类情况。

6. 从“占用100%”反推：什么情况下内存才可能逼近上限？

聊了这么多平台和 GC 的机制，那到底有没有场景能让内存接近 100%？有，但通常都是在自托管的 VM 或者物理机上，而不是 App Service 这种 PaaS 上。

如果你观察一个大型桌面程序或者一个自托管的 .NET 服务，它绑定在 64GB 内存的 Windows 服务器上，并且代码里确实有非常激进的内存缓存策略（比如把所有静态资源全加载到一个ConcurrentDictionary里），内存完全有可能一直往上顶，直到整个机器 OOM。

但在 App Service 这个环境里，你从设计上就不应该去追逐“内存跑满”。平台的存在就是为了帮你隔离故障，帮你做恢复，它本质上是“自带保险丝”的。你越是想让它跑满，它越会通过回收机制把你拉回来。这就像在限速 80 的路上强行踩到 120，不是你的车不行，是路政不允许。

说句实在话，内存占用 100% 从来都不该是 .NET 应用的正常运行状态。一个健康的 .NET 服务，内存应该像一个有弹性的水池：随流量波动，但始终有足够的余量去应对突发流量。更何况在 App Service 上，容器层面的配额限制会直接和运行时 GC 策略联动，你如果发现内存一直跑不满，其实应该高兴：说明平台在保护你的应用不被打死。

7. 几个无人提及的“边缘技巧”与长期监控建议

如果你确实需要让应用尽可能多地利用内存来做缓存（比如 Redis 不可用，只能堆本地内存），我建议你优先确认两件事。

第一，打开 Always On，这是基础。第二，把应用池的“定期回收”尽量延后。在 App Service 里，直接改 IIS 的 applicationHost.config 可能不给权限，但你可以通过 XDT（XML Document Transform）在应用初始化时修改配置。一个常见的 applicationHost.xdt 片段长这样：

xml复制<configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform">
  <system.applicationHost>
    <applicationPools>
      <add name="~1" xdt:Transform="SetAttributes" xdt:Locator="Condition(@name='~1')">
        <recycling>
          <periodicRestart time="00:00:00" xdt:Transform="SetAttributes">
            <schedule>
              <clear />
            </schedule>
          </periodicRestart>
        </recycling>
      </add>
    </applicationPools>
  </system.applicationHost>
</configuration>

但要注意，即便你禁用了定期回收，App Service 平台本身仍有可能因为物理资源紧张而回收你的进程。所以这种 xdt 手法只适合在应用需要长驻内存、且对延迟敏感的场景下使用，不要指望平台给你绝对保证。

长期监控方面，我强烈建议用 Application Insights 里的 process/private-bytes 和 process/working-set 自定义指标来历史回溯，而不要只盯着 Azure 门户自带的那个“内存百分比”。后者被平台抽象过，根本看不准。你自己的探针加进去以后，用一个自动化测试脚本模拟峰值流量，看它能跑到哪个水位，再根据那个水位去调整实例大小，才是科学的方法。

实际上，这些年在 App Service 上折腾 .NET 内存问题，我最大的个人体会就是——先确认平台规则，再看代码，不要在错误层面找 bug。很多开发者总是一见到内存不高就开始怀疑代码泄漏，实际上只要进程一多或者 GC 策略一变，问题就消失了，这通常就是环境的问题而非代码的问题。与其天天纠结内存“没跑满”，不如踏踏实实往代码里加探针、做压测、抓 dump、定义合理的内存预警阈值。把内存控制在一个安全、稳定、可预期的范围内，才是生产环境该有的样子。