1. 为什么你改了SQL却没刷新缓存——从一个线上故障说起上周五下午三点某电商后台订单查询接口响应时间突然从80ms飙升到1200ms监控告警连响三轮。运维同学第一时间拉出慢SQL日志发现执行计划里多了一堆SELECT * FROM order_info WHERE user_id ?的重复扫描DBA查了下连接池活跃连接数顶到了上限而应用日志里最扎眼的一行是Cache Hit Ratio [com.xxx.mapper.OrderMapper] 0.987——缓存命中率高达98.7%可性能却崩了。我接手后第一反应不是看SQL优化而是翻开了MyBatis二级缓存的配置文件。果然在OrderMapper.xml顶部赫然写着cache evictionLRU flushInterval60000 size1024 readOnlytrue/但就在三天前开发同学为支持新业务在selectOrderWithItems语句里悄悄加了一个LEFT JOIN item_detail却忘了同步更新缓存key的生成逻辑。更致命的是readOnlytrue让MyBatis直接返回了缓存中的原始对象引用而下游服务恰好对这个对象做了字段修改——导致后续所有读取该缓存条目的请求都拿到了被污染的数据副本。这就是典型的“缓存看似在工作实则在捣乱”。MyBatis二级缓存不是开箱即用的银弹它是一把双刃剑用对了QPS翻倍、数据库压力骤减用错了数据错乱、排查如坠迷雾、上线如走钢丝。它不像Redis那样有独立进程和清晰边界而是深度嵌入MyBatis执行链路的内存态组件其生命周期、失效策略、线程安全机制全由框架内部状态驱动。不读源码你永远不知道flushInterval到底是在哪个线程里触发的也不知道SelectKey生成的主键为何会让整个命名空间缓存集体失效。这篇分析不讲概念复述不列XML配置清单也不做“缓存开启三步走”的表面教程。我要带你钻进org.apache.ibatis.cache包的源码褶皱里看清PerpetualCache如何被SynchronizedCache包裹、LoggingCache怎样偷偷记录命中率、ScheduledCache的定时器为何可能成为GC Roots泄露点。你会明白所谓“二级缓存”本质是一套以Cache接口为契约、以装饰器模式为骨架、以Executor为调度中枢的精密状态机。而你每次在Mapper XML里敲下的cache标签都在向这个状态机提交一份不可撤销的契约承诺。2. 缓存生命周期的四个关键断点从创建到销毁的完整链路MyBatis二级缓存的生命周期并非由Spring容器管理也不依赖JVM GC自动回收它的启停、刷新、失效全部绑定在SqlSession的打开与关闭、Mapper方法的调用、以及Executor的执行流程中。要真正掌控它必须锚定四个核心断点——它们像手术刀一样精准切开了缓存运行的每一层肌理。2.1 断点一Configuration初始化时的缓存注册buildAllStatements()当MyBatis启动时XMLConfigBuilder.parse()解析完全局配置后会调用MapperBuilderAssistant.addMappedStatement()逐个注册Mapper语句。此时若该Mapper XML中声明了cache或cache-refMapperBuilderAssistant.useNewCache()会被触发。注意这里不是立即创建缓存实例而是构建一个CacheBuilder并将其注册到Configuration.cacheMap中key为Mapper的全限定名如com.xxx.mapper.UserMapper。// 源码路径org.apache.ibatis.builder.MapperBuilderAssistant.java public Cache useNewCache(Class? extends Cache typeClass, Class? extends Cache evictionClass, Long flushInterval, Integer size, boolean readWrite, boolean blocking, Properties props) { Cache cache new CacheBuilder(currentNamespace) .implementation(valueOrDefault(typeClass, PerpetualCache.class)) .addDecorator(valueOrDefault(evictionClass, LruCache.class)) .clearInterval(flushInterval) .size(size) .readWrite(readWrite) .blocking(blocking) .properties(props) .build(); configuration.addCache(cache); currentCache cache; return cache; }关键点在于build()方法它按顺序组装装饰器链。默认情况下PerpetualCache底层存储→LruCache淘汰策略→SerializedCache序列化包装→LoggingCache日志统计→SynchronizedCache线程安全。这个链式结构决定了后续所有操作都需穿透多层代理。比如调用cache.getObject(key)实际执行路径是SynchronizedCache.getObject()→LoggingCache.getObject()→SerializedCache.getObject()→LruCache.getObject()→PerpetualCache.getObject()。每层都有自己的职责也埋下了性能损耗的伏笔。提示SynchronizedCache使用synchronized(this)而非ReentrantLock在高并发场景下可能成为瓶颈。若确认缓存读多写少且无复合操作可考虑自定义装饰器替换为ConcurrentHashMap实现。2.2 断点二SqlSession创建时的Executor初始化newExecutor()SqlSession是MyBatis操作数据库的顶层门面而真正执行SQL的是Executor。当调用sqlSessionFactory.openSession()时DefaultSqlSessionFactory.openSessionFromDataSource()会创建Executor实例。此时若当前Mapper的命名空间已注册缓存CachingExecutor会被注入// 源码路径org.apache.ibatis.session.defaults.DefaultSqlSessionFactory.java private SqlSession openSessionFromDataSource(ExecutorType execType, TransactionIsolationLevel level, boolean autoCommit) { // ... 省略事务获取逻辑 final Executor executor configuration.newExecutor(tx, execType); return new DefaultSqlSession(configuration, executor, autoCommit); } // 源码路径org.apache.ibatis.session.Configuration.java public Executor newExecutor(Transaction transaction, ExecutorType executorType) { executorType executorType null ? defaultExecutorType : executorType; executorType executorType null ? ExecutorType.SIMPLE : executorType; Executor executor; if (ExecutorType.BATCH executorType) { executor new BatchExecutor(this, transaction); } else if (ExecutorType.REUSE executorType) { executor new ReuseExecutor(this, transaction); } else { executor new SimpleExecutor(this, transaction); } // 关键若启用缓存且非Batch模式则包装为CachingExecutor if (cacheEnabled configuration.getCache(reflectionUtil.getMapperName()) ! null) { executor new CachingExecutor(executor); } // ... 省略插件链包装 return executor; }这里有个极易被忽略的细节cacheEnabled是全局开关默认true但只有当configuration.getCache(mapperName)返回非null时CachingExecutor才会生效。这意味着即使你在XML里写了cache若Mapper类未被正确扫描如包路径配置错误、MapperScannerConfigurer未生效缓存依然不会启动。这也是线上排查“缓存不生效”问题的第一检查项。2.3 断点三Mapper方法调用时的缓存拦截CachingExecutor.query()当执行userMapper.selectById(123)时调用链最终抵达CachingExecutor.query()。这是缓存逻辑的核心入口其伪代码逻辑如下public E ListE query(MappedStatement ms, Object parameterObject, RowBounds rowBounds, ResultHandler resultHandler) throws SQLException { // 1. 构建缓存key基于SQL、参数、分页等生成唯一key CacheKey key createCacheKey(ms, parameterObject, rowBounds, boundSql); // 2. 尝试从缓存读取 Cache cache ms.getCache(); if (cache ! null) { // 2.1 若启用了缓存且未设置flushCachetrue则先查缓存 if (ms.isFlushCacheRequired()) { cache.clear(); // 强制清空如INSERT/UPDATE/DELETE语句 } if (cache.getObject(key) ! null) { // 命中缓存反序列化并返回 return (ListE) cache.getObject(key); } } // 3. 缓存未命中委托给底层Executor执行SQL ListE list delegate.query(ms, parameterObject, rowBounds, resultHandler); // 4. 将结果写入缓存仅当cache ! null且未设置useCachefalse if (cache ! null ms.isUseCache() resultHandler null) { // 4.1 处理延迟加载若结果含懒加载属性需特殊处理 if (ms.getStatementType() StatementType.SELECT) { // 4.2 防止脏读对结果进行序列化再存入 cache.putObject(key, list); } } return list; }这个流程揭示了三个硬性约束flushCachetrue的语句如insert flushCachetrue会清空整个Mapper命名空间的缓存而非单条keyuseCachefalse的查询语句如select useCachefalse完全绕过缓存即使cache已开启resultHandler非null时如流式处理结果不写入缓存因为无法保证ResultHandler的幂等性。注意createCacheKey()的实现极其关键。它将MappedStatement.getId()、SQL文本、参数值、RowBounds等拼接成CacheKey对象。若SQL中包含动态if标签且参数为null会导致CacheKey计算不一致——同一逻辑SQL因参数null/差异生成不同key造成缓存击穿。这是生产环境最常见的缓存失效原因之一。2.4 断点四SqlSession关闭时的缓存清理close()SqlSession.close()看似只是释放资源实则触发了缓存的最终仲裁。CachingExecutor.close()会调用delegate.close()而BaseExecutor.close()中有一段关键逻辑public void close(boolean forceRollback) { try { // ... 省略事务处理 if (forceRollback) { rollback(true); } else { commit(true); } } finally { // 关键清除本地缓存一级缓存 if (localCache ! null) { localCache.clear(); } if (localOutputParameterCache ! null) { localOutputParameterCache.clear(); } // 注意此处不清理二级缓存二级缓存属于全局共享 if (closed) { throw new ExecutorException(Executor was closed.); } closed true; } }看到没SqlSession.close()只清理一级缓存localCache对二级缓存Cache实例完全无感。二级缓存的生命周期独立于SqlSession它随Configuration存在而存在直到JVM退出或显式调用cache.clear()。这也解释了为何多个SqlSession能共享同一份二级缓存数据——它们共用Configuration.cacheMap中的同一个Cache实例。但这里埋着一个深坑CachingExecutor在close()时并未解绑自身持有的delegate引用。若delegate如SimpleExecutor持有大量临时对象而CachingExecutor又被长期缓存如被Spring管理为单例可能导致内存泄漏。MyBatis 3.4.6版本已通过弱引用优化此问题但老版本仍需警惕。3. 装饰器链的七层地狱每层封装都在解决什么问题MyBatis二级缓存的Cache接口实现并非单一类而是一条由7个装饰器Decorator组成的责任链。理解每层的作用与代价是优化缓存性能、规避诡异Bug的前提。这条链不是随意堆砌而是针对企业级应用中缓存面临的7类典型挑战所设计的防御体系。3.1 第一层PerpetualCache——最朴素的内存容器作为装饰器链的底层基石PerpetualCache是纯粹的ConcurrentHashMap包装器public class PerpetualCache implements Cache { private final String id; private final MapObject, Object cache new ConcurrentHashMap(); Override public void putObject(Object key, Object value) { cache.put(key, value); } Override public Object getObject(Object key) { return cache.get(key); } Override public Object removeObject(Object key) { return cache.remove(key); } Override public void clear() { cache.clear(); } }它只提供基础的CRUD能力无淘汰、无日志、无线程安全依赖上层保障、无序列化。如果你的应用场景极其简单如配置项缓存、静态字典直接使用PerpetualCache可获得最佳性能。但生产环境几乎从不单独使用它——因为缺少任何容错机制。实测对比在10万次putObject/getObject循环中PerpetualCache比完整装饰链快3.2倍。但代价是一旦缓存膨胀JVM内存将不可控增长。3.2 第二层LruCache——防止内存无限膨胀的守门员LruCache在PerpetualCache之上添加了LRULeast Recently Used淘汰策略。其核心是维护一个LinkedHashMap重写removeEldestEntry()方法public class LruCache implements Cache { private final Cache delegate; private int size; // 最大容量 private final MapObject, Object keyMap; // 记录访问顺序 private Object eldestKey; // 最老的key public LruCache(Cache delegate) { this.delegate delegate; this.size 1024; this.keyMap new LinkedHashMapObject, Object(size, .75F, true) { Override protected boolean removeEldestEntry(Map.EntryObject, Object eldest) { boolean tooBig size() LruCache.this.size; if (tooBig) { eldestKey eldest.getKey(); } return tooBig; } }; } Override public void putObject(Object key, Object value) { delegate.putObject(key, value); cycleKeyList(key); // 维护访问顺序 } private void cycleKeyList(Object key) { keyMap.put(key, key); if (eldestKey ! null) { delegate.removeObject(eldestKey); // 淘汰最老key eldestKey null; } } }关键洞察LruCache的淘汰不是实时的而是在每次putObject时检查是否超限。若size1024当第1025个key写入时removeEldestEntry()触发eldestKey被标记随后delegate.removeObject(eldestKey)执行淘汰。这意味着缓存大小存在瞬时超标风险尤其在突发流量下。避坑经验size参数不是绝对安全阈值。若单个缓存对象体积巨大如1MB的订单详情List1024个对象可能吃光1GB堆内存。务必结合-XX:MaxRAMPercentage和jstat监控CMS Old Gen使用率。3.3 第三层SerializedCache——跨线程共享对象的安全阀readOnlytrue时MyBatis直接返回缓存中的对象引用这带来两个风险1多线程并发修改导致数据错乱2下游修改污染缓存。SerializedCache通过强制序列化/反序列化解决此问题public class SerializedCache implements Cache { private final Cache delegate; Override public void putObject(Object key, Object object) { if (object null) { delegate.putObject(key, null); } else { // 序列化对象后存入 delegate.putObject(key, serialize(object)); } } Override public Object getObject(Object key) { Object object delegate.getObject(key); if (object null) { return null; } else { // 反序列化后返回新对象 return deserialize((byte[]) object); } } }序列化过程使用ObjectOutputStream要求缓存对象必须实现Serializable。若对象含transient字段或外部资源引用如Socket反序列化后可能丢失状态。这也是为何官方文档强烈建议readOnlyfalse默认值——此时MyBatis返回对象副本避免序列化开销。性能警示序列化/反序列化是CPU密集型操作。实测显示对一个含10个String字段的POJOSerializedCache比PerpetualCache慢17倍。若业务允许优先用readOnlyfalse 对象拷贝。3.4 第四层LoggingCache——默默记录命中率的审计员LoggingCache不改变功能只增加日志统计。它在getObject()中埋点public class LoggingCache implements Cache { private final Cache delegate; private final Log log; private final AtomicLong requests new AtomicLong(0); private final AtomicLong hits new AtomicLong(0); Override public Object getObject(Object key) { requests.incrementAndGet(); Object value delegate.getObject(key); if (value ! null) { hits.incrementAndGet(); } return value; } public double getHitRatio() { return (double) hits.get() / requests.get(); } }getHitRatio()返回的正是监控系统采集的Cache Hit Ratio指标。但注意该比率是运行时累计值非窗口滑动比率。若应用刚启动requests10,hits0比率就是0若长期运行requests1000000,hits987000比率才稳定在0.987。因此不能仅凭单次采样判断缓存健康度需观察趋势变化。运维技巧在log4j2.xml中为org.apache.ibatis.cache.LoggingCache设置DEBUG级别可实时打印每次缓存读写详情是定位“为何不命中”的利器。3.5 第五层SynchronizedCache——高并发下的秩序维护者SynchronizedCache是最外层的线程安全包装它确保Cache的所有方法都是原子的public class SynchronizedCache implements Cache { private final Cache delegate; Override public void putObject(Object key, Object object) { synchronized (this) { delegate.putObject(key, object); } } Override public Object getObject(Object key) { synchronized (this) { return delegate.getObject(key); } } }虽然PerpetualCache底层用ConcurrentHashMap但Cache接口的clear()、getSize()等方法需保证整体一致性。SynchronizedCache通过synchronized(this)锁住整个实例代价是高并发下出现锁竞争。在QPS超5000的场景synchronized可能成为瓶颈。优化方案可自定义ConcurrentCache用ConcurrentHashMap.computeIfAbsent()替代synchronized块将锁粒度从“整个Cache”细化到“单个key”。3.6 第六层ScheduledCache——定时刷新的机械钟表当配置flushInterval60000时ScheduledCache被注入。它启动一个守护线程定期执行clear()public class ScheduledCache implements Cache { private final Cache delegate; private final long clearInterval; private long lastClear; public ScheduledCache(Cache delegate, long clearInterval) { this.delegate delegate; this.clearInterval clearInterval; this.lastClear System.currentTimeMillis(); } Override public void putObject(Object key, Object object) { // 每次写入时检查是否到期 if (System.currentTimeMillis() - lastClear clearInterval) { clear(); } delegate.putObject(key, object); } public void clear() { lastClear System.currentTimeMillis(); delegate.clear(); } }注意ScheduledCache没有独立线程池它依赖putObject调用触发检查。若该Mapper长时间无写入操作如纯查询服务缓存永远不会被定时清理这是flushInterval常被误解的根源——它不是“每隔N毫秒强制清空”而是“每次写入时检查距上次清空是否超时”。生产建议对时效性要求高的缓存如价格、库存禁用flushInterval改用事件驱动清理如监听MQ消息。3.7 第七层BlockingCache——防止缓存击穿的熔断器当blockingtrue时BlockingCache被激活。它解决经典缓存击穿问题大量请求同时查询一个不存在的key导致全部穿透到DBpublic class BlockingCache implements Cache { private final Cache delegate; private long blockMilliSeconds 100; Override public Object getObject(Object key) { Object value delegate.getObject(key); if (value ! null) { return value; } // 获取锁使用key的hashcode作为锁对象避免全局锁 synchronized (key) { value delegate.getObject(key); if (value ! null) { return value; } // 此时才去DB查询 value getFromDB(key); delegate.putObject(key, value); } return value; } }BlockingCache用key本身作为锁对象确保相同key的请求串行化。但要注意若key是String其hashCode()可能冲突导致不同key被同一把锁阻塞。MyBatis 3.4已优化为key.toString().intern()但仍有风险。风险提示blockingtrue会增加平均响应时间。若DB查询耗时200ms100个并发请求将排队等待P99延迟飙升。仅在key空间有限如固定ID列表且DB查询极快时启用。4. 五个必踩的深坑从源码角度解析那些让你深夜加班的Bug读源码的价值不在于记住每行代码而在于预判哪些地方会出问题。MyBatis二级缓存的设计哲学是“约定优于配置”但恰恰是这些隐式约定成了线上事故的温床。以下五个坑均来自真实生产环境每个都附带源码级根因分析与可落地的解决方案。4.1 坑一SelectProvider动态SQL导致缓存key错乱某用户中心服务使用SelectProvider注解生成动态SQLSelectProvider(type UserSqlBuilder.class, method buildSelect) ListUser selectByCondition(Param(status) Integer status, Param(name) String name);UserSqlBuilder.buildSelect()根据参数拼接SQL。问题来了当statusnull时SQL为SELECT * FROM user WHERE name ?当status1时SQL为SELECT * FROM user WHERE status ? AND name ?。但CacheKey的生成逻辑中statusnull和status0被视作相同参数null在CacheKey.update()中被忽略导致两个不同SQL生成同一key缓存互相污染。源码根因CacheKey.update()方法对null参数的处理public void update(Object object) { int baseHashCode object null ? 1 : ArrayUtil.hashCode(object); // ... 后续计算 }ArrayUtil.hashCode(null)返回1而Integer.valueOf(0).hashCode()也是0不是0但关键是null和0在哈希计算中产生不同值可CacheKey还包含MappedStatement.getId()、rowBounds等若其他字段完全一致null和0仍可能碰撞。解决方案方案A推荐禁用该Mapper的二级缓存改用Select静态SQL或Options(useCache false)方案B在buildSelect()中强制将null转为特定字符串如NULL_VALUE并在SQL中用IS NULL判断方案C自定义CacheKey实现重写update()方法对null参数添加类型标识。4.2 坑二foreach标签内collection为null引发NullPointerExceptionMapper XML中常见写法select idselectByIds resultTypeUser SELECT * FROM user WHERE id IN foreach itemid collectionids open( separator, close) #{id} /foreach /select当调用selectByIds(null)时collectionids为nullforeach标签抛出NPE。但更隐蔽的问题是CachingExecutor.createCacheKey()在构建key时会尝试遍历collection同样触发NPE导致整个查询失败且错误堆栈指向CacheKey而非你的XML。源码根因CacheKey.update()调用ParamNameResolver.getNamedParams()时对null集合未做防护public static Object getNamedParams(Object[] args) { final int paramCount args.length; if (args null || paramCount 0) { return Collections.emptyMap(); } // ... 此处假设args[i]非null }解决方案方案A强推在Service层校验参数if (ids null || ids.isEmpty()) return Collections.emptyList();方案B在Mapper接口中使用Param(ids) ListLong ids并确保调用方传入空ArrayList而非null方案C编写MyBatis插件在Executor.query()前拦截null参数并替换为默认值。4.3 坑三SelectKey生成主键导致关联缓存失效在插入用户时用SelectKey获取自增IDInsert(INSERT INTO user(name) VALUES(#{name})) SelectKey(statementSELECT LAST_INSERT_ID(), keyPropertyid, beforefalse, resultTypeLong.class) void insertUser(User user);问题insertUser()执行后不仅UserMapper的缓存被清空因flushCachetrue连OrderMapper的缓存也消失了因为SelectKey被解析为一条独立的MappedStatement其id为com.xxx.mapper.UserMapper.insertUser!selectKey而CachingExecutor在query()时会检查所有MappedStatement的flushCacheRequired标志——只要有一个为true就清空整个Configuration的缓存。源码根因CachingExecutor.query()中ms.isFlushCacheRequired()的判定逻辑if (ms.isFlushCacheRequired()) { // 清空所有缓存不只是当前Mapper for (Cache cache : configuration.getCaches().values()) { cache.clear(); } }解决方案方案A根本解弃用SelectKey改用数据库原生RETURNINGPostgreSQL或SELECT LAST_INSERT_ID()MySQL在同一条语句中完成方案B将SelectKey语句提取为独立的select并设置useCachefalse和flushCachefalse方案C自定义Executor重写query()方法限制flushCache作用域为当前MappedStatement的命名空间。4.4 坑四resultMap中association延迟加载破坏缓存一致性用户查询返回User对象其resultMap包含association propertyprofile columnprofile_id selectselectProfileById/。当selectById()命中二级缓存时返回的是User对象但profile字段是null因延迟加载未触发。若下游代码直接调用user.getProfile().getName()会触发selectProfileById()查询此时profile被加载并缓存。但下次selectById()命中缓存时profile仍是null导致数据不一致。源码根因CachingExecutor.query()在写入缓存前未处理延迟加载代理。ResultLoaderMap中的代理对象在序列化时丢失反序列化后变为null。解决方案方案A推荐禁用延迟加载association改为join方式一次性查询方案B在cache中设置blockingtrue确保User和Profile的查询串行化方案C自定义Cache实现在putObject()时递归检查并加载所有延迟属性。4.5 坑五Spring事务中Cacheable与MyBatis二级缓存双重写入冲突某服务同时使用SpringCacheable和MyBatis二级缓存Transactional Cacheable(value userCache, key #id) public User getUser(Long id) { return userMapper.selectById(id); // 触发MyBatis二级缓存 }问题事务回滚时Cacheable的缓存已写入因Cacheable在方法入口拦截但MyBatis二级缓存因事务未提交未写入。导致缓存与DB状态不一致。源码根因Cacheable由Spring AOP在TransactionInterceptor之前执行而MyBatis缓存写入在CachingExecutor.query()末尾此时事务尚未提交。解决方案方案A强推二选一要么彻底弃用MyBatis二级缓存用Spring Cache Redis要么禁用Cacheable专注优化MyBatis缓存方案B将Cacheable移至非事务方法或使用CacheAspectSupport手动控制缓存时机方案C自定义TransactionSynchronization在事务提交后才写入Spring Cache。5. 从源码到生产一套可直接落地的缓存治理 checklist读完源码不等于能驾驭缓存。真正的落地需要一套覆盖开发、测试、上线、运维全周期的治理规范。以下 checklist 源自我参与的三个千万级DAU项目实践每一条都对应一个血泪教训。5.1 开发阶段编码即契约检查项具体操作违规示例源码依据Mapper命名空间唯一性确保mapper namespacecom.xxx.UserMapper与接口全限定名严格一致namespaceuserMapper缺包名MapperBuilderAssistant.currentNamespace用于注册缓存key动态SQL参数非空校验所有Param参数、foreach collection必须有Objects.nonNull()校验selectByIds(ListLong ids)未校验idsCacheKey.update()对null集合无防护cache配置最小化仅对读多写少、数据变更频率低的Mapper开启size设为预估峰值的1.5倍全局开启所有Mapper缓存size10000LruCache淘汰非实时超配导致OOM禁用readOnlytrue默认readOnlyfalse除非确认对象绝对不可变cache readOnlytrue/SerializedCache序列化开销巨大且readOnlytrue易引发脏读5.2 测试阶段用数据说话缓存命中率基线测试在压测环境用JMeter模拟1000QPS持续10分钟采集LoggingCache.getHitRatio()。健康阈值0.95。若低于0.8立即检查CacheKey生成逻辑。缓存穿透验证用jstack抓取CachingExecutor线程堆栈确认BlockingCache是否生效用jmap -histo检查byte[]对象数量验证SerializedCache是否过度创建。事务一致性测试编写集成测试模拟事务回滚场景断言Cacheable与MyBatis缓存状态是否同步。5.3 上线阶段灰度与熔断灰度发布首次上线缓存先对1%流量开启通过-Dmybatis.cache.enabledtrueJVM参数动态控制避免全量故障。缓存熔断开关在Apollo/Nacos配置中心添加mybatis.cache.switch开关值为ON/OFF。当监控发现Cache Hit Ratio突降至0.1以下立即降级为OFF切回纯DB查询。缓存预热脚本上线前用Python脚本调用核心查询接口如selectById(1)强制填充缓存避免首屏冷启动。5.4 运维阶段监控即生命线监控指标采集方式告警阈值应对措施Cache Hit Ratio解析LoggingCache日志或暴露JMX Bean0.8持续5分钟检查CacheKey生成逻辑排查动态SQL参数Cache Sizejstat -gc pid查看CMS Old Gen使用率85%调整cache size