User implements Serializable {
//Serializable实现序列化，为了将来反序列化
}
运行程序进行测试，控制台输出结果如下所示：
只进行了一次查询，那么就说明数据已经进入到了二级缓存中。
对于缓存数据更新机制，当某一个作用域(一级缓存 Session/二级缓存Namespaces)的进行了新增、修改、删除操作后，默认该作用域下所有 select 中的缓存将被 clear。
工作机制
- 一个会话查询一条数据，这个数据就会被放在当前会话的一级缓存中；
- 如果当前会话关闭了，这个会话对应的一级缓存就没了，但是我们想要的是，会话关闭了，一级缓存中的数据被保存到二级缓存中；
- 新的会话被查询信息，就可以从二级缓存中获取内容；
- 不同的mapper查出的数据会放在自己对应的缓存(map)中；
小结：
- 只要开启了二级缓存，在同一个Mapper文件下就有效；
- 二级缓存需要缓存的数据实现Serializable接口
- 所有的数据都会先放在一级缓存中；
- 只有会话提交或者关闭以后，一级缓存中的数据才会转移到二级缓存中
总结：
- MyBatis一级缓存的生命周期和SqlSession一致。
- MyBatis一级缓存内部设计简单，只是一个没有容量限定的HashMap，在缓存的功能性上有所欠缺。
- MyBatis的一级缓存最大范围是SqlSession内部，有多个SqlSession或者分布式的环境下，数据库写操作会引起脏数据，建议设定缓存级别为Statement。
- MyBatis的二级缓存相对于一级缓存来说，实现了SqlSession之间缓存数据的共享，同时粒度更加的细，能够到namespace级别，通过Cache接口实现类不同的组合，对Cache的可控性也更强。
- MyBatis在多表查询时，极大可能会出现脏数据，有设计上的缺陷，安全使用二级缓存的条件比较苛刻。
- 在分布式环境下，由于默认的MyBatis Cache实现都是基于本地的，分布式环境下必然会出现读取到脏数据，需要使用集中式缓存将MyBatis的Cache接口实现，有一定的开发成本，直接使用Redis,Memcached等分布式缓存可能成本更低，安全性也更高。
无论是一级缓存还是二级缓存，只要数据发生了写操作（增、删、改）， 缓存数据都将被自动清理
由于Mybatis的缓存清理机制过于死板，所以，一般在开发实践中并不怎么使用！更多的是使用其它的缓存工具并自行制定缓存策略