Myabtis源码分析四-缓存模块分析，装饰模式的使用(1)

2401_83915664

于 2024-05-16 11:26:06 发布

阅读量406

点赞数 3

分类专栏：程序员文章标签：缓存 java 数据库

本文链接：https://blog.csdn.net/2401_83915664/article/details/138953936

版权

程序员专栏收录该内容

557 篇文章 0 订阅

订阅专栏

/**

Simple blocking decorator
Simple and inefficient version of EhCache’s BlockingCache decorator.
It sets a lock over a cache key when the element is not found in cache.
This way, other threads will wait until this element is filled instead of hitting the database.
阻塞版本的缓存装饰器，保证只有一个线程到数据库去查找指定的key对应的数据

public class BlockingCache implements Cache {

//阻塞的超时时长

private long timeout;

//被装饰的底层对象，一般是PerpetualCache

private final Cache delegate;

//锁对象集，粒度到key值

private final ConcurrentHashMap<Object, ReentrantLock> locks;

public BlockingCache(Cache delegate) {

this.delegate = delegate;

this.locks = new ConcurrentHashMap<>();

}

@Override

public String getId() {

return delegate.getId();

}

@Override

public int getSize() {

return delegate.getSize();

}

@Override

public void putObject(Object key, Object value) {

try {

delegate.putObject(key, value);

} finally {

releaseLock(key);

}

@Override

public Object getObject(Object key) {

acquireLock(key);//根据key获得锁对象，获取锁成功加锁，获取锁失败阻塞一段时间重试

Object value = delegate.getObject(key);

if (value != null) {//获取数据成功的，要释放锁

releaseLock(key);

}

return value;

}

@Override

public Object removeObject(Object key) {

// despite of its name, this method is called only to release locks

releaseLock(key);

return null;

}

@Override

public void clear() {

delegate.clear();

}

@Override

public ReadWriteLock getReadWriteLock() {

return null;

}

private ReentrantLock getLockForKey(Object key) {

ReentrantLock lock = new ReentrantLock();//创建锁

ReentrantLock previous = locks.putIfAbsent(key, lock);//把新锁添加到locks集合中，如果添加成功使用新锁，如果添加失败则使用locks集合中的锁

return previous == null ? lock : previous;

}

//根据key获得锁对象，获取锁成功加锁，获取锁失败阻塞一段时间重试

private void acquireLock(Object key) {

//获得锁对象

Lock lock = getLockForKey(key);

if (timeout > 0) {//使用带超时时间的锁

try {

boolean acquired = lock.tryLock(timeout, TimeUnit.MILLISECONDS);

if (!acquired) {//如果超时抛出异常

throw new CacheException("Couldn’t get a lock in " + timeout + " for the key " + key + " at the cache " + delegate.getId());

}

} catch (InterruptedException e) {

throw new CacheException("Got interrupted while trying to acquire lock for key " + key, e);

}

} else {//使用不带超时时间的锁

lock.lock();

}

private void releaseLock(Object key) {

ReentrantLock lock = locks.get(key);

if (lock.isHeldByCurrentThread()) {

lock.unlock();

}

public long getTimeout() {

return timeout;

}

public void setTimeout(long timeout) {

this.timeout = timeout;

}

除了 BlockingCache 之外，缓存模块还有其他的装饰器如：

LoggingCache：日志能力的缓存；
ScheduledCache：定时清空的缓存；
BlockingCache：阻塞式缓存；
SerializedCache：序列化能力的缓存；
SynchronizedCache：进行同步控制的缓存；

那么问题来了，我们知道HashMap是线程不安全的，那么Mybatis 的缓存功能使用 HashMap 实现会不会出现并发安全的问题呢？

MyBatis 的缓存分为一级缓存、二级缓存。二级缓存是多个会话共享的缓存，确实会出现并发安全的问题，因此 MyBatis 在初始化二级缓存时，会给二级缓存默认加上 SynchronizedCache 装饰器的增强，在对共享数据 HashMap 操作时进行同步控制，所以二级缓存不会出现并发安全问题；而一级缓存是会话独享的，不会出现多个线程同时操作缓存数据的场景，因此一级缓存也不会出现并发安全的问题；

四、缓存的唯一标识 CacheKey

===================

MyBatis 中涉及到动态 SQL 的原因，缓存项的 key 不能仅仅通过一个 String 来表示，所以通过 CacheKey 来封装缓存的 Key 值，CacheKey 可以封装多个影响缓存项的因素；

判断两个 CacheKey是否相同关键是比较两个对象的hash值是否一致；构成CacheKey对象的要素包括：