我理想的缓存使用番石榴

发布于 2024-11-25 05:51:18 字数 1782 浏览 6 评论 0原文

在过去的几周里,我断断续续地尝试使用 guava 的 MapMaker。请参阅我之前的两个问题此处此处来遵循我的思维过程。

根据我所学到的知识,我的下一次尝试将放弃软值,转而使用 maximumSize 和 expireAfterAccess:

ConcurrentMap<String, MyObject> cache = new MapMaker()
        .maximumSize(MAXIMUM_SIZE)
        .expireAfterAccess(MINUTES_TO_EXPIRY, TimeUnit.MINUTES)
        .makeComputingMap(loadFunction);

where

Function<String, MyObject> loadFunction = new Function<String, MyObject>() {
   @Override
   public MyObject apply(String uidKey) {
      return getFromDataBase(uidKey);
   }
};

然而,我仍在努力解决的一个剩余问题是,此实现将驱逐对象,即使它们是强可达的,一旦他们的时间到了。这可能会导致具有相同 UID 的多个对象在环境中漂浮,这是我不希望的(我相信我想要实现的目标称为规范化)。

因此,据我所知,唯一的答案是有一个额外的映射,它充当内部函数,我可以检查数据对象是否仍在内存中:

ConcurrentMap<String, MyObject> interner = new MapMaker()
        .weakValues()
        .makeMap();

并且加载函数将被修改:

Function<String, MyObject> loadFunction = new Function<String, MyObject>() {
   @Override
   public MyObject apply(String uidKey) {
      MyObject dataObject = interner.get(uidKey);
      if (dataObject == null) {
         dataObject = getFromDataBase(uidKey);
         interner.put(uidKey, dataObject);
      }
      return dataObject;
   }
};

但是,使用两个映射代替一个缓存似乎效率低下。有没有更复杂的方法来解决这个问题?一般来说,我是否以正确的方式处理这个问题,或者我应该重新考虑我的缓存策略?

Off and on for the past few weeks I've been trying to find my ideal cache implementation using guava's MapMaker. See my previous two questions here and here to follow my thought process.

Taking what I've learned, my next attempt is going to ditch soft values in favor of maximumSize and expireAfterAccess:

ConcurrentMap<String, MyObject> cache = new MapMaker()
        .maximumSize(MAXIMUM_SIZE)
        .expireAfterAccess(MINUTES_TO_EXPIRY, TimeUnit.MINUTES)
        .makeComputingMap(loadFunction);

where

Function<String, MyObject> loadFunction = new Function<String, MyObject>() {
   @Override
   public MyObject apply(String uidKey) {
      return getFromDataBase(uidKey);
   }
};

However, the one remaining issue I'm still grappling with is that this implementation will evict objects even if they are strongly reachable, once their time is up. This could result in multiple objects with the same UID floating around in the environment, which I don't want (I believe what I'm trying to achieve is known as canonicalization).

So as far as I can tell the only answer is to have an additional map which functions as an interner that I can check to see if a data object is still in memory:

ConcurrentMap<String, MyObject> interner = new MapMaker()
        .weakValues()
        .makeMap();

and the load function would be revised:

Function<String, MyObject> loadFunction = new Function<String, MyObject>() {
   @Override
   public MyObject apply(String uidKey) {
      MyObject dataObject = interner.get(uidKey);
      if (dataObject == null) {
         dataObject = getFromDataBase(uidKey);
         interner.put(uidKey, dataObject);
      }
      return dataObject;
   }
};

However, using two maps instead of one for the cache seems inefficient. Is there a more sophisticated way to approach this? In general, am I going about this the right way, or should I rethink my caching strategy?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

爱本泡沫多脆弱 2024-12-02 05:51:18

两个映射是否有效完全取决于 getFromDatabase() 的昂贵程度以及您的对象有多大。做这样的事情似乎并没有超出所有合理的界限。

至于实现,看起来您可以以稍微不同的方式对地图进行分层以获得您想要的行为,并且仍然具有良好的并发属性。

  1. 创建第一个具有弱值的映射,并将计算函数 getFromDatabase() 放在该映射上。
  2. 第二张地图是过期的,也在计算,但这个函数只是从第一张地图获取。

通过第二张地图完成所有访问。

换句话说,过期映射的作用是将最近使用的对象子集固定在内存中,而弱引用映射是真正的缓存。

-dg

Whether two maps is efficient depends entirely on how expensive getFromDatabase() is, and how big your objects are. It does not seem out of all reasonable boundaries to do something like this.

As for the implementation, It looks like you can probably layer your maps in a slightly different way to get the behavior you want, and still have good concurrency properties.

  1. Create your first map with weak values, and put the computing function getFromDatabase() on this map.
  2. The second map is the expiring one, also computing, but this function just gets from the first map.

Do all your access through the second map.

In other words, the expiring map acts to pin a most-recently-used subset of your objects in memory, while the weak-reference map is the real cache.

-dg

暖风昔人 2024-12-02 05:51:18

我不明白这里的全貌,但有两件事。

  1. 给出这样的声明:“一旦对象的时间到了,即使它们是强可达的,此实现也会逐出对象。这可能会导致具有相同 UID 的多个对象在环境中漂浮,这是我不希望的。” -- 听起来你只需要使用weakKeys(),而不是使用定时或基于大小的驱逐。

  2. 或者,如果您确实想将“interner”引入其中,我会使用真正的Interners.newWeakInterner

I don't understand the full picture here, but two things.

  1. Given this statement: "this implementation will evict objects even if they are strongly reachable, once their time is up. This could result in multiple objects with the same UID floating around in the environment, which I don't want." -- it sounds like you just need to use weakKeys() and NOT use either timed or size-based eviction.

  2. Or if you do want to bring an "interner" into this, I'd use a real Interners.newWeakInterner.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文