Spring MVC应用高并发会话下偶现数据覆盖问题求助

1. JDK版本差异引发的并发行为变化 #

• JDK 8到11的Java内存模型（JMM）实现细节有调整：JDK 8默认使用ParallelGC，而JDK 11默认采用G1GC，垃圾收集器的差异会影响对象的内存可见性。如果代码中存在未正确同步的共享变量，JDK 11下线程间的内存屏障策略变化可能导致某个线程无法及时读取到其他线程更新后的值，进而基于旧数据修改，覆盖正确的产品信息。
• 并发工具类的实现优化：JDK 11对ConcurrentHashMap、Atomic系列类等并发组件做了底层优化，若代码依赖了JDK 8中某些未被官方承诺的“巧合行为”（比如特定场景下的锁粒度），升级到JDK 11后这些行为改变会触发隐藏的竞态条件。

2. Wildfly生产与开发环境的配置差异 #

• 线程池配置：生产环境Wildfly通常会配置更大的线程池来处理高并发请求，而开发机线程数较少，冲突概率极低，导致竞态条件在开发压测中无法复现。更多并发线程同时操作同一订单数据时，未加保护的更新逻辑会直接覆盖彼此的修改。
• 事务隔离级别与传播行为：若开发机使用的事务隔离级别（如REPEATABLE READ）比生产环境（如READ COMMITTED）更严格，生产环境下的不可重复读问题会导致线程读取到中间状态的数据进行更新。另外，生产环境可能开启了分布式事务，事务同步的延迟也会放大数据覆盖的概率。
• 缓存机制：生产环境若启用了Hibernate二级缓存或Wildfly内置的缓存服务，缓存同步策略配置不当（如未设置失效时间、同步模式错误）会导致部分线程读取到缓存中的旧产品数据，更新后覆盖数据库中的正确值。

3. 代码中隐藏的并发漏洞（高并发场景下触发） #

• 非线程安全的共享状态：Spring MVC的Controller、Service默认是单例Bean，若这些Bean中存在未加同步的成员变量（比如用于临时存储订单信息的实例变量），高并发下多个线程会同时修改该变量，JDK 8下可能因指令重排的概率低未暴露，而JDK 11的即时编译优化会让这种冲突频繁发生。
• 乐观锁实现失效：如果订单表使用版本号做乐观锁，但更新逻辑中未正确校验版本号（比如UPDATE语句未带上version = ?条件），或者版本号更新时机错误，多个线程读取同一版本的订单数据后，后执行的更新会直接覆盖先执行的修改。
• 无保护的数据库更新：若更新订单产品的SQL语句是UPDATE booking SET product = ? WHERE user_id = ?，未使用行锁（如SELECT ... FOR UPDATE）或唯一约束，多个线程针对同一用户的并发更新会导致后执行的SQL覆盖前一个的结果。

4. 类加载与字节码生成的差异 #

• JDK 11引入了模块化系统（JPMS），部分依赖类的加载逻辑发生变化。如果Spring MVC的代理类（如CGLIB、JDK动态代理）在模块化环境下生成的字节码存在同步逻辑缺失，原本的同步方法可能失去线程安全特性。
• JDK 11的即时编译器（JIT）优化策略与JDK 8不同，比如对同步块的锁消除、锁粗化规则调整，可能导致代码中原本的同步逻辑被意外优化掉，触发竞态条件。

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