what the fuck，有 GC 也内存泄露你的应用逻辑是多复杂

你只管往舒服的写
不要给自己找麻烦
提高抽象层次对进一步优化有好处

🤔你的意思是 one-shot Listener
你的意思是设置 onChange 不能拿到一个“配置”对象，太死板？

是不是你多想了😳
看起来这是框架的事情

正在用 TornadoFX 他的 onChange 就有这个问题

🤔 被 onChange 的对象…… 就是 Listener 闭包呗。

我是指 A.onChange() 的 A

是啊，onChange 的 listener 嘛
不就是和 Listener 模式的 this 不一样而已

我没有任何办法拿到 Listener 或 能取消掉监听器的句柄，除非我退化成最原始的写法

这是框架该做的事情吧……🤔

你这个内存泄露连带资源泄露不？
e.g. 无效的 android Context 通过闭包泄露

比如呢？
e.g. 一个 File 应该在一个 basic block 里就 close，而不是随函数作用域 close

你的 Listener 引用是放哪里的
你 override 的 onChange 是哪里创建的

🤔之前见过一个 Android 的例子，要求应用全局持有一个 class instance
最后是并行 service 解决了

其实有一个缓解的接口是使用弱引用的，但是emmm Tornado FX没弄对应的 Kotlin 版

🤔🤔🤔
常见 JVM 是不需要弱引用去解决循环引用问题的

弱引用往往就是 缓存

是解决生命周期不一致的问题

所以你倒是说说 target 和 listener 都是啥生命周期啊？

不是框架 finialize 解决了么
内存管理问题不是 你业务逻辑的资源回收问题
那是相当基础的对象引用图
怎么可能总出问题

他可能是为了 流 式的调用， onChange 返回的是 this；如果用 addListener() SAM 因为kotlin的 lambda SAM 不能拿到自己的 this ，也就没法 removeListener(Listener)

是啊，为了链式调用你就不能用本该返回的配置对象了

所以说是框架的问题，或者是你对框架理解的问题，不是自动内存管理的问题啊