Apache Shiro 1.2.3高CPU负载下登录耗时过长问题求助

首先，核心原因很明确：你的密码验证逻辑是CPU密集型操作，在CPU被后台数据进程占满的情况下，登录请求的验证线程只能排队等待CPU资源，导致耗时大幅增加。

具体细节拆解 #

• 哈希迭代的高CPU成本：你使用了SHA-512算法+100000次迭代来存储和验证密码，这种设计本来就是为了提升暴力破解的难度——但代价是单次验证需要消耗大量CPU算力。CPU空闲时，这个运算能在0.5秒左右完成；但当CPU被后台进程占满到100%时，登录验证的线程无法获得足够的CPU时间片，只能等待，自然会把耗时拉长到20-35秒。
• 代码中的关键耗时点：你提到的this.getCredentialsMatcher().doCredentialsMatch(token, info)最终会调用自定义HashingPasswordService里的passwordsMatch方法，其中的this.hashService.computeHash(request)就是执行10万次SHA-512迭代计算的地方，这一步是整个登录流程的CPU消耗核心。
• 线程资源竞争：默认情况下，登录验证线程和后台数据处理线程的优先级是相同的，高负载下没有资源抢占优势，进一步加剧了等待时间。

可行的优化方案 #

• 平衡安全与性能，调整迭代次数：10万次迭代虽然安全，但在高负载场景下性能代价过高。可以根据你的安全需求评估，适当降低迭代次数（比如调整到5万次，具体需结合安全合规要求），减少单次验证的CPU消耗。
• 优化后台进程的CPU占用：
  • 给后台数据处理线程设置较低的线程优先级，让登录验证线程能优先获取CPU资源；
  • 对后台数据处理做限流或异步批量处理，避免长时间持续占满CPU。
• 引入验证结果缓存：对最近登录成功的用户，短时间内缓存其验证状态（注意缓存有效期不能太长，避免安全风险），重复登录时直接返回结果，跳过哈希运算步骤。
• 分离验证服务：把密码验证逻辑独立部署到专门的服务实例，让登录验证有专属的CPU资源，不再和后台数据处理争抢资源。

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