相互依赖的缓存失效和内存管理

Question

Closed. This question is opinion-based. It is not currently accepting answers.

---

想要改进这个问题？更新问题，以便可以通过编辑这篇文章用事实和引文来回答它。

去年已关闭。

Answer 1

如果有人感兴趣（无论如何可能没有人感兴趣），我不得不放弃全局缓存的想法，并通过使我的Expression自缓存来解决问题。

我在名为 ExpressionBase 的基类中实现了所有逻辑。

该解决方案包括以下内容：

• 表达式包含对其依赖项的弱引用列表，并在发生更改时通知它们。这样就不会出现内存泄漏，也无需取消订阅。
• 在表达式求值期间，它会以类似于我之前的答案中描述的方式自动检测依赖项并订阅它们。
• 保留依赖项列表是为了防止过早对中间表达式进行垃圾收集（我之前的答案中的 SumProxyExpression 情况）。这样，每个弱引用都有其反向的强引用，这样弱引用链就不会被 GC 破坏，除非这些链无处可去。

Answer 2

好的，在这里我将尝试使用 Java 语言来解释我的解决问题的方法。

所有内容都将通过 SumExpression 示例进行解释 - 该表达式用于将其他两个表达式的结果相加。

用户代码

我从最直接的方法开始——观察者模式。每个表达式都会监听其依赖项以判断缓存失效。以下是以此方式实现的 SumExpression 版本：

public class SumExpression implements Expression<Integer> {
    private final Expression<Integer> a;
    private final Expression<Integer> b;

    Integer value;
    private Listener invalidator = new Listener() {
        @Override
        public void changed() {
            invalidate();
        }
    };
    
    public SumExpression(SimpleVariable<Integer> a, SimpleVariable<Integer> b) {
        this.a = a;
        this.b = b;
        a.listeners().addListener(invalidator);// don't forget to call it!
        b.listeners().addListener(invalidator);
    }
    
    public Integer getValue()
    {
        validate();
        return value;
    }
    
    private void validate() {
        if(value == null)
            value = evaluate;
    }

    private void evaluate() {
        value = null;
    }
    
    public void dispose() { // USER, DON'T FORGET TO CALL IT!!!
        a.removeListener(invalidator);
        b.removeListener(invalidator);
    }

    ListenerCollection listeners = new ListenerCollection();
    
    @Override
    public void addListener(Listener l) {
        listeners.addListener(l);
    }

    @Override
    public void removeListener(Listener l) {
        listeners.removeListener(l);
    }
}

但是，有很多地方可能会出错，而像将两个数字相加这样简单的事情应该要简单得多。因此，我通过以下方式将逻辑与缓存分离：

public class SumExpression implements Expression<Integer> {
    private final Expression<Integer> a;
    private final Expression<Integer> b;

    public SumExpression(Expression<Integer> a, Expression<Integer> b)
    {
        this.a = a;
        this.b = b;
    }
    
    public Integer evaluate(EvaluationContext context)
    {
        return context.getValue(a)+context.getValue(b);
    }
}

简单得多，是吗？请注意，这里 EvaluationContext 的职责是双重的：它从缓存中检索值并收集 SumExpression 和表达式 a 之间的依赖关系列表b。

核心代码

接下来，我通过全局缓存类提供了EvaluationContext，该类将缓存的数据存储在类似于WeakHashMap的结构中，并将依赖图数据存储在一个DAG 的节点类型为 WeakReference。

这是我的eval和update实现：

public <T1> T1 eval(final Expression<T1> expression)
{
    Weak weak = weaken(expression);
    T1 result = (T1) cache.get(weak);
    if(result == null) {
        result = expression.evaluate(new EvaluationContext()
        {
            @Override
            public <T2> T2 getValue(Expression<T2> dependency) {
                registerDependency(expression, dependency);
                return eval(dependency);
            }
        });
        cache.put(weak, result);
    }
    return result;
}

public void update(Expression<?> ex) {
    changed(weaken(ex));
}

public void changed(Weak weak) {
    cache.remove(weak);
    
    dependencies.removeOutgoingArcs(weak);
    for(Weak dependant : new ArrayList<Weak>(dependencies.getIncoming(weak))) {
        changed(dependant);
    }
}

当我的缓存管理器被要求提供一个对象时，它首先检查缓存。如果缓存中没有值，它会要求表达式进行计算。然后，表达式通过调用 getValue() 方法要求缓存管理器解决其依赖关系。这会在依赖图中创建一条弧。该图稍后用于缓存失效。

当表达式失效时，将探索依赖图并且所有依赖缓存都失效。

一旦垃圾收集器通知我们（通过 ReferenceQueue）某些表达式对象的死亡，就会立即执行缓存和依赖图清理。

一切基本上都按其应有的方式进行。然而，也有一些棘手的情况。

棘手的情况

第一种情况是悬挂的中间依赖项。假设我们有以下类：

class SumProxyExpression implements Expression<Integer> {
    private final Expression<Integer> a;
    private final Expression<Integer> b;

    public SumProxyExpression(Expression<Integer> a, Expression<Integer> b) {
        this.a = a;
        this.b = b;
    }

    @Override
    public Integer evaluate(EvaluationContext context) {
        Expression<Integer> s = new SumExpression(a, b);
        return context.getValue(s);
    }
}

如果我们创建 c=SumProxyExpression(a,b) 的实例并稍后更改 a 的值，我们将需要 c 也可以更改其值。但是，如果中间 SumExpression 已被垃圾回收，则可能不会发生这种情况。为了解决这个问题，我不会从依赖图中删除节点，除非它们是叶节点（仅具有传入或仅传出弧）。

我不知道如何解决的另一种情况如下：

class SelfReferencingExpression implements Expression<List<?>> {
    class Result extends ArrayList<Integer> {
    }

    @Override
    public List<?> evaluate(EvaluationContext resolver) {
        return new Result();
    }
}

如果我缓存此类表达式的结果，它永远不会被垃圾收集，因为我保留对缓存值的硬引用（Result)，并且它具有对包含类（表达式）的引用，因此表达式始终可达，但永远无法使用。

这是内存泄漏，我不知道如何消除它。告诉用户永远不要有这样的参考是可能的，但非常危险，所以我想找到更好的解决方案。

替代解决方案

我还考虑过通过从通用自缓存表达式类继承来实现它，而不是将所有内容都保存在全局缓存中。此解决方案将解决最后一个测试用例 (SelfReferencingExpression)，但会因第一个测试用例 (SumProxyExpression) 而失败。