第5章 术后监护：缓存类型转换与扩展机制

第 5 章 · 术后监护：缓存、类型转换与扩展机制

章节摘要：本章跟在手术后头走——SQL 执行完不等于结束。缓存是术后记忆，记住查过的结果也带来脏读风险；TypeHandler 是隐形缝合线，负责 Java 类型与 JDBC 类型的双向对齐；插件允许你在四大对象的执行链上插队处理；MBG 批量预制标准手术方案；与 Spring 集成则把整张手术台搬进病房，交给容器统一调度。读完你能安全地启用这些"监护设备"，而不是被它们反噬。

一条主线

前三章打通了映射主干，此时你的 MyBatis 已经"能做手术"。但生产环境的考验往往从手术结束后才开始：同一秒内一千个请求查同一份配置，能不能不都打到数据库？数据库里的整型、字符串、枚举、JSON 列，与 Java 侧的实体字段对不齐怎么办？分页、慢 SQL 审计这些横切需求，能不能不改业务代码就插进去？

这些都是"监护设备"的职责。5.1 讲术后记忆——一级缓存跟着 SqlSession 走、二级缓存跟着命名空间走，各自的命中条件与失效纪律；5.2 讲隐形缝合线——TypeHandler 的默认清单与自定义套路（以"字符串列表存 JSON 列"为例）；5.3 讲插队机制——四大对象各有哪些方法可拦，手写一个慢 SQL 计时插件；5.4 用 MBG 把三十张表的单表手术方案批量预制出来；5.5 把手术台搬进 Spring，讲清 SqlSessionTemplate 为什么线程安全、事务为什么必须交出去。

术后监护设备分布

一句金句：缓存记住的是结果，不是承诺——另一张命名空间改了数据，它不知道；监护设备越强大，越要懂它的盲区。

沿途站点

• 5.1 一级缓存与二级缓存：两级缓存的归属范围、缓存键的构成要素、五种失效情形、二级缓存的序列化要求与跨命名空间引用，多表 join 下的脏读复现与防线。
• 5.2 TypeHandler：类型缝合线：默认处理器的对照清单、枚举映射的两种内置选择、手写 JSON 列表处理器的完整过程与三种注册方式。
• 5.3 插件机制：四大拦截点：Executor、StatementHandler、ParameterHandler、ResultSetHandler 各自的可拦方法表、责任链与动态代理的实现，慢 SQL 计时插件实战。
• 5.4 代码生成器 MBG：能生成什么与不能生成什么、配置文件逐段讲解、运行方式、Example 查询的用法与边界。
• 5.5 与 Spring 集成：SqlSessionFactoryBean、MapperScan 扫描、SqlSessionTemplate 的线程安全原理、事务为什么必须交给 Spring。

拐点与结论

第一个转折在 5.1：很多人以为二级缓存是"性能优化开关"，配置里加一行就完事。看完脏读复现你会明白，跨命名空间的数据一致性问题意味着它只适合"读多改少且归属单一"的数据，大多数互联网项目更应慎用。知道何时不开，比知道怎么开更重要。

第二个转折在 5.5：集成 Spring 之后，代码里再也不要出现 openSession。SqlSessionTemplate 用代理把"每次操作借一个新会话"做成了默认行为，事务边界由声明式注解控制——这是从"框架使用"到"工程整合"的分水岭。

读完你应该

1. 能说清一二级缓存各自的归属对象、命中条件，以及任意写操作对它们的影响
2. 能用日志验证一次缓存命中，并解释缓存键由哪些要素构成
3. 能复现一次二级缓存的脏读，并给出至少两种防线
4. 能手写一个处理 JSON 列表的 TypeHandler，并用三种方式之一注册生效
5. 能说出四大对象分别能拦截哪些方法，并实现一个打印执行耗时的插件
6. 能用 MBG 为一组表生成实体、映射与 Example，并知道它不生成什么
7. 能解释 Spring 环境下事务边界由谁控制、SqlSessionTemplate 为什么线程安全

下一章的接力

监护设备齐了，最后一章做全册复盘：从一台转账手术讲事务纪律，从坏味道清单讲代码规范与测试，从慢查询与大结果集讲性能优化，再用一张排错决策树收拢全册的常见故障，最后看看 3.5 之后的版本演进与生态坐标。