Java memory management
Tutorial Details:
Java memory management
Java memory management
By: By Java Q&A Experts
Are memory leaks possible, preventable in Java?
What sort of memory leaks are possible in Java and how do I prevent them?
In any language, application-level memory management problems revolve around the deallocation of memory. These problems fall into two categories: premature deallocation (corrupted pointers) and incomplete deallocation (memory leaks).
In the case of incomplete deallocation, there are two subcases: coding bugs and design bugs. Coding bugs are language dependent. In the case of C, this would involve free() ing less than was malloc() ed, while in C++ this might involve using delete in lieu of delete[] . Design bugs, on the other hand, do not depend on the language; instead, they involve simple programmer negligence.
In languages like C/C++, all memory management is handled by the programmer, so all of these problems can arise, even after the programmer has expended much effort to ensure the code is free of such defects. In fact, in C/C++ the more you try to avoid memory leaks, the more likely you are to create corrupted pointers, and vice versa. And, by nature the risk of such bugs increases with code size and complexity, so it's difficult to protect large C/C++ applications from these types of bugs.
In Java, on the other hand, the Java language and runtime together entirely eliminate the problems of corrupted pointers and code-level memory leaks. Here's how:
In Java, memory is allocated only to objects. There is no explicit allocation of memory, there is only the creation of new objects. (Java even treats array types as objects.)
The Java runtime employs a garbage collector that reclaims the memory occupied by an object once it determines that object is no longer accessible. This automatic process makes it safe to throw away unneeded object references because the garbage collector does not collect the object if it is still needed elsewhere. Therefore, in Java the act of letting go of unneeded references never runs the risk of deallocating memory prematurely.
In Java, it's easy to let go of an entire "tree" of objects by setting the reference to the tree's root to null ; the garbage collector will then reclaim all the objects (unless some of the objects are needed elsewhere). This is a lot easier than coding each of the objects' destructors to let go of its own dependencies (which is a coding-level problem with C++).
So what about memory leaks caused by poor program design? In such designs, unnecessary object references originating in long-lived parts of the system prevent the garbage collector from reclaiming objects that are in fact no longer needed. Such errors typically involve a failure "in the large" to properly encapsulate object references among various parts of the code.
Another design flaw occurs "in the small," at the level of a faulty algorithm; the use of Collections objects in such cases will typically magnify the error.
As the technology improves, a suitably implemented JVM could help reduce the effects of such designed-in memory leaks by using the garbage collector to track object usage over time. The garbage collector could then rearrange objects in memory according to a freshness factor based on when they were last referenced, for example. Stale objects would become eligible for physical RAM swap-out (even though, for safety, they would still exist).
Ideally of course, programmers would design applications with objects' lifecycles in mind, rather than rely on clever features of state-of-the-art JVM implementations.
In conclusion: Design problems can be mitigated by letting go of object references in one's own classes as soon as one can (knowing that in Java there is no risk of damaging another part of the code).
Tip: The KL Group's JProbe tool can help identify possible sources of memory leaks by showing which objects are holding on to graphs of references to other objects.
Note: Implementations of Sun's JVM prior to HotSpot used a technique called conservative garbage collection, which could introduce memory leaks of its own, beyond those caused by the programmer. To wit, as long as the application contained a 32-bit integer primitive (int) whose value coincided with the address of an object, the garbage collector would not reclaim the object. Although the likelihood was small, it wasn't zero. For this reason, and for the best performance in general, use HotSpot where possible.
This page formated for crawlers and browsers that don't support scripts and tables.
Home
EZone
Read
Tutorial at: Click here to view the tutorial
Rate Tutorial: Java memory management
View Tutorial: Java memory management
Related
Tutorials:
 Build
servlet-based enterprise Web applications - JavaWorld - December
1998
Build
servlet-based enterprise Web applications - JavaWorld - December
1998
|
The Java HotSpot
Performance Engine is set to break new records - JavaWorld
The Java HotSpot
Performance Engine is set to break new records - JavaWorld
|
Java memory management
Java memory management
|
Smart object-management saves the
day - JavaWorld November 1999
Smart object-management saves the
day - JavaWorld November 1999
|
Create automated and distributed
management applications with Jiro
technology, Part 1 - JavaWorld February
Create automated and distributed
management applications with Jiro
technology, Part 1 - JavaWorld February 2000
|
Double-checked
locking: Clever, but broken - JavaWorld February
2001
Double-checked
locking: Clever, but broken - JavaWorld February
2001
|
Warning! Threading in
a multiprocessor world - JavaWorld February 2001
Warning! Threading in
a multiprocessor world - JavaWorld February 2001
|
Manage distributed
sessions - JavaWorld April
2001
Manage distributed
sessions - JavaWorld April
2001
|
Can double-checked locking be fixed? - JavaWorld May 2001
Can double-checked locking be fixed? - JavaWorld May 2001
|
Java Tip 130: Do you
know your data
size?
Java Tip 130: Do you
know your data
size?
|
Welcome to the WfMOpen project
WfMOpen is a J2EE based implementation of a workflow facility (workflow engine) as proposed by the Workflow Management Coalition (WfMC) and the Object Management Group (OMG).
|
Fixing the Java Memory Model, Part 2
Writing concurrent code is hard to begin with; the language should not make it any harder. While the Java platform included support for threading from the outset, including a cross-platform memory model that was intended to provide \"Write Once, Run Anywh
|
Fixing the Java Memory Model, Part 1
JSR 133, which has been active for nearly three years, has recently issued its public recommendation on what to do about the Java Memory Model (JMM).
|
Improve Application Management With JMX
Improve Application Management With JMX
Leverage JMX technology and existing tools to boost the operations management capabilities of your business applications.
|
Monitoring Local and Remote Applications Using JMX 1.2 and JConsole
Monitoring Local and Remote Applications Using JMX 1.2 and JConsole
The latest release of Java, J2SE 5.0 (codenamed Tiger), adds core support for the Java Management Extensions (JMX) 1.2 into the Java standard libraries. This article walks you through h
|
Java Application Instrumentation with Log4J
Java Application Instrumentation with Log4J
Application metrics, such as performance metrics, are key to understanding and improving application efficiency. Profiling and monitoring tools yield valuable information on CPU and resource usage, including OS
|
Using JConsole to Monitor Applications
JConsole is the Java Monitoring and Management Console, a new graphical tool shipped in J2SE JDK 5.0. This article describes how JConsole can be used to observe information about an application running on the Java platform, with an overview of the J2SE 5.
|
Getting Started with Java Management Extensions (JMX): Developing Management and Monitoring Solutions
The Java Management Extensions (JMX) API is a standard specification developed through the Java Community Process (JCP) as JSR 3 for managing and monitoring applications and services.
|
Accessing Database from servlets through JDBC!
Accessing Database from servlets through JDBC!
Java Servlets
J ava Servlets are server side components that provides a powerful mechanism for developing server side of web application. Earlier CGI was developed to provide server side capabilities
|
Getting Started With the PIM APIs
This article provides a code-intensive introductory tutorial to Personal information management (PIM) APIs, JSR 75.
|
|
|
|
