Mybatis源码分析——一级缓存和二级缓存分析

前言

像Mybatis、Hibernate这样的ORM框架，封装了JDBC的大部分操作，极大的简化了我们对数据库的操作。

 

在实际项目中，我们发现在一个事务中查询同样的语句两次的时候，第二次没有进行数据库查询，直接返回了结果，实际这种情况我们就可以称为缓存。

Mybatis的缓存级别

一级缓存

• MyBatis的一级查询缓存（也叫作本地缓存）是基于org.apache.ibatis.cache.impl.PerpetualCache 类的 HashMap本地缓存，其作用域是SqlSession，myBatis 默认一级查询缓存是开启状态，且不能关闭。

• 在同一个SqlSession中两次执行相同的 sql查询语句，第一次执行完毕后，会将查询结果写入到缓存中，第二次会从缓存中直接获取数据，而不再到数据库中进行查询，这样就减少了数据库的访问，从而提高查询效率。

• 基于PerpetualCache 的 HashMap本地缓存，其存储作用域为 Session，PerpetualCache 对象是在SqlSession中的Executor的localcache属性当中存放，当 Session flush 或 close 之后，该Session中的所有 Cache 就将清空。

二级缓存

• 二级缓存与一级缓存其机制相同，默认也是采用 PerpetualCache，HashMap存储，不同在于其存储作用域为 Mapper(Namespace)，每个Mapper中有一个Cache对象，存放在Configration中，并且将其放进当前Mapper的所有MappedStatement当中，并且可自定义存储源，如 Ehcache。

• Mapper级别缓存，定义在Mapper文件的<cache>标签并需要开启此缓存。

用下面这张图描述一级缓存和二级缓存的关系。

CacheKey

在 MyBatis 中，引入缓存的目的是为提高查询效率，降低数据库压力。既然 MyBatis 引入了缓存，那么大家思考过缓存中的 key 和 value 的值分别是什么吗？大家可能很容易能回答出 value 的内容，不就是 SQL 的查询结果吗。那 key 是什么呢？是字符串，还是其他什么对象？如果是字符串的话，那么大家首先能想到的是用 SQL 语句作为 key。但这是不对的，比如：

SELECT * FROM user where id > ?

id > 1 和 id > 10 查出来的结果可能是不同的，所以我们不能简单的使用 SQL 语句作为 key。从这里可以看出来，运行时参数将会影响查询结果，因此我们的 key 应该涵盖运行时参数。除此之外呢，如果进行分页查询也会导致查询结果不同，因此 key 也应该涵盖分页参数。综上，我们不能使用简单的 SQL 语句作为 key。应该考虑使用一种复合对象，能涵盖可影响查询结果的因子。在 MyBatis 中，这种复合对象就是 CacheKey。下面来看一下它的定义。

public class CacheKey implements Cloneable, Serializable { public static final CacheKey NULL_CACHE_KEY = new NullCacheKey(); private static final int DEFAULT_MULTIPLYER = 37; private static final int DEFAULT_HASHCODE = 17; // 乘子，默认为37 private final int multiplier; // CacheKey 的 hashCode，综合了各种影响因子 private int hashcode; // 校验和 private long checksum; // 影响因子个数 private int count; // 影响因子集合 private List<Object> updateList; public CacheKey() { this.hashcode = DEFAULT_HASHCODE; this.multiplier = DEFAULT_MULTIPLYER; this.count = 0; this.updateList = new ArrayList<Object>(); } /* * 每当执行更新操作时，表示有新的影响因子参与计算 * 当不断有新的影响因子参与计算时，hashcode 和 checksum 将会变得愈发复杂和随机。这样可降低冲突率，使 CacheKey 可在缓存中更均匀的分布。 */ public void update(Object object) { int baseHashCode = object == null ? 1 : ArrayUtil.hashCode(object); // 自增 count count++; // 计算校验和 checksum += baseHashCode; // 更新 baseHashCode baseHashCode *= count; // 计算 hashCode hashcode = multiplier * hashcode + baseHashCode; // 保存影响因子 updateList.add(object); } /** * CacheKey 最终要作为键存入 HashMap，因此它需要覆盖 equals 和 hashCode 方法 */ @Override public boolean equals(Object object) { // 检测是否为同一个对象 if (this == object) { return true; } // 检测 object 是否为 CacheKey if (!(object instanceof CacheKey)) { return false; } final CacheKey cacheKey = (CacheKey) object; // 检测 hashCode 是否相等 if (hashcode != cacheKey.hashcode) { return false; } // 检测校验和是否相同 if (checksum != cacheKey.checksum) { return false; } // 检测 coutn 是否相同 if (count != cacheKey.count) { return false; } // 如果上面的检测都通过了，下面分别对每个影响因子进行比较 for (int i = 0; i < updateList.size(); i++) { Object thisObject = updateList.get(i); Object thatObject = cacheKey.updateList.get(i); if (!ArrayUtil.equals(thisObject, thatObject)) { return false; } } return true; } @Override public int hashCode() { // 返回 hashcode 变量 return hashcode; } }

当不断有新的影响因子参与计算时，hashcode 和 checksum 将会变得愈发复杂和随机。这样可降低冲突率，使 CacheKey 可在缓存中更均匀的分布。CacheKey 最终要作为键存入 HashMap，因此它需要覆盖 equals 和 hashCode 方法。

一级缓存源码解析

一级缓存的测试

同一个session查询

public static void main(String[] args) { SqlSession session = sqlSessionFactory.openSession(); try { Blog blog = (Blog)session.selectOne("queryById",1); Blog blog2 = (Blog)session.selectOne("queryById",1); } finally { session.close(); } }

结论：只有一个DB查询

两个session分别查询

public static void main(String[] args) { SqlSession session = sqlSessionFactory.openSession(); SqlSession session1 = sqlSessionFactory.openSession(); try { Blog blog = (Blog)session.selectOne("queryById",17); Blog blog2 = (Blog)session1.selectOne("queryById",17); } finally { session.close(); } }

结论：进行了两次DB查询

同一个session，进行update之后再次查询

public static void main(String[] args) { SqlSession session = sqlSessionFactory.openSession(); try { Blog blog = (Blog)session.selectOne("queryById",17); blog.setName("llll"); session.update("updateBlog",blog); Blog blog2 = (Blog)session.selectOne("queryById",17); } finally { session.close(); } }

结论：进行了两次DB查询

总结：在一级缓存中，同一个SqlSession下，查询语句相同的SQL会被缓存，如果执行增删改操作之后，该缓存就会被删除。

创建缓存对象PerpetualCache

我们来回顾一下创建SqlSession的过程

SqlSession session = sessionFactory.openSession(); public class DefaultSqlSessionFactory implements SqlSessionFactory { private final Configuration configuration; @Override public SqlSession openSession() { return openSessionFromDataSource(configuration.getDefaultExecutorType(), null, false); } private SqlSession openSessionFromDataSource(ExecutorType execType, TransactionIsolationLevel level, boolean autoCommit) { Transaction tx = null; try { final Environment environment = configuration.getEnvironment(); final TransactionFactory transactionFactory = getTransactionFactoryFromEnvironment(environment); tx = transactionFactory.newTransaction(environment.getDataSource(), level, autoCommit); //创建SQL执行器 final Executor executor = configuration.newExecutor(tx, execType); return new DefaultSqlSession(configuration, executor, autoCommit); } catch (Exception e) { closeTransaction(tx); // may have fetched a connection so lets call close() throw ExceptionFactory.wrapException("Error opening session. Cause: " + e, e); } finally { ErrorContext.instance().reset(); } } } public class Configuration { protected final InterceptorChain interceptorChain = new InterceptorChain(); 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 { //默认创建SimpleExecutor executor = new SimpleExecutor(this, transaction); } if (cacheEnabled) { //开启二级缓存就会用CachingExecutor装饰SimpleExecutor executor = new CachingExecutor(executor); } executor = (Executor) interceptorChain.pluginAll(executor); return executor; } } public class SimpleExecutor extends BaseExecutor { public SimpleExecutor(Configuration configuration, Transaction transaction) { super(configuration, transaction); } } public abstract class BaseExecutor implements Executor { private static final Log log = LogFactory.getLog(BaseExecutor.class); protected Transaction transaction; protected Executor wrapper; protected ConcurrentLinkedQueue<DeferredLoad> deferredLoads; protected PerpetualCache localCache; protected PerpetualCache localOutputParameterCache; protected Configuration configuration; protected int queryStack; private boolean closed; protected BaseExecutor(Configuration configuration, Transaction transaction) { this.transaction = transaction; this.deferredLoads = new ConcurrentLinkedQueue<DeferredLoad>(); //创建一个缓存对象，PerpetualCache并不是线程安全的 //但SqlSession和Executor对象在通常情况下只能有一个线程访问，而且访问完成之后马上销毁。也就是session.close(); this.localCache = new PerpetualCache("LocalCache"); this.localOutputParameterCache = new PerpetualCache("LocalOutputParameterCache"); this.closed = false; this.configuration = configuration; this.wrapper = this; } }

我只是简单的贴了代码，大家可以看我之前的博客，我们可以看到DefaultSqlSession中有SimpleExecutor对象，SimpleExecutor对象中有一个PerpetualCache，一级缓存的数据就是存储在PerpetualCache对象中，SqlSession关闭的时候会清空PerpetualCache

一级缓存实现

再来看BaseExecutor中的query方法是怎么实现一级缓存的，executor默认实现为CachingExecutor

CachingExecutor

public class CachingExecutor implements Executor { private final Executor delegate; private final TransactionalCacheManager tcm = new TransactionalCacheManager(); @Override public <E> List<E> query(MappedStatement ms, Object parameterObject, RowBounds rowBounds, ResultHandler resultHandler) throws SQLException { BoundSql boundSql = ms.getBoundSql(parameterObject); // 创建 CacheKey CacheKey key = createCacheKey(ms, parameterObject, rowBounds, boundSql); return query(ms, parameterObject, rowBounds, resultHandler, key, boundSql); } @Override public <E> List<E> query(MappedStatement ms, Object parameterObject, RowBounds rowBounds, ResultHandler resultHandler, CacheKey key, BoundSql boundSql) throws SQLException { // 从 MappedStatement 中获取 Cache，注意这里的 Cache 是从MappedStatement中获取的 // 也就是我们上面解析Mapper中<cache/>标签中创建的，它保存在Configration中 // 我们在上面解析blog.xml时分析过每一个MappedStatement都有一个Cache对象，就是这里 Cache cache = ms.getCache(); // 如果配置文件中没有配置 <cache>，则 cache 为空 if (cache != null) { //如果需要刷新缓存的话就刷新：flushCache="true" flushCacheIfRequired(ms); if (ms.isUseCache() && resultHandler == null) { ensureNoOutParams(ms, boundSql); @SuppressWarnings("unchecked") // 访问二级缓存 List<E> list = (List<E>) tcm.getObject(cache, key); // 缓存未命中 if (list == null) { // 如果没有值，则执行查询，这个查询实际也是先走一级缓存查询，一级缓存也没有的话，则进行DB查询 list = delegate.<E> query(ms, parameterObject, rowBounds, resultHandler, key, boundSql); // 缓存查询结果 tcm.putObject(cache, key, list); // issue #578 and #116 } return list; } } return delegate.<E> query(ms, parameterObject, rowBounds, resultHandler, key, boundSql); } }

如果设置了flushCache="true"，则每次查询都会刷新缓存

<!-- 执行此语句清空缓存 --> <select id="getAll" resultType="entity.TDemo" useCache="true" flushCache="true" > select * from t_demo </select>

如上，注意二级缓存是从 MappedStatement 中获取的。由于 MappedStatement 存在于全局配置中，可以多个 CachingExecutor 获取到，这样就会出现线程安全问题。除此之外，若不加以控制，多个事务共用一个缓存实例，会导致脏读问题。至于脏读问题，需要借助其他类来处理，也就是上面代码中 tcm 变量对应的类型。下面分析一下。

TransactionalCacheManager

/* * 事务缓存管理器 */ public class TransactionalCacheManager { // Cache 与 TransactionalCache 的映射关系表 private final Map<Cache, TransactionalCache> transactionalCaches = new HashMap<Cache, TransactionalCache>(); public void clear(Cache cache) { // 获取 TransactionalCache 对象，并调用该对象的 clear 方法，下同 getTransactionalCache(cache).clear(); } public Object getObject(Cache cache, CacheKey key) { // 直接从TransactionalCache中获取缓存 return getTransactionalCache(cache).getObject(key); } public void putObject(Cache cache, CacheKey key, Object value) { // 直接存入TransactionalCache的缓存中 getTransactionalCache(cache).putObject(key, value); } public void commit() { for (TransactionalCache txCache : transactionalCaches.values()) { txCache.commit(); } } public void rollback() { for (TransactionalCache txCache : transactionalCaches.values()) { txCache.rollback(); } } private TransactionalCache getTransactionalCache(Cache cache) { // 从映射表中获取 TransactionalCache TransactionalCache txCache = transactionalCaches.get(cache); if (txCache == null) { // TransactionalCache 也是一种装饰类，为 Cache 增加事务功能 // 创建一个新的TransactionalCache，并将真正的Cache对象存进去 txCache = new TransactionalCache(cache); transactionalCaches.put(cache, txCache); } return txCache; } }

TransactionalCacheManager 内部维护了 Cache 实例与 TransactionalCache 实例间的映射关系，该类也仅负责维护两者的映射关系，真正做事的还是 TransactionalCache。TransactionalCache 是一种缓存装饰器，可以为 Cache 实例增加事务功能。我在之前提到的脏读问题正是由该类进行处理的。下面分析一下该类的逻辑。

TransactionalCache

public class TransactionalCache implements Cache { //真正的缓存对象，和上面的Map<Cache, TransactionalCache>中的Cache是同一个 private final Cache delegate; private boolean clearOnCommit; // 在事务被提交前，所有从数据库中查询的结果将缓存在此集合中 private final Map<Object, Object> entriesToAddOnCommit; // 在事务被提交前，当缓存未命中时，CacheKey 将会被存储在此集合中 private final Set<Object> entriesMissedInCache; public TransactionalCache(Cache delegate) { this.delegate = delegate; this.clearOnCommit = false; this.entriesToAddOnCommit = new HashMap<Object, Object>(); this.entriesMissedInCache = new HashSet<Object>(); } @Override public Object getObject(Object key) { // 查询的时候是直接从delegate中去查询的，也就是从真正的缓存对象中查询 Object object = delegate.getObject(key); if (object == null) { // 缓存未命中，则将 key 存入到 entriesMissedInCache 中 entriesMissedInCache.add(key); } if (clearOnCommit) { return null; } else { return object; } } @Override public void putObject(Object key, Object object) { // 将键值对存入到 entriesToAddOnCommit 这个Map中中，而非真实的缓存对象 delegate 中 entriesToAddOnCommit.put(key, object); } @Override public Object removeObject(Object key) { return null; } @Override public void clear() { clearOnCommit = true; // 清空 entriesToAddOnCommit，但不清空 delegate 缓存 entriesToAddOnCommit.clear(); } public void commit() { // 根据 clearOnCommit 的值决定是否清空 delegate if (clearOnCommit) { delegate.clear(); } // 刷新未缓存的结果到 delegate 缓存中 flushPendingEntries(); // 重置 entriesToAddOnCommit 和 entriesMissedInCache reset(); } public void rollback() { unlockMissedEntries(); reset(); } private void reset() { clearOnCommit = false; // 清空集合 entriesToAddOnCommit.clear(); entriesMissedInCache.clear(); } private void flushPendingEntries() { for (Map.Entry<Object, Object> entry : entriesToAddOnCommit.entrySet()) { // 将 entriesToAddOnCommit 中的内容转存到 delegate 中 delegate.putObject(entry.getKey(), entry.getValue()); } for (Object entry : entriesMissedInCache) { if (!entriesToAddOnCommit.containsKey(entry)) { // 存入空值 delegate.putObject(entry, null); } } } private void unlockMissedEntries() { for (Object entry : entriesMissedInCache) { try { // 调用 removeObject 进行解锁 delegate.removeObject(entry); } catch (Exception e) { log.warn("Unexpected exception while notifiying a rollback to the cache adapter." + "Consider upgrading your cache adapter to the latest version. Cause: " + e); } } } }

存储二级缓存对象的时候是放到了TransactionalCache.entriesToAddOnCommit这个map中，但是每次查询的时候是直接从TransactionalCache.delegate中去查询的，所以这个二级缓存查询数据库后，设置缓存值是没有立刻生效的，主要是因为直接存到 delegate 会导致脏数据问题。

为何只有SqlSession提交或关闭之后二级缓存才会生效？

那我们来看下SqlSession.commit()方法做了什么

SqlSession

public class DefaultSqlSession implements SqlSession { private final Configuration configuration; private final Executor executor; @Override public void commit(boolean force) { try { // 主要是这句 executor.commit(isCommitOrRollbackRequired(force)); dirty = false; } catch (Exception e) { throw ExceptionFactory.wrapException("Error committing transaction. Cause: " + e, e); } finally { ErrorContext.instance().reset(); } } } public class CachingExecutor implements Executor { private final Executor delegate; private final TransactionalCacheManager tcm = new TransactionalCacheManager(); @Override public void commit(boolean required) throws SQLException { delegate.commit(required); tcm.commit();// 在这里 } } public class TransactionalCacheManager { private final Map<Cache, TransactionalCache> transactionalCaches = new HashMap<Cache, TransactionalCache>(); public void commit() { for (TransactionalCache txCache : transactionalCaches.values()) { txCache.commit();// 在这里 } } } public class TransactionalCache implements Cache { private final Cache delegate; public void commit() { if (clearOnCommit) { delegate.clear(); } flushPendingEntries();//这一句 reset(); } private void flushPendingEntries() { for (Map.Entry<Object, Object> entry : entriesToAddOnCommit.entrySet()) { // 在这里真正的将entriesToAddOnCommit的对象逐个添加到delegate中，只有这时，二级缓存才真正的生效 delegate.putObject(entry.getKey(), entry.getValue()); } for (Object entry : entriesMissedInCache) { if (!entriesToAddOnCommit.containsKey(entry)) { delegate.putObject(entry, null); } } } }

如果从数据库查询到的数据直接存到 delegate 会导致脏数据问题。下面通过一张图演示一下脏数据问题发生的过程，假设两个线程开启两个不同的事务，它们的执行过程如下：

如上图，时刻2，事务 A 对记录 A 进行了更新。时刻3，事务 A 从数据库查询记录 A，并将记录 A 写入缓存中。时刻4，事务 B 查询记录 A，由于缓存中存在记录 A，事务 B 直接从缓存中取数据。这个时候，脏数据问题就发生了。事务 B 在事务 A 未提交情况下，读取到了事务 A 所修改的记录。为了解决这个问题，我们可以为每个事务引入一个独立的缓存。查询数据时，仍从 delegate 缓存（以下统称为共享缓存）中查询。若缓存未命中，则查询数据库。存储查询结果时，并不直接存储查询结果到共享缓存中，而是先存储到事务缓存中，也就是 entriesToAddOnCommit 集合。当事务提交时，再将事务缓存中的缓存项转存到共享缓存中。这样，事务 B 只能在事务 A 提交后，才能读取到事务 A 所做的修改，解决了脏读问题。

二级缓存的刷新

我们来看看SqlSession的更新操作

public class DefaultSqlSession implements SqlSession { private final Configuration configuration; private final Executor executor; @Override public int update(String statement, Object parameter) { try { dirty = true; MappedStatement ms = configuration.getMappedStatement(statement); return executor.update(ms, wrapCollection(parameter)); } catch (Exception e) { throw ExceptionFactory.wrapException("Error updating database. Cause: " + e, e); } finally { ErrorContext.instance().reset(); } } } public class CachingExecutor implements Executor { private final Executor delegate; private final TransactionalCacheManager tcm = new TransactionalCacheManager(); @Override public int update(MappedStatement ms, Object parameterObject) throws SQLException { flushCacheIfRequired(ms); return delegate.update(ms, parameterObject); } private void flushCacheIfRequired(MappedStatement ms) { //获取MappedStatement对应的Cache，进行清空 Cache cache = ms.getCache(); //SQL需设置flushCache="true" 才会执行清空 if (cache != null && ms.isFlushCacheRequired()) { tcm.clear(cache); } } }

MyBatis二级缓存只适用于不常进行增、删、改的数据，比如国家行政区省市区街道数据。一但数据变更，MyBatis会清空缓存。因此二级缓存不适用于经常进行更新的数据。

使用redis存储二级缓存

通过上面代码分析，我们知道二级缓存默认和一级缓存都是使用的PerpetualCache存储结果，一级缓存只要SQLSession关闭就会清空，其内部使用HashMap实现，所以二级缓存无法实现分布式，并且服务器重启后就没有缓存了。此时就需要引入第三方缓存中间件，将缓存的值存到外部，如redis和ehcache

修改mapper.xml中的配置。

<?xml version="1.0" encoding="UTF-8" ?> <!DOCTYPE mapper PUBLIC "-//mybatis.org//DTD Mapper 3.0//EN" "http://mybatis.org/dtd/mybatis-3-mapper.dtd" > <mapper namespace="com.yibo.saas.common.dal.dao.AreaDefaultMapper"> <!-- flushInterval（清空缓存的时间间隔）: 单位毫秒，可以被设置为任意的正整数。 默认情况是不设置，也就是没有刷新间隔，缓存仅仅调用语句时刷新。 size（引用数目）: 可以被设置为任意正整数，要记住你缓存的对象数目和你运行环境的可用内存资源数目。默认值是1024。 readOnly（只读）:属性可以被设置为true或false。只读的缓存会给所有调用者返回缓存对象的相同实例。 因此这些对象不能被修改。这提供了很重要的性能优势。可读写的缓存会返回缓存对象的拷贝（通过序列化）。这会慢一些，但是安全，因此默认是false。 eviction（回收策略）: 默认的是 LRU: 1.LRU – 最近最少使用的:移除最长时间不被使用的对象。 2.FIFO – 先进先出:按对象进入缓存的顺序来移除它们。 3.SOFT – 软引用:移除基于垃圾回收器状态和软引用规则的对象。 4.WEAK – 弱引用:更积极地移除基于垃圾收集器状态和弱引用规则的对象。 blocking（是否使用阻塞缓存）: 默认为false，当指定为true时将采用BlockingCache进行封装，blocking，阻塞的意思， 使用BlockingCache会在查询缓存时锁住对应的Key，如果缓存命中了则会释放对应的锁，否则会在查询数据库以后再释放锁， 这样可以阻止并发情况下多个线程同时查询数据，详情可参考BlockingCache的源码。 type（缓存类）：可指定使用的缓存类，mybatis默认使用HashMap进行缓存,这里引用第三方中间件进行缓存 --> <cache type="org.mybatis.caches.redis.RedisCache" blocking="false" flushInterval="0" readOnly="true" size="1024" eviction="FIFO"/> <!-- useCache（是否使用缓存）：默认true使用缓存 --> <select id="find" parameterType="map" resultType="com.yibo.model.User" useCache="true"> SELECT * FROM user </select> </mapper>

依然很简单， RedisCache 在保存缓存数据和获取缓存数据时，使用了Java的序列化和反序列化，因此需要保证被缓存的对象必须实现Serializable接口。

也可以自己实现cache

public class RedisCache implements Cache { private final String id; private static ValueOperations<String, Object> valueOs; private static RedisTemplate<String, String> template; public static void setValueOs(ValueOperations<String, Object> valueOs) { RedisCache.valueOs = valueOs; } public static void setTemplate(RedisTemplate<String, String> template) { RedisCache.template = template; } private final ReadWriteLock readWriteLock = new ReentrantReadWriteLock(); public RedisCache(String id) { if (id == null) { throw new IllegalArgumentException("Cache instances require an ID"); } this.id = id; } @Override public String getId() { return this.id; } @Override public void putObject(Object key, Object value) { valueOs.set(key.toString(), value, 10, TimeUnit.MINUTES); } @Override public Object getObject(Object key) { return valueOs.get(key.toString()); } @Override public Object removeObject(Object key) { valueOs.set(key.toString(), "", 0, TimeUnit.MINUTES); return key; } @Override public void clear() { template.getConnectionFactory().getConnection().flushDb(); } @Override public int getSize() { return template.getConnectionFactory().getConnection().dbSize().intValue(); } @Override public ReadWriteLock getReadWriteLock() { return this.readWriteLock; } }

Mapper中配置自己实现的Cache

<cache type="com.chenhao.mybatis.cache.RedisCache"/>

 

参考： https://www.cnblogs.com/java-chen-hao/p/11770064.html