2

我正在查看这个类java.lang.ref.Reference（以及它的子类），我想知道为什么它没有实现 Java 8 的Supplier<T>接口。

看来这应该是不费吹灰之力。供应商的get()方法满足Reference。我犹豫要实现SoftReference<T>自己的扩展的唯一原因Supplier<T>是因为我知道References垃圾收集器是特殊情况。

制作这样的课程有什么问题可以预见吗

public class SoftReferenceSupplier<T> extends SoftReference<T> implements Supplier<T>
{
    public SoftReferenceSupplier(T referent)
    {
        super(referent);
    }

    public SoftReferenceSupplier<T referent, ReferenceQueue<? super T> queue)
    {
        super(referent,queue);
    }
}

我不想以某种方式破坏 SoftReferences 的目的，因为一些垃圾收集警告会干扰供应商的处理方式。

顺便说一句，我知道SoftReferences将null在完整的垃圾收集后返回。我的程序有需求SoftReferences，我想让它实现这个功能接口以增加灵活性。

4

2 回答 2

1

Reference比. 大很多Supplier。据我所知，更改Reference<T>为实现Supplier<T>不会破坏任何现有代码，但在我看来，这没有多大意义。当所有新的功能接口都被引入到语言中时，本来可以遍历每个现有的类，让每个类都实现每个碰巧有匹配方法的新功能接口，但我看不到这个。

在很多情况下，一个类实际上实现了一个函数式接口是没有意义的，因为如果你需要将一个对象看作是一个函数式接口的实例，你可以只使用方法引用。

Reference<Object> reference = new WeakReference<>(someObject);
Supplier<Object> supplier = reference::get;

这个解决方案不依赖于两个方法碰巧都被调用的事实get，所以在我看来，最好是Reference实现Supplier。

于 2015-11-09T14:15:17.477 回答
0

我做了一些谷歌搜索，但没有找到任何与为什么 Java 的Reference 类没有实现Supplier interface相关的东西。但是 JavadocSupplier留下了一些线索。我认为答案在于它是如何Supplier被引入 Java 的——即作为用于 Lambda 表达式的函数式编程接口。这两种get()方法的含义只是逻辑上不同的东西。get()Reference类实例的方法返回所指对象；instance的get()方法Supplier返回 lambda 表达式的结果。很难想象两者之间的语义重叠，除非我正在创建一个涉及 JVM 软引用、弱引用和/或幻像引用的 lambda 表达式。

于 2015-10-30T06:14:45.670 回答