mybatis二级缓存默认非线程安全，底层使用perpetualcache（hashmap），需通过synchronizedcache装饰器加锁保障一致性；它以轻量同步封装底层缓存，支持装饰器链，但仅限单jvm，不解决分布式一致性。
MyBatis二级缓存默认不是线程安全的，底层用的是 PerpetualCache（基于 HashMap），多个线程并发读写时可能引发数据错乱或 ConcurrentModificationException。要保障多线程环境下的缓存一致性，SynchronizedCache 是 MyBatis 官方提供的最轻量、最直接的同步方案——它不改写存储逻辑，而是在操作入口加锁，把并发访问串行化。
为什么不能只靠 synchronized 方法？
MyBatis 的缓存接口 Cache 要求实现类必须有一个带 String id 参数的构造器，并支持装饰器链式调用。如果在自定义缓存类里仅给 putObject/getObject 加 synchronized 关键字，会带来两个问题：
- 锁粒度太粗：整个方法体被锁住，读写互斥，严重拖慢高并发读场景
- 无法兼容装饰器链：比如你同时用了
LruCache和自定义序列化，synchronized 方法无法嵌套进 delegate 流程
SynchronizedCache 的标准用法
它本身就是一个装饰器，不负责存储，只负责同步。典型配置方式如下：
- 在
<cache></cache>标签中通过type指定：<cache type="org.apache.ibatis.cache.impl.SynchronizedCache"></cache> - 或在 Java 注解中配合
@CacheNamespace使用（MyBatis 3.4+）：@CacheNamespace(implementation = SynchronizedCache.class) - 它会自动包装你指定的底层缓存（如
PerpetualCache或 Redis 实现），所有get/put/remove操作都会先获取同一把对象锁（delegate的 monitor）
和 ReentrantReadWriteLock 的关键区别
虽然 SynchronizedCache 简单可靠，但它用的是重量级锁（monitorenter/monitorexit），不具备读写分离能力。如果你的应用读远多于写（比如商品详情页缓存），更推荐自定义缓存实现并集成 ReentrantReadWriteLock：
- 读操作用
readLock().lock()，允许多个线程并发读 - 写操作（
put/remove）用writeLock().lock()，独占排他 - 注意：必须确保
getObject和putObject对同一个 key 的读写成对加锁，避免“脏读”
实战避坑提醒
即使加了 SynchronizedCache，仍需注意以下几点：
- 它不解决跨 JVM 缓存一致性：SynchronizedCache 只作用于单个 JVM 进程内，集群部署时必须搭配 Redis/Ehcache 等分布式缓存
-
不替代缓存更新策略：CRUD 操作后，MyBatis 默认清空当前 namespace 下全部缓存，但不会自动失效关联缓存（如用户信息变更时未联动清理其订单列表），需手动
cache.clear()或设计缓存依赖关系 -
避免锁升级陷阱：若在
getObject中执行耗时操作（如远程调用、复杂反序列化），会导致其他线程长时间阻塞，应将耗时逻辑移出同步块
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
