Java - Stack and Heap Memory

n this section we will look at how variables are stored in memory in Java. We are examining memory in Java at this point so that you can understand at a lower level what happens when you create and manipulate the objects that make up your programs.

Primitive data types have just one value to store. For instance:

int i = 1;

The appropriate amount of space is allocated given the data type, and the variable is stored in memory just as it is.

Objects must be stored differently because they are more complex. They often hold multiple values, each of which must be stored in memory. The association between each value and the object must be maintained throughout its life. An object reference variable must then hold a reference to those values. This reference represents the location where the object and its metadata are stored.

There are two kinds of memory used in Java. These are called stack memory and heap memory. Stack memory stores primitive types and the addresses of objects. The object values are stored in heap memory. An object reference on the stack is only an address that refers to the place in heap memory where that object is kept.

Say you've got two Test objects, and you assign the first to the second, like this:

Test test1 = new Test();
Test test2 = new Test();

test2 = test1;

What you're actually doing when you write this is assigning the address of the test1 object to thetest2 object. Assume that test1's memory address was 0x33d444 and that test2's address was0x99f775. After performing the above assignment, test2 now holds this address in stack memory:0x99f775, which refers to the same object as test1. The test2 object on the heap still exists, but it cannot be accessed. That's because this reassignment overwrote the old address that test2 was keeping on the stack. This kind of reassignment makes two stack references to the same object on the heap.

It is useful to know that these two different kinds of memory exist in Java. Stack memory is the program's memory, and heap memory resides outside of the program.

As a Java programmer, you do not have to directly address memory allocation and recovery of memory space, which is a common headache for C++ programmers. When you need a new object, Java allocates the required memory. When you are done with an object, the memory is reclaimed for you automatically via Java's garbage collection facility.

Garbage collection runs as a thread in the background, looking for objects that no longer have a usable reference. When it finds them, it destroys them and reclaims the memory.

The implementation of garbage collection varies between Java Virtual Machines. They generally follow the same process, however. First, the garbage collector gets a snapshot of all running threads and all loaded classes. Then, all objects that are referred to by this thread set are marked as current. The process stops when all objects that it is possible to reach have been marked and the rest have been discarded.

In order to help the Virtual Machine, it is a good idea to remove your references to unneeded objects. This is often done by simply setting your reference to null:

Test t = new Test();
t.someAction();
// all done
t = null;

7.8.1 Finalizers

Constructors create objects. Most OOP languages provide methods for you to clean up after yourself. That is, they provide a way for you to destroy the objects you've created after you no longer reference them. Such methods are called finalizers.

NOTE

ColdFusion does not have finalizers for the same reason it doesn't have constructors: No objects are created. Memory is allocated in ColdFusion for what CF developers refer to as objects, such as the application object, the session object, and the query object. And good ColdFusion programming practice dictates that you shouldn't have a bunch of stuff lying around memory resident, so when you're done with a session variable but you still have an active session, you can set references you don't need to null.

Because all objects in Java extend java.lang.Object, which defines a finalize() method, any object can call finalize(). The protected void finalize() method returns nothing and does nothing. The finalize() method may never be invoked more than once by a JVM for an object.

The typical example for when to use finalizers is when you're working with file input/output. When you open a connection to a resource, such as a file, you might not have a chance to close it before an exception is thrown. In this case, you've got invalid processes consuming system resources unnecessarily.

Finalizers are generally regarded as the sort of thing to do in a last-ditch effort to save system resources. This is because they do not necessarily run as soon as it is possible. That means that the programmer cannot be certain when exactly they will run. Finalizers should therefore be used sparingly. We will see alternatives in Chapter 8, "Exceptions."