Re: Life of an instance
Salad wrote:
I might have
Customer cust = new Customer()
Don't forget the semicolon!
So how long does cust live? Is there a way to close or kill off cust?
Or does the instance live for as long as the application runs?
Mark Space <marksp...@sbc.global.net> wrote:
"cust" lives until it is no longer reachable.
void test1 () {
Customer cust = new Customer();
System.out.println( cust );
}
"cust" is no longer reachable at the closed brace "}" and is available
for garbage collection there.
There's no real need to "close" objects premature. The Java language
defines when they go out of scope, it's done (for the most part)
automatically for you.
If you have a specific situation, then please describe it in detail.
There are a few corner cases where the programmer one must assist the
JVM, or one can hold a reference too long and prevent the JVM from
garbage collecting object. But those are more "debugging" scenarios,
not really a general principle.
There is a general principle, not related to debugging, involving such
things as collections classes.
First, to the OP, google on "Java garbage collection" and look around
java.sun.com for white papers on the topic.
"Garbage collection" means the release of memory formerly occupied by
an object. This is different from "collections types", which are the
interfaces and classes that represent lists, maps, queues, stacks and
so on.
As Mark Space said, when an object has no references to it, it can be
collected.
In the given example:
Customer cust = new Customer();
the 'new' operator creates a 'Customer' object in (heap) memory and
returns a reference to that object. The 'cust' variable holds that
reference. In other words, 'cust' is a pointer to the memory space
occupied by the 'Customer' object.
In Mark Space's example, once the pointer 'cust' goes out of scope,
there is no other pointer that points to the area of memory where that
object resides. That means the garbage collector (GC), a Java virtual
machine process, can return that memory to the heap for future
allocation to another object. In that case, as Mark Space said, there
is nothing else for the programmer to do.
If there is a collection, for example a 'Stack', that holds another
pointer to the same object, then that object is still "reachable",
meaning that there is a way for the program to access the object
through that other pointer. As long as the program has some pointer
that can "reach" the object, the GC may not release its memory.
A stack has a concept of a "top" - the highest part of the collection
that has information the program cares about. To pop an item off the
stack, you move the "top" down by one item and return a copy of what
had been the top pointer.
public class SimpleStack <Foo>
{
private final Foo [] stack; // array to hold pointers
private final int capacity; // maximum stack depth
private int top; // number of pointers in stack
public Foo( int cap )
{
this.stack = new Foo [this.capacity = cap];
}
public void push( Foo foo )
{
if ( this.top < this.capacity )
{
this.stack [this.top++] = foo;
}
}
public Foo pop()
{
if ( this.top == 0 )
{
return null;
}
Foo ret = this.stack [--this.top];
this.stack [this.top] = null; // general principle
return ret;
}
}
If the line marked "general principle" were not there, then the
location at 'this.stack [this.top]' would still contain a pointer to
the top object. You wouldn't be able to access it directly, but it
would be there, so the GC could not possibly release that object's
memory.
Giving that location in the stack array a different pointer value, in
this case 'null', causes the structure to "forget" where the old
referenced object is. When the client code (i.e., the code that calls
the 'pop' method) loses all its references to the popped object, the
stack won't have one either, and there will be no more references to
the object, making it collectible.
The general principle is that if you have a hidden reference or
collection of references, like the mess of pointers in the 'stack'
array, and you aren't responsible for those hidden references, you
risk hanging on to a reference for too long.
--
Lew