Suppose you have a Collection<B>
, and you're about to remove an item. Instance of B
is referenced from an instance of A
, and references an instance of C
, as shown in the first picture:
Now, since there was a reference pointing to B, there's no question about the object being "deleted", or garbage collected. It simply gets removed from the collection, like this, right?
Now, let's have a Collection<A>
with the same referencing hierarchy as before, and let's remove an instance of A.
If there's no other reference to A
, not only it gets removed from the collection, it is marked as garbage. Am I right? And what about B
and C
? Do they become garbage too, provided there's no other references except B
referencing an instance of C
?
This is a simplification of what I'm facing. I want to remove an A
instance from a collection and I want to make sure B
and C
go with it. At the point where A
is no longer in my collection, all the "children" that are still alive are a memory leak for me.
When I look at these pictures I made, it seems too stupid of a question. But my situation is a little less trivial. It looks something like this:
A Model
A Model
has a collection of B Model
instances (B
is kind of the child of A
, both in Model and ViewModel layers)B Model
"knows its parent' - references its parent 'A Model' instanceI have a Collection of those A ViewModel
instances. When I delete one, I need everything other to go with it. Provided there's no other "outside reference" to any of the instances involved (basically, no other arrow pointing coming in from outside of the picture), will the removed 'A ViewModel' instance take all the children with it? If so, are there any "gotchas" that could make this simplification misleading? And if I'm completely wrong, why? :)
Thanks for reading this far!
An increased allocation rate of objects on the managed heap causes garbage collection to occur more frequently.
The garbage collector serves as an automatic memory manager. You do not need to know how to allocate and release memory or manage the lifetime of the objects that use that memory. An allocation is made any time you declare an object with a “new” keyword or a value type is boxed.
NET's garbage collector manages the allocation and release of memory for your application. Each time you create a new object, the common language runtime allocates memory for the object from the managed heap.
When the garbage collector performs a collection, it releases the memory for objects that are no longer being used by the application. It determines which objects are no longer being used by examining the application's roots.
Provided there's no other "outside reference" to any of the instances involved (basically, no other arrow pointing coming in from outside of the picture), will the removed 'A ViewModel' instance take all the children with it?
Yes, provided there are no references from your code to the child, it will be eligible for garbage collection, and should eventually be collected.
If there's no other reference to A, not only it gets removed from the collection, it is marked as garbage. Am I right?
That is not actually how this works. The GC doesn't "track garbage" - instead, it checks all of the object references from currently executing code, and walks out to find references that are currently "alive". Anything left over at that point is not alive, and then becomes eligible for collection. If the only way to reach "B" or "C", in your graph, is through that instance of "A", and you remove "A" from the collection, all of those will become eligible for GC and be found in the next appropriate GC collection.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With