Spring 中的 Open Session In View 详解

最后修改:2024年1月27日

by Ali Dehghani

1. 概述

“会话绑定请求”（Session per Request）是一种常见的事务模式，其核心思想是将持久化会话（Session）的生命周期与 HTTP 请求绑定在一起。Spring 提供了对此模式的实现——OpenSessionInViewInterceptor，用于简化懒加载关联对象的处理，从而提升开发效率。

本文将深入剖析该机制的内部原理，并探讨这个颇具争议的模式如何在提升便利性的同时，也可能成为性能隐患的源头。踩坑容易，排坑难，务必谨慎。

2. Open Session In View 简介

要理解 Open Session In View（简称 OSIV）的作用，先看一个典型请求流程：

✅ Spring 在请求开始时创建一个 Hibernate Session（注意：此时不一定已建立数据库连接）
✅ 后续所有需要 Session 的操作都会复用这个已存在的实例
✅ 请求结束时，由拦截器统一关闭该 Session

初看之下，这似乎是个“省心”功能：框架自动管理会话的开闭，开发者无需关心底层细节，专注业务逻辑即可。这确实能显著提升开发效率。

⚠️ 然而，OSIV 在生产环境中可能引发隐蔽的性能问题，且这类问题往往难以定位。

2.1. Spring Boot 中的默认行为

Spring Boot 默认启用了 OSIV。从 2.0 版本起，若未显式配置，启动时会输出警告：

spring.jpa.open-in-view is enabled by default. Therefore, database 
queries may be performed during view rendering. Explicitly configure 
spring.jpa.open-in-view to disable this warning

提示很明确：数据库查询可能发生在视图渲染阶段（比如模板填充时），存在潜在风险。

可通过配置关闭：

spring.jpa.open-in-view=false

2.2. 是模式还是反模式？

关于 OSIV 的争议由来已久：

  • ✅ 支持者观点：极大提升开发效率，尤其在处理懒加载关联（lazy associations）时，避免大量 LazyInitializationException
  • ❌ 反对者观点：可能导致数据库连接池耗尽、意外的 N+1 查询等问题，影响系统性能

下文将从实际场景出发，剖析这两方面的利弊。

3. 懒加载的“救星”？

由于 OSIV 将 Session 生命周期绑定到整个请求，即使在 @Transactional 方法返回后，Hibernate 仍能正常加载懒关联数据。

我们以用户及其权限为例：

@Entity
@Table(name = "users")
public class User {

    @Id
    @GeneratedValue
    private Long id;

    private String username;

    @ElementCollection
    private Set<String> permissions;

    // getters and setters
}

permissions 是一个典型的懒加载集合。

服务层代码如下，明确使用 @Transactional 划定事务边界：

@Service
public class SimpleUserService implements UserService {

    private final UserRepository userRepository;

    public SimpleUserService(UserRepository userRepository) {
        this.userRepository = userRepository;
    }

    @Override
    @Transactional(readOnly = true)
    public Optional<User> findOne(String username) {
        return userRepository.findByUsername(username);
    }
}

3.1. 理想情况

调用 findOne 时，预期流程如下：

  1. Spring 事务代理拦截调用，获取或创建事务
  2. 执行方法逻辑
  3. 事务提交，**Session 被关闭**

由于 permissions 未显式初始化，**方法返回后访问该属性应抛出 LazyInitializationException**。

3.2. 现实情况

我们写一个 REST 接口，尝试在转换为 DTO 时访问 permissions：

@RestController
@RequestMapping("/users")
public class UserController {

    private final UserService userService;

    public UserController(UserService userService) {
        this.userService = userService;
    }

    @GetMapping("/{username}")
    public ResponseEntity<?> findOne(@PathVariable String username) {
        return userService
                .findOne(username)
                .map(DetailedUserDto::fromEntity)
                .map(ResponseEntity::ok)
                .orElse(ResponseEntity.notFound().build());
    }
}

DTO 转换中会遍历 permissions，按理说应触发异常。但实际测试通过：

@SpringBootTest
@AutoConfigureMockMvc
@ActiveProfiles("test")
class UserControllerIntegrationTest {

    @Autowired
    private UserRepository userRepository;

    @Autowired
    private MockMvc mockMvc;

    @BeforeEach
    void setUp() {
        User user = new User();
        user.setUsername("root");
        user.setPermissions(new HashSet<>(Arrays.asList("PERM_READ", "PERM_WRITE")));

        userRepository.save(user);
    }

    @Test
    void givenTheUserExists_WhenOsivIsEnabled_ThenLazyInitWorksEverywhere() throws Exception {
        mockMvc.perform(get("/users/root"))
          .andExpect(status().isOk())
          .andExpect(jsonPath("$.username").value("root"))
          .andExpect(jsonPath("$.permissions", containsInAnyOrder("PERM_READ", "PERM_WRITE")));
    }
}

测试通过，说明 permissions 成功加载。

原因：OSIV 在请求开始时已创建 Session，事务代理复用了这个 Session，并未在方法结束后立即关闭。因此，整个请求周期内都可安全访问懒加载属性。

3.3. 对开发效率的影响

若关闭 OSIV，开发者必须手动初始化所有懒加载属性。最常见（但不推荐）的做法是使用 Hibernate.initialize()：

@Override
@Transactional(readOnly = true)
public Optional<User> findOne(String username) {
    Optional<User> user = userRepository.findByUsername(username);
    user.ifPresent(u -> Hibernate.initialize(u.getPermissions()));
    return user;
}

可见，OSIV 确实简化了开发。但便利的背后，是潜在的性能代价。

4. 性能的“隐形杀手”

考虑一个扩展场景：在查出用户后，需调用远程服务：

@Override
public Optional<User> findOne(String username) {
    Optional<User> user = userRepository.findByUsername(username);
    if (user.isPresent()) {
        // 调用远程服务，如 HTTP 请求
        remoteService.call(user.get());
    }
    return user;
}

此时，我们移除了 @Transactional 注解，避免长时间持有事务。

4.1. 避免混合 IO 操作

若保留 @Transactional，会发生什么？

假设远程服务响应较慢：

  1. 事务开始，Session 创建（尚未连接数据库）
  2. 执行查询，Session 获取数据库连接
  3. 调用远程服务期间，数据库连接持续被占用

⚠️ 若此时请求量突增，所有连接可能都被阻塞在远程调用上，导致数据库连接池耗尽。

在事务中混合数据库 IO 与其他 IO（如网络调用）是典型坏味道，必须避免。

我们本以为移除 @Transactional 就安全了，但 OSIV 的存在让事情变得复杂。

4.2. 连接池耗尽风险

只要 OSIV 启用，每个请求都绑定一个 Session。即使服务方法无事务，该 Session 一旦执行数据库操作，就会获取连接并一直持有到请求结束。

因此，上述看似“优化”后的代码，在 OSIV 下仍是隐患：

@Override
public Optional<User> findOne(String username) {
    Optional<User> user = userRepository.findByUsername(username);
    if (user.isPresent()) {
        // 远程调用期间，数据库连接仍被占用！
        remoteService.call(user.get());
    }
    return user;
}

流程如下：

  1. 请求开始，OSIV 过滤器创建 Session
  2. 查询用户，Session 获取连接
  3. 调用远程服务，连接未释放
  4. 请求结束，OSIV 关闭 Session，连接归还

结果：高并发 + 慢远程调用 → 连接池耗尽 → 应用无响应

更糟的是，问题根源（慢远程服务）与症状（数据库连接不足）看似无关，导致线上问题极难排查。

4.3. 额外的无效查询

除了连接池问题，OSIV 还可能导致：

  • ✅ 意外触发懒加载查询：在 Controller 或 View 层访问未初始化的属性，会触发额外 SQL
  • ✅ N+1 查询问题：遍历集合时逐个加载关联对象
  • ✅ 自动提交模式执行：这些额外查询在 auto-commit=true 模式下执行，每条 SQL 都是一次独立事务，加重数据库负担

这些查询往往在开发环境难以发现，直到线上才暴露。

5. 如何选择？

OSIV 是模式还是反模式？答案取决于你的场景。

  • ✅ 适合场景：简单 CRUD 应用，无远程调用，懒加载使用频繁。开启 OSIV 可显著提升开发体验。
  • ❌ 禁用场景：涉及大量远程调用、异步处理或复杂业务流程。建议关闭 OSIV，避免潜在性能问题。

建议策略：

  • 新项目默认关闭 OSIV（spring.jpa.open-in-view=false）
  • 若后续出现 LazyInitializationException，再根据情况决定是否开启或采用其他方案
  • 已开启 OSIV 的项目，关闭需谨慎，可能引发大量懒加载异常，需逐一处理

关键是要清楚权衡利弊。

6. 替代方案

关闭 OSIV 后，需解决懒加载异常问题。以下是两种推荐做法：

6.1. 实体图（Entity Graphs）

在 Spring Data JPA 中，使用 @EntityGraph 可声明式地预加载关联数据：

public interface UserRepository extends JpaRepository<User, Long> {

    @EntityGraph(attributePaths = "permissions")
    Optional<User> findByUsername(String username);
}

此方式会生成 JOIN 查询，一次性加载主实体及指定关联，避免多次查询。

若需不同粒度的数据，可定义多个方法：

public interface UserRepository extends JpaRepository<User, Long> {
    @EntityGraph(attributePaths = "permissions")
    Optional<User> findDetailedByUsername(String username);

    Optional<User> findSummaryByUsername(String username);
}

6.2. Hibernate.initialize() 的坑

有人可能建议用 Hibernate.initialize() 手动初始化：

@Override
@Transactional(readOnly = true)
public Optional<User> findOne(String username) {
    Optional<User> user = userRepository.findByUsername(username);
    user.ifPresent(u -> Hibernate.initialize(u.getPermissions()));
    return user;
}

或者简单调用 getter 触发加载：

user.ifPresent(u -> u.getPermissions().size());

⚠️ 不推荐这两种方式，原因如下：

  • 会生成至少两条 SQL：主查询 + 关联查询
  • 增加网络往返次数，性能不如 JOIN 查询

对比：

-- Hibernate.initialize() 方式
> select u.id, u.username from users u where u.username=?
> select p.user_id, p.permissions from user_permissions p where p.user_id=?

-- EntityGraph 或 Fetch Join 方式
> select u.id, u.username, p.user_id, p.permissions from users u 
  left outer join user_permissions p on u.id=p.user_id where u.username=?

结论：优先使用 @EntityGraph 或 JPQL 中的 JOIN FETCH，避免多次查询。

7. 总结

Open Session In View 是一把双刃剑。它在简化开发的同时，也可能引入连接池耗尽、额外查询等性能问题。作为有经验的开发者，应根据应用特点权衡是否启用。

核心建议：新项目默认关闭，按需开启；已有项目若开启，需警惕潜在风险。替代方案如 @EntityGraph 更加可控，推荐优先使用。

示例代码详见 GitHub 仓库。

原始标题:A Guide to Spring's Open Session In View

« 上一篇： Hibernate 错误 'Not all named parameters have been set' 详解
» 下一篇： Java Weekly, 第306期