Mybatis系列5：装饰器模式在缓存中的应用

MyBatis 作为一个强大的持久层框架，缓存是其必不可少的功能之一。 MyBatis 中的缓存是两层结构的，分为一级缓存、二级缓存，但在本质上是相同的，它们使用的都是 Cache 接口的实现。本节主要对 Cache 接口及其实现类进行介绍，然后再看一级缓存和二级缓存如何使用。

1. 什么是装饰器模式

1.1功能

装饰器坚持is-a 原则，但代理未必遵循is-a
装饰器是在原有基础上增加新功能，而代理并没有改原有类，而是另外一个对象.
动态地为一个对象增加新地功能 装饰模式是一种御用代替继承的技术，无需通过继承增加子类就能扩展对象的新功能。使用对象的关联关系代替继承关系，更加灵活，同时避免类型体系的快速膨胀。
有四个角色：

• componet抽象构件角色：真实对象和装饰对象有相同的接口或者抽象类。这样客户端对象就能够以与真实对象相同的方式同装饰对象交互。
• ConcreteComponent：具体构件角色（真实对象）： io流中的FileInputStream，FileOutputStream
• Decorator装饰角色： 持有抽象构件的引用。装饰对象接受所有客户端的请求，并把这些请求转发给正式的对象，这样就能在真实对象调用前后增加新的功能。
• ConcreteDecorator具体装饰角色：负责给构件对象增加新的责任。

1.2 例子

装饰器实现了一个接口，同时这个类中还声明了接口 实现思路：一个接口，定义基本的功能；一个抽象类，构建装饰角色。之后可以创建多个抽象类的子类，分别实现不同的功能。其特点是装饰角色抽象类和相关子类的构造函数都是接口。 创建接口和其实现类：

public interface ICar {
    void move();
}

//ConcreteComponent 具体构件角色(真实对象)

class Car implements ICar {
    @Override
    public void move() {
        System.out.println("陆地上跑！");
    }
}

装饰器抽象类
//Decorator装饰角色

class SuperCar implements ICar {
    protected ICar car;
    public SuperCar(ICar car) {
        super();
        this.car = car;
    }

    @Override
    public void move() {
        car.move();
    }
}

抽象类的不同子类：
//ConcreteDecorator具体装饰角色

class FlyCar extends SuperCar {

    public FlyCar(ICar car) {
        super(car);
    }

    public void fly(){
        System.out.println("天上飞！");
    }

    @Override
    public void move() {
        super.move();
        fly();
    }

}

//ConcreteDecorator具体装饰角色

class WaterCar extends SuperCar {

    public WaterCar(ICar car) {
        super(car);
    }

    public void swim(){
        System.out.println("水上游！");
    }

    @Override
    public void move() {
        super.move();
        swim();
    }

}

//ConcreteDecorator具体装饰角色

class AICar extends SuperCar {

    public AICar(ICar car) {
        super(car);
    }

    public void autoMove(){
        System.out.println("自动跑！");
    }

    @Override
    public void move() {
        super.move();
        autoMove();
    }
}

调用：

 public static void main(String[] args) {
        Car car=new Car();
        car.move();
        FlyCar flyCar=new FlyCar(car);
        flyCar.move();
        System.out.println("------------");

        WaterCar waterCar=new WaterCar(car);
        waterCar.move();

        System.out.println("-------");

        AICar aiCar=new AICar(new FlyCar(new WaterCar(new FlyCar(car))));
        aiCar.move();
    }

在上面的类中flyCar等又采用继承的方式来扩展，其实在SuperCar里的car就是原始类，SUperCar可以在此的基础上直接扩展新内容，例如：
//Decorator装饰角色

class SuperCar implements ICar {
    protected ICar car;
    public SuperCar(ICar car) {
        super();
        this.car = car;
    }

    @Override
    public void move() {
        car.move();//原始内容
        fly();//添加的装饰内容

    }
    public void fly(){
        System.out.println("天上飞！");
    }

}

1.3 总结

装饰器模式也叫包装器模式（Wrapper）
装饰模式降低系统的耦合度，可以动态地增加或删除对象的职责，并使得需要装饰的具体构建类和具体装饰器可以独立变化，以便增加新的具体构建类和具体装饰类。
优点：扩展方便，比继承灵活，可以对一个对象多次装饰，创造出不同行为的组合，得到功能更强大的对象。具体构建类和具体装饰器类可以独立变化，用户可以根据需要自己增加新的具体构建子类和具体装饰子类。
缺点：产生很多小对象，一定程度上影响了性能。装饰器模式易出错，调试排查比较麻烦。
装饰模式和桥接模式的区别：
两个模式都是为了解决过多子类对象问题，但诱因不一样。桥接模式是对象自身现有机制沿着多个维度变化，是既有部分不稳定，装饰模式是为了增加新的功能。

2. 装饰器模式在缓存中的应用

2.1 cache的实现框架

在 MyBatis 的缓存模块中，使用了装饰器模式的变体，其中将 Decorator 接口和 Component接口合并为一个 Component 接口

Cache 接口及其实现

public interface Cache {

  String getId();
  void putObject(Object key, Object value);
  Object getObject(Object key);
  Object removeObject(Object key);
  void clear();
  int getSize();

  default ReadWriteLock getReadWriteLock() {
    return null;
  }
}

Cache 接口的实现类有多个，大部分都是装饰器，只有 PerpetualCache提供了 Cache 接口的基本实现。

比如看一个先进先出的：

public class FifoCache implements Cache {

  private final Cache delegate;
  private final Deque<Object> keyList;
  private int size;

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

Cache实例 delegate即是类内部的一个属性，又是构造方法传进来的参数，这种格式十有八九是装饰器模式。

2.2 几种典型缓存的功能

下面看一下几个典型缓存方式的功能和实现方式。

2.2.1 BlockingCache

BlockingCache 是阻塞版本的缓存装饰器，它会保证只有一个线程到数据库中查找指定 key对应的数据。
该类的实现代码不算多，删除部分不太重要的，核心如下：

public class BlockingCache implements Cache {

  private long timeout;
  private final Cache delegate;
  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);
    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();
  }

  private ReentrantLock getLockForKey(Object key) {
    return locks.computeIfAbsent(key, k -> new ReentrantLock());
  }

  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();
    }
  }

}

假设线程 A 在 BlockingCache 中未查找到 keyA 对应的缓存项时，线程 A 会获取 keyA 对应
的锁，这样后续线程在查找 keyA 时会发生阻塞。
在set之前，acquireLock()方法中会尝试获取指定 key 对应的锁。如果该 key 没有对应的锁对象则为其创
建新的ReentrantLock 对象，再加锁；如果获取锁失败， 则阻塞一段时间。

2.2.2 FifoCache&LruCache

在很多场景中，为了控制缓存的大小，系统需要按照一定的规则清理缓存。 FifoCache 是先入先出版本的装饰器， 当 向缓存添加数据时，如果缓存项的个数已经达到上限， 则会将缓存中最老（ 即最早进入缓存 ） 的缓存项删除。
FifoCache.getObject()和 removeObject()方法的实现都是直接调用底层 Cache 对象的对应方法 ， 在 FifoCache.putObject()方法中会完成缓存项个数的检测 以及缓存的清理操作。
因为特性不同，两者在插入和删除时又有本质的区别，我们分别来看一下如何实现的。
FifoCache 我们只保留增删和定义的核心逻辑：

public class FifoCache implements Cache {

  private final Cache delegate;
  private final Deque<Object> keyList;
  private int size;

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

  public void putObject(Object key, Object value) {
    cycleKeyList(key);
    delegate.putObject(key, value);
  }


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

  private void cycleKeyList(Object key) {
    keyList.addLast(key);
    if (keyList.size() > size) {
      Object oldestKey = keyList.removeFirst();
      delegate.removeObject(oldestKey);
    }
  }
}

我们可以看到使用的是队列 LinkedList,这个队列的两端都提供了get/set方法，所以正常插入用addLast，对满清理时用的是removeFirst，为啥不是头部插入，尾部取，感觉有点奇怪，不过貌似这样外部用起来更好理解。在插入的时候使用cycleKeyList进行了判断，如果插入之后溢出了就执行移除第一个。

LruCache 是按照近期最少使用算法，在需要清理缓存时 ， 它会清除最近最少使用的缓存项，我们看其实现：

public class LruCache implements Cache {

  private final Cache delegate;
  private Map<Object, Object> keyMap;
  private Object eldestKey;

  public LruCache(Cache delegate) {
    this.delegate = delegate;
    setSize(1024);
  }

   
      @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);
    cycleKeyList(key);
  }

  @Override
  public Object getObject(Object key) {
    keyMap.get(key); //touch
    return delegate.getObject(key);
  }
 
  private void cycleKeyList(Object key) {
    keyMap.put(key, key);
    if (eldestKey != null) {
      delegate.removeObject(eldestKey);
      eldestKey = null;
    }
  }

}

可以看到，为了满足LRU的性质，这里使用的是LinkedHashMap，这个是在调用构造方法时在setSize()方法里初始化的。
这里的
put和get方法都比较简单，但是在setSize比较特殊，这里重写了LinkedHashMap的removeEldestEntry()方法来实现对最早数据的移除（原始函数里是空的，只是返回一个false）。
这里的问题是如何判断最老数据是哪个呢？看上面的代码貌似没有这个判断逻辑。
这个是隐藏在LinkedHashMap.get()方法里，这个方法在执行的时候会有一个调整节点位置的操作，也就是每访问一次，会将访问过的节点直接移动到队尾，所以要删的时候，只要删除队首的元素就行了。

除此之外，还有串行等多种方式，机制差不多，我们不再展开，但是有三个看上去挺特殊的缓存方式，弱引用缓存，软引用缓存和虚引用缓存，这个值得好好研究一下，下一篇，我们专门研究。