string.Intern() 会阻塞线程，.NET 6 前用全局锁导致高并发下严重争用，.NET 6 起改用无锁哈希表但仍有开销；其驻留字符串永不回收，易致内存泄漏，慎用于动态内容。
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 string></string>自行管理生命周期，可控可清理
为什么 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<string object></string>缓存其规范形式，设Size和AbsoluteExpiration防止内存失控 - 纯比较场景，直接用
string.Equals(a, b, StringComparison.Ordinal)—— JIT 在 .NET Core 3+ 对此做了深度内联和向量化优化，比 intern + 引用比较还快
var comparer = StringComparer.Ordinal;
if (comparer.Equals(headerKey, "Authorization")) { /* ... */ }真正需要 Intern() 的场景极少：比如自研 DSL 解析器中，上千个语法关键字需极致去重与比较性能，且生命周期贯穿整个服务运行期。
