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