禁用认证的Spring MVC微服务EC2实例CPU使用率过高求助

核心问题定位 #

从线程栈可以明确，CPU过高是因为CorsProvider.isValidOriginHost方法里的正则表达式匹配陷入了灾难性回溯。这种情况通常出现在正则存在嵌套重复、模糊匹配结构时，遇到特定输入字符串会导致匹配过程指数级增长，直接耗尽CPU资源。

而启用认证的实例运行正常，大概率是因为认证过滤器提前拦截了那些触发正则回溯的恶意/异常请求，没让它们走到CORS校验环节；禁用认证后，这类请求直接进入CORS处理逻辑，才引发CPU占满的问题。

修复步骤 #

1. 紧急临时缓解 #

• 临时下线禁用认证的实例，或通过WAF/安全组拦截Origin/Referer字段包含超长、特殊格式字符串的请求，先把CPU使用率降下来。
• 若无法下线，可临时修改CorsProvider逻辑：跳过正则匹配，直接硬编码业务允许的合法Origin列表，先恢复服务可用性。

2. 修复正则表达式问题 #

找到CorsProvider.isValidOriginHost中的正则表达式，重构以避免灾难性回溯：

• 检查是否存在(a+)+b这类嵌套重复结构，或大量可选分支、模糊匹配规则。
• 优化方向：
  • 使用原子组(?>...)或占有量词++/??，阻止正则引擎不必要的回溯。
  • 将模糊匹配改为精确规则，比如限制域名长度、明确字符范围（仅允许域名合法字符）。
  • 示例：若原正则为^(([a-zA-Z0-9-]+)\.)+[a-zA-Z]{2,}$，可改为^(?>[a-zA-Z0-9-]+\.)+[a-zA-Z]{2,}$，或拆分域名段逐个校验，避免嵌套重复引发的回溯。

3. 完善CORS校验逻辑 #

• 增加前置校验：先检查Origin/Referer长度，超过合理范围（如256字符）直接拒绝；过滤包含*、\等非域名合法字符的请求。
• 维护合法Origin白名单：优先匹配白名单，命中则跳过正则校验；未命中的请求要么走严格正则校验，要么直接拒绝（根据业务需求）。

4. 排查请求来源 #

• 查看EC2访问日志，定位触发问题的具体请求（重点看Origin/Referer字段值），确认是恶意攻击还是业务侧异常请求。
• 若是恶意请求，后续在WAF层添加拦截规则，避免同类请求再次触发问题。

5. 验证修复效果 #

• 修复后在测试环境构造触发回溯的异常请求（如超长域名字符串），验证CPU使用率是否恢复正常。
• 部署到生产环境后，持续监控CPU指标和线程状态，确保问题不再复现。

内容的提问来源于stack exchange，提问作者Karthik sharma