Java Memory leakage analysis (3)

Abstraction

Although Java virtual machines and garbage collection mechanisms manage most of the memory transactions, there may still be memory leaks in Java software. Indeed, memory leakage is a common problem in large projects. The first step to avoid Memory leakage is to understand the cause of their occurrence. This article introduces some common defects and provides some very good practice examples to guide you to write code without memory leakage. Once your program has memory leakage, it is very difficult to find out the cause of the leakage in the code. At the same time, this article also introduces a new tool to find memory leaks and then specify the root cause. This tool is easy to use and allows you to find memory leaks in product-level systems.

　　Garbage Collection (GC) Role

Although garbage collection is concerned with most of the problems, including memory management, which makes the programmer's tasks easier, the programmer may still make some mistakes and cause memory leakage. GC (garbage collection) recursively references all inherited objects from the "root" (Objects in the stack, static data members, JNI handles, etc, mark all the living objects that can be accessed. These objects become the only objects that can be manipulated by the program, and other objects are released. This is safe because GC makes the program unable to access the released objects.

Memory management can be said to be automatic, but this does not leave programmers out of memory management issues. For example, there is always a certain amount of overhead for memory allocation (and release), although these overhead are implied by programmers. If a program creates many objects, the execution speed of the program is slower than that of the program that completes the same task and creates fewer objects (the content provided by other programs is the same ).

The main cause of Memory leakage is that I forgot to release the memory I previously applied. If a reference to useless objects exists in the program, these objects will reside in the memory and consume the memory, because the Garbage Collector cannot verify whether these objects are no longer needed. As we can see earlier, if an object is referenced, this object is defined as "alive" and will not be released. To determine that the memory occupied by an object will be recycled, the programmer must confirm that the object will no longer be used. A typical practice is to set the object data member to null or remove the object from the set. Note: When local variables are not needed, you do not need to explicitly set them to null because these references are automatically cleared when a method is executed.

At a higher level, this is what memory leakage is considered by all languages with memory management. The remaining object references will no longer be used.

　　Typical Leakage

Now that we know that there is indeed a memory leak in Java, let's look at some typical leaks and find out why they happen.

　　Global set

It is common to have a variety of global data warehouses in large applications, such as a JNDI-tree or a session table. In these cases, the focus is on managing the data warehouse size. Of course, there are some appropriate mechanisms to remove useless data from the repository.

There are many different solutions. The most common solution is to clear jobs that run cyclically. This job will verify the data in the repository and then clear all unnecessary data.
Another method is to use reference calculation. The set is used to understand the number of referrer for each set. This requires when the notification set of the associator will be completed. When the number of associators is zero, you can remove related elements from the set.

　　High-speed cache

Cache is a data structure used to quickly find the results of operations that have been executed. Therefore, if an operation is slow, you can first put the common input data into the cache, and then call the data in the cache later.

There is also a dynamic implementation of high-speed cache. When the data operation is completed, it is sent to the high-speed cache. A typical algorithm is as follows:

1. Check whether the result is in the cache. If yes, the result is returned;

2. if the result is not there, calculate the result;

3. Add the results to the cache for future operation calls.

This algorithm problem (or potential memory leakage) is at the end. If an operation is accompanied by a different number, it is also a very large result to be saved to the cache. This method is not competent.

To avoid this potentially fatal design error, the program must determine that the cache has an upper bound in the memory used by the program. Therefore, a better algorithm is:

1. Check whether the result is in the cache. If yes, the result is returned;

2. if the result is not there, calculate the result;

3. If the cache occupies too much space, remove the old results from the cache;

4. Add the results to the cache for future operation calls.

By constantly Removing old results from the cache, we can assume that in the future, the probability of the latest input data being reused will be much greater than the old results. This is usually a good idea.

This new algorithm ensures that the cache capacity is in a predetermined range. It is difficult to calculate the exact range because the objects in the cache will continue to be valid when referenced. Correct division of the cache size is a complex task. You must weigh the contradiction between the available memory size and fast data access.

Another way to solve this problem is to use the java. Lang. Ref. softreference class to insist on putting objects into high-speed cache. This method ensures that the reference of these objects can be released when the VM runs out of memory or requires more heaps.

　　Class Loader

The creation of Java class loaders has many vulnerabilities that may cause memory leakage. Due to the complex structure of the Class Loader, it is difficult to obtain the perspective of Memory leakage. These difficulties are not only because the class loader is only related to the "common" object reference, but also to the internal reference of the object, such as data variables, methods, and various types. This means that as long as there is a Class Loader for data variables, methods, various types and objects, the class loader will reside in JVM. Since the class loader can be associated with many classes and static data variables, a considerable amount of memory may leak.

　　Locate Memory leakage

Often, the initial sign of program memory leakage occurs after an error, and an outofmemoryerror is returned in your program. This typical situation occurs in the product environment, where you want to minimize the possibility of Memory leakage and debugging. Maybe your testing environment is different from the system environment of the product, and the leaked ones will only be revealed in the product. In this case, you need a low housekeeping tool to monitor and find memory leaks. At the same time, you also need to associate this tool with your system, instead of restarting it or automating your code. Perhaps more importantly, when you do the analysis, you need to be able to separate the tool so that the system will not be disturbed.

An outofmemoryerror is often a sign of Memory leakage. It is possible that the application uses too much memory. At this time, you cannot increase the number of JVM heaps, you cannot change your program to reduce memory usage. However, in most cases, an outofmemoryerror is a sign of Memory leakage. One solution is to continue listening for GC activities and check whether the memory usage increases over time. If yes, there must be a memory leakage in the program.

　　Detailed output

There are many ways to monitor the activity of the garbage collector. Perhaps the most widely used is to run jvm with the:-xverbose: GC option, and then observe the output results for a period of time.

[Memory] 10.109-10.235: GC 65536 K-> 16788 K (65536 K), 126.000 MS

The value after the arrow (16788 K in this example) is the heap Usage After garbage collection.

　　Console

Observing these endless GC detailed statistical outputs is a very tedious task. Fortunately, there are some tools to do these tasks in place of us. The jrockit Management Console outputs the heap usage graphically. By observing images, we can easily observe whether the heap usage increases with time.

Figure 1. The jrockit Management Console

The management console can even be configured to send emails to you when the heap usage is faulty (or other events occur. This clearly makes it easier to monitor memory leakage.