I know that a retain cycle (at least in Objective-C and Swift) is when two objects claim ownership of one another (they have references to each other). And in Objective-C we can solve the issue by declaring one of them weak.
From what I have read and understood, the Java GC is not affected by retain cycles, and we do not have to worry about weak references. How does it solve it?
The Java (JVM) garbage collector works by looking for "reachable" objects - from the root(s) of the object tree. If they can't be reached (if they have no outside object references) then entire object graphs can be discarded.
Essentially it just just traverses the tree from root(s) to leaf nodes and marks all objects it encounters. Any memory not taken up by marked objects in the heap is swept (marked as free). This is called mark and sweep. img src
This can't be done easily in objective-c because it uses reference counting, not mark and sweep which has it's flaws
The reason there can be no retain cycles is because if they aren't linked to the "tree" anywhere, they aren't marked and can be discarded.
The garbage collector looks for reachable objects, starting from the roots (typically: variables on the call stack or global variables). So if two objects reference each other but are not otherwise reachable they won't be flagged as "live" and will be collected.
As the name suggests, Garbage Collection refers to removing of objects which are no longer in use. It is a well known fact that irrespective of their scope objects, Java stores objects in heap. Thus, if we keep on creating objects without clearing the heap, our computers might run out of heap space and we get ‘Out of Memory’ error. Garbage Collection in Java is a mechanism which is controlled and executed by the Java Virtual Machine (JVM) to release the heap space occupied by the objects which are no more in use. In contrast to C++, garbage collection in java relives the developer from the Memory Management related activities. The JVM executes this process with the help of a demon thread called the ‘Garbage Collector’. The garbage collector thread first invokes the finalize method of the object. This performs the cleanup activity on the said object. As a developer we cannot force the JVM to run the garbage collector thread. Though there are methods e.g Runtime.gc () or System.gc(), but none of these assures the execution of garbage collector thread. These methods are used to send garbage collection requests to the JVM. It is up to the Java Virtual machine when it will initiate the garbage collection process.
Take a look at this stuff
In basic terms, Garbage Collection works by walking the object graphs from a number of predefined roots. Anything not accessible from those roots is garbage, therefore one object referencing another is irrelevant unless either can be accessed from one or more roots.
It's all explained in more detail in How Garbage Collection Really Works.
The behavior of a tracing garbage collector may be viewed as analogous to that of a bowling alley pinsetter, which automatically sweeps up all pins that have been knocked over without disrupting pins that are still standing. Rather than trying to identify knocked-over pins, the pinsetter grabs all of the pins that are still standing, lifts them off the alley, and then runs a sweeper bar over the alley surface, removing wholesale any pins that might happen to be there without knowing or caring where they are.
A tracing GC works by visiting a certain set of "rooted" object references (which are regarded as always "reachable") and objects that are reachable via references held in reachable objects. The GC will mark such objects and protect their contents somehow. Once all such objects have been visited, the system will then visit some "special" objects (e.g. lists of weak or phantom references, or references to objects with finalizers) and others which are reachable from them but weren't reachable from ordinary rooted references, and then regard any storage which hasn't been guarded as eligible for reuse.
The system will need to specially treat objects that were reachable from special objects but weren't reachable from ordinary ones, but otherwise won't need to care about "ordinary" objects that become eligible for collection. If an object doesn't have a finalizer and isn't targeted by a weak or phantom reference, the GC may reuse its associated storage without ever bothering to look at any of it. There's no need for the GC to worry about the possibility that a group of objects that aren't reachable via any rooted references might hold references to each other because the GC wouldn't bother examining of those references even if they existed.
