在Java中使用弱引用的代价

weakreference对CMS垃圾收集器有负面影响。据我所知,从我们的服务器的行为来看,它影响并行评论阶段的时间。在这个阶段,所有的应用程序线程都会停止,所以这是非常不受欢迎的事情。所以你需要小心处理我们的关系。

在我的实现中,当垃圾收集期间访问每个弱引用时,每个弱引用都会有少量的额外开销。

所以结果是:我不担心它,除非你使用了大量的弱引用,否则这不是一个大问题。

最重要的是,成本与存在的弱引用的数量成正比,而不是整个堆的大小。

然而,这并不是说支持弱引用的垃圾回收器会和不支持弱引用的垃圾回收器一样快。这里假定的问题是,既然Java支持弱引用,那么使用它们的增量成本是多少?

LIVE

要处理弱引用,只需添加以下内容:

• 设置时忽略弱引用 现场 位在要设置的被引用对象上)。
• 现场 ,它是一个 WeakReference ,然后检查它弱引用的对象,如果该对象不是 ,清除引用。

这种逻辑的小变化适用于软引用和虚引用。

here 如果你真的很好奇。

public Object getSomethingExpensiveToFind() {
    if(cache.contains(EXPENSIVE_OBJ_KEY)) {
        return cache.get(EXPENSIVE_OBJ_KEY);
    }

    Object sth = obtainSomethingExpensiveToFind(); // computationally expensive
    cache.put(EXPENSIVE_OBJ_KEY, sth);
    return sth;
} 

想象一下这个场景:

1) 应用程序内存不足

2) GC会清除弱引用,因此缓存也会被清除

3) app继续,很多方法,比如getSomeThingExpensiveTofId()都会被调用并重建缓存

5) GC清除磨损引用,清除缓存

7) 等等。。。

我遇到了这样一个问题——应用程序经常被GC中断,它完全击败了整个缓存点。