使用Kotlin函数引用注册与注销监听器是否安全？底层匿名类实现逻辑解析

嘿，最近我在写代码的时候遇到了一个关于Kotlin函数引用的疑惑，折腾了一番后整理出了思路和解决方案，跟大家聊聊：

我的初始代码与发现的问题 #

一开始我写了这样的代码来处理加载状态监听：

fun listener() {
    // 执行一些操作
    adapter.removeLoadStateListener(::listener)
}
adapter.addLoadStateListener(::listener)

结果同事提醒了一个有意思的现象：

val x1 = ::listener
val x2 = ::listener
x1 == x2 // true
x1 === x2 // false

我自己也做了个测试：

var mySet = mutableSetOf<() -> Unit>()
fun a() { }
fun b() { }
mySet.add(::a)
mySet.add(::b)
mySet.remove(::a)
mySet.contains(::a) // false
mySet.contains(::b) // true

这让我意识到自己对::myFun的工作机制其实一知半解，也开始担心最初的代码是不是真的安全。

核心问题：用函数引用做监听器安全吗？ #

我最关心的是：使用::listener这种方式引用方法，作为需要多次调用（添加+移除）的监听器，到底靠不靠谱？它底层的实现逻辑是怎样的？

原理拆解 #

其实Kotlin的函数引用背后是这么工作的：

• 每次你调用::函数名，都会生成一个全新的匿名类实例，这个实例实现了对应的函数式接口（比如这里的(CombinedLoadStates) -> Unit）。这就是为什么x1 === x2会返回false——它们是内存里的两个不同对象。
• 但Kotlin为这些函数引用实例重写了equals方法：只要两个引用指向的是同一个原始函数，equals就会返回true，这也解释了为什么x1 == x2是true，以及测试里mutableSet.remove(::a)能成功（Set的remove是基于equals判断的）。

那回到初始代码的安全性：如果监听框架的内部是用equals来匹配要移除的监听器，那代码是能正常工作的；但如果框架是用身份判断（===）来查找实例，那removeLoadStateListener(::listener)就会找不到之前添加的那个实例，导致移除失败。虽然大多数场景下框架会遵循equals约定，但这种不确定性始终是个隐患。

最终采用的可靠方案 #

考虑到潜在的风险，我们决定改用显式的匿名对象实现，确保添加和移除的是同一个实例：

val listener = object : (CombinedLoadStates) -> Unit {
    override operator fun invoke(loadState: CombinedLoadStates) {
        // 执行一些操作
        adapter.removeLoadStateListener(this)
    }
}
adapter.addLoadStateListener(listener)

这个方案里，this指向的始终是同一个对象，不管框架内部用哪种判断逻辑，都能精准匹配到要移除的监听器，彻底消除了函数引用带来的不确定性。

内容的提问来源于stack exchange，提问作者Felix ZY