Exchange Web Services（EWS）调用是否会引发内存泄漏？——基于FindItems接口的测试验证

从你的测试过程和结果来看，暂时不能直接判定这是EWS调用导致的内存泄漏，咱们来拆解下原因，以及如何更准确地验证：

核心原因分析 #

• GC延迟回收特性：.NET的垃圾回收（GC）不会在对象失效后立刻释放内存，它会根据内存占用压力、回收时机等条件自动触发回收逻辑。你的测试代码里没有主动触发GC，所以每次调用后看到的内存增长，很可能只是暂时未被回收的对象占用的空间，而非真正的内存泄漏——这些对象后续会在GC运行时被清理。
• 内存指标的局限性：你用来监控内存的PrivateMemorySize64指标，反映的是进程的私有内存总量，其中包含了未被回收的托管对象、JIT编译的代码、运行时内部结构等多种内容，单一数值变化不足以证明存在泄漏。要准确判断，需要用专业的内存分析工具（比如Visual Studio自带的内存探查器、JetBrains dotMemory），查看对象的存活引用链，确认是否有本该被回收的对象被意外持有（比如某个全局缓存、未释放的网络连接）。
• API版本的潜在影响：EWS Managed API的旧版本确实存在过一些内存相关的小问题，建议你先确认自己使用的API版本是否是最新的稳定版。

更准确的验证方案 #

你可以修改测试代码，在调用getId后主动触发GC，再观察内存变化：

static void loop(ExchangeService accountExchangeService) {
    while (true) {
        Process currentProcess = Process.GetCurrentProcess();
        Console.WriteLine("press a key to run the test");
        Console.ReadKey();
        long aMem = currentProcess.PrivateMemorySize64;
        Console.WriteLine("memory before function:" + aMem);
        getId(accountExchangeService);
        // 主动触发GC并等待终结器执行，确保可回收对象被清理
        GC.Collect();
        GC.WaitForPendingFinalizers();
        GC.Collect(); // 二次回收，处理终结器释放后的残余对象
        currentProcess = Process.GetCurrentProcess();
        long bMem = currentProcess.PrivateMemorySize64;
        Console.WriteLine("memory after function:" + bMem);
        long delta = bMem - aMem;
        Console.WriteLine("delta memory: " + delta.ToString());
        Console.WriteLine("");
    }
}

如果修改后每次的内存差值趋近于0，或者不再持续稳定增长，说明之前的内存变化只是GC延迟导致的正常现象；如果仍然每次都有明显的内存增长，再用内存分析工具去排查具体的存活对象和引用来源。

内容的提问来源于stack exchange，提问作者Vincent