深入解析MyBatis一级缓存机制：底层实现与性能优化

> ### 摘要 > MyBatis的一级缓存是其默认启用的缓存机制，用户无法显式禁用，但可通过调整SQL会话（SqlSession）生命周期或执行flushCache等操作间接影响其行为。该缓存基于PerpetualCache实现，底层依托HashMap存储，作用域限定在单个SqlSession内，具备“会话级”局部性特征。其命中依赖于SQL语句、参数、环境配置等完全一致的条件，一旦发生增删改操作或手动清空，缓存即失效。本文深入剖析其底层实现逻辑，揭示其高效性与局限性并存的技术本质。 > ### 关键词 > 一级缓存,MyBatis,缓存机制,底层实现,默认启用 ## 一、一级缓存的基本原理 ### 1.1 一级缓存的基本概念与特性 一级缓存是MyBatis框架中悄然运转却不可或缺的“呼吸节奏”——它不声不响，默认启用，像空气一样自然存在，却从不允许被显式关闭。这种设计并非疏忽，而是深植于MyBatis对开发体验与性能平衡的审慎考量：它不增加配置负担，也不牺牲基础效率。用户无法禁用，却可通过SqlSession的生命周期管理、手动调用`flushCache()`或执行增删改操作等方式，间接参与其行为调控。它不张扬，却严格恪守一致性契约——只有当SQL语句、参数、环境配置（如Mapper命名空间、数据库连接等）完全一致时，才肯慷慨交付缓存结果；一旦任一条件偏移，它便即刻归零，毫无妥协。这种“默认启用”的坚定姿态，既是对轻量级会话缓存价值的肯定，也暗含一种温柔的提醒：真正的高效，从来不是无条件的捷径，而是在可控边界内对重复劳动的体恤。 ### 1.2 一级缓存的作用范围与生命周期 一级缓存的生命，始终与SqlSession紧紧相系——它诞生于SqlSession创建之时，消散于SqlSession关闭之刻，全程不曾越界半步。这种“会话级”局部性，既是它的铠甲，也是它的疆界。它不跨线程、不跨会话、不跨事务边界，哪怕同一JVM中两个完全相同的查询请求，只要分属不同SqlSession，便各自独立缓存、互不感知。它的生命周期短促而专注，像一次完整的对话：从打开会话、执行查询、暂存结果，到遭遇更新操作或主动清空，再到最终关闭——整个过程干净利落，不留冗余痕迹。正因如此，一级缓存从不承诺长期稳定，它只忠实地服务于当下这一次会话中的重复读取需求，以最克制的方式，在毫秒之间完成对开发者意图的静默响应。 ### 1.3 一级缓存的存储结构分析 一级缓存的底层实现，由PerpetualCache担当核心载体，而其内核，是一片朴素却高效的HashMap。没有复杂的淘汰策略，没有序列化开销，没有分布式协调——它只是以键值对的形式，将查询结果稳稳托住。键（Key）由MappedStatement的ID、SQL文本、参数对象、行Bounds及环境配置共同构成，经哈希运算后精准定位；值（Value）则是查询所得的结果对象，原样封装，毫秒可取。这种基于内存的直连式存储，赋予了一级缓存近乎零延迟的命中速度，却也将其牢牢锚定在单个SqlSession的内存空间之内。它不追求宏大架构，只践行一个简单信条：在最该出现的地方，用最简方式，做最确定的事——而这，正是MyBatis一贯的理性之美。 ## 二、一级缓存的底层实现 ### 2.1 缓存键的生成机制 缓存键（Cache Key）是一级缓存沉默而精准的“身份识别器”——它不依赖外部配置，也不接受人工干预，而是由MyBatis在每次查询执行前，自动、严谨地组装而成。这个键并非简单拼接SQL字符串，而是融合了多重上下文要素：MappedStatement的唯一ID（标识具体Mapper方法）、经标准化处理的SQL语句文本、参数对象（Parameter Object）的深拷贝哈希值、行边界（RowBounds）的偏移与限制信息，以及当前SqlSession所绑定的环境配置（如数据库连接池、事务隔离级别等）。这些要素被封装进`CacheKey`对象，并通过一套确定性哈希算法生成最终键值。正因如此，哪怕仅有一个参数字段值发生微小变更，或同一SQL在不同命名空间下被调用，都会导致哈希结果迥异，从而彻底规避缓存误命中。这种“严丝合缝”的生成逻辑，既非过度设计，亦非权宜之计，而是MyBatis对数据一致性近乎执拗的守护——它用代码写下一句无声的承诺：**凡不同者，必不共享；凡相同者，必可复用。** ### 2.2 缓存值的存储方式 一级缓存的存储方式，是理性克制与工程直觉的完美交汇。它不引入额外序列化层，不启用软引用或弱引用策略，更不预设淘汰规则——所有缓存值均以原始Java对象形态，直接存入PerpetualCache内部封装的HashMap中。这意味着，查询返回的List、Map、自定义实体类等结果对象，未经任何转换或包装，便被原样托举于内存之上。这种“零损耗存储”赋予了一级缓存无可比拟的读取效率，却也意味着其生命周期完全依附于SqlSession的内存生命周期：一旦SqlSession关闭，HashMap连同其中所有对象引用一并释放，GC可立即回收。它不试图延长对象存在时间，也不承担跨会话状态维护之责；它只是安静地站在那里，在同一个SqlSession内，为重复查询筑起一道毫秒级响应的屏障。这并非简陋，而是一种清醒的选择——在局部性明确、时效性极高的场景下，最朴素的存储，恰恰是最可靠的存储。 ### 2.3 缓存的读写操作流程 一级缓存的读写流程，是一场高度协同、环环相扣的静默协作。当执行`select`语句时，MyBatis首先基于前述规则生成`CacheKey`，随即在当前SqlSession关联的PerpetualCache中尝试`get()`——若命中，则跳过数据库访问，直接返回缓存结果；若未命中，则交由Executor执行真实SQL查询，获取结果后，再以相同`CacheKey`调用`putObject()`完成写入。而写操作的触发点远不止于此：任何`insert`、`update`、`delete`语句执行完毕后，MyBatis会自动清空当前SqlSession中所有缓存项——这不是粗暴清除，而是基于“读写分离”原则的主动失效；同样，显式调用`sqlSession.clearCache()`或`sqlSession.commit()/rollback()`时，缓存亦同步刷新。整个流程无用户感知，无配置介入，却始终恪守“一次会话，一份真相”的契约。它不追求高并发下的复杂协调，只专注在单一会话维度内，以最轻量的方式，将重复查询的开销压缩至趋近于零——这便是默认启用背后，那份沉静而坚定的技术诚意。 ## 三、总结 一级缓存作为MyBatis默认启用的缓存机制，其设计哲学根植于“轻量、局部、可控”三大原则。它无法被禁用，却通过SqlSession生命周期自然约束作用域，以PerpetualCache为载体、HashMap为底层存储，实现毫秒级响应；其缓存键由MappedStatement ID、SQL文本、参数对象、RowBounds及环境配置共同生成，确保命中条件严格一致；读写流程全自动协同，增删改操作即触发失效，无需人工干预。这种高度内聚、边界清晰的实现，既保障了单一会话内的查询效率，又规避了跨会话数据不一致风险。正因其默认启用、不可禁用，开发者更需理解其行为逻辑——在享受便利的同时，清醒认知其局限：它不是通用缓存解决方案，而是MyBatis为单次SqlSession精心设计的一致性加速器。