背景
在“普通老式”JavaFX 桌面应用程序中，我有一个实体，它公开了一个不可修改的 ObservableSet View 。像这样:
public ObservableSet<AbstractMessage> getMessagesUnmodifiable() {
return FXCollections.unmodifiableObservableSet(messages);
}
在其他地方，客户端代码像这样使用这个 API:
model.getMessagesUnmodifiable()
.addListener((SetChangeListener<AbstractMessage>) change -> {
if (change.wasAdded())
// ... do some work
});
从我编写客户端代码的第一天(实际上是今天)开始，我立即感到有点担心。是否可以将监听器添加到不可修改 Set？如果我添加一个监听器，那么我是否修改了 Set？
理论
我没有找到关于这个主题的文档。 FXCollections.unmodifiableObservableSet() 的 JavaDoc有一句话说与这个问题无关:
Creates and returns unmodifiable wrapper on top of provided observable set.
表弟FXCollections.unmodifiableObservableMap()还有话要说:
Only mutation operations made to the underlying ObservableMap will be reported to observers that have registered on the unmodifiable instance. This allows clients to track changes in a Map but disallows the ability to modify it.
我在引用中用粗体标记的正是我想要实现的，但使用的是 Set 而不是 Map。由于不可修改和可观察的映射是可能的，我认为它也必须对集契约(Contract)样起作用。
练习
我的客户端代码没有抛出异常。就是这样。但它不起作用。我的听众永远不会被召唤。它确实有效如果我只是为了测试重写实体的 getter 方法，以便他返回可修改的 ObservableSet 引用，上面没有糖。因此，对 FXCollections.unmodifiableObservableSet() 的调用显然以某种方式破坏了集合的行为。
我在一个单独的测试应用程序中快速编写了几行代码。然而，在我的测试应用程序(一个简单的 public static void main)中，它就像一个魅力。我重写了我的测试应用程序和我的真实桌面应用程序，以便两者之间的代码绝对相同，结果如下:向不可修改的 View 添加监听器在我的桌面应用程序中不起作用，但是它在我的测试应用程序中没有缺陷。我无法解释这个发现。
最佳答案
从 FXCollections.unmodifiableObservableSet() 返回的集合以神秘的方式工作。您可能认为您向支持集添加了一个监听器，但实际上，您添加的监听器直接进入包装器，包装器已将自己注册为支持集的弱监听器(WeakSetChangeListener) .
只要包装器还活着，他的个人监听器就会从支持集中获取事件，并将这些事件分发给我在包装器中注册的监听器。但是由于我从未存储对包装器的强引用，所以包装器被垃圾收集器拾取并处理掉只是时间问题。我所有喜欢触发的听众都加入了旅程。
这也是我的小型测试应用程序和桌面应用程序之间的全部区别，尽管代码相同，但结果却完全不同。我的测试应用程序立即从头到尾执行完毕。尽管我的桌面应用程序从注册监听器到实际事件需要时间。就在那段时间里，GC 介入并把我搞砸了。
在只花时间阅读源代码之后，从理论上讲，我必须得出结论，不可修改但可观察的 Map 的工作方式相同。所以吸取教训:保存对不可修改的包装器的引用或修改客户端的 API，以便客户端可以将监听器直接传递给支持 Set(这是我选择的解决方案)。
有关弱监听器如何在 JavaFX 中工作的更多信息，请参阅我发布的另一个答案 here .
关于java - 是否可以在不可修改的 ObservableSet 上注册 SetChangeListener？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/25224170/