为何ThreadLocal<T>自引用会引发C# .NET 7内存泄漏？

以下是一段会引发严重内存泄漏的C# .NET 7代码：

using System.Threading;

while (true)
{
    ThreadLocal<object> tl = new();
    tl.Value = tl;
}

运行这段代码后，进程内存占用会快速飙升（测试环境中每几秒增长1GB），直到内存耗尽导致进程崩溃。

有两种修复该泄漏的方式：

• 将tl.Value = tl;替换为tl.Value = new object();
• 在循环末尾调用tl.Dispose();

虽然ThreadLocal自带会自动执行的终结器，按常理最终应该触发Dispose，但实际却出现了内存泄漏。而且即使ThreadLocal不是直接自引用，只要存在指向自身的间接引用链，同样会引发泄漏（这也是我最初发现该问题的真实场景）。

这属于有文档记录的预期行为吗？为什么会出现这种情况？

编辑补充：
下面是手动每100000次循环调用垃圾回收器的版本，即使手动触发全代GC，内存依然会泄漏（只是速度变慢，可能是因为GC本身的耗时）：

using System;
using System.Threading;

int countUntilGc = 100000;
while (true)
{
    ThreadLocal<object> tl = new();
    tl.Value = tl;

    countUntilGc--;
    if (countUntilGc <= 0)
    {
        GC.Collect();
        countUntilGc = 100000;
    }
}

问题分析与解答 #

这是循环引用+终结器延迟回收机制共同导致的：

1. 当ThreadLocal实例的Value指向自身时，形成了强引用循环：ThreadLocal实例 → 内部存储的Value → 自身。
2. .NET GC虽能处理普通循环引用，但当循环中的对象带有终结器时，逻辑会更复杂：
   • 第一次GC时，发现ThreadLocal无外部引用，但因它有终结器，GC会将其放入终结器队列而非直接回收。此时该对象仍被视为"存活"，它引用的所有对象（包括自身）也会被标记为存活。
   • 终结器线程处理队列中的对象时，ThreadLocal的终结器逻辑依赖清理内部线程本地存储（TLS）数据，但自引用的存在导致即使终结器执行，对象仍有指向自身的强引用，GC后续无法回收该实例。
3. 手动调用GC.Collect()也无法打破循环——终结器执行后，对象的强引用链依然存在，GC无法判定它可被回收。

只有主动调用Dispose()才能提前清理ThreadLocal内部的引用关系、打破循环；或者避免让Value指向自身，消除循环引用根源，GC才能正常识别对象为可回收状态。

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