javascript - kinetic.js 中的删除和销毁有什么区别

Question

我阅读了 KineticJS Docs 上的文档，它说:

destroy() - 删除并销毁自身

remove() - 从父级中删除自身，但不销毁

如果我的理解是正确的，remove() 函数会从父节点中删除该节点，但仍分配在内存中。而 destroy() 完全释放内存，这是正确的吗？有人可以用外行的话解释一下如果我使用销毁而不是删除会出现哪些并发症吗？

提前谢谢您。

最诚挚的问候， 凌丹迪

Answer 1

我相信你是对的，但只是为了补充你所说的内容，我认为你会使用:

remove() - 删除节点并可能稍后使用该节点

destroy() - 如果您知道不再需要该节点，则完全销毁该节点

此外，以下是直接取自 wiki 的垃圾收集的一些优点和缺点:http://en.wikipedia.org/wiki/Garbage_collection_%28computer_science%29

Benefits

Garbage collection frees the programmer from manually dealing with memory deallocation. As a result, certain categories of bugs are eliminated or substantially reduced:

• Dangling pointer bugs, which occur when a piece of memory is freed while there are still pointers to it, and one of those pointers is dereferenced. By then the memory may have been re-assigned to another use, with unpredictable results.
• Double free bugs, which occur when the program tries to free a region of memory that has already been freed, and perhaps already been allocated again.
• Certain kinds of memory leaks, in which a program fails to free memory occupied by objects that have become unreachable, which can lead to memory exhaustion. (Garbage collection typically does not deal with the unbounded accumulation of data that is reachable, but that will actually not be used by the program.)
• Efficient implementations of persistent data structures Some of the bugs addressed by garbage collection can have security implications.

Disadvantages

Typically, garbage collection has certain disadvantages:

• Garbage collection consumes computing resources in deciding which memory to free, even though the programmer may have already known this information. The penalty for the convenience of not annotating object lifetime manually in the source code is overhead, which can lead to decreased or uneven performance. Interaction with memory hierarchy effects can make this overhead intolerable in circumstances that are hard to predict or to detect in routine testing.
• The moment when the garbage is actually collected can be unpredictable, resulting in stalls scattered throughout a session. Unpredictable stalls can be unacceptable in real-time environments, in transaction processing, or in interactive programs. Incremental, concurrent, and real-time garbage collectors address these problems, with varying trade-offs.
• Non-deterministic GC is incompatible with RAII based management of non GCed resources. As a result, the need for explicit manual resource management (release/close) for non-GCed resources becomes transitive to composition. That is: in a non-deterministic GC system, if a resource or a resource like object requires manual resource management (release/close), and this object is used as 'part of' another object, then the composed object will also become a resource like object that itself requires manual resource management (release/close).

这是来自 SO 的另一个引用:How does the Garbage Collection mechanism work?