string.Intern() 会阻塞线程，.NET 6 前用全局锁导致高并发下严重争用，.NET 6 起改用无锁哈希表但仍有开销；其驻留字符串永不回收，易致内存泄漏，慎用于动态内容。

c# 在高并发下，string.Intern() 的使用和陷阱 第1张

string.Intern() 会阻塞线程吗？

会。在 .NET Framework 和早期 .NET Core 中，string.Intern() 内部使用全局锁（AppDomain 级静态锁），所有调用都串行化。高并发下大量线程争抢这把锁，表现为 CPU 占用不高但响应延迟飙升，Intern() 调用本身变成瓶颈。

从 .NET 6 开始，底层改用无锁哈希表 + 细粒度同步机制，吞吐明显提升，但仍非完全无开销——尤其当字符串首次插入 intern 池时，需原子写入和内存屏障，且池大小增长会触发内部 rehash。

  • 不要在每秒数万次请求的热路径中无条件调用 string.Intern()
  • 若必须用，优先在应用启动期或配置加载阶段完成“冷数据”驻留，而非运行时动态 Intern()
  • 用 dotnet-trace 或 PerfView 抓取 Microsoft-Windows-DotNETRuntime/ContentionStop 事件，确认是否真有锁争用

intern 池里的字符串永不释放？

是的。被 string.Intern() 加入池的字符串，只要 AppDomain（.NET Framework）或进程（.NET Core+）存活，就一直保留在内存中，GC 不回收——哪怕没有任何外部引用指向它。

这是最常被忽略的内存陷阱：一个动态生成的、带时间戳或 GUID 的字符串，如果误被 Intern()，就会永久驻留，随请求数线性增长，最终 OOM。

  • string.IsInterned(s) 可安全判断某字符串是否已在池中，避免重复插入
  • 永远不要对用户输入、日志消息、HTTP Header 值等不可控内容调用 Intern()
  • 若需缓存字符串，用 ConcurrentDictionary 自行管理生命周期，可控可清理

为什么 string.Intern() 后 == 比较变快了？

因为 == 对 string 是引用比较（String.Equals 重载后默认语义仍是值比较，但 JIT 会对 intern 字符串做优化）。当两个字符串都来自 intern 池，它们必为同一对象，引用相等即值相等，跳过逐字符比对。

但这只在双方都已 intern 时生效。若仅一方 intern，或其中一个是新构造字符串，仍走完整值比较逻辑，性能无收益，反而因额外的池查找拖慢。

  • 只有成对使用才有意义：所有参与比较的字符串必须统一走 Intern() 流程
  • 注意字符串字面量自动 intern，但拼接结果（如 "a" + "b"）在编译期能常量折叠才进池；运行时 string.Concat 或 $"..." 默认不进池
  • 用 Object.ReferenceEquals(a, b) 显式验证是否真共享引用，比依赖 == 更可靠

替代方案：什么时候该用 MemoryCache 或 StringComparer.Ordinal？

绝大多数高并发场景下，string.Intern() 都不是最优解。更轻量、可控的方式是：

  • 对固定枚举类字符串（如状态码、协议字段名），用 static readonly string 字段预定义，天然单例且无锁
  • 对动态但有限集合（如租户 ID、API 版本），用 MemoryCache 缓存其规范形式，设 Size 和 AbsoluteExpiration 防止内存失控
  • 纯比较场景，直接用 string.Equals(a, b, StringComparison.Ordinal) —— JIT 在 .NET Core 3+ 对此做了深度内联和向量化优化，比 intern + 引用比较还快
var comparer = StringComparer.Ordinal;
if (comparer.Equals(headerKey, "Authorization")) { /* ... */ }

真正需要 Intern() 的场景极少：比如自研 DSL 解析器中，上千个语法关键字需极致去重与比较性能，且生命周期贯穿整个服务运行期。