Java Reference
In-Depth Information
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:
•
At some point in the program execution, module m2 tries to access the memory using the
reference r1. Because module m1 has already reclaimed the memory referenced by r1, the
same memory might have been reallocated by the allocator and may have entirely different
data stored at that memory location. In such a case, r1 is called a
dangling reference
because it
is referencing a memory location that has already been reclaimed. If you try to read data using
a dangling reference, the result would be unpredictable. You cannot have a dangling reference
in Java.
•
Module m1 may try to use reference r1 after it has reclaimed the memory referenced by r1.
This will also lead to the problem of using a dangling reference.
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 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 life cycle 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 the
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.
Memory Allocation in Java
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.
Employee emp = new Employee();
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 above 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 class, information about the garbage
collection status of the object, locking information about the object, length of an array if the object is an array, etc.
