Spring Boot 1.4升级至2.2后SQL Server出现行锁，默认隔离级别是否变更？

针对你把Spring Boot应用从1.4版本升级到2.2版本后，遇到SQL Server行锁定（row in use）的问题，我来梳理下这个版本区间内和事务隔离级别、ORM行为相关的关键变化，帮你定位问题：

核心结论：Spring默认隔离级别本身未变，但配套组件的默认行为有调整 #

首先明确：Spring（包括Spring Boot）的@Transactional注解默认隔离级别一直是Isolation.DEFAULT，也就是直接沿用数据库的默认隔离级别——SQL Server的默认隔离级别是READ COMMITTED，这一点在你升级前后没有变化。但升级后出现锁定问题，大概率是Spring Data JPA、Eclipselink或SQL Server驱动/连接池的默认配置变化导致的锁定行为改变。

关键版本差异点梳理 #

1. Spring Data JPA事务属性的细微调整 #

在Spring Boot 1.4（基于Spring Framework 4.3）中，Spring Data JPA的SimpleJpaRepository默认CRUD方法的事务配置：

• 查询类方法（如findById()）默认是只读事务
• 修改类方法（如save()、delete()）使用默认事务属性

到Spring Boot 2.2（基于Spring Framework 5.2），虽然核心逻辑没变，但Spring对事务的只读属性传播、EntityManager的事务同步机制做了更严格的处理。比如，只读事务会被Eclipselink更彻底地优化，可能导致某些查询的锁定行为和之前不同；另外，事务的超时时间默认配置也有调整，可能间接引发锁定等待。

2. Eclipselink与Spring Boot整合的默认配置变更 #

Spring Boot 2.x对Eclipselink的自动配置做了不少优化，其中和锁定相关的关键点：

• 事务隔离级别传递：Spring Boot 1.4中，Spring的事务隔离级别可能没有完全传递给Eclipselink的EntityManager，导致实际运行时使用的是Eclipselink的默认隔离级别（可能和数据库默认有差异）；而2.2版本修复了这个问题，严格沿用数据库的READ COMMITTED，如果你的代码之前依赖了这种“不严格”的隔离行为，就会触发之前没出现的行锁定。
• 缓存与锁定机制：Eclipselink的一级缓存（EntityManager缓存）在Spring Boot 2.2中的默认行为有调整，比如默认启用的缓存刷新策略可能导致更频繁的数据库交互，进而触发行锁定；另外，悲观锁的默认超时时间配置也可能有变化。

3. SQL Server驱动与连接池的默认变化 #

• 驱动版本升级：Spring Boot 1.4默认使用的是mssql-jdbc 6.x版本，而2.2默认使用7.x+版本，新版本驱动对SQL Server的隔离级别、锁定行为的处理有细节调整，比如默认是否启用快照隔离的兼容性处理。
• 连接池切换：Spring Boot 2.x默认使用HikariCP作为连接池，而1.4默认是Tomcat JDBC连接池。两个连接池对事务隔离级别的默认传递方式、连接复用策略不同，可能导致会话的隔离级别设置出现差异，引发锁定。

排查建议 #

• 确认实际运行的隔离级别：在代码中添加调试代码，打印当前EntityManager的事务隔离级别：

  EntityManager em = ...; // 获取EntityManager
  System.out.println("Current isolation level: " + em.getTransaction().getIsolationLevel());
  

  或者在SQL Server中执行DBCC USEROPTIONS查看当前会话的隔离级别配置。
• 检查Eclipselink配置：查看是否有eclipselink.jdbc.isolation-level配置项，Spring Boot 2.2中这个属性的默认值可能和1.4不同；另外检查eclipselink.lock.timeout等锁定相关参数。
• 审计事务注解：排查代码中自定义的@Transactional注解，是否在升级后某些方法的隔离级别被意外修改；同时检查Spring Data JPA的自定义查询方法是否有新增的锁定注解（如@Lock）。
• 排查乐观锁误用：如果你的实体类使用了版本字段（@Version），升级后Eclipselink的乐观锁机制是否被默认启用，导致更新时出现版本冲突引发的锁定提示。

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