前段时间在群里看到一条求助项目里给Hibernate配了二级缓存压测时日志却还在不断打印SQLQPS死活上不去。问了一圈问题出在他把二级缓存当成了“万能的查询缓存”拿它去缓存一条HQL条件查询——这是最常见的误用场景。这篇文章想把Hibernate二级缓存这件事讲透。围绕Ehcache和Redis这两个主流方案我会先说明缓存机制里那些容易被忽略的前提再分别给出选型判断和配置指南最后把我在实际项目里踩过的缓存不生效、脏读一致性等问题完整复盘一遍。如果你正在为项目选型或者刚接入缓存发现没效果这篇应该能省下不少时间。1. 到底该不该上二级缓存先搞清楚Hibernate的缓存机制再谈选型1.1 一级缓存和二级缓存的本质区别很多人在讨论二级缓存之前连一级缓存和二级缓存的边界都模糊。Hibernate的一级缓存也叫Session缓存生命周期跟随Session事务Session关闭缓存就没了。所以在一个事务里连续两次按主键查同一个实体第二次不会发SQL事务结束这个实体就从缓存里消失了。一级缓存解决的是“同一个事务内重复读取”的问题作用域非常小。二级缓存是SessionFactory级别的缓存跨Session、跨事务共享。一个请求在事务A里查了id100的用户事务B再按id100查时如果二级缓存开启了就可以直接命中缓存对象不再访问数据库。这也是为什么二级缓存被称为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 一张表看清选型判断维度下面这张表是我在项目中做技术方案评审时常用的对比框架直接复制到你们的架构评审文档里也能用判断维度EhcacheRedis数据存储位置应用JVM堆内独立进程/独立节点访问延迟微秒级无网络开销亚毫秒到毫秒级有序列化开销多实例一致性本地副本需额外集群同步方案中心化存储天然统一容量上限受JVM堆内存限制可扩至内存/集群规模过期策略支持TTL和最大堆内存淘汰支持TTL、LRU/LFU等淘汰策略运维复杂度随应用启动无额外依赖需要独立部署、监控、告警故障影响面仅影响单实例缓存中心故障影响所有实例适用场景单机小应用、极低延迟要求、数据量可控多实例集群、共享缓存数据、跨服务复用表格列完了结论也明显了如果应用只部署一台实例Redis带来的分布式优势完全发挥不出来白白增加一次网络跳转如果应用已经跑在多个节点上还硬上Ehcache最终还是要补一套集群同步方案复杂度并不比Redis低。3. Ehcache接入Hibernate新版JCache配置链路全记录3.1 依赖引入别用已经废弃的旧模块如果你翻开老博客看到的配置大概率是hibernate-ehcache和net.sf.ehcache:ehcache这套组合。这套组合在新版Hibernate中已经废弃了新版Hibernate的缓存标准迁移到了JCacheJSR-107对应的集成模块是hibernate-jcache。以Hibernate 5.6和Ehcache 3.x为例Maven依赖长这样dependency groupIdorg.hibernate/groupId artifactIdhibernate-jcache/artifactId version5.6.15.Final/version /dependency dependency groupIdorg.ehcache/groupId artifactIdehcache/artifactId version3.10.8/version /dependency dependency groupIdorg.ehcache/groupId artifactIdehcache-jsr107/artifactId version3.10.8/version /dependencyhibernate-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主配置里打开二级缓存开关并指定RegionFactoryproperty namehibernate.cache.use_second_level_cachetrue/property property namehibernate.cache.region.factory_classorg.hibernate.cache.jcache.JCacheRegionFactory/property property namehibernate.javax.cache.providerorg.ehcache.jsr107.EhcacheCachingProvider/property property namehibernate.javax.cache.uriehcache.xml/propertyhibernate.javax.cache.uri指向Ehcache的配置文件路径。ehcache.xml可以定义不同缓存区域的大小以及TTL策略比如给用户实体分配10000条堆内条目缓存、过期时间30分钟config xmlns:xsihttp://www.w3.org/2001/XMLSchema-instance xmlnshttp://www.ehcache.org/v3 xsi:schemaLocationhttp://www.ehcache.org/v3 http://www.ehcache.org/v3/ehcache-core.xsd cache aliasuser expiry ttl unitminutes30/ttl /expiry resources heap unitentries10000/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 ListOrder orders new ArrayList();注意集合缓存和实体缓存区域最好分开命名便于单独调整过期策略。集合缓存的失效粒度是整个集合某个子实体更新会导致整个集合缓存失效千万别随意设很长的过期时间。3.4 验证是否生效命中率统计怎么看配置完后验证缓存是否真正生效是我必做的一步。Hibernate提供了内置的统计指标开启方式很简单property namehibernate.generate_statisticstrue/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.ehcacheClassLoader加载了两个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 groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-cache/artifactId /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-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手动evictcacheManager.getCache(userInfo).evict(userId);这种方式天然比TTL过期更及时。因为TTL过期是被动动作时间到了才清理晚一秒钟数据就是脏一秒。主动失效配合较短TTL兜底既能保证数据更新后立刻生效又能在漏清理时避免长时间脏读。这里我强调一个看起来反常识但要记住的口诀别在更新时去写缓存只在更新时清缓存。缓存写入交给读路径在缓存缺失时自然回填。更新时写缓存容易出现写了一半、事务回滚、缓存和数据库不一致的问题所以让缓存永远不承担写操作里的数据源职责。5.4 一张问题清单速查表把之前遇到的缓存问题整理成一张速查表排查时可对照使用现象可能原因处理方式二次请求仍然打印SQL缓存未开启、实体未标注Cache或Cacheable检查配置项和实体注解命中计数为0使用了HQL条件查询或NativeQuery确认查询是否按主键访问或改用按ID加载使用旧版本Ehcache导致配置失效依赖中混入net.sf.ehcache排除旧依赖统一使用Ehcache 3.x跨请求缓存不生效事务未提交导致缓存写入不确定保持缓存读写都在已提交事务内实体更新后读到的还是旧值并发策略为NONSTRICT_READ_WRITE且未主动失效改为READ_WRITE策略显式evict列表数据部分新部分旧查询缓存主键列表未随实体更新失效关闭查询缓存或为列表定制短TTL和主动清理Redis中数据反序列化失败Jackson序列化不支持对象结构给对象提供默认构造器和getter必要时改用DTO缓存穿透导致数据库压力未降不存在的数据每次穿透缓存空值缓存并设置短TTL或使用布隆过滤器5.4 最后说点实在的回到开头的选型问题如果你维护的系统是单体应用、单实例部署、数据量可控Ehcache依然是低开销高性价比的选择如果你的应用已经在多实例集群上跑请直接考虑Redis别在进程内缓存的一致性问题上浪费时间。我自己在重构一个多实例的订单服务时最终采用的就是Spring Cache加Redis的组合虽然比直接改Hibernate配置多了几个类和注解但跨实例的一致性、缓存命中率和后续的维护体验都好了一大截。缓存从来不是装上就能一劳永逸的插件它是一套需要持续设计的数据一致性机制。把“什么时候能缓存”、“什么时候必须失效”想清楚比纠结选哪个缓存中间件重要得多。