1. Semaphore（信号量）
   有n个非线程安全的资源（资源池），这些资源使用一个Semaphore（计数信号量）保护，每个线程在使用这些资源时需要首先获得一个信号量（acquire）表示当前资源池还有可用资源，然后线程从该资源池中获取并移除一个资源，在使用完后，将该资源交回给资源池，并释放已经获得信号量（release）（这里的“移除”、“交回”并不一定需要显示操作，只是一种形象的描述，之所以这么描述是应为这里的各个资源是一样的，因而对一个线程它每次拿到的资源不一定是同一个资源，用于区分Stripe的使用场景），其中Pool是一种典型的应用。
2. CountDownLatch（闭锁）
   有n个Task，它们执行完成后需要执行另外一个收尾的Task（Aggregated Task），比如在做Report计算中，有n个Report要计算，而在所有Report计算完成后需要生成一个基于所有Report结果的一个总的Report，而这个总的Report需要等到所有Report计算出结果后才能开始，此时就可以定义一个CountDownLatch，其初始值是n，在总的Report计算前调用CountDownLatch的await方法等待其他Report执行完成，而其他Report在完成后都会调用CountDownLatch中的countDown方法。
3. CyclicBarrier（关卡）
   每个线程执行完成后需要等待，直到n个线程都执行完成后，才能继续执行，在n个线程执行完成之后，而下一次执行开始之前可以添加自定义逻辑（通过构建CyclicBarrier实例时传入一个Runnable实例自定义逻辑），即在每个线程执行完成后调用CyclicBarrier的await方法并等待（即所谓的关卡），当n个线程都完成后，自定义的Runnable实例会自动被执行（如果存在这样的Runnable实例的话），然后所有线程继续下一次执行。这个现实中的例子没有想到比较合适的。。。。
4. Exchanger（交换者）
   Exchanger是一种特殊的CyclicBarrier，它只有两个线程参与，一个生产者，一个消费者，有两个队列共同参与，生产者和消费者各自有一个队列，其中生产者向它的队列添加数据，而消费者从它包含的队列中拿数据，当生产者中的队列满时调用exchange方法，传入自己原有的队列，期待交换得到消费者中空的队列；而当消费者中的队列满时同样调用exchange方法，传入自己的原有队列，期待获取到生产者中已经填满的队列。这样，生产者和消费者可以和谐的生产消费，并且它们的步骤是一致的（不管哪一方比另一方快都会等待另一方）。

Stripe的应用场景

Stripe的简单实现

Stripe在Guava中的实现

public abstract class Striped<L> {
  /**
   * Returns the stripe that corresponds to the passed key. It is always guaranteed that if
   * {@code key1.equals(key2)}, then {@code get(key1) == get(key2)}.
   *
   * @param key an arbitrary, non-null key
   * @return the stripe that the passed key corresponds to
   */
  public abstract L get(Object key);

  /**
   * Returns the stripe at the specified index. Valid indexes are 0, inclusively, to
   * {@code size()}, exclusively.
   *
   * @param index the index of the stripe to return; must be in {@code [0size())}
   * @return the stripe at the specified index
   */
  public abstract L getAt(int index);

  /**
   * Returns the index to which the given key is mapped, so that getAt(indexFor(key)) == get(key).
   */
  abstract int indexFor(Object key);

  /**
   * Returns the total number of stripes in this instance.
   */
  public abstract int size();

  /**
   * Returns the stripes that correspond to the passed objects, in ascending (as per
   * {@link #getAt(int)}) order. Thus, threads that use the stripes in the order returned
   * by this method are guaranteed to not deadlock each other.
   *
   * <p>It should be noted that using a {@code Striped<L>} with relatively few stripes, and
   * {@code bulkGet(keys)} with a relative large number of keys can cause an excessive number
   * of shared stripes (much like the birthday paradox, where much fewer than anticipated birthdays
   * are needed for a pair of them to match). Please consider carefully the implications of the
   * number of stripes, the intended concurrency level, and the typical number of keys used in a
   * {@code bulkGet(keys)} operation. See <a href="http://www.mathpages.com/home/kmath199.htm">Balls
   * in Bins model</a> for mathematical formulas that can be used to estimate the probability of
   * collisions.
   *
   * @param keys arbitrary non-null keys
   * @return the stripes corresponding to the objects (one per each object, derived by delegating
   *         to {@link #get(Object)}; may contain duplicates), in an increasing index order.
   */
  public Iterable<L> bulkGet(Iterable<?> keys);
}

1. automatic loading of entries into the cache
2. least-recently-used eviction when a maximum size is exceeded
3. time-based expiration of entries, measured since last access or last write
4. keys automatically wrapped in WeakReference
5. values automatically wrapped in WeakReference or SoftReference soft
6. notification of evicted (or otherwise removed) entries
7. accumulation of cache access statistics

1. 定义一个CacheConfig类用于纪录所有的配置，如CacheLoader，maximum size、expire time、key reference level、value reference level、eviction listener等。
2. 定义一个Cache接口，该接口类似Map（或ConcurrentMap），但是为了和Map区别开来，因而重新定义一个Cache接口。
3. 定义一个实现Cache接口的类CacheImpl，它接收CacheConfig作为参数的构造函数，并将CacheConfig实例保存在字段中。
4. 在实现上模仿ConcurrentHashMap的实现方式，有一个Segment数组，其长度由配置的concurrencyLevel值决定。为了实现最近最少使用算法（LRU），添加AccessQueue和WriteQueue字段，这两个Queue内部采用双链表，每次新创建一个Entry，就将这个Entry加入到这两个Queue的末尾，而每读取一个Entry就将其添加到AccessQueue的末尾，没更新一个Entry将该Entry添加到WriteQueue末尾。为了实现key和value上的WeakReference、SoftReference，添加ReferenceQueue<K>类型的keyReferenceQueue和valueReferenceQueue字段。
5. 在每次调用方法之前都遍历AccessQueue和WriteQueue，如果发现有Entry已经expire，就将该Entry从这两个Queue上和Cache中移除。然后遍历keyReferenceQueue和valueReference，如果发现有项存在，同样将它们移除。在移除时如果有EvictionListener注册着，则调用该listener。
6. 对Segment实现，它时一个CacheEntry数组，CacheEntry是一个链节点，它包含hash、key、vlaue、next。CacheEntry根据是否需要包装在WeakReference中创建WeakEntry或StrongEntry，而对value根据是否需要包装在WeakReference、SoftReference中创建WeakValueReference、SoftValueReference、StrongValueReference。在get操作中对于需要使用CacheLoader加载的值先添加一个具有LoadingValueReference值的Entry，这样可以保证同一个Key只加载依次。在加载成功后将LoadingValueReference根据配置替换成其他Weak、Soft、Strong ValueReference。
   
7. 对于cache access statistics，只需要有一个类在需要的地方做一些统计计数即可。
8. 最后我必须得承认以上的设计有很多是对Guava Cache的参考，我有点后悔没有在看源码之前考虑这个问题，等看过以后思路就被它的实现给羁绊了。。。。

public final class CacheStats {
  private final long hitCount;
  private final long missCount;
  private final long loadSuccessCount;
  private final long loadExceptionCount;
  private final long totalLoadTime;
  private final long evictionCount;

}