在 Spring WebFlux 响应式环境中，即使未显式管理线程，共享的 HmacUtils 实例（尤其基于 HMAC_MD5）仍可能因底层 Mac 实现非线程安全而引发竞态条件，导致 hmacHex() 返回不一致结果。
在 spring webflux 响应式环境中，即使未显式管理线程，共享的 `hmacutils` 实例（尤其基于 `hmac_md5`）仍可能因底层 `mac` 实现非线程安全而引发竞态条件，导致 `hmachex()` 返回不一致结果。
Spring WebFlux 基于 Netty 构建，采用事件驱动、多线程非阻塞模型——同一 HmacUtils 实例（如 public static final HmacUtils HMAC_UTILS = new HmacUtils(HmacAlgorithms.HMAC_MD5, "secret");）会被多个 Netty I/O 线程（如 reactor-netty-epoll-X）并发调用。虽然 Apache Commons Codec 的 HmacUtils 类本身是不可变且线程安全的，但其内部封装的 javax.crypto.Mac 实例并非如此。
关键问题在于：Mac 是有状态对象。以 JDK 默认的 HmacMD5 实现为例，它内部持有 MD5Digest（来自 Bouncy Castle 或 SunJCE），该摘要器维护内部字节数组和计数器（如 byteCount, state[]）。当多个线程同时调用 mac.update() 和 mac.doFinal() 时，状态被交叉修改，导致计算结果错乱——这正是你观察到“相同输入返回不同 hmacHex 值”的根本原因。synchronized 临时修复只是掩盖了问题，而非消除风险。
✅ 正确解决方案如下：
-
避免复用
Mac实例（推荐）
每次计算都创建新Mac，利用HmacUtils的静态工具方法（无状态）：// ✅ 安全：每次调用都新建 Mac 实例 String signature = HmacUtils.hmacHex(HmacAlgorithms.HMAC_MD5, "secret", "data".getBytes(StandardCharsets.UTF_8));
-
改用线程安全的算法实现
JDK 的HmacSHA256等现代算法在多数 Provider 中已实现线程安全（如SunJCE），但 MD5/SHA1 仍需谨慎。可显式指定 Provider 并验证：// 尝试使用 Bouncy Castle（需添加依赖） Security.addProvider(new BouncyCastleProvider()); String sig = HmacUtils.hmacHex( HmacAlgorithms.HMAC_MD5, "secret", "data".getBytes(), BouncyCastleProvider.PROVIDER_NAME ); -
使用
ThreadLocal<mac></mac>（慎用）
若性能敏感且必须复用，可用ThreadLocal隔离实例（注意内存泄漏风险）：private static final ThreadLocal<Mac> MAC_HOLDER = ThreadLocal.withInitial(() -> { try { return Mac.getInstance(HmacAlgorithms.HMAC_MD5.getName()); } catch (Exception e) { throw new IllegalStateException(e); } });
⚠️ 注意事项：
-
HMAC_MD5已属弱加密算法，生产环境应禁用，改用HmacSHA256或更高强度算法； - 所有
Mac实例均需通过Mac.getInstance(algorithm)获取，禁止跨线程共享； - 单元测试中 Flaky 行为往往是线程安全缺陷的早期信号，不可仅靠
synchronized或重试掩盖。
总结：响应式编程不等于自动线程安全——只要存在共享可变状态（哪怕隐藏在 Mac 内部），竞态条件就可能发生。始终遵循“无状态优先、按需创建、算法升级”三原则，才能写出真正健壮的 WebFlux 服务。
