We Keep Coding

Role of the garbage collector

While reading a course on the garbage collector I understood that it removes unreferenced objects from memory, I tried to answer some questions in a quiz related to the subject and I found this question:
The role of the garbage collector is to ensure that there is enough memory to run a Java program?
Is it true or false? I know it manages memory, but does it guarantee that there is enough memory to run a program?

It does, what it sounds exactly:
"Garbage collection"
Garbage collector has not a responsibility of memory allocation or ensuring there is enough memory to run program.
So take a look at wikipedia about garbage collector : https://en.wikipedia.org/wiki/Garbage_collection_(computer_science)
Also according to oracle :
What is Automatic Garbage Collection? Automatic garbage collection is
the process of looking at heap memory, identifying which objects are
in use and which are not, and deleting the unused objects. An in use
object, or a referenced object, means that some part of your program
still maintains a pointer to that object. An unused object, or
unreferenced object, is no longer referenced by any part of your
program. So the memory used by an unreferenced object can be
reclaimed.
https://www.oracle.com/webfolder/technetwork/tutorials/obe/java/gc01/index.html
And check that stacoverflow questiont also : What's the difference between memory allocation and garbage collection, please?

Garbage collection of List items

I have a Java ArrayList with references to other objects stored within the List.
If I mark the List as null then when it is garbage collected, will all the stored items in it also get claimed by GC (assuming there are no other references to them)?
thanks,
Jakao

If you know it (can access it from code / have a reference to it anywhere) it´s there (and won´t ever be collected), if you don´t it might be gone. When is it gone? None of your concern, that´s the point of having a garbage collector.

Assuming there are no other references to them, they will be GC.
In java object reference is an abstract concept, you should not worry about how the JVM manages object storage, but if you interested in memory managment in java, I suggest you deepen the arguments of the weak and soft reference and memory pools.

How to avoid object collection by garbage collector

I have some objects in my code which are not invoked in everyloop,But they are useful in future when some forced termination from loop,unpredictable error etc happens, So how to make sure that this objects are not ever collected by garbage collector.
For example : I have one class so I dont want GC to perform any Garbage collection on this class

If the objects are valuable and expensive to create, you should hang on to them in a field in your class. You could create a Map that would act sort of like a cache and grab them out of the Map when you're ready to use them again.

If they are useful in the future you have a reference to these objects somewhere. This is enough to ensure that they will never be garbage collected.

Keep a strong reference to the object, Doing this will always ensure that your object will not be GCed. I would also leave such things to the Garbage collector which I think is smarter than us(with all due respect) when it comes to memory management

You should have a look at the scope of your variables. as long as they are in scope they should not be garbage collected.

Garbage Collector Simply Avoids The Object Which Have Any Reference In The Code Further. So If You Want Any Object To Never Get Collected By G.C. Until The Execution Of Your Code. Just Have A Global Reference To That Object.

ways of making an object to explicitly garbage collected

I have read about making an object explicitly garbage collected, that in many ways. So i wanted to know some of the methods of making it explicitly garbage collected

There is no way for explicit garbage collection.
You can "politely ask" the virtual machine to do garbage collection by calling:
System.gc();
but it is not guaranteed it will.
Calling the gc method suggests that the Java Virtual Machine expend effort toward recycling unused objects in order to make the memory they currently occupy available for quick reuse. When control returns from the method call, the Java Virtual Machine has made a best effort to reclaim space from all discarded objects.
and "best effort" might be to postpone the garbage collection.
For how to make objects elligible for garbage collection read Effective Java, Chapter 2

You can explicitly make an object eligible for garbage collection by setting all references to it to null.
This won't call the garbage collector itself, but when the collection does start, it will collect this object.
You're best off letting the Java garbage collector doing it all automatically by itself. It has been optimized to the point where it'll be better and more efficient than anything you'd ever want to probably do.

System.gc is to tell the JVM to execute the garbage collector explicitly.
But as for as some methods which i know to make an object explicitly garbage collected are:
Assigning its reference to point to null
EX: Animal a = new Animal();
a = null
Assigning its reference to point to another object.
EX: Animal a1 = new Animal();
a1 = new Animal();

You shouldn't worry about forcing a GC unless you're writing, say, a tool like VisualVM yourself.
NetBeans, IntelliJ, VisualVM, and a great many others can all force a GC, not hint, but really force. Using JVMTI you can force a GC.
BUT once again you probably do NOT want to do that.
You force a GC (not hint) using JVMTI's ForceGarbageCollection.
That said, you probably really DO NOT want to do that (it really bares repeating).
Authoritative info on the subject if you really want to know (but you probably don't) how to force, for a fact, a GC:
http://java.sun.com/javase/6/docs/platform/jvmti/jvmti.html#ForceGarbageCollection

How does Java Garbage collector handle self-reference?

Hopefully a simple question. Take for instance a Circularly-linked list:
class ListContainer
{
private listContainer next;
<..>
public void setNext(listContainer next)
{
this.next = next;
}
}
class List
{
private listContainer entry;
<..>
}
Now since it's a circularly-linked list, when a single elemnt is added, it has a reference to itself in it's next variable. When deleting the only element in the list, entry is set to null. Is there a need to set ListContainer.next to null as well for Garbage Collector to free it's memory or does it handle such self-references automagically?

Garbage collectors which rely solely on reference counting are generally vulnerable to failing to collection self-referential structures such as this. These GCs rely on a count of the number of references to the object in order to calculate whether a given object is reachable.
Non-reference counting approaches apply a more comprehensive reachability test to determine whether an object is eligible to be collected. These systems define an object (or set of objects) which are always assumed to be reachable. Any object for which references are available from this object graph is considered ineligible for collection. Any object not directly accessible from this object is not. Thus, cycles do not end up affecting reachability, and can be collected.
See also, the Wikipedia page on tracing garbage collectors.

Circular references is a (solvable) problem if you rely on counting the references in order to decide whether an object is dead. No java implementation uses reference counting, AFAIK. Newer Sun JREs uses a mix of several types of GC, all mark-and-sweep or copying I think.
You can read more about garbage collection in general at Wikipedia, and some articles about java GC here and here, for example.

The actual answer to this is implementation dependent. The Sun JVM keeps track of some set of root objects (threads and the like), and when it needs to do a garbage collection, traces out which objects are reachable from those and saves them, discarding the rest. It's actually more complicated than that to allow for some optimizations, but that is the basic principle. This version does not care about circular references: as long as no live object holds a reference to a dead one, it can be GCed.
Other JVMs can use a method known as reference counting. When a reference is created to the object, some counter is incremented, and when the reference goes out of scope, the counter is decremented. If the counter reaches zero, the object is finalized and garbage collected. This version, however, does allow for the possibility of circular references that would never be garbage collected. As a safeguard, many such JVMs include a backup method to determine which objects actually are dead which it runs periodically to resolve self-references and defrag the heap.

As a non-answer aside (the existing answers more than suffice), you might want to check out a whitepaper on the JVM garbage collection system if you are at all interested in GC. (Any, just google JVM Garbage Collection)
I was amazed at some of the techniques used, and when reading through some of the concepts like "Eden" I really realized for the first time that Java and the JVM actually could beat C/C++ in speed. (Whenever C/C++ frees an object/block of memory, code is involved... When Java frees an object, it actually doesn't do anything at all; since in good OO code, most objects are created and freed almost immediately, this is amazingly efficient.)
Modern GC's tend to be very efficient, managing older objects much differently than new objects, being able to control GCs to be short and half-assed or long and thorough, and a lot of GC options can be managed by command line switches so it's actually useful to know what all the terms actually refer to.
Note: I just realized this was misleading. C++'s STACK allocation is very fast--my point was about allocating objects that are able to exist after the current routine has finished (which I believe SHOULD be all objects--it's something you shouldn't have to think about if you are going to think in OO, but in C++ speed may make this impractical).
If you are only allocating C++ classes on the stack, it's allocation will be at least as fast as Java's.

Java collects any objects that are not reachable. If nothing else has a reference to the entry, then it will be collected, even though it has a reference to itself.

yes Java Garbage collector handle self-reference!
How?
There are special objects called called garbage-collection roots (GC roots). These are always reachable and so is any object that has them at its own root.
A simple Java application has the following GC roots:
Local variables in the main method
The main thread
Static variables of the main class
To determine which objects are no longer in use, the JVM intermittently runs what is very aptly called a mark-and-sweep algorithm. It works as follows
The algorithm traverses all object references, starting with the GC
roots, and marks every object found as alive.
All of the heap memory that is not occupied by marked objects is
reclaimed. It is simply marked as free, essentially swept free of
unused objects.
So if any object is not reachable from the GC roots(even if it is self-referenced or cyclic-referenced) it will be subjected to garbage collection.

Simply, Yes. :)
Check out http://www.ibm.com/developerworks/java/library/j-jtp10283/
All JDKs (from Sun) have a concept of "reach-ability". If the GC cannot "reach" an object, it goes away.
This isn't any "new" info (your first to respondents are great) but the link is useful, and brevity is something sweet. :)