Spring整合Hibernate实战：事务、懒加载与夏令时排雷指南

先交代一个背景：我最近在帮人维护一个2015年上线、至今还在稳定跑业务的老项目，技术栈是 Spring 4 + Hibernate 4，后来升到 5.x。这类系统最大的问题不是代码难懂，而是当初的集成配置逻辑已经没人能完整说清楚了——大家只记得"这么配能跑"，却不知道为什么这么配。所以当我想把 Spring 整合 Hibernate 这件事重新梳理一遍时，我意识到这不仅是写给新手看的教程，更是写给所有还要面对遗留系统的开发者的一份排雷手册。

Spring 和 Hibernate 这对组合，一句"经典"不足以概括。它经历过 XML 满天飞的时代，也见证了注解和 Spring Boot 的崛起。即便在今天，Hibernate 依然是 Spring Data JPA 底层的默认实现，大量金融、政务、传统企业的核心系统还在用它跑着亿万级数据。你早晚会遇到它，与其到时候对着报错一脸懵，不如现在把整合的原理和细节一次吃透。这篇文章不讲空话，直接带你从依赖配置、SessionFactory 构建、事务边界，一直走到夏令时日期错乱、懒加载异常、N+1 查询这些实战深水区。

1. 为什么还要手动集成 Hibernate：老技术栈的现实抉择

1.1 Spring Boot 时代，为什么还要懂这套整合

先说个很多人误解的点：Spring Boot 出现后，spring-boot-starter-data-jpa 确实让你一个注解就能跑起 JPA，但它的底层还是 Hibernate。而你在网上搜到的绝大多数"Spring Boot + JPA"教程，其实都在使用 Spring 整合 Hibernate 的那套机制，只不过被 Boot 的自动配置给包起来了。

所以手动整合 Hibernate 这件事，不是过时的技能，而是理解 Spring Boot 自动配置的一把钥匙。你只有亲手配过 LocalSessionFactoryBean、HibernateTransactionManager、@Transactional 之间的关系，才能明白为什么 Boot 里改一个 spring.jpa.hibernate.ddl-auto 就会影响建表行为，为什么 OpenEntityManagerInViewFilter 这个过滤器能解决懒加载异常，为什么事务注解没生效时会出现各种诡异的连接问题。

另外，遗留项目不会消失。现实中你接触到的很多系统，代码还是 Spring MVC + XML 配置的骨架，只是在上面打了补丁。我见过太多在旧项目上做新需求的开发者，连 HibernateTemplate 和 getCurrentSession() 的区别都说不清，遇到 Session is closed 就束手无策。这些能力，只有回到手动整合的层面上才能真正学明白。

1.2 整合前必须先想清楚的四个问题

别急着写代码，先把这几个问题想透：

1. 事务边界在哪里？ 一个请求对应一个事务，还是一个 Service 方法对应一个事务？这决定了你怎么配置 Session 的生命周期。
2. Session 的作用域怎么定？ Hibernate 的 Session 不是线程安全的，它应该绑定到当前线程，还是每次都新建？
3. 懒加载要不要用？ 实体关联关系默认是懒加载的，如果 Service 层事务结束了，Controller 再去访问关联对象，就会抛 LazyInitializationException。
4. 连接池用什么？ 早期流行 c3p0，后来有了 HikariCP。你是在维护老项目，还是从零搭建？这决定你的选型。

这四个问题，本质上都指向同一个核心：Hibernate 的 Session 和 Spring 管理的事务，如何协同工作。把这条主线抓住，整合的每一步配置就都有了解释。

2. 依赖与数据源落地：从 Maven 坐标到连接池

2.1 最小依赖集合与版本矩阵

先说版本。Spring 4.3.x 对应 Hibernate 5.2.x，Spring 5.2.x 对应 Hibernate 5.4.x，Spring 6.x 需要 Hibernate 6.x 和 Java 17。如果你在维护老项目，不要盲目升级 Hibernate 大版本——Hibernate 6 对 5 有很多不兼容的改动，SessionFactory 的构建方式、类型系统、甚至 SQL 生成规则全变了，升级成本远比你想象的高。

一个经典的 Spring 4.3 + Hibernate 5.2 基础依赖长这样：

xml复制<properties>
    <spring.version>4.3.30.RELEASE</spring.version>
    <hibernate.version>5.2.18.Final</hibernate.version>
</properties>

<dependencies>
    <!-- Spring 核心与 ORM 模块 -->
    <dependency>
        <groupId>org.springframework</groupId>
        <artifactId>spring-context</artifactId>
        <version>${spring.version}</version>
    </dependency>
    <dependency>
        <groupId>org.springframework</groupId>
        <artifactId>spring-orm</artifactId>
        <version>${spring.version}</version>
    </dependency>
    <dependency>
        <groupId>org.springframework</groupId>
        <artifactId>spring-tx</artifactId>
        <version>${spring.version}</version>
    </dependency>

    <!-- Hibernate ORM -->
    <dependency>
        <groupId>org.hibernate</groupId>
        <artifactId>hibernate-core</artifactId>
        <version>${hibernate.version}</version>
    </dependency>
    <dependency>
        <groupId>org.hibernate</groupId>
        <artifactId>hibernate-c3p0</artifactId>
        <version>${hibernate.version}</version>
    </dependency>

    <!-- MySQL 驱动 -->
    <dependency>
        <groupId>mysql</groupId>
        <artifactId>mysql-connector-java</artifactId>
        <version>5.1.49</version>
    </dependency>
</dependencies>

注意 hibernate-c3p0 和 c3p0 是不一样的。Hibernate 官方提供的集成包会自动引入 c3p0 核心库，并且把 Hibernate 自己的连接池策略切换到 c3p0。如果你看到老项目里单独配了 c3p0-xxx.jar，建议确认版本一致性，避免出现类冲突。

2.2 SessionFactory 构建的两种姿势

手动整合最核心的一步，就是让 Spring 帮你构建 SessionFactory。常用的是 Spring 提供的 LocalSessionFactoryBean，它有三个必须配置的项目：数据源、Hibernate 属性、实体映射位置。

以 JavaConfig 为例：

java复制@Configuration
@EnableTransactionManagement
public class HibernateConfig {

    @Bean
    public DataSource dataSource() {
        ComboPooledDataSource ds = new ComboPooledDataSource();
        try {
            ds.setDriverClass("com.mysql.jdbc.Driver");
            ds.setJdbcUrl("jdbc:mysql://localhost:3306/legacy_db?useSSL=false&serverTimezone=Asia/Shanghai");
            ds.setUser("root");
            ds.setPassword("123456");
        } catch (PropertyVetoException e) {
            throw new RuntimeException(e);
        }
        return ds;
    }

    @Bean
    public LocalSessionFactoryBean sessionFactory(DataSource dataSource) {
        LocalSessionFactoryBean factoryBean = new LocalSessionFactoryBean();
        factoryBean.setDataSource(dataSource);
        factoryBean.setPackagesToScan("com.example.entity");

        Properties props = new Properties();
        props.put("hibernate.dialect", "org.hibernate.dialect.MySQL5Dialect");
        props.put("hibernate.show_sql", "true");
        props.put("hibernate.format_sql", "true");
        props.put("hibernate.hbm2ddl.auto", "validate");
        props.put("hibernate.current_session_context_class", "org.springframework.orm.hibernate5.SpringSessionContext");
        factoryBean.setHibernateProperties(props);

        return factoryBean;
    }
}

这里有几处容易踩坑的细节：

• packagesToScan 指定实体包路径，Spring 会扫描 @Entity 注解的类并自动注册映射。如果你用的是 XML 映射文件，则用 setMappingResources 或 setMappingLocations，两者不要混用，否则会重复映射。
• hibernate.current_session_context_class 必须设为 SpringSessionContext，否则 sessionFactory.getCurrentSession() 会抛 No CurrentSessionContext configured 错误。这个配置会在 Spring 事务中把当前的 Hibernate Session 绑定到事务线程上。
• hibernate.hbm2ddl.auto 在生产和开发环境要区分。开发环境可以用 update，生产环境建议 validate 或 none，否则一个误操作可能把线上表结构改了。

2.3 c3p0 连接池参数怎么定才务实

热搜词里有 "struts2 hibernate c3p0" 这个组合，说明老项目里 c3p0 出场率是真的高。c3p0 的配置，我一直建议按下面的优先级去定：先用默认值跑通，再根据监控数据调整。

properties复制# c3p0 连接池配置
hibernate.c3p0.min_size=3
hibernate.c3p0.max_size=20
hibernate.c3p0.timeout=300
hibernate.c3p0.max_statements=50
hibernate.c3p0.idle_test_period=120

我在老项目上遇到过最经典的问题：数据库设置了 wait_timeout=28800（8小时），但 c3p0 没有设置 idle_test_period，导致空闲一晚上的连接第二天全变成死连接，早晨第一波请求全部报 Communications link failure。这个问题排查起来极其迷惑，因为连接池的日志显示连接是"活的"，实际上 MySQL 早就把连接断掉了。所以 idle_test_period 一定要小于数据库的 wait_timeout，并且加上连接有效性检测（testConnectionOnCheckout=true 或 preferredTestQuery）。

3. 事务边界与 Session 生命周期：集成成败的核心枢纽

3.1 Hibernate Session 到底该活多久

这个问题的答案直接决定你的系统是稳定还是诡异。Hibernate 的 Session 是轻量级对象，但不是线程安全的，它对应一个数据库事务（或者说一个逻辑工作单元）。最正确的生命周期是：一个业务操作（一个事务）一个 Session，操作结束、事务提交，Session 立即关闭。

如果你把 Session 当成 JDBC Connection 一样，用完之后只回收不关闭，甚至让它跨越多个请求，那恭喜你，你会在多线程环境下遇到各种随机报错：concurrent access、Session closed、object references an unsaved transient instance，而且很难复现。

Spring 整合 Hibernate 的核心作用，就是通过 HibernateTransactionManager 把 Session 的生命周期和 Spring 事务绑定起来：事务开始时，从 SessionFactory 中获取一个 Session（如果当前线程没有的话）；事务提交时，刷新 Session 并关闭；事务回滚时，关闭 Session。你的业务代码不需要手动调用 session.openSession() 或 session.close()，只需要保证事务边界正确。

3.2 声明式事务的正确配置方式

Spring 的声明式事务，核心是一个 TransactionManager 加一行 @Transactional。整合 Hibernate 时，事务管理器必须是 HibernateTransactionManager：

java复制@Bean
public HibernateTransactionManager transactionManager(SessionFactory sessionFactory) {
    HibernateTransactionManager txManager = new HibernateTransactionManager();
    txManager.setSessionFactory(sessionFactory);
    return txManager;
}

@EnableTransactionManagement 注解必须放在一个 @Configuration 类上，它的作用是注册一个 BeanFactoryTransactionAttributeSourceAdvisor，让 Spring 扫描 @Transactional 注解。

有几个细节影响了事务是否真正生效，我几乎每次都会被问到：

• @Transactional 要放在接口实现类上，或者干脆放在实现类里。 如果只放在接口方法上，而实现类没有实现接口（或用 CGLIB 代理），事务可能不生效。Spring 官方建议直接标注在实现类或类级别。
• 同一个类内部调用带 @Transactional 的方法，事务不生效。 因为 this.method() 不会经过 Spring 生成的代理对象。解决方式：把方法拆到另一个 Bean，或通过 AopContext.currentProxy()（需要配置 exposeProxy=true）。
• HibernateTransactionManager 和 DataSourceTransactionManager 不要混用。 如果你在同一个项目里又用 MyBatis 又用 Hibernate，那得用 JtaTransactionManager 或分布式事务方案。日常单一数据源场景，就用 HibernateTransactionManager，它内部持有的还是那个 DataSource，只是额外接管了 Hibernate Session 的管理。

3.3 openSessionInView 模式的取舍

LazyInitializationException 是 Hibernate 新手最常遇见的异常。它发生在：Service 层方法上加了 @Transactional，事务在方法返回时就提交了，Session 关闭；然后 Controller 层试图访问一个懒加载的集合属性，这时候 Session 已经没了，Hibernate 报错。

解决办法有四种，按推荐程度排序：

1. 在事务边界内完成所有需要的关联数据加载。 这是最干净的方式，比如在 Service 层用 Hibernate.initialize(entity.getOrders()) 或写一个带 join fetch 的 HQL/JPQL 查询。
2. 用 DTO 组装好数据再返回 Controller。 不与实体直接打交道，一劳永逸地避免懒加载和序列化问题。
3. 开启 Open Session in View（OSIV）模式，用过滤器/拦截器在请求开始时打开 Session，请求结束时关闭。
4. 把实体关联改成 EAGER 抓取。 不推荐，会严重影响性能。

OSIV 模式在老项目里非常常见，配置也很简单：

java复制@Bean
public FilterRegistrationBean<OpenSessionInViewFilter> openSessionInViewFilter() {
    FilterRegistrationBean<OpenSessionInViewFilter> registration = new FilterRegistrationBean<>();
    registration.setFilter(new OpenSessionInViewFilter());
    registration.addUrlPatterns("/*");
    registration.setOrder(1);
    return registrationBean;
}

但我要泼一盆冷水：OSIV 让 Session 的生命周期延长到了整个 HTTP 请求，这违背了"事务内使用 Session"的原则。它会把数据库连接持有时间拉长，在高并发下很容易撞上连接池上限。我见过一个项目因为 OSIV 导致连接池 20 个连接全被占用，其他请求全部阻塞。所以这个模式适合低并发、重读场景的老系统，新项目尽量不要用。

4. 完整实操：用户模块的增删改查整合全流程

4.1 实体类映射的注意点

理论说完，上一段真实的代码。假设我们有一个用户表 t_user，对应实体：

java复制@Entity
@Table(name = "t_user")
public class User {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    @Column(name = "id")
    private Long id;

    @Column(name = "username", length = 64, nullable = false)
    private String username;

    @Column(name = "created_at")
    private Date createdAt;

    @Transient
    private String notPersistedField;

    // getter / setter 省略
}

几个注意点：

• @GeneratedValue(strategy = GenerationType.IDENTITY) 对应 MySQL 的自增主键。如果数据库用的是 Oracle 序列，要用 GenerationType.SEQUENCE 并配合 @SequenceGenerator。
• @Transient 标注的字段不会映射到数据库，但它和 Java 的 transient 关键字不是一回事，注意别混淆。
• 字段命名映射有个老坑：Hibernate 默认的物理命名策略会把 createdAt 映射成 createdat（全小写无下划线）。老项目里常见的做法是在属性上显式写 @Column(name = "created_at")，避免依赖命名策略。如果你用的是 Hibernate 5.x，可以在配置里指定 hibernate.physical_naming_strategy=org.springframework.boot.orm.jpa.hibernate.SpringPhysicalNamingStrategy 或自定义策略。

Hibernate 5 中字段访问方式的坑也值得提醒。如果 @Id 标注在 getId() 方法上，Hibernate 默认按属性访问（Property Access）；如果标注在 id 字段上，默认按字段访问（Field Access）。两者混用会导致 Hibernate 在运行时对某些字段访问不到值，报出 Could not determine type 或者 Unable to access field 的错误。规范做法：全用字段注解，保持风格统一。

4.2 DAO 层写法与 HibernateTemplate 的取舍

早期项目里你会看到两类 DAO：一类直接注入 SessionFactory 调 getCurrentSession()，另一类用 HibernateTemplate 封装。我个人的看法是：

• 新代码建议直接用 SessionFactory + Session，不要在 DAO 层多套一层 HibernateTemplate。 Spring 官方在 Spring 5 中已经标记 HibernateTemplate 为 deprecated（最终在 Spring 6 移除了 Hibernate 5 支持），它的存在主要是兼容旧代码。
• 直接操作 Session 的 DAO 长这样：

java复制@Repository
public class UserDao {

    @Autowired
    private SessionFactory sessionFactory;

    public User findById(Long id) {
        return getSession().get(User.class, id);
    }

    public void save(User user) {
        getSession().saveOrUpdate(user);
    }

    public List<User> findByUsername(String username) {
        String hql = "from User u where u.username = :username";
        Query<User> query = getSession().createQuery(hql, User.class);
        query.setParameter("username", username);
        return query.list();
    }

    private Session getSession() {
        return sessionFactory.getCurrentSession();
    }
}

注意 getCurrentSession() 必须在事务环境中调用。如果你在无事务的地方调用它，会抛 Session is closed 或 No Session found for current thread。这是个高频报错，本质原因就是没有 @Transactional。

4.3 懒加载异常排查：一个典型的 LazyInitializationException

我构造一个最常见的场景来演示排查链路。假设 User 有一个一对多关联订单：

java复制@OneToMany(mappedBy = "user", fetch = FetchType.LAZY)
private List<Order> orders = new ArrayList<>();

Service 层：

java复制@Service
public class UserService {

    @Autowired
    private UserDao userDao;

    @Transactional(readOnly = true)
    public User getUserById(Long id) {
        return userDao.findById(id);
    }
}

Controller 层：

java复制@RestController
public class UserController {

    @Autowired
    private UserService userService;

    @GetMapping("/user/{id}")
    public User getUser(@PathVariable Long id) {
        User user = userService.getUserById(id);
        System.out.println(user.getOrders().size());  // 这里抛 LazyInitializationException
        return user;
    }
}

报错信息是：

code复制org.hibernate.LazyInitializationException: failed to lazily initialize a collection of role: com.example.entity.User.orders, could not initialize proxy - no Session

排查链路是这样的：

1. 首先确认 getUserById 方法的事务边界。方法上虽然有 @Transactional(readOnly = true)，但方法执行完，事务就提交了，Session 随之关闭。
2. Controller 在事务外访问 user.getOrders()，此时 orders 只是一个未初始化的懒加载代理集合，需要访问数据库，但 Session 已关闭。
3. 解决办法不是给 Controller 加事务，而是把懒加载的集合在 Service 事务内初始化。

正确修法，在 Service 层完成数据加载：

java复制@Transactional(readOnly = true)
public User getUserByIdWithOrders(Long id) {
    User user = userDao.findById(id);
    Hibernate.initialize(user.getOrders()); // 事务内强制初始化
    return user;
}

或者更优雅一点，用 HQL 的 join fetch：

java复制public User findByIdWithOrders(Long id) {
    String hql = "select distinct u from User u left join fetch u.orders where u.id = :id";
    return getSession().createQuery(hql, User.class)
            .setParameter("id", id)
            .uniqueResult();
}

需要说明的是，上面这些懒加载陷阱不是说让你一律不用懒加载。正确姿势是：在事务边界内，把要用的关联数据按需加载完整；事务边界外，只做数据展示或 DTO 转换，不要访问任何懒加载属性。

5. 夏令时引发的日期错乱：Hibernate 的隐藏坑

5.1 问题现象与根因

热搜词里出现了 "hibernate日期夏令时报错"，这个话题值得单独写一章。我去年在一个做欧美市场的系统里遇到过这个问题：用户在美国东部时间（America/New_York）下单，数据库存的时间总是差一个小时，而且不是每天都差，只在每年 3 月第二个周日和 11 月第一个周日附近出现。

根因链条是这样的：

1. 数据库服务器时区是 UTC，JVM 默认时区是 America/New_York，JDBC 连接字符串里没有指定 serverTimezone。
2. Hibernate 在把 java.util.Date 写入数据库时，会调用 JDBC 驱动的 setTimestamp()，驱动会用 JVM 默认时区把时间转换成本地时间。
3. 夏令时切换时，America/New_York 在凌晨 2 点会跳到 3 点，这一小时内不存在的时间（如 2:30），驱动和 Hibernate 处理方式不一致，就会产生偏移。更隐蔽的是，在切换前后某些时间段，Timestamp 的转换会多出一个小时或少一个小时。

简单来说：时区设置不一致，叠加 JVM 默认时区和数据库时区的隐式转换，夏令时切换的瞬间就会出问题。

还有一个相关的经典错误：使用 MySQL 时，连接串没加 serverTimezone 参数，会直接报：

code复制The server time zone value 'EDT' is unrecognized or represents more than one time zone...

这是因为 MySQL 8.x 驱动（com.mysql.cj.jdbc.Driver）对时区校验非常严格。

5.2 修复方案与验证方式

我的建议是分三步处理，从源头消除时间错乱：

1. 统一所有的时区基准。 JVM 启动参数加 -Duser.timezone=UTC（或统一为 Asia/Shanghai），数据库时区也设为 UTC，JDBC 连接串明确写 serverTimezone=UTC。这样从数据库到应用层，全程 UTC 存储，展示时再按用户的本地时区转换。
2. 避免使用 java.util.Date 和 java.sql.Timestamp 做业务时间字段，优先使用 java.time.LocalDateTime 或 java.time.OffsetDateTime。 LocalDateTime 不携带时区信息，Hibernate 按数据库类型直接映射，彻底绕开 JVM 默认时区的隐式转换；OffsetDateTime 携带时区偏移，适合需要保留原始时区的场景。
3. 如果是老代码改不动，就在数据库连接串上做兜底。 MySQL 连接串追加 serverTimezone=UTC&useLegacyDatetimeCode=false，同时检查 Hibernate 的 hibernate.jdbc.time_zone 配置。

实体字段改造示例：

java复制// 推荐做法：用 LocalDateTime
@Column(name = "created_at")
private LocalDateTime createdAt;

// 保留原有时区信息：用 OffsetDateTime
@Column(name = "created_at_offset")
private OffsetDateTime createdAtOffset;

注意 Hibernate 5.2 之前的版本对 java.time 支持不够好，需要 hibernate-java8 模块。Hibernate 5.2 及以后，LocalDateTime、LocalDate、Instant 这些类型已经是内置支持，直接使用即可。

验证方式也很简单：写一个单元测试，模拟夏令时切换前后的时间点（比如 2023-03-12 01:30:00 和 2023-03-12 03:30:00），分别做一次写入和读取，断言读出来的时间与写入值一致。如果你能跑通这两个用例，说明时区配置是正确的。

6. 性能调优与维护建议：缓存、批量操作与实体设计

6.1 N+1 查询问题：集成方案最容易暴露的短板

Spring 整合 Hibernate 后，最常见的性能杀手就是 N+1 查询。上面 User 和 Order 的例子，如果查 100 个用户，再遍历每个用户取订单列表，你会看到 1 条用户查询 + 100 条订单查询，总共 101 条 SQL。

解决 N+1 的常规手段：

• HQL 里用 join fetch 显式抓取，一次性把关联集合查出来。
• 批量抓取（@BatchSize），在实体关联上标注：

java复制@OneToMany(mappedBy = "user", fetch = FetchType.LAZY)
@BatchSize(size = 20)
private List<Order> orders = new ArrayList<>();

这样加载 orders 时，Hibernate 会按 size 批量查询 IN 条件，把 N+1 变成 N/20+1。

• @Fetch(FetchMode.SUBSELECT)，用子查询一次加载所有关联集合，适合关联查询没有 IN 限制的场景。

在集成配置层面，你还可以打开 SQL 日志来观察 Hibernate 实际发出了多少条 SQL。hibernate.show_sql=true 这个配置在调试期很有用，但生产环境一定要关掉，否则日志量会非常大，反而拖垮性能。

6.2 二级缓存配置：能用，但别盲目开

Hibernate 的二级缓存（Second Level Cache）曾经被很多项目滥用，结果就是缓存一致性问题一大堆。这里说我的经验：

• 二级缓存适合缓存那些几乎不变的数据，比如字典表、配置表、部门树。不适合缓存频繁增删改的业务数据。
• Hibernate 5.x 需要引入 Ehcache 3 或 Infinispan 作为缓存实现。 如果引入了 hibernate-ehcache，要确认版本和 net.sf.ehcache 的兼容性，这个坑也踩过不少。
• 通过 @Cacheable 和 @Cache 注解标注实体：

java复制@Entity
@Cacheable
@org.hibernate.annotations.Cache(usage = CacheConcurrencyStrategy.READ_ONLY)
public class DictItem {
    ...
}

READ_ONLY 只适合完全不变的数据；如果有更新，用 READ_WRITE 但要承担缓存一致性的维护成本。对于绝大多数系统，先不加二级缓存，把 SQL 优化好，效果往往比引入缓存层更明显。

6.3 批量操作的注意事项

用 Hibernate 做批量插入，是另一个性能雷区。如果你写一个循环，每循环一次 session.save(user)，Hibernate 会先把实体放入持久化上下文（一级缓存），直到事务提交时才一次性 flush。如果循环 10 万次，一级缓存里就积累了 10 万个实体，内存直接爆炸。

标准解决方式是分段 flush 和 clear：

java复制@Transactional
public void batchInsert(List<User> users) {
    Session session = sessionFactory.getCurrentSession();
    for (int i = 0; i < users.size(); i++) {
        session.save(users.get(i));
        if (i % 50 == 0) {
            session.flush();    // 强制 SQL 写出
            session.clear();    // 清空一级缓存
        }
    }
}

经验值是每 20~50 条 flush 一次，具体大小取决于单条记录的数据量和机器内存。注意 flush 会立即发出 SQL，但事务还没提交，所以如果后面发生回滚，这些 SQL 也会一起回滚。另外，clear 之后原来持有的实体对象会变成游离态（detached），不要再尝试对它做修改并期待 Hibernate 帮你自动更新。

批量删除同理，最有效的还是直接在 HQL 里执行 delete from User u where u.status = :status，Hibernate 会在会话层发出一条批量 SQL，而不是逐条删除。

最后我想说，Spring 整合 Hibernate 这件事，上手不难，难的是把事务、Session、缓存、时区这些底层机制串成一条完整的认知链。你看网上那些报错讨论，无论报什么异常，最后八成都能归因到"Session 生命周期没管理好"或者"事务边界划错了"。把这两个根子上的问题想明白，再碰到任何整合问题，你都有清晰的排查方向。

再分享一个我自己的小习惯：每接一个 Spring + Hibernate 的老项目，我第一件事不是看业务代码，而是先把 applicationContext.xml 里 sessionFactory 和 transactionManager 的配置逐行读一遍，确认 hibernate.current_session_context_class 和扫描路径没有问题，再跑一个简单查询验证事务正常。这个习惯帮我避开了很多莫名其妙的"偶发性"问题。如果你正准备在自己的项目里集成 Hibernate，建议也按这个顺序来：先把配置和环境跑通，再写业务，最后再谈优化。