Azure Function执行后内存未释放，如何实现内存回收？

先说说你代码里的几个明显问题，这些都会影响内存回收：

• 没必要用Task.FromResult包装File.OpenRead，属于画蛇添足，反而容易引发资源处理的潜在问题。
• 初始化了容量100万的List<string>并加载全部文件内容，虽然是局部变量，但CLR的垃圾回收不会在函数执行结束后立刻触发，导致内存暂时被占用。
• 在using块内直接return，虽然流会被using自动释放，但strings的作用域要到函数结束才终止，拖慢了GC回收的时机。

下面是具体的优化和内存释放措施：

1. 优化代码逻辑，主动清理大集合 #

如果不是必须把所有文件内容存在内存里，尽量按需处理，不要一股脑全加载。如果确实需要存储，用完后主动清空并解除引用，帮助GC更快识别可回收对象：

// 使用完集合后主动清空内容
strings.Clear();
// 解除引用，让GC能及时回收内存
strings = null;

2. 修正文件读取方式，避免不必要的阻塞 #

把同步的文件读取改成异步模式，同时修正using的使用方式，去掉多余的Task包装：

var strings = new List<string>(1000000);
// 用异步方式打开文件流，更贴合Azure Function的异步模型
using (var fs = new FileStream(@"C:\secretfile.txt", FileMode.Open, FileAccess.Read, FileShare.Read, bufferSize: 4096, useAsync: true))
using (var reader = new StreamReader(fs))
{
    string rowText;
    // 用异步读取行的方法，避免同步阻塞
    while ((rowText = await reader.ReadLineAsync()) != null)
    {
        strings.Add(rowText);
        strings.Add(rowText + "C");
        strings.Add(rowText + "W");
    }
}
// 用完集合立刻清理
strings.Clear();
strings = null;
// 最后返回结果
return new OkObjectResult(responseMessage);

3. 主动触发GC（谨慎使用） #

如果确实需要立刻释放内存，可以在函数末尾主动调用GC，但要注意这会带来一定性能开销，仅在必要场景下使用：

// 清理完集合后触发垃圾回收
GC.Collect();
GC.WaitForPendingFinalizers();

4. App Service计划下的额外优化 #

• 在Azure门户给函数应用配置进程回收规则，比如设定内存阈值，当进程占用内存超过指定值时自动重启回收，避免影响同计划内的其他应用。
• 确保函数运行在最新的.NET版本上，新版本GC的内存回收效率更高。
• 绝对不要用静态变量存储大对象，静态变量的生命周期与应用域一致，会长期占用内存。

最后提醒：局部变量离开作用域后会被标记为可回收，但GC的触发时机由CLR决定，不会立即释放内存。优先通过优化代码减少内存占用，比强制GC更靠谱。

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