所有线程执行完毕调用GC.Collect()后，C#进程内存能否恢复至初始状态？

这个问题问得很到位，刚好戳中了.NET GC很多人容易误解的点——先直接给结论：不会回归到接近0的状态，而且确实存在不少容易被忽略的内存占用（排除错误代码导致的泄漏），下面我拆解开来给你讲清楚：

为什么内存不会回归到接近0？ #

• 已加载程序集的常驻内存：这是最直观的部分——CLR加载的所有DLL（包括你自己的程序集、.NET框架类库、第三方库）的元数据、JIT编译后的本地机器码、类型信息这些都是常驻内存的，不会被GC回收。如果你的依赖很多，这部分占用几个GB完全是可能的，而且会一直保留到进程终止。
• CLR运行时本身的固定开销：GC的堆结构（比如分代堆的内存块、空闲内存链表）、线程池的空闲线程栈内存（线程池会保留一定数量的空闲线程复用，它们的栈内存不会被释放）、CLR内部的管理结构（比如类型缓存、同步原语资源、AppDomain的配置数据），这些都是进程运行的基础开销，GC碰都不会碰。
• 非托管内存的残留：即使你的代码没直接调用非托管API，.NET框架底层也会用到一些非托管内存（比如某些IO操作的缓冲区、加密库的底层资源）。有些非托管内存会通过Finalizer自动释放，但不是所有都能在一次GC.Collect()后立刻清理干净，部分会残留一段时间。

那些容易被忽略的内存占用（非泄漏） #

• 终结器队列未处理的对象：如果你的代码里有带Finalize方法（或者用了~类名析构函数）的对象，第一次调用GC.Collect()只会把它们标记为待终结，要等CLR的终结器线程执行完这些析构逻辑后，再调用一次GC.Collect()才能真正回收这部分内存。只调用一次的话，这些对象还会占着内存。
• 大对象堆（LOH）的碎片化：如果密集计算中创建了大量大于85KB的大对象，LOH不会像新生代堆那样自动压缩内存。即使这些对象被回收，空闲的内存块会留在LOH里，CLR会复用但不会归还给操作系统。所以任务管理器里看到的进程内存占用还是很高，虽然这些内存是“空闲”的，但不会被释放出去。
• 线程本地存储（TLS）的残留数据：如果线程在TLS（比如ThreadLocal<T>或者传统的TLS API）里存储了数据，即使线程执行完回到线程池，这些数据如果没被显式清理，会一直占用内存——直到线程池销毁这个线程，而线程池的空闲线程可能会被保留数小时甚至更久。
• 缓存类的隐性占用：.NET框架里有些内置缓存（比如Type对象的缓存、反射相关的缓存），这些缓存是CLR内部维护的，不会被GC回收，也会占用一部分内存，而且随着程序运行会逐渐累积。

总之，.NET的GC是管理托管内存的，但进程的内存占用远不止托管堆这一块。即使没有内存泄漏，调用GC.Collect()后，进程也会保留大量必要的运行时开销和无法释放的内存块，不可能回到接近0的状态。

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