17370845950

c# 高并发下使用 Regex 的性能问题和 Regex.CompileToAssembly
Regex高并发变慢主因是缓存争用与频繁重编译:弱引用LRU缓存+共享锁导致锁竞争,pattern动态时命中率趋零;应改用RegexGenerator(.NET7+)或静态预编译实例。

Regex 在高并发场景下为什么会变慢?

因为默认的 Regex 实例不是线程安全的,且每次调用 new Regex(pattern) 或静态方法如 Regex.IsMatch(input, pattern) 时,.NET 会隐式缓存编译结果——但这个缓存是弱引用 + LRU 策略,高并发下容易失效或频繁重编译。更关键的是,缓存键只包含 patternRegexOptions,不区分调用上下文,多个线程争抢同一缓存项会触发内部锁(RegexCache.s_lock),成为瓶颈。

  • 现象:QPS 上千后,Regex.IsMatch 的 CPU 占用陡增,profiler 显示大量时间花在 RegexRunner.Scan 和锁等待上
  • 根本原因不是正则本身慢,而是编译开销和缓存同步开销被放大
  • 尤其当 pattern 来自配置或用户输入(无法提前预编译)、且 options 动态变化时,缓存命中率趋近于 0

Regex.CompileToAssembly 已被废弃,别再用了

Regex.CompileToAssembly 是 .NET Framework 2.0–4.x 提供的“把正则编译成独立 DLL”的方案,目的是绕过运行时编译。但它在 .NET Core/.NET 5+ 中**完全移除**,官方文档明确标记为 obsolete,且存在严重缺陷:

  • 生成的程序集无法跨平台(依赖 System.Text.RegularExpressions 的具体实现细节)
  • 每次 pattern 或 options 变更都要重新生成、部署新 DLL,运维成本爆炸
  • 生成的类型必须 public,破坏封装;且需反射加载,丢失编译期类型检查
  • 实际性能提升有限——现代 JIT 和 Regex 源生编译(RegexGenerator)已远超它

如果你在旧项目里还看到 Regex.CompileToAssembly 调用,第一件事是搜索替换为 RegexOptions.Compiled 或(更推荐)RegexGenerator

替代方案:用 RegexGenerator(.NET 7+ 推荐)或预编译实例

.NET 7 引入源码生成器 RegexGenerator,在编译期把正则转为纯 C# 代码,零运行时编译、零反射、无锁——这才是高并发下的正解。

[RegexGenerator(@"\d{3}-\d{2}-\d{4}", RegexOptions.None)]
public static partial class SsnRegex
{
    public static partial bool IsMatch(ReadOnlySpan input);
}

使用时直接调用 SsnRegex.IsMatch(input),性能接近手写字符串扫描。注意:

  • 必须用 partial 类 + static 方法,且 generator 属性参数必须是编译期常量
  • 不支持运行时拼接的 pattern(比如 string.Format("{0}.*", userPattern)
  • 若还在用 .NET 6 或更早,退而求其次:把常用 pattern 提前构造为静态 Regex 实例,并显式指定 RegexOptions.Compiled

例如:

private static readonly Regex EmailRegex = new Regex(@"^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$", RegexOptions.Compiled | RegexOptions.NonBacktracking);

⚠️ 注意:RegexOptions.Compiled 在 .NET 5+ 中已默认启用 JIT 编译,加不加影响不大;真正有用的是 RegexOptions.NonBacktracking(防止回溯爆炸)和确保实例复用。

动态 pattern 场景下怎么保性能?

当 pattern 必须来自数据库、API 或用户输入时,无法用 RegexGenerator,也不能每次 new —— 此时核心策略是「控制编译频次 + 隔离缓存」:

  • ConcurrentDictionary 手动缓存,key 为 pattern + options.GetHashCode() 拼接字符串
  • 限制缓存大小(如最多 100 个),避免内存泄漏;用 Lazy 防止并发重复编译
  • 对高频 pattern(如日志行解析),可预热:应用启动时主动编译并注入缓存
  • 绝对不要在循环里写 new Regex(pattern),哪怕 pattern 看似固定——JIT 不会帮你优化掉

一个最小可行缓存示例:

private static readonly ConcurrentDictionary> _regexCache = new();
public static Regex GetOrCompile(string pattern, RegexOptions options = RegexOptions.None)
{
    var key = $"{pattern}_{options.GetHashCode()}";
    return _regexCache.GetOrAdd(key, _ => new Lazy(() => new Regex(pattern, options))).Value;
}

真正难的不是写对这十几行,而是意识到:正则不是“写完就扔”的胶水代码,高并发下它和数据库连接、内存分配一样,是需要显式治理的资源。