Regex高并发变慢主因是缓存争用与频繁重编译:弱引用LRU缓存+共享锁导致锁竞争,pattern动态时命中率趋零;应改用RegexGenerator(.NET7+)或静态预编译实例。
因为默认的 Regex 实例不是线程安全的,且每次调用 new Regex(pattern) 或静态方法如 Regex.IsMatch(input, pattern) 时,.NET 会隐式缓
存编译结果——但这个缓存是弱引用 + LRU 策略,高并发下容易失效或频繁重编译。更关键的是,缓存键只包含 pattern 和 RegexOptions,不区分调用上下文,多个线程争抢同一缓存项会触发内部锁(RegexCache.s_lock),成为瓶颈。
Regex.IsMatch 的 CPU 占用陡增,profiler 显示大量时间花在 RegexRunner.Scan 和锁等待上Regex.CompileToAssembly 是 .NET Framework 2.0–4.x 提供的“把正则编译成独立 DLL”的方案,目的是绕过运行时编译。但它在 .NET Core/.NET 5+ 中**完全移除**,官方文档明确标记为 obsolete,且存在严重缺陷:
System.Text.RegularExpressions 的具体实现细节)RegexGenerator)已远超它如果你在旧项目里还看到 Regex.CompileToAssembly 调用,第一件事是搜索替换为 RegexOptions.Compiled 或(更推荐)RegexGenerator。
.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 属性参数必须是编译期常量string.Format("{0}.*", userPattern))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 必须来自数据库、API 或用户输入时,无法用 RegexGenerator,也不能每次 new —— 此时核心策略是「控制编译频次 + 隔离缓存」:
ConcurrentDictionary 手动缓存,key 为 pattern + options.GetHashCode() 拼接字符串Lazy 防止并发重复编译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; }
真正难的不是写对这十几行,而是意识到:正则不是“写完就扔”的胶水代码,高并发下它和数据库连接、内存分配一样,是需要显式治理的资源。