我阅读了 KineticJS Docs 上的文档，它说：
destroy() - 移除并销毁自身
remove() - 从父级中删除自身，但不要销毁
如果我的理解是正确的，remove() 函数会从父节点中删除节点，但仍分配在内存中。而 destroy() 完全释放内存，对吗？有人可以用外行的方式解释如果我使用破坏而不是删除会有什么并发症吗？
提前谢谢你。
最诚挚的问候， 丹迪凌
【问题讨论】：
标签： javascript garbage-collection html5-canvas kineticjs
我相信你是对的，但只是为了补充你所说的，我认为你会使用：
remove() - 删除一个节点并可能在以后使用该节点
destroy() - 如果您知道不再需要该节点，则完全销毁该节点
此外，以下是垃圾收集的一些优点和缺点，这些优点和缺点直接来自 wiki：http://en.wikipedia.org/wiki/Garbage_collection_%28computer_science%29
好处
垃圾收集使程序员免于手动处理内存释放。因此，某些类别的错误被消除或大大减少：
- 悬空指针错误，当一块内存被释放但仍有指向它的指针时发生，其中一个指针被取消引用。到那时，内存可能已被重新分配给其他用途，结果无法预料。
- 双重释放错误，当程序尝试释放已释放的内存区域时发生，可能已经再次分配。
- 某些类型的内存泄漏，其中程序无法释放已变得无法访问的对象占用的内存，这可能导致内存耗尽。 （垃圾收集通常不处理可到达但实际上不会被程序使用的数据的无限积累。）
- 持久数据结构的高效实现 垃圾收集解决的一些错误可能会产生安全隐患。
缺点
通常，垃圾回收有一些缺点：
- 垃圾收集在决定释放哪些内存时会消耗计算资源，即使程序员可能已经知道此信息。在源代码中不手动注释对象生命周期的便利性的代价是开销，这可能导致性能下降或不均匀。在难以预测或在常规测试中检测到的情况下，与内存层次效应的交互会使这种开销变得无法忍受。
- 实际收集垃圾的时间可能无法预测，从而导致在整个会话中分散停顿。在实时环境、事务处理或交互式程序中，不可预测的停顿可能是不可接受的。增量、并发和实时垃圾收集器可以解决这些问题，但需要权衡取舍。
- 非确定性 GC 与基于 RAII 的非 GC 资源管理不兼容。因此，对非 GC 资源的显式手动资源管理（释放/关闭）的需求变得可传递到组合。即：在非确定性 GC 系统中，如果一个资源或类似资源的对象需要手动资源管理（释放/关闭），而该对象被用作另一个对象的“一部分”，那么组合对象也将成为资源之类的对象本身需要手动资源管理（释放/关闭）。
还有来自 SO 的另一个参考：How does the Garbage Collection mechanism work?
【讨论】：