Java Reference
In-Depth Information
Finalizing 15247
Finalizing 15248
Finalizing 15246
The program creates 20,000 objects of the Finalize class without storing their references. It is important that
you do not store the references of the objects you create. As long as you hold the reference of an object, it will not be
destroyed and its finalizer will not be run. You can see from the output that only three objects got a chance to run their
finalizers before the program finished. You may get no output at all or a different output. If you do not get any output,
you can try by increasing the number of objects to create. The garbage collector will destroy objects when it feels it
is running low in memory. You may need to create more objects to trigger garbage collection, which in turn will run
finalizers of your objects.
Immutable Objects
An object whose state cannot be changed after it is created is called an immutable object. A class whose objects are
immutable is called an immutable class. If an object's state can be changed (or mutated) after it has been created, it is
called a mutable object, and its class is called a mutable class.
Before I go into details of creating and using immutable objects, let's define the word “immutability.” Instance
variables of an object define the state of an object. There are two views of an object's state: internal and external. The
internal state of the object is defined by the actual values of its instance variables at a point in time. The external state
of the object is defined by the values that the users (or clients) of the object see at a point in time. When we state that
an object is immutable, we must be specific about which state of the object we mean to be immutable: internal state,
external state, or both.
Typically, when we use the phrase “an immutable object” in Java, we mean external immutability. In external
immutability, an object may change its internal state after its creation. However, the change in its internal state is
not visible to external users. The users do not see any changes in its state after its creation. In internal immutability,
the state of an object does not change after it is created. If an object is internally immutable, it is also externally
immutable. I will discuss examples of both.
Immutable objects have several advantages over mutable objects. An immutable object can be shared by
different areas of a program without worrying about its state changes. Testing an immutable class is easy. An
immutable object is inherently thread-safe. You do not have to synchronize access to your immutable object from
multiple threads since its state does not change. Please refer to the chapter on threads in the topic Beginning Java
Language Features for more details on thread synchronization. An immutable object does not have to be copied and
passed to another area of the program in the same Java application because its state does not change. You can just
pass its reference and that serves as a copy. Its reference can be used to access its content. Avoiding copying is a big
performance advantage as it saves both time and space.
Let's start with a mutable class whose object's state can be modified after it is created. Listing 7-15 has code for an
IntHolder class.
Listing 7-15. An Example of a Mutable Class Whose Object's State Can Be Changed After Creation
// IntHolder.java
package com.jdojo.object;
public class IntHolder {
private int value;
public IntHolder(int value) {
this.value = value;
}
 
Search WWH ::




Custom Search