Hibernate二级缓存专项：Ehcache与Redis的选型对比和踩坑复盘

前段时间在群里看到一条求助：项目里给Hibernate配了二级缓存，压测时日志却还在不断打印SQL，QPS死活上不去。问了一圈，问题出在他把二级缓存当成了“万能的查询缓存”，拿它去缓存一条HQL条件查询——这是最常见的误用场景。

这篇文章想把Hibernate二级缓存这件事讲透。围绕Ehcache和Redis这两个主流方案，我会先说明缓存机制里那些容易被忽略的前提，再分别给出选型判断和配置指南，最后把我在实际项目里踩过的缓存不生效、脏读一致性等问题完整复盘一遍。如果你正在为项目选型或者刚接入缓存发现没效果，这篇应该能省下不少时间。

1. 到底该不该上二级缓存：先搞清楚Hibernate的缓存机制再谈选型

1.1 一级缓存和二级缓存的本质区别

很多人在讨论二级缓存之前，连一级缓存和二级缓存的边界都模糊。Hibernate的一级缓存也叫Session缓存，生命周期跟随Session事务，Session关闭缓存就没了。所以在一个事务里连续两次按主键查同一个实体，第二次不会发SQL；事务结束，这个实体就从缓存里消失了。一级缓存解决的是“同一个事务内重复读取”的问题，作用域非常小。

二级缓存是SessionFactory级别的缓存，跨Session、跨事务共享。一个请求在事务A里查了id=100的用户，事务B再按id=100查时，如果二级缓存开启了，就可以直接命中缓存对象，不再访问数据库。这也是为什么二级缓存被称为Hibernate性能优化的最后一块拼图——但要注意，它解决的只是“同一个实体的主键查询”这一类问题，不是所有查询都能受益。

理解这个区别之后，很多配置问题就豁然开朗了：如果你发现某个查询没走缓存，先别急着怀疑配置，很可能是这个查询类型本身就不在二级缓存的覆盖范围内。

1.2 二级缓存到底缓存了什么：实体、集合与查询缓存

Hibernate二级缓存按作用对象分成三块：实体缓存、集合缓存、查询缓存。

实体缓存是最核心的部分，缓存的是持久化实体的主键和属性快照。它要求被缓存的实体必须能被拆分成“主键到值”的映射，所以只有按主键加载（Session.get、load、Session.byId）或者通过关联导航访问实体时，才会直接命中实体缓存。

集合缓存放的是某个实体关联的集合数据，比如一个Order实体对应的List。它的缓存键是“所属实体的主键 + 集合属性名”，缓存内容是一组子实体的主键列表。查询缓存则是针对HQL、Criteria查询的结果集，缓存键由查询语句、参数值、查询空间（涉及的表）组成。

这里有个很容易踩的坑：查询缓存看似能缓存HQL结果，但它只缓存“实体的主键ID列表”，真正返回实体时还要按ID去访问实体缓存。也就是说，查询缓存是建立在实体缓存之上的，如果实体本身没被缓存，查询缓存命中了也还要去数据库重新加载实体，性能收益大打折扣。

1.3 并发访问策略：选错会导致数据错乱

Hibernate为二级缓存定义了四种并发访问策略（CacheConcurrencyStrategy），这不仅是配置注解时的必选项，也直接决定了缓存的安全边界：

• READ_ONLY：只缓存只读数据，性能最好，任何更新操作都会破坏一致性。
• READ_WRITE：读写模式，Hibernate通过软锁和版本号维护数据一致性，适合需要更新的实体。
• NONSTRICT_READ_WRITE：非严格读写，更新时缓存不会立即失效，而是以较低的频率异步更新，适合读多写少且允许短暂脏读的场景。
• TRANSACTIONAL：事务级隔离，要求环境支持JTA，配置复杂度高，实际项目中用得不多。

选策略的原则很朴素：能标注只读的数据就尽量用READ_ONLY，比如字典表、配置表；业务数据用READ_WRITE；如果业务允许最终一致，NONSTRICT_READ_WRITE也可以降低缓存维护开销。但千万别所有实体都标READ_ONLY——一旦某个事务更新了实体，缓存里的旧数据会一直存活到过期，脏读问题就埋下了。

1.4 一个来自压测现场的警醒

我在某个后台管理系统里见过一次“越优化越慢”的典型案例。团队给所有实体都开启了二级缓存，同时把查询缓存也打开了，压测结果居然比不开缓存还差。原因有两个：第一，查询缓存命中一次要经历查询空间匹配和参数序列化校验，计算成本不低，对频繁变化的表和复杂条件查询来说命中率极低；第二，系统里有不少写操作，每次写都要处理缓存失效和版本校验，额外开销反而拖慢了整体吞吐。

所以我的建议是：二级缓存不是装了就能提升性能的标配，它只适合“读多写少、按主键访问多、事务边界清晰”的场景。在选型之前，先盘点自己的查询模式，如果系统里大部分SQL都是动态条件查询和报表统计，那二级缓存很可能帮不上忙。

2. Ehcache和Redis根本不是同一个赛道：按部署架构选型才有意义

2.1 本地内存和分布式缓存的差异点

“Ehcache和Redis哪个好”这个问题，在技术社区里几乎每周都有人问。但严格来说，这两个东西不完全是同一类解决方案。Ehcache是进程内缓存，操作的就是当前JVM的堆内存，没有网络IO和序列化开销，单次访问延迟通常在微秒级；Redis是独立部署的分布式缓存，数据存放在另一个进程甚至另一台机器上，每次访问要经过序列化和网络传输，单次延迟在亚毫秒到毫秒级。

很多人只看延迟就得出“Ehcache更快”的结论，却忽略了更高维度的架构约束。应用部署为多实例时，每个JVM内部各自有一份Ehcache缓存，数据副本之间天然存在一致性问题。为了同步，Ehcache提供了集群组播或基于Terracotta的分布式方案，但这些方案要么配置复杂，要么有第三方依赖，远不如一个中心化的Redis集群好维护。

Redis作为中心化缓存，所有应用实例共享同一份数据，一致性模型简单清晰，还天然支持过期策略、持久化和集群横向扩展。代价就是每次缓存访问多一次网络开销，这在绝大多数业务场景下完全可接受。

2.2 什么场景适合Ehcache，什么场景适合Redis

以我实际接触的项目来看，选择判断可以收敛成三个问题，不用纠结参数细节：

第一，应用是单实例还是多实例？单实例应用用Ehcache很舒适，配置简单、零网络开销，JVM内数据自洽。一旦应用准备水平扩容，Ehcache的副本一致性问题就会立刻浮出水面，这个时候就该考虑Redis。

第二，数据变更频率和一致性要求有多高？读多写少、允许短暂旧数据，Ehcache也能扛；但如果有强一致要求，或者写操作频繁，进程内缓存要么频繁失效导致命中率下降，要么冒着脏读风险保存旧数据，不如直接上Redis。

第三，团队是否已经运维了Redis基础设施？如果项目里已有Redis集群，新的缓存需求没必要另起炉灶；如果没有，只是为一个后台管理系统引入一套Redis，运维成本也是选型时要算进去的账。

2.3 一张表看清选型判断维度

下面这张表是我在项目中做技术方案评审时常用的对比框架，直接复制到你们的架构评审文档里也能用：

表格列完了，结论也明显了：如果应用只部署一台实例，Redis带来的分布式优势完全发挥不出来，白白增加一次网络跳转；如果应用已经跑在多个节点上，还硬上Ehcache，最终还是要补一套集群同步方案，复杂度并不比Redis低。

3. Ehcache接入Hibernate：新版JCache配置链路全记录

3.1 依赖引入：别用已经废弃的旧模块

如果你翻开老博客，看到的配置大概率是hibernate-ehcache和net.sf.ehcache:ehcache这套组合。这套组合在新版Hibernate中已经废弃了，新版Hibernate的缓存标准迁移到了JCache（JSR-107），对应的集成模块是hibernate-jcache。

以Hibernate 5.6和Ehcache 3.x为例，Maven依赖长这样：

<dependency> <groupId>org.hibernate</groupId> <artifactId>hibernate-jcache</artifactId> <version>5.6.15.Final</version> </dependency> <dependency> <groupId>org.ehcache</groupId> <artifactId>ehcache</artifactId> <version>3.10.8</version> </dependency> <dependency> <groupId>org.ehcache</groupId> <artifactId>ehcache-jsr107</artifactId> <version>3.10.8</version> </dependency>

hibernate-jcache负责Hibernate与JCache API之间的适配，ehcache-jsr107则是把Ehcache 3.x实现包装成标准JCache Provider。两个依赖缺一不可，少了第二个会导致运行时找不到CachingProvider实现。

提示：使用Spring Boot时优先通过spring-boot-dependencies管理版本号，避免手工指定导致版本冲突。

3.2 hibernate.cfg.xml与ehcache.xml配置

依赖引入之后，需要在Hibernate主配置里打开二级缓存开关，并指定RegionFactory：

<property name="hibernate.cache.use_second_level_cache">true</property> <property name="hibernate.cache.region.factory_class">org.hibernate.cache.jcache.JCacheRegionFactory</property> <property name="hibernate.javax.cache.provider">org.ehcache.jsr107.EhcacheCachingProvider</property> <property name="hibernate.javax.cache.uri">ehcache.xml</property>

hibernate.javax.cache.uri指向Ehcache的配置文件路径。ehcache.xml可以定义不同缓存区域的大小以及TTL策略，比如给用户实体分配10000条堆内条目缓存、过期时间30分钟：

<config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://www.ehcache.org/v3" xsi:schemaLocation="http://www.ehcache.org/v3 http://www.ehcache.org/v3/ehcache-core.xsd"> <cache alias="user"> <expiry> <ttl unit="minutes">30</ttl> </expiry> <resources> <heap unit="entries">10000</heap> </resources> </cache> </config>

这里有个细节：Hibernate生成的缓存区域名称默认是实体的全限定类名，但可以通过@Cache(region = "user")指定区域名称。如果指定的region名称没有在ehcache.xml中定义，Ehcache会使用默认的缓存配置创建区域，实际大小可能被默认配置限制，容易在压测时出现频繁淘汰。建议在配置里为每个常用实体显式指定region。

3.3 在实体上标注缓存策略

配置好SessionFactory后，还需要在实体上显式标注缓存策略，否则Hibernate默认不会缓存任何实体：

@Entity @Cacheable @org.hibernate.annotations.Cache(usage = CacheConcurrencyStrategy.READ_WRITE, region = "user") public class User { @Id private Long id; private String name; // ... }

javax.persistence.Cacheable注解是JPA标准，org.hibernate.annotations.Cache是Hibernate扩展，主要用来指示并发策略和region名称。我习惯两个都标注，这样可以保证既符合JPA规范又能精细控制Hibernate行为。

集合缓存的标注类似，在实体的集合属性上加上缓存注解：

@OneToMany(mappedBy = "user") @Cache(usage = CacheConcurrencyStrategy.READ_WRITE, region = "orders") private List<Order> orders = new ArrayList<>();

注意：集合缓存和实体缓存区域最好分开命名，便于单独调整过期策略。集合缓存的失效粒度是整个集合，某个子实体更新会导致整个集合缓存失效，千万别随意设很长的过期时间。

3.4 验证是否生效：命中率统计怎么看

配置完后，验证缓存是否真正生效是我必做的一步。Hibernate提供了内置的统计指标，开启方式很简单：

<property name="hibernate.generate_statistics">true</property>

然后在程序里通过SessionFactory获取统计信息，打印关键指标：

SessionFactory sessionFactory = ...; Statistics stats = sessionFactory.getStatistics(); System.out.println("Second level hit: " + stats.getSecondLevelCacheHitCount()); System.out.println("Second level miss: " + stats.getSecondLevelCacheMissCount()); System.out.println("Query cache hit: " + stats.getQueryCacheHitCount());

用日志输出这些指标压在测试日志里，连续执行两次按主键加载实体的操作，如果第二次没有新增SQL且Second level hit增加，说明缓存已生效。我之前遇到过配置全部正确但命中数仍然为0的情况，最后发现是依赖里混入了旧版net.sf.ehcache，ClassLoader加载了两个CachingProvider，解决办法是把旧依赖彻底排掉，只保留Ehcache 3.x。

4. Redis方案的正确姿势：绕开Hibernate原生插件，用Spring Cache打组合拳

4.1 为什么Hibernate没有像样的Redis缓存插件

很多从Ehcache文档转过来的人会问：Hibernate有没有官方的Redis缓存Provider？答案是没有。Hibernate的缓存RegionFactory接口天然面向JVM内的本地缓存设计，后来虽然通过JCache抽象能接入各种Provider，但Redis属于跨进程分布式存储，要让它完整实现Hibernate的Region语义并不容易——尤其是实体缓存的锁机制、集合缓存失效通知、事务提交后的延迟写入，这些在本地缓存里简单直接，在分布式环境下却涉及网络同步和一致性问题。

社区里出现过一些第三方实现，但成熟度和维护力度参差不齐，生产环境中不建议冒险。更务实的做法是把缓存关注点从ORM层迁移到应用层，用Spring Cache加Redis统一管理缓存。这套方案不绑定Hibernate，将来换ORM框架也不需要重写缓存逻辑。

4.2 Spring Cache + Redis的最小配置

在Spring Boot项目中，引入spring-boot-starter-cache和spring-boot-starter-data-redis依赖，再定义一个RedisCacheManager即可：

<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-cache</artifactId> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-data-redis</artifactId> </dependency>

配置类：

@Configuration @EnableCaching public class RedisCacheConfig { @Bean public RedisCacheManager cacheManager(RedisConnectionFactory factory) { RedisCacheConfiguration config = RedisCacheConfiguration.defaultCacheConfig() .entryTtl(Duration.ofMinutes(30)) .serializeKeysWith(RedisSerializationContext.SerializationPair.fromSerializer(new StringRedisSerializer())) .serializeValuesWith(RedisSerializationContext.SerializationPair.fromSerializer(new GenericJackson2JsonRedisSerializer())); return RedisCacheManager.builder(factory) .cacheDefaults(config) .withInitialCacheConfigurations(customTtlMap()) .build(); } }

上面代码里有几个关键决策：Key用StringRedisSerializer，保证Redis里的key可读；Value用GenericJackson2JsonRedisSerializer，把Java对象序列化成JSON。默认的JdkSerializationRedisSerializer虽然也能用，但序列化后的数据是一堆二进制乱码，排查问题时非常痛苦。

customTtlMap可以按缓存名称定义不同的过期时间，比如缓存名为“token”的区域设置10分钟过期，缓存名为“userInfo”的区域设置2小时过期，灵活度比统一TTL高得多。

4.3 把缓存注解加到服务层：隐患与收益

Spring Cache的用法很直白，把@Cacheable注解加到Service方法上，第二层缓存逻辑就自动生效了：

@Service public class UserService { @Cacheable(cacheNames = "userInfo", key = "#id") public User getUser(Long id) { return userRepository.findById(id).orElse(null); } @CacheEvict(cacheNames = "userInfo", key = "#user.id") public void updateUser(User user) { userRepository.save(user); } }

读操作缓存、写操作清缓存，这是最简单也最不容易出错的组合。相比直接集成Hibernate原生缓存，把注解放在Service层有几个好处：失效逻辑和方法业务绑定在一起，肉眼可见；不改变DAO层的查询语义；还能对不经过Hibernate的远程调用、第三方接口返回值做缓存。

隐患也有。@Cacheable默认拦截的是方法入参和返回值，如果方法参数包含多个对象，key的生成需要手动指定，否则可能缓存了完全不相干的组合键。另外，被缓存对象必须支持序列化，Jackson序列化要求对象有默认构造器和getter，否则运行时会直接抛异常。

如果真的需要从Service层查询Hibernate实体的同时保留实体关联访问能力，我会在缓存对象和JPA实体之间做一层转换，使用DTO而不是直接把实体丢进Redis。这样既能避免懒加载出错，也能防止把持久态对象序列化后残留在Redis里产生脏数据。

4.4 序列化和TTL设计：别等出问题再回头补

Redis缓存最容易忽略的就是序列化一致性。假设你用JSON序列化缓存了User对象，后来给User新增了一个字段，Redis里已有缓存无法反序列化出新字段，就会导致接口读取到旧版本数据。此时要么给对象增加兼容字段的默认值处理，要么在发布前主动让缓存过期，否则需要等自然TTL到期才能恢复。

TTL设计我建议遵守“宁可短不可长”的原则。业务数据的缓存时间一般在5到30分钟比较合理，别一上来就设置几小时甚至一天。过长的TTL会让数据新鲜度变差，一旦业务口径调整，要等很久缓存才能刷新。分布式环境下治理脏数据最简单的手段就是强制TTL，因为只靠主动失效，永远可能出现某个节点漏更新。

缓存穿透和缓存雪崩也要考虑。穿透可以用空值缓存（缓存null并设置较短TTL）应对；雪崩要给同类缓存设置随机基础TTL，避免同一时刻大量键同时过期。

5. 缓存不生效与脏读问题的踩坑实录：完整排查链路

5.1 压测发现SQL偶发重复，是缓存没写还是没读？

有一次在某个订单系统里，我们开了二级缓存后压测，发现同一用户的信息接口偶尔还会触发两次SQL。当时团队第一反应是缓存没配上，结果查配置全对。后来用统计接口一细看，发现第一次调用Second level miss增加，第二次调用hit增加——说明缓存写入和读取都没问题，那问题出在哪？

最终定位到事务边界：第一次请求因为某些校验逻辑，在事务提交前就返回了结果。Hibernate的二级缓存写入时机和事务提交绑定，事务没有commit，缓存也不会真正写入。所以第二个请求进来时缓存还是空的，只能重新查库。这个场景也解释了为什么“同一个事务内很快，跨事务就慢”——这是事务边界没有把写缓存动作包含在内。

经验：开通二级缓存后，所有涉及缓存读写的业务都必须保证事务正常提交。不要尝试在Service方法返回结果之后再手动刷缓存，这会让缓存状态和事务状态脱钩。

5.2 查询缓存和实体缓存混用导致的数据错乱问题

还有一次踩坑是在业务模块里同时开启了查询缓存和实体缓存，结果出现了一个诡异的现象：同一批列表数据，用户A看到的是新数据，用户B看到的还是旧数据。

原因是查询缓存里存的是主键ID列表，而实体缓存里存的是实体快照。列表接口先命中查询缓存拿到旧的主键ID列表，再通过实体缓存加载实体；但另一个请求更新了实体并刷新了实体缓存，主键列表却没变。最终展示的集合里，一部分实体来自新缓存、一部分来自旧缓存，数据完全错乱。

从那以后，我在绝大多数项目里都默认关闭hibernate.cache.use_query_cache，除非查询条件固定、查询频率极高、返回结果集很小，而且能接受查询列表的最终一致性。查询缓存的失效条件太微妙，为了省一次SQL查询的结果，往往得不偿失。

5.3 缓存失效策略的设计：主动失效优先于时间过期

经过一系列事故之后，我对缓存失效策略的优先级排得很明确：主动失效优先级最高，TLL过期兜底。

主动失效的方式很简单——在写操作时显式调用缓存清理。用Spring Cache注解实现就是@CacheEvict，也可以直接在方法里注入CacheManager手动evict：

cacheManager.getCache("userInfo").evict(userId);

这种方式天然比TTL过期更及时。因为TTL过期是被动动作，时间到了才清理，晚一秒钟数据就是脏一秒。主动失效配合较短TTL兜底，既能保证数据更新后立刻生效，又能在漏清理时避免长时间脏读。

这里我强调一个看起来反常识但要记住的口诀：别在更新时去写缓存，只在更新时清缓存。缓存写入交给读路径在缓存缺失时自然回填。更新时写缓存容易出现写了一半、事务回滚、缓存和数据库不一致的问题，所以让缓存永远不承担写操作里的数据源职责。

5.4 一张问题清单速查表

把之前遇到的缓存问题整理成一张速查表，排查时可对照使用：

5.4 最后说点实在的

回到开头的选型问题：如果你维护的系统是单体应用、单实例部署、数据量可控，Ehcache依然是低开销高性价比的选择；如果你的应用已经在多实例集群上跑，请直接考虑Redis，别在进程内缓存的一致性问题上浪费时间。我自己在重构一个多实例的订单服务时，最终采用的就是Spring Cache加Redis的组合，虽然比直接改Hibernate配置多了几个类和注解，但跨实例的一致性、缓存命中率和后续的维护体验都好了一大截。

缓存从来不是装上就能一劳永逸的插件，它是一套需要持续设计的数据一致性机制。把“什么时候能缓存”、“什么时候必须失效”想清楚，比纠结选哪个缓存中间件重要得多。