In a production environment, memory leaks can force organizations to add more memory and hardware resources. They can even cause an application to crash unexpectedly. In theory, Java memory leaks should not emerge as a development or production issue because the garbage collector is responsible for memory management.
Built-in Java memory management enables developers to sidestep tedious memory management considerations and is a fundamental reason why Java is a relatively straightforward development environment. Practically, however, the garbage collector function is unable to accurately address all memory management considerations, due to programming oversights and Java language program loopholes that allow memory leaks.
The garbage collector's job is to periodically collect unreferenced objects. Java memory leaks typically occur because the garbage collector reserves, or allocates, memory for each object associated with a program - whether or not the program uses the object. The garbage collector, as a result, reserves memory for each object, but does not have the intelligence to reallocate memory reserved for an idle object to another command. Consequently, the garbage collector falsely assumes that memory is being used by objects. The objects that are not being used but still hold references are not collected, thus leading to memory leaks.
Failure to adequately manage memory can significantly hinder the performance of your Java and J2EE applications. This column will outline the root causes of memory leaks and detail best practices for identifying and eliminating memory leaks in development and production to ensure robust Java and J2EE application performance.
Four Leading Causes of Memory Leaks
Memory management is a complex process, and the source of a memory leak is not always evident. Outlined below are four leading causes of memory leaks.STATIC COLLECTION CLASSES
Static collection classes, such as HashMap and Vector, are susceptible to memory leaks because they are designed to hold other referenced objects. Static key words (as shown in Listing 1) are likely to cause memory leaks because static variables remain in memory as long as the application runs, regardless of its object creation and destruction.
LISTENERS
There are several listener types available in J2EE that provide notification when an event occurs. Until a J2EE application receives event notification, any storage held by that application will not be garbage-collected by the Java Virtual Machine (JVM). Web application listener events are new in the Servlet 2.3 Specifi-ca-tion. These listeners include servlet creation and invalidation as well as application startup and shutdown. The two listener classes, javax.Servlet.servletContextListener and javax.servlet.http.HttpSessionListener, when not implemented correctly, can lead to long-running applications that hold storage. To avoid this problem, keep the storage associated with servlet sessions small to minimize the effect on the heap. The Graphics Interchange Format (GIF), for example, should not be held in a session object that is kept in session using a listener.
PHYSICAL CONNECTIONS
Physical connections, such as database and network connections, are not going to be garbage-collected automatically unless they are disconnected explicitly. Java database connections are typically initialized using the DataSource.getConnection() method, which is used to handle physical connections. These physical connections must be freed when they are no longer required by the application using the close() method. Because the scope of such connections is independent of the JVM, the garbage collector does not have the ability to affect a physical connection. When your application server uses the connection pool, the DataSource.getConnection() method allows you to release connections back to the pool so other transactions can use the physical connection to access the database.
Connection pools bring advantages to application development by reducing the overhead of an application by physically connecting to and disconnecting from a database. The physical connections are maintained by the application server and managed from a pool that is farmed out to each application that retrieves data from a database. Using a connection pool limits the number of physical database connections. Therefore, it is very important for an application to release its connection once it has finished sharing information with a database.
JAVA NATIVE INTERFACE REFERENCES
Similar to the physical connections mentioned above, the Java Native Interface (JNI) allows Java code to run with other languages, such as C and C++. The references created in the C or C++ application environments should be unreferenced explicitly. Because the C or C++ storage is not allocated from the JVM Heap, it will not be garbage-collected by the JVM. Because the JVM does not have the ability to de-allocate JNI references, JNI memory must be managed directly by the C or C++ application.
A Best-Practice Approach to Hunting Memory Leaks
It is not always easy to detect memory leaks by scanning your code. Not all of the programmers involved with a J2EE project may have the time or experience to code memory management appropriately. Although many project managers face this issue, there is no standard solution to this problem because nearly every Java environment is unique. There are, however, guidelines that development teams should follow to optimize memory performance. An overview of best practices for ensuring a high level of memory performance throughout each phase of the "build, run, manage" application infrastructure life cycle follows.BETTER CODING
Listing 2 illustrates how programmers can overlook memory leaks. The helper object in Listing 2 is a memory leak until another class removes it from the LongReferent class. Listing 2 shows that the garbage collector is not always responsible for collecting memory. The memory leak in this program can be avoided by removing the helper object from LongReferent explicitly, by the same class or by some other class. Objects stored in a HashMap are removed using the clear() or remove(object key) HashMap class method calls. Once the reference is removed from the HashMap, it is a candidate for garbage collection. Always double-check that the references are released, especially when you write static collection classes, listeners, database access code, and JNI code.
One approach to avoiding memory leaks is to write both "create method" and "remove method" commands in each class, then check for remove-method usage. In the unit-testing phase, you can search for create-method and remove-method usage in the code. The memory code is functioning properly if there is an equal number of calls for the create method and remove method commands. If the number of calls for these methods don't match, you should fix the code by adding or removing methods wherever they are missing.
BETTER APPLICATION PROGRAM INTERFACE
To achieve an added level of control over memory and garbage collection from the program, J2EE introduced the java.lang.ref package. For example, the WeakHashMap class java.lang.ref package uses weak keys to reference objects within the garbage collection. An object is available for the garbage collector when the WeakHashMap key is invalid. The garbage collector can make a key invalid if the memory is low, allowing the object it references to be freed. The garbage collector moves the key through three stages: finalizable, finalized, and reclaimed. It is not unlikely that the application could try to retrieve an object only to determine the object has been reclaimed by a garbage-collection cycle. This process works effectively for objects that can be re-created and easily collected whenever memory is running low.
Listing 3 shows the usage of the WeakHashMap class. Listing 3 is similar to Listing 2, except that it uses the WeakHashMap instead of the HashMap class. The difference between the two classes is that HashMap contains strongly referenced keys, which cannot be removed until the program unreferences them explicitly. The WeakHashMap class contains weakly referenced keys that can be removed by the garbage collector without unreferencing, or removing, keys in the program when memory is running low. The garbage collector algorithm determines the removal of weakly referenced keys. This varies by JVM.
The garbage collector generally removes unused, weakly referenced objects first so that it can allocate the unused memory for new objects. The program also checks for null keys and refreshes them with keys and values when it uses WeakHashMap. As part of this process, the garbage collector works in the background to remove the keys automatically. These classes are important to consider, especially when you implement memory-hog functionality - such as caching modules - that enables cached objects to be easily re-created. This approach can be used to replace the HashMap calls in the first example.
BETTER DEVELOPMENT AND TESTING TOOLS
Even when following best practices, it is virtually impossible to avoid memory leaks in medium or large projects in which many programmers are writing thousands of lines of code. Fortunately, there are effective performance tools available to pinpoint memory leaks automatically. Some products are built into development solutions, and others are stand-alone tools. Some of the newest development tools include profilers, which enable developers to monitor performance issues from the same development integrated development environment. Profiler solutions from Candle Corp. and other vendors can pinpoint memory leaks automatically as part of a broader development tool. An effective profiler tool must enable developers to:
- Identify which method allocated the memory
- Clarify if the memory was released by the garbage collector and how long it was allocated
- Determine which objects are holding the reference to the memory; Listing 1 shows that the HashMap is holding the memory reference
BETTER PRODUCTION TOOLS
Although profilers excel at identifying memory leaks and other performance problems, developers and testers must be able to use the tools effectively. Memory problems that are overlooked in development will likely cascade in the production phase. Profiles provide development teams with a significant amount of performance data, which, in turn, may create more development cycles in the project due to the additional work associated with finely tuning memory management. Added production cycles may not be feasible for projects that have tight deadlines.
Fortunately, monitoring tools in production enable users to track J2EE application performance in real-world environments. Production profiling solutions from Candle, IBM, and other vendors monitor resource utilization for memory consumption. These tools provide visibility into the J2EE application environment that enables users to proactively improve performance and avoid production downtime.
Conclusion
Memory leaks often destabilize an application in production by consuming large quantities of memory or causing the JVM to crash. Moreover, whenever the system is low on memory the garbage collector tries to collect the memory more frequently, thus diminishing application performance. During development, programmers must pay special attention to memory leak problems associated with static collection classes, listeners, physical connections, and JNIs. The latest profiling tools identify memory problems long before the testing and production phases.Production monitoring tools enable you to track application health and view otherwise-hidden performance metrics. Organizations are better able to tune memory management, which can improve the overall production stability and uptime. Organizations that address memory leaks by using a combination of development best practices and profiling and management tools can optimize memory management, which can increase the performance of their J2EE applications.
Reference : http://websphere.sys-con.com/node/44716
No comments:
Post a Comment