Garbage collection can be tuned on the JVM - see
this article[
^] - rather then in code. You can call collection from code but it is not the best approach as the JVM is, at the end of everything, the final arbiter of what is garbage.
To answer the individual points:
arsenk02 wrote:
Java’s garbage-collection mechanism may recover only memory that is definitely unused.
When an object can no longer be accessed it becomes 'collectable'. In this it means accessible from a live thread. This is important as it allows for cyclicle objects to be collected, see the following:
Foo a = new Foo();
Foo b = new Foo();
a.setBar(b);
b.setBar(a);
a = null;
b = null;
arsenk02 wrote:
It is not possible to force garbage collection reliably.
Collection is specific to the JVM. There are some rules about
what can be collected, but not
how.
arsenk02 wrote:
It is not possible to predict when a piece of unused memory will be collected, only to say when it becomes eligible for collection.
Again, the programmer does not know which JVM will be running and so you cannot say precisely how or when collection will take place. In most JVM's the collection is done on a separate GC thread that tries to reduce the impact on the runtime making a compromise between the frequency of collection and the amount of available memory. If you allocate a lot of memory to your JVM, it won't bother collecting too often as it won't need to.
arsenk02 wrote:
Garbage collection does not prevent memory leaks; they can still occur if unused references are not cleared to null or destroyed.
If you have a reference to an object that is still accessible it will not be collected, it can't be. Soo if youare in the habit of creating lots functional objects that get held until they finish, but never actually complete, you'll run into memory leak.
My advice is to read the articles you've been pointed to and if you are still concerned, put a monitor on your app, such as
jconsole[
^] and watch where the memory is going to.