一路跟着三位老师在同时学习相关知识：我想我大致明白了消息队列的特性以及真正适用的场景，周二许老师的课程中刚好提到了相关东西特意为了许老师。
    关系型数据库、非关系型数据库、消息队列其实都属于存储中间件，老师今天的话题如何利用缓存来减少磁盘IO其实就是涉及了三种存储中间件；其实老师今天的三种方法我的理解其实就是对应了三种存储中间件：三种存储中间件都和内存有关，如何合理使用缓存、内存、磁盘去做合适的事情才是关键；
老师课程的算法：几门相关的课程同时在学时间还是偏紧，不过刘老师的操作系统、许老师的架构、以及老师的消息队列同时学习，倒是了解什么场景下用以及用哪种消息队列；至少跟着老师的消息队列我应当知道业务中的什么事情让它去承担并且使用什么策略，先用现成的吧；改进只能等第二遍学习时再去做了。
  一直跟着学习学到现在发现学好消息队列的前提：1)对业务的数据情况清楚2)对于当下使用的存储中间件情况非常清楚3)对于消息队列所在的系统熟悉：其中就涉及需要非常了解操作系统和当前系统的架构最后就是充分利用当下的消息队列追加一些适合自己业务场景的算法：调整优化当下所用的消息队列。

老师，我在github上写了一个lru的实现。https://github.com/fomeiherz/code-snippet/tree/master/lru

使用了HashMap和Queue一起实现的。使用HashMap保存键值对可以实现O(1)复杂查询，使用队列保存key，头部出队，尾部入队。更新比较复杂，需要删除对应的元素后，才可以再入队，这里是O(n) 复杂度。

老师，更新队列顺序时是否会有更快办法？或者有更快的实现办法呢？求指导

public class DefaultLruCache<K, V> extends LruCache<K, V> {

    private LruCacheImpl<K, V> cache;

    public DefaultLruCache(int capacity, Storage<K, V> lowSpeedStorage) {
        super(capacity, lowSpeedStorage);
        cache = new LruCacheImpl<>(capacity, true);
    }

    @Override
    public V get(K key) {
        V value = cache.get(key);
        if (value == null) {
            value = lowSpeedStorage.get(key);
            cache.put(key, value);
        }
        return value;
    }

    class LruCacheImpl<K, V> extends LinkedHashMap<K, V> {

        public LruCacheImpl(int capacity, boolean accessOrder) {
            super(capacity, 0.75F, accessOrder);
        }

        @Override
        protected boolean removeEldestEntry(Map.Entry<K, V> eldest) {
            return size() > capacity;
        }
    }
}

来晚了，根据jms和kafka这两节，我试着猜想一下jms的机制，顺便提个问题：
1. 老师这节提到的jms实现的缓存机制，都是基于direct buffer自己实现的一个内存池，并实现了变种的LRU对么？这个缓存就是前面提到的journal cache，被writeThread/RelicationThread/FlushThread使用？
2. 这个内存池看起来并没有借助于netty的direict buffer pool是吧？
3. 那原谅我对比一下jms和rocket，jms没有基于mmap去做而选择direct buffer，看起来是为了：
a. 减少GC的压力
b. 比mmap更容易控制，就更容增加缓存的命中率
这样？
4. 另外，有个概念我很模糊，有资料说direct buffer在写磁盘/socket时并不能真的节省一次cpu copy？那这样的话jms可以说并没有利用zero copy？

望解惑