我理想的缓存使用番石榴
在过去的几周里,我断断续续地尝试使用 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 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
两个映射是否有效完全取决于 getFromDatabase() 的昂贵程度以及您的对象有多大。做这样的事情似乎并没有超出所有合理的界限。
至于实现,看起来您可以以稍微不同的方式对地图进行分层以获得您想要的行为,并且仍然具有良好的并发属性。
通过第二张地图完成所有访问。
换句话说,过期映射的作用是将最近使用的对象子集固定在内存中,而弱引用映射是真正的缓存。
-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.
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
我不明白这里的全貌,但有两件事。
给出这样的声明:“一旦对象的时间到了,即使它们是强可达的,此实现也会逐出对象。这可能会导致具有相同 UID 的多个对象在环境中漂浮,这是我不希望的。” -- 听起来你只需要使用weakKeys(),而不是使用定时或基于大小的驱逐。
或者,如果您确实想将“interner”引入其中,我会使用真正的
Interners.newWeakInterner
。I don't understand the full picture here, but two things.
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.
Or if you do want to bring an "interner" into this, I'd use a real
Interners.newWeakInterner
.