使用 deferreds 时是否存在潜在的内存泄漏？
Are there any potential memory leaks when using deferreds?
我在我的代码中的某个地方得到了一个 jQuery.Deferred，我向它添加了几个回调，它们是短期对象的成员方法。我想知道在这种情况下是否存在任何类型的内存泄漏可能性，类似于 .NET 事件处理程序。
我正在检查 jQuery 的代码，但没有看到任何清除回调的部分。我什至没有找到延迟对象的生命周期应该在哪里结束。
谁能解释一下这个话题？
编辑
随着我的思考，它缩小到这个问题。在 JavaScript 中，持有对对象（非原型）成员函数的引用是否会拒绝对象被 GC-d？因为 jQuery 似乎在延迟对象的回调中持有这些函数引用。
据我所见（以及一些简单的阅读：Do never resolved promises cause memory leak?），未解决的 Promises 或 Deferrereds -- 除非你是：
- 创建大量：任何对象的数百个实例都是拖累，需要特殊处理和设计
- 维护对阻止 GC 运行 清理任何范围外项目的实例的引用
我会回答我的问题，因为经过一番思考，这似乎是一个简单的问题。实际上 JavaScript 函数不属于 "tightly" 定义它们的 objects，除非它们被手动绑定到 Function.prototype.bind，但这是另一种情况。
因此，如果函数有自己的生命，持有对它们的引用不应拒绝收集最初定义的 object。
此外，我还必须注意，如果我不持有对延迟 object 本身的直接或封闭引用，这一切都没有关系，因为无论何时它都完成了工作 (resolved/rejected) 它将成为收藏品。
如果这里的假设有误，请更有经验的人指正。
I haven't seen any part where callbacks are cleared.
承诺结算（履行或拒绝）后回调将被清除。
I didn't even find where the lifecycle of a deferred object should end.
当没有任何东西再引用它时，promise 的生命周期就结束了。
通常有两件事持有对它的引用：最终将解决承诺的解析器（例如超时、ajax 请求等），以及存储承诺的实体，因为他们想使用它（即它的结果）稍后。 Promise 对象依次持有对所有回调（直到结算）和结果值（自结算）的引用。
如果 promise 从未被解决，有回调附加到它，并且被某些引用阻止被垃圾收集，那么泄漏 可能 发生。不过这种情况非常罕见。
In JavaScript, will holding a reference to a member function of an object (not prototype) deny the object from being GC-d?
没有，一般不会。 javascript 中没有 "members"，只有普通的独立函数。
当然，当函数作为闭包时，它可以保存对对象的引用，并且会阻止它被收集。
我在我的代码中的某个地方得到了一个 jQuery.Deferred，我向它添加了几个回调，它们是短期对象的成员方法。我想知道在这种情况下是否存在任何类型的内存泄漏可能性，类似于 .NET 事件处理程序。
我正在检查 jQuery 的代码，但没有看到任何清除回调的部分。我什至没有找到延迟对象的生命周期应该在哪里结束。
谁能解释一下这个话题？
编辑
随着我的思考，它缩小到这个问题。在 JavaScript 中，持有对对象（非原型）成员函数的引用是否会拒绝对象被 GC-d？因为 jQuery 似乎在延迟对象的回调中持有这些函数引用。
据我所见（以及一些简单的阅读：Do never resolved promises cause memory leak?），未解决的 Promises 或 Deferrereds -- 除非你是：
- 创建大量：任何对象的数百个实例都是拖累，需要特殊处理和设计
- 维护对阻止 GC 运行 清理任何范围外项目的实例的引用
我会回答我的问题，因为经过一番思考，这似乎是一个简单的问题。实际上 JavaScript 函数不属于 "tightly" 定义它们的 objects，除非它们被手动绑定到 Function.prototype.bind，但这是另一种情况。
因此，如果函数有自己的生命，持有对它们的引用不应拒绝收集最初定义的 object。
此外，我还必须注意，如果我不持有对延迟 object 本身的直接或封闭引用，这一切都没有关系，因为无论何时它都完成了工作 (resolved/rejected) 它将成为收藏品。
如果这里的假设有误，请更有经验的人指正。
I haven't seen any part where callbacks are cleared.
承诺结算（履行或拒绝）后回调将被清除。
I didn't even find where the lifecycle of a deferred object should end.
当没有任何东西再引用它时，promise 的生命周期就结束了。
通常有两件事持有对它的引用：最终将解决承诺的解析器（例如超时、ajax 请求等），以及存储承诺的实体，因为他们想使用它（即它的结果）稍后。 Promise 对象依次持有对所有回调（直到结算）和结果值（自结算）的引用。
如果 promise 从未被解决，有回调附加到它，并且被某些引用阻止被垃圾收集，那么泄漏 可能 发生。不过这种情况非常罕见。
In JavaScript, will holding a reference to a member function of an object (not prototype) deny the object from being GC-d?
没有，一般不会。 javascript 中没有 "members"，只有普通的独立函数。
当然，当函数作为闭包时，它可以保存对对象的引用，并且会阻止它被收集。