Java中AES解密耗时过长问题求助

这种时快时慢的问题确实让人头疼，结合你描述的Red Hat + Tomcat + Java AES解密场景，我从几个常见方向帮你拆解可能的原因：

1. JCE权限策略的初始化阻塞 #

AES-256加密/解密需要Java Cryptography Extension (JCE)的无限制权限策略文件。在Red Hat的OpenJDK环境中，默认可能未启用该策略，或者第一次加载策略时需要读取系统文件、做权限校验——如果系统I/O繁忙、SELinux策略有延迟，这个初始化过程就会被卡很久。

为什么会有1/5的请求瞬时完成？大概率是线程复用：Tomcat线程池里的某些线程已经完成过一次JCE初始化，缓存了相关加密实例，后续请求复用这些线程时就不用再走初始化流程；而新创建的线程则需要重新触发这个慢初始化步骤。

对比另一个API，它可能在应用启动阶段就提前初始化了加密组件（比如静态代码块、Spring的@PostConstruct方法），把慢初始化的成本摊到了启动时，而非请求阶段。

2. 安全随机数生成器阻塞 #

AES解密（尤其是初始化Cipher实例时）通常会用到SecureRandom生成随机数或初始化向量。Red Hat Linux默认的SecureRandom实现依赖系统熵池（/dev/random）——如果服务器是虚拟机、没有足够硬件随机源（比如未配置HSM、TPM），熵池很容易被耗尽，SecureRandom会一直阻塞直到熵池有足够随机数据，这个过程可能长达十几分钟。

那为什么偶尔会快？当熵池刚好有足够数据时，请求能快速拿到随机数；多数时候熵池空了，就会陷入等待。另一个API可能用了非阻塞的随机源（比如/dev/urandom），或者提前预生成了随机数缓存，所以不会被卡住。

你可以试试：

• 在代码里把new SecureRandom()换成SecureRandom.getInstance("SHA1PRNG")
• 在Tomcat的JVM启动参数里添加-Djava.security.egd=file:/dev/./urandom，强制使用非阻塞熵源

3. 加密组件的复用问题 #

如果你的代码每次解密都新建Cipher实例（比如每次都调用Cipher.getInstance("AES/CBC/PKCS5Padding")），而没有做缓存，那每次请求都要重新查找算法、初始化组件，再加上前面的JCE或随机数问题，延迟就会被放大。

注意Cipher不是线程安全的，不能直接全局复用，但可以用ThreadLocal为每个线程存储一个实例，这样每个线程只初始化一次，后续请求复用即可。另一个API大概率已经做了这个优化，所以解密速度稳定在毫秒级。

4. SELinux或系统权限的隐性限制 #

Red Hat的SELinux可能对Java进程访问加密相关系统资源（比如JCE策略文件、熵设备）做了权限审计或限制，偶尔会触发延迟的权限检查，甚至阻塞进程。你可以去/var/log/audit/audit.log里看看有没有和Java进程、加密操作相关的拒绝记录或审计日志，这可能是间歇性延迟的诱因。

5. 先定位具体慢的环节 #

建议先在代码里加精确的计时日志，比如：

long start = System.currentTimeMillis();
// 密钥初始化步骤
long keyInitEnd = System.currentTimeMillis();
// Cipher初始化步骤
long cipherInitEnd = System.currentTimeMillis();
// 解密操作步骤
long decryptEnd = System.currentTimeMillis();

logger.info("密钥初始化耗时: {}ms, Cipher初始化耗时: {}ms, 解密耗时: {}ms",
    keyInitEnd - start, cipherInitEnd - keyInitEnd, decryptEnd - cipherInitEnd);

通过日志明确是哪一步慢，再针对性排查，比盲目猜原因效率高得多。

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