In a programming language, memory management is central to the development of a fast, efficient, and bug-free application. Memory management involves two activities:

When a program needs memory, memory is allocated from a memory pool. When the program is finished with the memory, the memory is returned to the memory pool, so it can be reused by some other part of the program in the future. The process of returning memory to the pool is known as memory reclamation or memory recycling. The memory allocation and reclamation can be accomplished explicitly or implicitly.

In explicit memory allocation , the programmer decides how much memory is needed. The programmer requests that amount of memory from the program runtime environment, known as the memory allocator or simply the allocator. The allocator allocates the requested memory and marks that memory as in-use, so it will not allocate the same memory block again. Here, we assumed that our request for new memory block to allocator is always fulfilled. This can happen only if we have an infinite amount of memory. However, that is not the case with any computer. Some computers may have megabytes of memory and some may have gigabytes. However, there is always a limit to the memory available on a computer. If we run a program that always allocates memory blocks from the memory pool and never returns the memory back to the pool, we will soon run out of memory and the program will stop.

In explicit memory reclamation, the programmer decides when to return the memory to the memory pool. The allocator is free to allocate the returned memory when it receives a new request for memory allocation. Explicit memory reclamation often leads to subtle bugs in programs. It also complicates the inter-modules interface design. Suppose there are two modules in an application and they are named m1 and m2. Module m1 allocates a block of memory and the reference to that memory is r1. Module m1 makes a call to module m2, passing the reference r1. Module m2 stores the reference r1 for future use. Which module should be responsible for the reclamation of the memory referenced by r1? There could be different scenarios depending on the program flow between the two modules. Suppose module m1 reclaims the memory immediately after a call to module m2. In such a case, you may come across two problems:

If module m2 reclaims the memory referenced by r1, you may end up with the same dangling reference problem if any of the modules, m1 or m2, try to use reference r1. What happens if none of the modules reclaims the memory and never uses the reference r1 again? The memory will never be returned to the memory pool and will never be reused. This situation is known as a memory leak because the allocator has no knowledge of the memory block, which is not returned to it, even though it is never used again by the program. If memory leaks happen regularly, the program will eventually run out of memory and will cease to function. If your program runs for a short time with small memory leaks, you may not even notice this bug for years or for the entire life of your program!

In a programming language that allows explicit memory management, programmers spend a substantial amount of effort in the memory management aspect of the program. In another kind of memory-related problem, a programmer may allocate a big amount of memory statically, so that he can use it throughout the lifecycle of the program. The static memory allocation may not always succeed, since static memory has an upper limit. The hardest part of the memory management decision is to decide when to reclaim the memory to avoid dangling references and memory leaks.

In implicit memory allocation, a programmer indicates to the runtime system that he wants to allocate memory to store a particular type of data. The runtime system computes the memory needed to store the requested type of data and allocates it to the running program. In implicit/automatic memory reclamation, a programmer does not need to worry about memory reclamation. The runtime system will automatically reclaim all memory blocks, which will never be used by the program again. The process of automatic reclamation of unused memory is known as garbage collection . The program that performs garbage collection is known as a garbage collector or simply a collector. The garbage collector may be implemented as part of the language runtime system or as an add-on library.

In Java, programmers deal with objects. The memory required for an object is always allocated on the heap. The memory is allocated implicitly using the new operator. Suppose you have a class called Employee. You create an object of the Employee class.

Depending on the definition of the Employee class, the Java runtime computes how much memory is needed, allocates the needed memory on heap, and stores the reference to that memory block in the emp reference variable. Note that when you want to create an Employee object, you do not specify how much memory you need. The new Employee() part of the previous statement indicates to Java that you want to create an object of the Employee class. Java queries the definition of the Employee class to compute the memory required to represent an Employee object.

Every Java object in memory has two areas: a header area and a data area. The header area stores bookkeeping information to be used by the Java runtime, for example, the pointer to the object’s class, object’s garbage collection status, object’s locking information, length of an array if the object is an array, etc. The data area is used to store the values of all instance variables of the object. The header area layout is fixed for a particular JVM implementation, whereas the data area layout is dependent on the object type. The Java Hotspot virtual machine uses two machine-words (in 32-bit architecture one word is 4 bytes) for the object header. If the object is an array, it uses three machine-words for its header. One extra word in the header is used to store the value of the array’s length. However, most JVMs use three machine-words for an object’s header. Figure 11-1 depicts the object layout for the Java Hotspot VM.

The Java Hotspot VM uses a variable length object header to save memory on the heap. Since most Java objects are small, one machine-word savings per object for non-array objects is a significant heap space savings. The Java Hotspot VM’s object header contains the following information:

Java does not provide any direct means to compute the size of an object. You should not write a Java program that depends on the size of the objects anyway. The size of primitive types—for example, int, long, double, etc.—is fixed for all JVM implementations. The layout and size of an object depend on the JVM implementation. Therefore, any code that depends on the size of objects may work on one platform and not on others.

The garbage collector is part of the Java platform. It runs in the background in a low priority thread. It automatically reclaims objects. However, before it reclaims objects, it makes sure that the running program in its current state will never use them again. This way, it ensures that the program will not have any dangling references. An object that cannot be used in the future by the running program is known as a dead object or garbage. An object that can be used in the future by the running program is known as a live object.

There are many algorithms to determine whether an object is live or dead. One of the simplest, but not very efficient, algorithms is based on reference counting, which stores the count of references that refer to an object. When an object’s reference is assigned to a reference variable, the reference count is incremented by 1. When a reference variable no longer refers to an object, the reference count is decremented by 1. When the reference count for an object is zero, it becomes garbage (or dead). This algorithm has a lot of overhead of updating the reference count of objects. Another type of algorithm, which is called a tracing algorithm , is based on the concept of a root set. A root set includes the following:

A garbage collector, which is based on the tracing algorithm, starts traversing references starting from the root set. Objects that can be reached (or accessed) from the reference variables in the root set are known as reachable objects . A reachable object is considered live. A reachable object from the root set may refer to other objects. These objects are also considered reachable. Therefore, all objects that can be reached directly or indirectly from the root set reference variables are considered live. Other objects are considered dead and are thus eligible for garbage collection.

An object may manage resources other than memory on heap. These resources may include network connections, file handles, memory managed explicitly by native code, etc. For example, an object may open a file when the object is created. File handles that can be opened simultaneously may have an upper limit depending on your operating system. When the object is garbage collected, you may want to close those file handles. The garbage collector gives the dying object a chance to perform the cleanup work. It does this by executing a predefined block of code before the memory for the dying object is reclaimed. The process of performing the cleanup work, before the object is reclaimed by the garbage collector, is known as finalization . The block of code that is invoked by the garbage collector to perform finalization is known as the finalizer. In Java, you can define an instance method called finalize() in a class, which serves as a finalizer for the objects of that class. The Java garbage collector invokes the finalize() method of an object before it reclaims the memory occupied by the object.

Programmers have little control over the timing when the garbage collection is run. The JVM performs the garbage collection whenever it runs low on memory. The JVM tries its best to free up memory of all unreachable objects before it throws a java.lang.OutOfMemoryError error. The gc() method of the java.lang.Runtime class may be used to pass a hint to the JVM that it may run the garbage collection. The call to the gc() method is just a hint to the JVM. The JVM is free to ignore the call. Suggesting that the garbage collection should run can be invoked as shown:

The System class contains a convenience method called gc(), which is equivalent to executing the previous statement. You can also use the following statement to run the garbage collector:

The program in Listing 11-2 demonstrates the use of the System.gc() method . The program creates 2,000 objects of the Object class in the createObjects() method. The references of the new objects are not stored. You cannot refer to these objects again, and hence, they are garbage. When you invoke the System.gc() method, you suggest the JVM that it should try to reclaim the memory used by these objects. The memory freed by the garbage collector is displayed in the output section. Note that you will more than likely get a different output when you run this program. The freeMemory() method of the Runtime class returns the amount of free memory in the JVM.

In general, it is not advisable to invoke the garbage collector programmatically. Invoking the garbage collector has some overhead. It may slow down performance if it is invoked arbitrarily. The Java runtime takes care of reclaiming unused object’s memory automatically. You may get an OutOfMemoryError in your program. This error may be caused by many reasons. The Java runtime makes all efforts to free up memory, invoking the garbage collector before throwing the OutOfMemoryError error. Therefore, simply invoking the garbage collector programmatically will not make this error go away. To resolve this error, you can look at the following:

Finalization is an action that is automatically performed on an object before the memory used by the object is reclaimed by the garbage collector. The block of code that contains the action to be performed is known as a finalizer. The Object class has a finalize() method , which is declared as

Because all Java classes inherit from the Object class, the finalize() method can be invoked on all Java objects. Any class can override and implement its own version of the finalize() method. The finalize() method serves as a finalizer for Java objects. That is, the garbage collector automatically invokes the finalize() method on an object before reclaiming the object’s memory. Understanding the correct use of the finalize() method is key to writing a good Java program, which manages resources other than the heap memory.

Let’s first start with a simple example that demonstrates the fact that the finalize() method is called before an object is garbage collected. Listing 11-3 defines a finalize() method in the Finalizer class. I used the @SuppressWarnings("deprecation") annotation on the finalize() method to suppress the compile-time deprecation warning because the method has been deprecated in JDK9.

The finalize() method prints a message if the object being garbage collected has an ID that’s a multiple of 100. The main() method creates 500,000 objects of the Finalizer class and calls System.gc() to invoke the garbage collector.

When the garbage collector determines that an object is unreachable, it marks that object for finalization and places that object in a queue. If you want the Java runtime to finalize all objects that are pending finalization, you can do so by calling the runFinalization() method of the Runtime class as shown:

The System class has a runFinalization() convenience method, which is equivalent to calling the runFinalization() method of the Runtime class. It can be called as shown:

Invoking the runFinalization() method is only a hint to the Java runtime to invoke the finalize() method of all objects pending finalization. Technically, you may call the finalize() method on an object in your code as many times as you want. However, it is meant for the garbage collector to call an object’s finalize() method at most one time during the lifetime of the object. The garbage collector’s one-time call to the finalize() method of an object is not affected by the fact that the finalize() method of the object was called programmatically before.

Programmers should not override the finalize() method in a class trivially. A finalize() method with no code, or one which calls the finalize() method of the Object class, is an example of a trivially overridden finalize() method. The method in the Object class does nothing. If your class is a direct subclass of the Object class and you do not have any meaningful code in the finalize() method of your class, it is better not to include the finalize() method in your class at all. Memory reclamation is faster and sooner for the objects, which do not have an implementation of the finalize() method compared to those that have an implementation of the finalize() method.

The timing of object finalization is not guaranteed. Finalization of all unreachable objects is also not guaranteed. In short, there is no guarantee when the finalize() method of an unreachable object will be called or if it will be called at all. So, what good is the finalize() method? The main purpose of a garbage collector in Java is to relieve programmers from the burden of freeing the memory of unused objects to avoid the problem of memory leaks and dangling references. Its secondary job is to run the finalization on the objects with no guarantee about the timing. As a programmer, you should not depend much on the finalization process of garbage collection. You should not code the finalize() method or code it with care. If you need to clean up resources for sure when you are done with them, you may use a try-finally block. If your resources are AutoCloseable, you may use a try-with-resources block. A try-finally block works as follows:

You can acquire resources and use them in a try block and release them in the associated finally block. A finally block is guaranteed to be executed after a try block is executed. This way, you can be sure that scarce resources in your program are always freed once you are done with them. However, it may not always be feasible, because of performance issues, to release resources immediately after you are done with them. For example, you may not want to open a network connection every time you need it. You may open a network connection once, use it, and close it when you no longer need it. Sometimes you may not know the exact point in a program from where you will not need that network connection. In such cases, you can code the finalize() method as a backup to free the resources if they have not been freed yet. You can call the finalize() method programmatically when you know for sure that the resources can be freed. Listing 11-4 contains the code for a FinalizeAsBackup class that shows the skeleton of the code that uses such a technique.

The aMethod() method of the class gets the resource and stores its reference in the sr instance variable. Programmers call the finalize() method when they are sure they should free the resources. Otherwise, the garbage collector will call the finalize() method and resources will be freed. Note that the FinalizeAsBackup class is a template. It contains pseudocode to explain the technique. This class will not compile.

Someone is about to die. God asks him for his last wish. He says, “Give me my life back.” God grants his last wish and he gets back his life. When he was about to die the second time God kept quiet and let him die without asking him for his last wish. Otherwise, he would ask for his life repeatedly and he would never die.

The same logic applies to an object’s finalization in Java. The call to the finalize() method of an object is like the garbage collector asking the object for its last wish. Generally, the object responds, “I want to clean up all my mess.” That is, an object responds to its finalize() method call by performing some cleanup work. It may respond to its finalize() method call by resurrecting itself by placing its reference in a reachable reference variable. Once it is reachable through an already reachable reference variable, it is back to life. The garbage collector marks an object using the object’s header bits as finalized, after it calls the object’s finalize() method. If an already finalized object becomes unreachable the next time during garbage collection, the garbage collector does not call the object’s finalize() method again.

The resurrection of an object is possible because the garbage collector does not reclaim an object’s memory just after calling its finalize() method. After calling the finalize() method, it just marks the object as finalized. In the next phase of the garbage collection, it determines again if the object is reachable. If the object is unreachable and finalized, only then will it reclaim the object’s memory. If an object is reachable and finalized, it does not reclaim object’s memory; this is a typical case of resurrection.

Resurrecting an object in its finalize() method is not a good programming practice. One simple reason is that if you have coded the finalize() method, you expect it to be executed every time an object dies. If you resurrect the object in its finalize() method, the garbage collector will not call its finalize() method again when it becomes unreachable a second time. After resurrection, you might have obtained some resources that you expect to be released in the finalize() method. This will leave subtle bugs in your program. It is also hard for other programmers to understand your program flow if your program resurrects objects in their finalize() methods. Listing 11-5 demonstrates how an object can be resurrected using its finalize() method.

The Resurrect class creates 1,000 objects in the main() method. It does not store references of those new objects, so they become garbage as soon as they are created. After creating 100 new objects, it invokes the garbage collector using the System.gc() method. It also calls the System.runFinalization() method, so the finalizers are run for the garbage objects. When the garbage collector calls the finalize() method for an object, that object passes its reference to the resurrectIt() method. This method stores the dying object’s reference in the static variable res, which is reachable. The method resurrectIt() also calls the sayHello() method on the resurrected object to show which object was resurrected. Note that once another object resurrects itself, you are overwriting the static res variable with the recently resurrected object reference. The previously resurrected object becomes garbage again. The garbage collector will reclaim the memory for the previously resurrected object without calling its finalize() method again. You may get different output when you run the program.

The state of a Java object is defined based on two criteria:

Based on the finalization status, an object can be in one of the following three states:

When an object is instantiated, it is in the unfinalized state. For example,

The object referred to by the john reference variable is in an unfinalized state after this statement is executed. The finalizer of an unfinalized object had never been invoked automatically by the JVM. An object becomes finalizable when the garbage collector determines that the finalize() method can be invoked on the object. A finalized object has its finalize() method invoked automatically by the garbage collector.

Based on reachability, an object can be in one of three states:

An object is reachable if it can be accessed through any chain of references from the root set. A finalizer-reachable object can be reached through the finalizer of any finalizable object. A finalizer-reachable object may become reachable if the finalizer from which it is reachable stores its reference in an object that is reachable. This is the situation when an object resurrects. An object may resurrect itself in its finalize() method or through another object’s finalize() method. An unreachable object cannot be reached by any means.

There are nine combinations of object states based on their finalization status and reachability status. One of the nine combinations, finalizable and unreachable, is not possible. The finalize() method of a finalizable object may be called in the future. The finalize() method can still refer to the object using the this keyword. Therefore, a finalizable object cannot also be unreachable. An object can exist in one of the following eight states:

The concept of weak references in the context of garbage collection is not new to Java. It existed before in other programming languages. So far, the object references I have discussed are strong references. That is, as long as the object reference is in scope, the object it refers to cannot be garbage collected. For example, consider the following object creation and reference assignment statement:

Here, john is a reference to the object created by the expression new Employee("John Jacobs"). The memory state that exists after executing this statement is depicted in Figure 11-2.

If at least one strong reference to an object exists, the garbage collector will not reclaim that object. In the previous section, I discussed the object state based on its reachability. By stating that there is a strong reference to an object, I mean that the object is reachable. With the introduction of weak references, now there are three more states of an object based on its reachability:

Therefore, when I called an object reachable in the last section, I will call it strongly reachable now onward. This change in terminology is because of the introduction of three new kinds of object reachability. Before I discuss the three new kinds of object reachability, you need to know about the classes included in the java.lang.ref package. There are four classes of interest, as shown in Figure 11-3. I do not discuss the Reference class from the diagram.

Reference<T> is an abstract class and it is the superclass for the SoftReference<T>, WeakReference<T>, and PhantomReference<T> classes. They are generic classes; their type parameter T is the type of object they reference. The SoftReference, WeakReference, and PhantomReference classes are used to create weak references. Note that by the phrase “weak reference,” I mean a reference that is not a strong reference. By the phrase WeakReference, I mean the java.lang.ref.WeakReference class. The ReferenceQueue class is used to place the references of SoftReference, WeakReference, and PhantomReference objects in a queue. Let’s look at different ways to create these three types of objects. The constructors for these three classes are shown in Table 11-1.

The memory state after executing these two statements is depicted in Figure 11-4.

In Figure 11-4, there are two strong references and one soft reference. All three weak reference classes have two instance variables: referent and queue. They are used to hold the reference of the object and reference queue passed in to the constructors of these classes. A reference to any object stored in the referent instance variable of any of these three classes is known as a weak reference in general—and a soft reference, weak reference, or phantom reference in particular—depending on the class being used. Therefore, the link from a soft reference object to the employee object shown in Figure 11-4 is a weak reference. To be specific, I call it a soft reference because I used an object of the SoftReference class. Any reference that does not involve the referent instance variable of any of these three classes is a strong reference in Java. Therefore, john and sr are strong references.

How are weak references different from strong references ? The difference lies in how the garbage collector treats them. Weak references do not prevent the objects they reference from being collected by the garbage collector. That is, if there is a weak reference to an object, the garbage collector can still reclaim the object. However, if there is at least one strong reference to an object, the garbage collector will not reclaim the object. Before you start looking at details of how to use these three reference classes, let’s discuss the reachability of an object when these classes are involved in a program.

Among the three kinds of weak references, a soft reference is considered stronger than a weak reference and a phantom reference. A weak reference is considered stronger than a phantom reference. Therefore, the rule to identify the reachability of an object is that if an object is not strongly reachable, it is as reachable as the weakest reference in the reference chain leading to that object. That is, if a chain of references to an object involves a phantom reference, the object must be phantom reachable. If a chain of references to an object does not involve a phantom reference, but it involves a weak reference, the object must be weakly reachable. If a chain of references to an object does not involve a phantom reference and a weak reference, but it involves a soft reference, the object must be softly reachable.

How do you determine the reachability of an object when there is more than one chain of references to the object? In such cases, you determine the object’s reachability using all possible chains of references and use the strongest one. That is, if an object is softly reachable through one chain of references and phantom reachable through another, the object is considered softly reachable. Figure 11-5 depicts the examples of how an object’s reachability is determined. The elliptical shape at the end of every reference chain represents an object. The reachability of the object has been indicated inside the elliptical shape. The rectangles denote references.

This section uses objects of a trivial class to demonstrate the use of reference classes. This class, called BigObject, is shown in Listing 11-6. It has a big array of long as an instance variable, so it uses a big chunk of memory. The id instance variable is used to track the objects of this class. The finalize() method prints a message on the console using the object’s id.

The object that you pass to the constructors of the WeakReference, SoftReference, and PhantomReference classes is called a referent. In other words, the object referred to by the object of these three reference classes is called a referent . To get the reference of the referent of a reference object, you need to call the get() method.

Figure 11-6 depicts the memory states with all the references after you execute each statement in the previous snippet of code.

The clear() method clears the link between the reference (weak, soft, or phantom) object and its referent. The following piece of code illustrates its use:

The memory state with all references, after each statement in the previous snippet of code is executed, is depicted in Figure 11-7 . After the referent’s reference is cleared using the clear() method, the get() method returns null. Note that the get() method of a PhantomReference object always returns null.

A softly reachable object is used to maintain memory-sensitive caches. That is, if you want to maintain a cache of objects as long as the program is not running low on memory, you can use softly reachable objects. When the program runs low on memory, the garbage collector clears the soft references to an object, making the object eligible for reclamation. At that point, your program will lose some or all of its objects from the cache. Java does not guarantee that soft references will not be cleared if the program is not running low on memory. However, it guarantees that all soft references will be cleared before the JVM throws an OutOfMemoryError. There is also no guarantee of the order in which soft references will be cleared. However, JVM implementations are encouraged to clear the least-recently created/used soft reference first. Listing 11-7 shows the wrong use of soft references to cache data.

The intention of the programmer was to cache a big object with an ID of 101 using a soft reference . If the program runs low on memory, the cached big object with ID 101 may be reclaimed. The while loop inside the program is trying to create many big objects to make the program run low on memory. The programmer is expecting that when the program is executed, it should reclaim memory used by the big object with ID 101, before throwing an OutOfMemoryError.

The output shows that the program did not reclaim the memory used by the big object with ID 101. Why did the garbage collector not behave the way it was expected to behave? There is an error in the code for the WrongSoftRef class. The big object with ID 101 is strongly reachable because the bigObj reference to it is a strong reference. You must set the bigObj reference variable to null to make it softly reachable.

Listing 11-8 shows the correct use of soft references. It is clear from the output that the finalize() method of the big object with ID 101 was called and the object was reclaimed before JVM threw an OutOfMemoryError. You still got an OutOfMemoryError because you are creating many new objects inside a while loop and all of them are strongly reachable from the array list. This proves the point that soft references are cleared and the referents are reclaimed by the garbage collector before JVM throws an OutOfMemoryError. You may get a different output. Sometimes, you get an OutOfMemoryError without the object being reclaimed.

Listing 11-9 illustrates how to use soft references to implement memory-sensitive caches.

It can cache up to 10 objects of the BigObject class with IDs from 0 to 9. To get the cached object for a given ID, you need to call the getObjectById() method. If that ID has not yet been cached or it was reclaimed by the garbage collector, the method creates and caches the object. This example is very restrictive and its purpose is only to demonstrate the use of the SoftReference class to maintain a memory-sensitive cache. You can cache only objects with IDs from 0 to 9. It can be modified to meet specific requirements. For example, you can use an ArrayList to cache the objects instead of using an array. You can use the BigObjectCache class as shown:

If an object with an ID of 5 is not already in the cache, it will be cached and the new object reference will be assigned to cachedObject. If an object with an ID of 5 is already in the cache, the reference of that object from the cache will be returned and assigned to cachedObject.

An object of the ReferenceQueue<T> class is used in conjunction with objects of the SoftReference<T>, WeakReference<T>, and PhantomReference<T> classes if the object needs to be notified when its reachability changes. An object of any of these reference classes can be registered with a reference queue, as shown:

It is optional to register the SoftReference and WeakReference objects with a reference queue. However, you must register a PhantomReference object with a reference queue. When a SoftReference or WeakReference is cleared by the garbage collector, the reference of the SoftReference or the WeakReference object is appended to the reference queue. Note the references of the SoftReference and WeakReference are placed in the queue, not the reference of their referent. For example, if the garbage collector clears the soft reference to a BigObject with ID 19 in the previous snippet of code, sr will be placed in the reference queue. In case of a PhantomReference, when its referent becomes phantom reachable, the garbage collector places the PhantomReference object in the reference queue.

There are two ways to determine if a reference object has been placed in its reference queue. You can call the poll() or remove() method on a ReferenceQueue, or you can call the isEnqueued() method on the soft, weak, and phantom references. The poll() method removes a reference from the queue and returns the reference. If there is no reference available in the queue, it returns null. The remove() method works the same as the poll() method, except that if there is no reference available in the queue, it blocks until a reference becomes available. The isEnqueued() method for soft, weak, and phantom references returns true if they are placed in queue. Otherwise, it returns false. Listing 11-10 demonstrates how to use the ReferenceQueue class.

The only difference between a softly reachable and a weakly reachable object is that the garbage collector clears and reclaims weakly reachable objects whenever it runs, whereas it uses some algorithm to decide whether it needs to clear and reclaim a softly reachable object or not. In other words, the garbage collector may or may not reclaim a softly reachable object, whereas it always reclaims a weakly reachable object.

You may not see any important use of a weak reference because its referent is reclaimed when the garbage collector is run. Generally, weak references are not used to maintain caches. They are used to associate extra data with an object. Suppose you have a person’s details and his address. If you lose his details, you will not be interested in his address. However, as long as the person’s details are accessible, you want to keep his address information. This kind of information can be stored using weak references and a Hashtable. A Hashtable stores objects in key-value pairs. While adding a key-value pair to a Hashtable, you need to wrap the key object in a WeakReference object. The key and value are not garbage collected when the key is accessible or in use. When the key object is no longer in use, it will be garbage collected because it was wrapped inside a WeakReference. At that point, you can remove that entry from the Hashtable, so the value object will also be eligible for the garbage collection. The following is a sample snippet of code using Hashtable and WeakReference objects:

Note that using a WeakReference object to associate extra information with an object using a Hashtable involves some complex code and logic. The java.util.WeakHashMap class provides this functionality without writing any complex logic. You add the key-value pairs to a WeakHashMap without wrapping the key object inside a WeakReference. The WeakHashMap class takes care of creating a reference queue and wrapping the key object in a WeakReference. There is one important point to remember while using a WeakHashMap. The key object is reclaimed when it is not strongly reachable. However, the value object is not reclaimed immediately. The value object is reclaimed after the entry is removed from the map. The WeakHashMap removes the entry after the weak reference to the key has been cleared and one of its methods—put(), remove(), or clear()—is called. Listing 11-11 demonstrates the use of a WeakHashMap. The example uses objects of the BigObject class as keys as well as values. The messages in the output show when the key and value objects are reclaimed by the garbage collector. You may get different output when you run this program.

A PhantomReference object must be created with a ReferenceQueue. When the garbage collector determines that there are only phantom references to an object, it finalizes the object and adds the phantom references to their reference queues.

Why would you use a phantom reference instead of using a strong reference? A phantom reference is used to do post-mortem processing. Unlike the get() method of the soft and weak references, the phantom reference’s get() method always returns null. An object is phantom reachable when it has been finalized. If a phantom reference returns the referent’s reference from its get() method, it would resurrect the referent. This is why the phantom reference’s get() method always returns null.

Listing 11-12 demonstrates the use of a phantom reference to do some post-mortem processing for an object. You may get different output when you run this program.

You can also use phantom references to coordinate the post-mortem processing of more than one object. Suppose you have three objects called obj1, obj2, and obj3. All of them share a network connection. When all three objects become unreachable, you would like to close the shared network connection. You can achieve this by wrapping the three objects in a phantom reference object and using a reference queue. Your program can wait on a separate thread for all three phantom reference objects to be queued. When the last phantom reference is queued, you can close the shared network connection. Post-mortem coordination using a phantom reference is demonstrated in Listing 11-13. Note that the startThread() method of the PhantomRefDemo class creates and starts a thread that waits for three references to be enqueued. Once all three references are enqueued and their referents clears, the thread exits the application. The remove() method of the ReferenceQueue class blocks until there is a phantom reference in the queue. You may get different output when you run this program.

In the previous sections, you learned how to use PhantomReference and ReferenceQueue to perform cleanup work for objects when they become phantom reachable. To set up and perform the cleanup work was not easy. JDK9 introduced a new class named Cleaner in the java.lang.ref package. Its use to let you run a cleanup action for an object when the object becomes phantom reachable. The Cleaner class is intended to make setting up and performing the cleanup work easier for you. Here are the steps you need to perform:

Now I walk you through an example on how to use the Cleaner class. You can use one of the following methods of the Cleaner class to create a Cleaner :

Typically, you would create a Cleaner object for the entire application or library and store its reference in a static variable. The following statement creates a Cleaner:

Suppose you have the following object that needs cleanup work when it becomes phantom reachable:

The next step is to define a cleaning action, which is a Runnable. There are several ways to create a Runnable such as using a lambda expression, inner class, anonymous inner class, nested inner class, and having a top-level class, which implements the Runnable interface. It does not matter which method you choose to create a Runnable. It is important to make sure that the Runnable does not store the reference of the object whose cleanup work it is supposed to perform. Otherwise, the object will never become phantom reachable and your cleaning action will never be called by the Cleaner. You need to make all resources that need to be cleaned up are accessible to the Runnable. Suppose you have an object that stores a network connection and you want to close the connection as part of the object cleanup. You will need to make the network connection accessible to the Runnable, so it can close the connection when the cleanup work is performed. The following pseudo statement creates a Runnable:

The following statement registers myObject and its cleaningAction with the Cleaner:

Typically, you will keep the reference of the Cleanable in an instance variable of your object, so you can call its clean() method directly to clean up your object explicitly, if needed. Listing 11-14 contains the code for a CleanBigObject class. Explanation of its parts follows the code .

Here are the different parts of the CleanBigObject class :

Listing 11-15 contains the code for a CleanerTest class. In its main() method, it creates three objects of the CleanBigObject class and tries to clean up those objects in three different ways. The first example uses a try-with-resources block, so the close() method of the CleanBigObject class is automatically called, which cleans up the object. The second example cleans up the object explicitly by calling its close() method. The third example creates the object without storing its reference and invokes the garbage collection by calling System.gc(). In the end, the program sleeps for two seconds to give the garbage collection time to finish if the previous call to System.gc() makes the JVM run the garbage collection. Note that there is no guarantee that garbage collection will run and, in that case, you may not see the last line in the output.

The process of reclaiming the memory of dead objects is known as garbage collection. Garbage collection in Java is automatic. The Java runtime runs garbage collection in a low priority background thread. The JVM does its best to free up memory of dead objects before throwing an OutOfMemoryError. You can pass a hint, although it’s not needed in an application, to the JVM by calling Runtime.getRuntime().gc(). You can also use the convenience method System.gc() to pass the same hint to the JVM. The JVM is free to ignore the hint.

The memory occupied by an unreachable object is reclaimed in two phases. The first phase, called finalization, is an action automatically performed on an unreachable object before the memory used by the object is reclaimed by the garbage collector. The block of code that contains the action to be performed is known as a finalizer. A finalizer is implemented using the finalize() method of the object. In the finalize() method, the unreachable object may resurrect itself by storing its reference in a reachable object. In the second phase, if the object is still unreachable, the memory occupied by the object is reclaimed.

At times, you may want to use memory-sensitive objects, which are fine to be kept in memory if enough memory is available. However, if the application runs low on memory, it would be fine to reclaim those objects. Typically, objects cached for a better performance fall into this category of objects. Java provides the SoftReference<T>, WeakReference<T>, and PhantomReference<T> classes in the java.lang.ref package to work with such memory-sensitive objects. These objects may be queued to a ReferenceQueue when their referent’s reachability changes, so you can inspect the queue and perform cleanup work.

JDK9 added a new class named Cleaner to the java.lang.ref package. This class offers a better way to clean up objects when the objects become phantom reachable. The Cleaner lets you register objects and their cleaning actions as a Runnable. When a registered object becomes phantom reachable, the Cleaner performs the cleanup work using the registered Runnable for that object. The Cleaner also allows you to clean up the object explicitly. It guarantees that the cleanup will be performed only once in any case.