Does the Garbage Collector remove all or only those that have no reference?

The situation is a bit more complicated than this. Of course, what has reference is never "removed".

First, let's understand that the Java GC uses a copying mechanism, so "never" objects (in the last implementation I know, ie detail) are removed, they are dropped. The GC copies those who survive and throw away those who no longer need to remain active.

GC works by reading "whole" memory looking for reference to objects in heap . Of course there is optimization not to read all of it, it depends on the generation that needs to be cleaned.

Now Java can have reference to objects outside the heap , these objects are not free of the GC, it can be read to see if it has any reference to another object inside it, but references to it matter.

Just have a reference to an object and it is already considered as alive. And it is possible to have false positives. There are heuristics to avoid having to analyze the entire graph of references. You can not have a false negative, you would risk killing something that has yet to continue. It happens that some objects survive even without having a reference. It's not usually very hard and hard, it usually happens more in Gen0 than it needs to be very fast.

In the analysis the GC looks at everything in the so-called roots, for example the ones registered and the stack . From there he goes to look at all the objects that he knows are alive, or that already have references to him in the roots. He sets up a graph, walks through all living things. Objects that have no references to it are never parsed to see if they have references to other objects. In general the analysis ends in Gen0. Unless you fire a cleaning process on Gen1, it's up to him. And the same goes for Gen2.

I had seen that Java was going to do as .NET which would have a heap of large objects that works slightly differently, but the basis is this. I do not know how it was, if implemented.

There is special treatment when an object is above Gen0. Any attempt to write references contained in these objects has a writing barrier and analyzes if you need to take any extra action. If you do not need it fast, if you need it, you have extra control to do. Enter the slow path if the new reference points to an object in the previous generation. These cases need to create a list of extra references for the previous generation to look at when they will do their cleaning. This is necessary for GC not to have to scan the entire memory and at least the lower generations that are cleaned more frequently.

Looking at all this, roughly speaking, if an object does not have a reference to it, it is not analyzed whether it has references to other objects, and if the only reference to another object was the one that is no longer parsed, or all the references are in objects that will no longer be active, then that object pointed out no longer has references that require you to stay alive, so it will probably be abandoned and your memory will no longer be occupied. If on a single reference to an object, even unintentionally, it will still be kept and copied to a new memory arena, probably in a generation above what it is, up to Gen2 which is currently the last.

If there is a reference to it then being used, even if it is not being accessed at that time.