12-Mybatis源码和设计模式-3(缓存模块和装饰器模式)

最新推荐文章于 2024-06-22 20:44:36 发布
最新推荐文章于 2024-06-22 20:44:36 发布
阅读量352 收藏
点赞数
分类专栏： Mybatis
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/my_momo_csdn/article/details/93618387
版权

文章目录

缓存模块和装饰器模式

一、缓存模块

  • Mybatis缓存模块的核心功能是提供缓存的读取(基于Map来实现)，在核心功能的基础之上添加了很多附加功能，比如FIFO淘汰，LRU淘汰，阻塞缓存，定时清空的缓存，打印日志等，这些附加功能就是通过装饰器模式来添加到核心功能上去的。(类似于参考文章中的普通玩家，Vip玩家之类的)

二、装饰器模式

  • 给主核心功能添加附加功能，并且能够自由的组合，使用继承不灵活，且附加功能可能很多，继承将导致类非常庞大不可维护。
  • 具体可以参考装饰器模式07-结构型模式(中)

三、目录结构

  • 包：org.apache.ibatis.cache包

image

  • 图中可以看到缓存的核心接口，主体功能实现类和各种附加功能装饰器，由此形成了各具特色的缓存。

四、源码解析

4.1 接口

  • Cache，核心功能接口
public interface Cache {
 
  //缓存实现类的id
  String getId();
  
  //往缓存中添加数据，key一般是CacheKey对象
  void putObject(Object key, Object value);

  //根据指定的key从缓存获取数据
  Object getObject(Object key);
  
  //根据指定的key从缓存删除数据 
  Object removeObject(Object key);
  
  //清空缓存
  void clear();
   
  //获取缓存的个数
  int getSize();
  
  //获取读写锁 
  ReadWriteLock getReadWriteLock();
}

4.2 实现类

  • 实现类PerpetualCache实现了基本的主体功能
public class PerpetualCache implements Cache {

  private final String id;

  private Map<Object, Object> cache = new HashMap<>();

  public PerpetualCache(String id) {
    this.id = id;
  }

  @Override
  public String getId() {
    return id;
  }

  @Override
  public int getSize() {
    return cache.size();
  }

  @Override
  public void putObject(Object key, Object value) {
    cache.put(key, value);
  }

  @Override
  public Object getObject(Object key) {
    return cache.get(key);
  }

  @Override
  public Object removeObject(Object key) {
    return cache.remove(key);
  }

  @Override
  public void clear() {
    cache.clear();
  }

  @Override
  public ReadWriteLock getReadWriteLock() {
    return null;
  }

  @Override
  public boolean equals(Object o) {
    if (getId() == null) {
      throw new CacheException("Cache instances require an ID.");
    }
    if (this == o) {
      return true;
    }
    if (!(o instanceof Cache)) {
      return false;
    }

    Cache otherCache = (Cache) o;
    return getId().equals(otherCache.getId());
  }

  @Override
  public int hashCode() {
    if (getId() == null) {
      throw new CacheException("Cache instances require an ID.");
    }
    return getId().hashCode();
  }

}

4.3 装饰器类

  • 装饰器类给基本实现类添对应的功能
4.3.1 FifoCache
  • FifoCache让缓存具备FIFO的淘汰策略
/**
 * FIFO (first in, first out) cache decorator
 *
 * @author Clinton Begin
 * 给缓存添加淘汰策略，实现FIFO的功能
 * 1.我们发现FifoCache也实现了Cache接口，因此它的行为和PerpetualCache几乎是一致的(都实现了Cache接口定义的方法)
 * 并且FifoCache的这些方法的实现，内部都是调用PerpetualCache的实现，因为PerpetualCache才是缓存功能真正的实现者嘛。
 * 2.但是FifoCache也有自己需要添加的功能，需要实现FIFO的功能，因此FifoCache内部维护着一个FIFO队列的keyList，队列里
 * 保存着缓存的数据的key，在每一次保存数据的时候都会检查FIFO队列对起进行维护，超过设定大小就会去除最旧的key，同时把
 * 缓存中的key也删除。这样就为缓存实现了FIFO的淘汰策略
 * <p>
 * 小结一下：
 * 为线程添加缓存FIFO淘汰功能修改的地方只有一下2处，其他都是原封不动的调用PerpetualCache的方法：
 * A.存入元素时，需要检查FIFO队列
 * B.清理缓存时，清除FIFO队列
 */
public class FifoCache implements Cache {

    //真正的缓存功能实现对象
    private final Cache delegate;
    //FIFO队列
    private Deque<Object> keyList;
    //队列大小，默认1024
    private int size;

    public FifoCache(Cache delegate) {
        this.delegate = delegate;
        this.keyList = new LinkedList<Object>();
        this.size = 1024;
    }

    @Override
    public String getId() {
        return delegate.getId();
    }

    @Override
    public int getSize() {
        return delegate.getSize();
    }

    public void setSize(int size) {
        this.size = size;
    }

    @Override
    public void putObject(Object key, Object value) {
        //存入元素时,检查FIFO队列
        cycleKeyList(key);
        delegate.putObject(key, value);
    }

    @Override
    public Object getObject(Object key) {
        return delegate.getObject(key);
    }

    @Override
    public Object removeObject(Object key) {
        return delegate.removeObject(key);
    }

    @Override
    public void clear() {
        //清理操作时，将FIFO队列也清除
        delegate.clear();
        keyList.clear();
    }

    @Override
    public ReadWriteLock getReadWriteLock() {
        return null;
    }

    private void cycleKeyList(Object key) {
        //新添加的key需要保存到keyList里面
        keyList.addLast(key);
        //判断是否到了最大长度，到了的话需要移除头部最旧的key，同时把缓存中对应的key也删除掉
        if (keyList.size() > size) {
            Object oldestKey = keyList.removeFirst();
            delegate.removeObject(oldestKey);
        }
    }
}
  • FIFO的实现思路是：内部维护一个Deque的FIFO队列，每次存入元素时检查FIFO队列，清理缓存时，清除FIFO队列，不需要额外太多的工作。
4.3.2 LruCache
  • LruCache让缓存具备LRU的淘汰策略
/**
 * Lru (least recently used) cache decorator
 * 为缓存添加LRU的淘汰策略
 * 1.LRU的实现思路是，额外维护一个LRU队列按照key的访问顺序保存缓存的key，它是基于LinkedHashMap实现的
 * 2.每次put新增缓存，新的缓存key会被放在LRU队列尾部，并且会判断LRU队列中队列头部的最旧的那个key是否需要删除，
 *   如果长度达到了1024就把LRU队列中这个key删除并把这个key记录到一个变量eldestKey中，然后会判断eldestKey是否
 *   为null，如果不为null就在缓存队列中删除这个最旧的key
 *   (参考LinkedHashMap#afterNodeInsertion)
 * 3.每次get获取缓存的时候，在缓存队列获取缓存数据之前，会在LRU队列中获取一次key，这个获取其实并不是得到他的返回值，
 * 仅仅只是触发一次排除，get之后这个key就会被放在LRU队列的尾部，让队列按照LRU原则排序排序
 * (参考LinkedHashMap.get和LinkedHashMap.afterNodeAccess)
 *
 * @author Clinton Begin
 */
public class LruCache implements Cache {

    private final Cache delegate;
    //1.keyMap是一个LinkedHashMap，也是一个LRU队列，他是按照元素的访问顺序排队的，最久未被访问的元素排在
    //队头，最近访问的元素排在队尾(value和key是一样的，其实就是一个有序的链表)
    private Map<Object, Object> keyMap;
    //2.记录最老的key
    private Object eldestKey;

    //3.构造方法初始化LRU队列长度为1024
    public LruCache(Cache delegate) {
        this.delegate = delegate;
        setSize(1024);
    }

    @Override
    public String getId() {
        return delegate.getId();
    }

    @Override
    public int getSize() {
        return delegate.getSize();
    }

    //4.初始化LRU队列
    public void setSize(final int size) {
        //1.LinkedHashMap的元素是有序的，可以按照插入顺序或者按访问顺序(调用get方法)。构造方法的第三个参数可以指定使用哪一种顺序排序
        //true按照访问顺序排序，
        //false按照插入顺序排序
        //这里是按照访问顺序排序，符合LRU思想
        keyMap = new LinkedHashMap<Object, Object>(size, .75F, true) {

            private static final long serialVersionUID = 4267176411845948333L;
            /**
             * LinkedHashMap的removeEldestEntry方法，只要返回true，就会自动删除最近最少使用的key
             * 默认是按插入顺序排序，如果指定按访问顺序排序，那么调用get方法后，会将这次访问的元素移至
             * 链表尾部，不断访问可以形成按访问顺序排序的链表。可以重写removeEldestEntry方法返回
             * true值指定插入元素时移除最老的元素
             *
             * 这里的删除逻辑是这样的，在每一次插入一个新的元素之后，LinkedHashMap里面都会调用removeEldestEntry
             * 方法来判断是否需要删除元素，而传给removeEldestEntry的参数就是链表的头指针，也就是是将最旧的元素传进来，
             * 如果方法一直返回false说明队列永远不会删除元素。这里我们的逻辑是大于1024长度之后，就会返回true，那么返
             * 回true之后LinkedHashMap就会把first代表的最旧的元素删除，与此同时我们会把这个最旧的key记录到eldestKey变量，
             * 因为仅仅删除了这个LRU队列还不够，我们还需要删除真正的缓存队列，缓存队列这个删除逻辑是在put进元素的时候回去检
             * 查，在cycleKeyList中实现，可参考LinkedHashMap#afterNodeInsertion方法
             * */
            @Override
            protected boolean removeEldestEntry(Map.Entry<Object, Object> eldest) {
                boolean tooBig = size() > size;
                if (tooBig) {
                    eldestKey = eldest.getKey();
                }
                return tooBig;
            }
        };
    }

    @Override
    public void putObject(Object key, Object value) {
        delegate.putObject(key, value);
        //1.put进来一个缓存之后，将这个key放到LRU队列尾部，并判断是否有最旧的元素需要删除。逻辑都在cycleKeyList里面实现
        cycleKeyList(key);
    }

    @Override
    public Object getObject(Object key) {
        //1.这里访问get方法就是为了让这个访问的key放到队列的尾部，因此keyMap是按照访问顺序排序的，最久未被
        //问的会放在队列的前面,这里访问该key，就会把置于队尾，实现LRU
        //可以参考LinkedHashMap.get和LinkedHashMap.afterNodeAccess
        //touch
        keyMap.get(key);
        return delegate.getObject(key);
    }

    @Override
    public Object removeObject(Object key) {
        return delegate.removeObject(key);
    }

    @Override
    public void clear() {
        delegate.clear();
        //清理缓存的时候也要清理key集合
        keyMap.clear();
    }

    @Override
    public ReadWriteLock getReadWriteLock() {
        return null;
    }

    //将key放到LRU队列尾部，并判断是否有最旧的key需要删除
    private void cycleKeyList(Object key) {
        //1.这一步就会将key放到LRU队列的尾部，为什么是尾部，参考LinkedHashMap.afterNodeAccess
        keyMap.put(key, key);
        //2.如果有最旧的key需要删除，就删掉
        //LinkedHashMap删除key是在LinkedHashMap#afterNodeInsertion中调用的，这只是把LRU队列的key删除了，但是真正的缓存队列还没有删除key，
        //但是会把key赋值给eldestKey，每一次放进缓存的时候都会来检查，发现有eldestKey，就把他从真正的缓存队列里面清除，并把eldestKey置null
        if (eldestKey != null) {
            delegate.removeObject(eldestKey);
            eldestKey = null;
        }
    }
}

  • 1.LRU的实现思路是，额外维护一个LRU队列按照key的访问顺序保存缓存的key，它是基于LinkedHashMap实现的

  • 2.每次put新增缓存，新的缓存key会被放在LRU队列尾部，并且会判断LRU队列中队列头部的最旧的那个key是否需要删除，如果长度达到了1024就把LRU队列中这个key删除并把这个key记录到一个变量eldestKey中，然后会判断eldestKey是否为null，如果不为null就在缓存队列中删除这个最旧的key(参考LinkedHashMap#afterNodeInsertion)

  • 3.每次get获取缓存的时候，在缓存队列获取缓存数据之前，会在LRU队列中获取一次key，这个获取其实并不是得到他的返回值，仅仅只是触发一次排除，get之后这个key就会被放在LRU队列的尾部，让队列按照LRU原则排序排序(参考LinkedHashMap.get和LinkedHashMap.afterNodeAccess)

  • LinkedHashMap#afterNodeInsertion和afterNodeAccess

void afterNodeInsertion(boolean evict) { // possibly remove eldest
        LinkedHashMap.Entry<K,V> first;
        if (evict && (first = head) != null && removeEldestEntry(first)) {
            K key = first.key;
            removeNode(hash(key), key, null, false, true);
        }
    }
    
void afterNodeAccess(Node<K,V> e) { // move node to last
        LinkedHashMap.Entry<K,V> last;
        if (accessOrder && (last = tail) != e) {
            LinkedHashMap.Entry<K,V> p =
                (LinkedHashMap.Entry<K,V>)e, b = p.before, a = p.after;
            p.after = null;
            if (b == null)
                head = a;
            else
                b.after = a;
            if (a != null)
                a.before = b;
            else
                last = b;
            if (last == null)
                head = p;
            else {
                p.before = last;
                last.after = p;
            }
            tail = p;
            ++modCount;
        }
    }

4.4 小结

  • 如果熟悉装饰器模式，结合注释对上面的两种缓存增强应该比较容易理解，剩余的几种就不一一解析了，思想是一样，只是在装饰器内部实现了需要增强的功能点。

五、缓存功能解读

  • 前面我们没有对缓存本身功能实现进行解读。缓存模块对应的是一级缓存，不管是否使用一级缓存都是存在的，不使用的话可以通过配置在每次查询之前清空缓存，或者将一级缓存配置为SATEMENT,查询完就会清空一级缓存。

5.1 实现要点

  • 缓存模块的实现比较简单，主要在PerpetualCache中，内部封装一个HashMap来保存每一个缓存的k-v对，缓存的存取方法实际上都是对map的操作

5.2 缓存Key

  • 一级缓存是基于sqlSession的，因此如果有2个映射文件里面有2个完全一模一样的sql语句，查询2次，第二次也会走数据库，因为是2个不同的sqlSession。
  • 一级缓存的key值的设计比较复杂，判断两个key一样需要满足的条件比较多，如下所示：
    /**
     * CacheKey#equals
     *  缓存key的设计包含命名空间，分页信息，sql语句 ，参数值的信息，在BaseExecutor#createCacheKey这里是创建cacheKey的方法，包含了上面的四个要素。
     * 判断2个key相等的逻辑
     * 1.是一个对象，那么返回true
     * 2.被比较对象类型不是CacheKey，直接返回false
     * 3.hashcode不一样，返回false
     * 4.checksum不一样，返回false
     * 5.count不一样，返回false
     * 6.updateList列表不一样，返回false
     * 7.满足上面的条件，返回true，认为两个缓存key是一样的
     */
    @Override
    public boolean equals(Object object) {
        if (this == object) {
            return true;
        }
        if (!(object instanceof CacheKey)) {
            return false;
        }

        final CacheKey cacheKey = (CacheKey) object;

        if (hashcode != cacheKey.hashcode) {
            return false;
        }
        if (checksum != cacheKey.checksum) {
            return false;
        }
        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 (thisObject == null) {
                if (thatObject != null) {
                    return false;
                }
            } else {
                if (!thisObject.equals(thatObject)) {
                    return false;
                }
            }
        }
        return true;
    }
  • 具体涉及到缓存在整个Mybatis查询生命周期中的功能，后面分析Mybatis的核心流程的时候再分析，本文主要是引入缓存模块在设计上使用装饰器模式来实现，值得学习和研究。
惑边
关注
专栏目录
MyBatis二级缓存巧妙使用装饰器模式与builder模式
InterfaceJ的博客
01-06 810
MyBatis二级缓存巧妙使用装饰器模式与builder模式 mybatis在查询数据时使用一级缓存和二级缓存来提交查询效率，并减少数据库压力。 一级缓存也称为本地缓存，是默认开启的，它的生效范围为sqlSession，在实际的生产项目中，由于数据库连接是从连接池中获取，几乎每次使用的session都不同，因此很少能使用到一级缓存。 二级缓存也称为全书缓存，它的生效范围在一个namespace中...
mybatis-3-mybatis-3.4.5 源码
02-23
通过对MyBatis源码的学习，我们可以了解到MyBatis如何解析配置，如何构建SQL，如何处理参数和结果，以及如何利用缓存提高性能。这对于理解和优化MyBatis的应用，甚至开发自己的持久层框架都有极大的帮助。在阅读源码...
mybatis缓存的装饰器模式
weixin_33923148的博客
03-20 277
2019独角兽企业重金招聘Python工程师标准>>> ...
装饰器模式
xmh_sxh_1314的博客
08-27 604
 装饰器模式（Decorator Pattern）允许向一个现有的对象添加新的功能，同时又不改变其结构。这种类型的设计模式属于结构型模式，它是作为现有的类的一个包装。 这种模式创建了一个装饰类，用来包装原有的类，并在保持类方法签名完整性的前提下，提供了额外的功能。 意图：动态地给一个对象添加一些额外的职责。就增加功能来说，装饰器模式相比生成子类更为灵活。 主要解决：一般的，我们为了扩展一个类经常使用继承方式实现，由于继承为类引入静态特征，并且随着扩展功能的增多，子类会很膨胀。 何时使用：在不想增加很多.
【十三】图解mybatis缓存模块之装饰器模式
最新发布
作者：大头兵（kit）
06-22 1087
起初学习设计模式总觉得无用武之地，平常在业务系统开发工作中的确使用场景不多，这样以来久而久之就感觉设计模式离我们很远，后来在工作中也偶尔能够使用到了，另外在阅读优秀的开源项目中发现设计模式应用的很多，这样逐步加深了对设计模式的理解，所以我们平常使用不多的情况下可以找开源项目中的应用示例来加深对设计模式的理解。
Mybatis缓存模块-装饰器模式
Abracadabra__的博客
01-18 497
背景：在实践生产中，新需求在软件的整个生命过程中总是不断出现的。当有新需求出现时，就需要为某些组件添加新的功能来满足这些需求。 添加需求的方式 1、直接修改已有代码并添加新的功能。——破坏原有系统的稳定性，违反“开放-封闭”原则。 2、使用继承，创建子类并在子类中添加新功能实现扩展。——已有组件被final修饰不可行，待添加的新功能存在多种组合，使用继承方式可能会导致大量子类的出现。 3、装饰器模式——基于组合的方式实现该功能。 装饰器包含的角色： Component(组件)：组件接口定义了全部组件实现类以
mybatis-3.5.9 源码（mybatis-3-mybatis-3.5.9.tar.gz）
02-07
MyBatis 是一款著名的持久层框架，它支持定制化 SQL、存储过程以及高级映射。...这份源码不仅包含了 MyBatis 的核心功能，还反映了设计模式和最佳实践，对于提升个人的 Java 和数据库编程技能大有裨益。
mybatis-3-mybatis-3.5.8.zip源码
04-27
在mybatis-3-mybatis-3.5.8.zip源码中，我们可以深入理解MyBatis的工作原理和设计模式。这个版本的MyBatis包含以下几个主要模块： 1. **SqlSessionFactoryBuilder**: 用于构建SqlSessionFactory，它是MyBatis的核心...
mybatis-3-mybatis-3.5.7.zip源码
04-27
MyBatis是一个流行的Java...通过对MyBatis 3.5.7源码的深入学习，我们可以了解到其实现细节，包括反射、AOP、设计模式等多方面的知识，这对于提升Java开发能力、优化数据库操作和设计高效的数据访问层有着极大的帮助。
Mybatis-ehcache 1.2.1源码（ehcache-cache-mybatis-ehcache-1.2.1.zip）
07-05
Mybatis-ehcache 1.2.1 是一个集成Mybatis和Ehcache的缓存模块，用于提高Mybatis框架的查询效率。Ehcache是一个广泛使用的Java缓存解决方案，它能够有效地存储和检索数据，减少数据库的负载，提高应用程序性能。在...
Mybatis 缓存与装饰模式
CoderLi
05-12 197
装饰模式是一种结构型设计模式、允许你通过将对象放入包含行为的特殊封装对象中来为原来帝乡绑定新的行为。俗称套娃。 装饰模式中、封装器实现了与其封装对象相同的接口、封装器的成员变量可以是该接口的任意实现。 Mybatis 中的装饰模式 Cache 接口是 Mybatis 缓存中顶层的抽象接口、定义了 Mybatis 缓存最核心最基础的行为 public interface Cache { String getId(); void putObject(Object key, Object va.
mybatis--装饰模式
weixin_34366546的博客
10-23 97
装饰模式的具体分析可以参考之前的文章，装饰模式. 在学习mybat...
Mybatis缓存-装饰模式
万物皆字节
11-24 398
向已有的类添加新功能，通过类的关联关系而不是通过继承，更加灵活。 装饰器模式经典实现： java.io.InputStream mybatis中使用了装饰器模式的模块：二级缓存 接口：org.apache.ibatis.cache.Cache org.apache.ibatis.cache.decorators.BlockingCache等其他实现 BlockingCache实现了C...
装饰者模式与MyBatis二级缓存中装饰者模式的使用
LeeConnor的博客
01-10 1046
一、什么是装饰者模式        装饰者模式的定义是 动态地将责任附加到对象上。若要扩展功能，装饰者提供了比继承更加有弹性的替代方案。         在设计的时候，往往要给一个对象的功能进行一些修饰，对功能进行拓展和增强，以满足我们的需求。 二、装饰者模式的作用         比如我们现在有一个歌手大赛，所有的歌手都需要去唱歌。但是每一个歌手需要不一样的舞台特效，我们可提供的舞台特效
装饰器模式 —— mybatis
Xi__Yuan的专栏
09-12 313
mybatis 中 装饰器模式使用案例
mybatis之装饰者设计模式
Kirito_j的博客
04-25 547
前言 mybatis是一款优秀的持久层框架，支持sql，存储过程以及高级映射，也是一款开源框架，源码中使用了多种的设计模式，今天就来讲一个装饰者设计模式 mybatis-装饰者设计模式 在源码的cache中，应用了装饰者设计模式，通过装饰者模式，可以增强cache的功能，比如原来是LruCache，通过FifoCache装饰后，变成拥有Lru和Fifo的功能的cache Cache接口 所有装饰者...
第06篇:Mybatis缓存设计
西魏陶渊明的博客
07-12 467
官方文档 MyBatis 内置了一个强大的事务性查询缓存机制，它可以非常方便地配置和定制。本篇文章，小编将会在最短的时间呢，通过观察源码来深刻了解Mybatis的 一级二级缓存;然后在说如何定制。 一、Mybatis Cache设计 在Mybatis中所有的缓存,都是实现自Cache接口。无论是一级缓存还是二级缓存都是实现这个接口。其中一级缓存是本地缓存，二级缓存是一个允许开发者扩展的 缓存(eg: ehcache/或者内置的很多缓存)。 public interface Cache
框架源码常客JDK动态代理模式
qq_57756904的博客
06-03 299
实验不会说谎，多动动手去做做实验，加深印象。改变一些数据，你可能获得意外的惊喜噢！本篇文章是本人在研究MyBatis源码时总结出的一些结论，含金量饱满，分享给大家，可谓用心良苦。
mybatis缓存机制与装饰者模式
weixin_30454481的博客
06-23 108
mybatis 缓存 MyBatis的二级缓存的设计原理 装饰者模式 转载于:https://www.cnblogs.com/bbeb/p/11074764.html
深入剖析Mybatis源码：运行原理、缓存与设计模式
Mybatis源码分析是一门深入理解数据库持久化框架的重要课程，由Monkey老师主讲，主要针对Mybatis的工作原理、缓存机制以及设计模式进行剖析。Mybatis是一种高级的持久层框架，它简化了与关系数据库的交互，减少了...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值