ThreadLocal HashMap vs ConcurrentHashMap用于线程安全的未绑定缓存 [英] ThreadLocal HashMap vs ConcurrentHashMap for thread-safe unbound caches

问题描述

我正在创建一个具有以下特征的memoization缓存：

I'm creating a memoization cache with the following characteristics:

• 缓存未命中将导致计算和存储条目
  
  
  
  • 这个计算非常昂贵
  
  
  • 这个计算是幂等的
  
  
  
  
  • 输入最多会产生500个条目
  
  
  • 每个存储的条目非常小
  
  
  • 缓存相对短缺（通常不到一小时）
  
  
  • 总体而言，内存使用率不是问题
  
  
  • the inputs would result in at most 500 entries
  • each stored entry is very small
  • cache is relatively shorted-lived (typically less than an hour)
  • overall, memory usage isn't an issue

  什么会有优越的性能，或者在什么条件下会有一个解决方案受到青睐另一个？

  What would have superior performance, or under what conditions would one solution be favored over the other?

  ThreadLocal HashMap：

  ThreadLocal HashMap:

  class MyCache {
      private static class LocalMyCache {
          final Map<K,V> map = new HashMap<K,V>();
  
          V get(K key) {
              V val = map.get(key);
              if (val == null) {
                  val = computeVal(key);
                  map.put(key, val);
              }
              return val;
          }
      }
  
      private final ThreadLocal<LocalMyCache> localCaches = new ThreadLocal<LocalMyCache>() {
          protected LocalMyCache initialValue() {
              return new LocalMyCache();
          }
      };
  
      public V get(K key) {
          return localCaches.get().get(key);
      }
  }
  

  ConcurrentHashMap：

  ConcurrentHashMap:

  class MyCache {
      private final ConcurrentHashMap<K,V> map = new ConcurrentHashMap<K,V>();
  
      public V get(K key) {
          V val = map.get(key);
          if (val == null) {
              val = computeVal(key);
              map.put(key, val);
          }
          return val;
      }
  }
  

  我认为ThreadLocal解决方案最初会慢一些很多线程因为每个线程的所有缓存未命中，但是超过数千次读取，摊销成本将低于ConcurrentHashMap解决方案。我的直觉是否正确？

  I figure the ThreadLocal solution would initially be slower if there a lot of threads because of all the cache misses per thread, but over thousands of reads, the amortized cost would be lower than the ConcurrentHashMap solution. Is my intuition correct?

  或者是否有更好的解决方案？

  Or is there an even better solution?

  推荐答案

  使用ThreadLocal作为缓存是一种不好的做法

  use ThreadLocal as cache is a not good practice

  在大多数容器中，线程通过线程池重用，因此永远不会是gc。这会带来一些有线的东西

  In most containers, threads are reused via thread pools and thus are never gc. this would lead something wired

  使用ConcurrentHashMap你必须管理它以防止内存泄漏

  use ConcurrentHashMap you have to manage it in order to prevent mem leak

  如果你坚持，我建议使用周或软参考并在富有maxsize后逐出

  if you insist, i suggest using week or soft ref and evict after rich maxsize

  如果你找到一个内存缓存解决方案（不要重新发明轮子）
  试试番石榴缓存
  http：/ /docs.guava-libraries.googlecode.com/git/javadoc/com/google/common/cache/CacheBuilder.html

  if you are finding a in mem cache solution ( do not reinventing the wheel ) try guava cache http://docs.guava-libraries.googlecode.com/git/javadoc/com/google/common/cache/CacheBuilder.html

  这篇关于ThreadLocal HashMap vs ConcurrentHashMap用于线程安全的未绑定缓存的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！