Javascript 的垃圾收集关闭规则
我有一个程序，它使用 Javascript 作为脚本语言绑定到更大的 C++ 应用程序。我交替使用 V8 和 webkit，但底层运行时对于这个问题来说应该不重要。
在此应用程序中，我动态创建的对象将接收回调。我将像这样创建这个回调绑定...
function f() {
var obj = CreateNewCallbackObj();
obj.onCallback = dowork; // dowork is a function
}
显然这会出现 GC 问题，因为 obj 已经超出范围并且最终将被删除。
我想要的是对象能够自我管理其生命周期。该对象最终将收到一个回调，该回调将表明其生命结束，并且当发生这种情况时，它可以删除自身。
一种想法是通过添加 obj.myself=obj 来进行自引用。这似乎是错误的方法，但除非垃圾收集算法很聪明，否则它可能会起作用。
有正确的方法吗？没有构建用于存储对象的底层持久 DOM，所有 JS 对象都是根据需要动态分配的，但需要某种方式保留在 JS 引擎中。
I have a program that uses Javascript as a scripting language binding to a larger C++ application. I use V8 and webkit interchangeably, but the underlying runtime shouldn't matter for this question.
In this application, I have dynamically created objects will receive callbacks. I'll create this callback binding like this...
function f() {
var obj = CreateNewCallbackObj();
obj.onCallback = dowork; // dowork is a function
}
Clearly this will have GC problems because obj has gone out of scope and will be deleted eventually.
What I want is for the object to self manage its lifetime. The object will eventually receive a callback that will signal the end of its life, and when that happens it can delete itself.
One thought is to self-reference by adding an obj.myself=obj. This seems like the wrong way to do it, but it might work unless a garbage collection algorithm is smart.
Is there a right way to do this? There is no underlying persistant DOM that is built to store objects in, all of the JS objects are allocated dynamically as needed but need some way to stick around within the JS engine.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
自引用不能保证任何东西都存活。事实上，（据我所知）GC 语言几乎不存在单独使用引用计数的自尊实现。甚至不要考虑滥用 GC 算法或任何其他实现定义的细节 - 那就是疯狂。
至于替代方案：创建一些始终可访问的（例如全局）对象来保存所有这些对象（从而使它们保持活动状态）并提供删除对象的方法。然后祈祷没有其他人能得到推荐信——或者更好的是，不要担心这个。 GC 的全部意义在于，您不应该（必须）知道/关心内存何时被释放。
您还可以添加一个
alive属性，在所有方法的开头检查该属性，并在!this.alive时调用某个方法，并引发错误 - 这并不能保证，当然可以，但它可能有助于调试。Self-references will not guarantee that anything stays alive. In fact, there's about no self-respecting implementation of a GC'd language (that I'm aware of) that uses refcounting alone. Don't even think of abusing the GC algorithm, or any other implementation-defined detail - that way lies madness.
As for alternatives: Create some always reachable (e.g. global) object which holds all these objects (and thus keeps them alive) and provide a method to remove an object. Then pray nobody else got a reference - or even better, don't worry about this. The whole point of GC is that you shouldn't (have to) know/care when memory is released.
You could also add an
aliveproperty, check that at the start of all methods and raise an error if a method is invoked when!this.alive- that's no guarantee, of course, but it may help debugging.