Shulou(Shulou.com)06/02 Report--

What this article shares with you is an example analysis of JAVA memory leaks. The editor thinks it is very practical, so I share it with you to learn. I hope you can get something after reading this article.

Java memory leak is a problem that every Java programmer will encounter, the program runs normally locally, but when deployed to the remote end, there will be unlimited memory growth, and finally the system will be paralyzed, so how to test the stability of the program the fastest and best to prevent the system from collapsing? the author uses his own experience to share solutions to these problems with netizens.

As one of the most popular programming languages of Internet, Java is now very popular. Our network application is mainly developed in Java language, which is generally divided into three levels: client, server and database. In the process of testing, we found that there is a program module system memory and CPU resource consumption increased sharply, continued to grow until the emergence of java.lang.OutOfMemoryError. After analysis, Java memory leakage is the main factor that destroys the system. Here to share with you in the development process encountered in the Java memory leak detection and processing process.

one。 How Java manages memory

To determine if there is a memory leak in Java, we must first understand how Java manages memory. The memory management of Java is the problem of object allocation and release. In Java, the allocation of memory is done by the program, and the release of memory is done by the garbage collector (Garbage Collection,GC). Programmers do not need to call functions to free memory, but it can only reclaim space occupied by objects that are useless and no longer referenced by other objects.

Java's memory garbage collection mechanism starts from the main running object of the program to check the reference chain, and when traversing it, it is found that the isolated objects that are not referenced are treated as garbage collection. In order to release objects correctly, GC must monitor the running status of each object, including object application, reference, referenced, assignment and so on. GC needs to monitor. The purpose of monitoring the state of the object is to release the object in a more accurate and timely manner, and the fundamental principle of releasing the object is that the object is no longer referenced.

In Java, these useless objects are recycled by GC, so programmers do not need to consider this part of the memory leak. Although we have several functions that can access GC, such as the function System.gc () that runs GC, according to the Java language specification, this function does not guarantee that JVM's garbage collector will execute. Because different JVM implementers may use different algorithms to manage GC. Generally, threads in GC have a lower priority. There are also many strategies for JVM to call GC. Some start to work when memory usage reaches a certain level, some are executed regularly, some are slow execution of GC, and some are interrupted execution of GC. But generally speaking, we don't need to care about that.

one。 What is a memory leak in Java

The main reason for the memory leak is that the memory space was previously applied for and forgot to release. If there are references to useless objects in the program, those objects will reside in memory and consume memory because the garbage collector GC cannot verify that these objects are no longer needed. If there is a reference to an object, the object is defined as a "valid activity" and will not be released. To make sure that the memory occupied by the object will be reclaimed, we must make sure that the object will no longer be used. Typically, set the object data member to null or remove the object from the collection. However, when local variables are not needed, it does not need to be explicitly set to null, because these references are automatically cleaned up when a method is executed.

In Java, a memory leak means that there are some allocated objects, which have the following two characteristics: first, these objects are referenced, that is, in a directed tree, there is a tree path that can be connected to them; second, these objects are useless, that is, the program will never use these objects again. If the objects meet these two conditions, the objects can be determined as memory leaks in Java, these objects will not be recycled by GC, but it takes up memory.

To quote a common example, in the following code, the Object object is looped and put into a Vector. If only the object itself is released, but because the Vector still references the object, the object is not recyclable to GC. Therefore, if an object has to be deleted from the Vector after it has been added to the Vector, the easiest way is to set the Vector object to null.

Vector v = new Vector (10)

For (int I = 1; I < 100; iTunes +)

. {

Object o = new Object ()

V.add (o)

O = null

} / / at this point, none of the Object objects are released because the variable v refers to them.

In fact, these objects are already useless, but there is nothing GC can do when they are referenced (in fact, GC thinks it is still useful), which is the most important cause of memory leaks. Another example is cited to illustrate the memory leak of Java. Suppose you have a log class Logger that provides a static log (String msg), and any other class can call Logger.Log (message) to log the contents of message to the log file of the system.

The Logger class has a static variable temp of type HashMap. Each time you execute log (message), the value of message is first written to temp (with the current thread + current time as the key), and entries with the current thread and current time as keys are deleted from the temp before exiting. Note that the current time here is constantly changing, so the fact that log deletes an entry before exiting does not delete the entry that was written at the beginning of execution. In this way, any string passed as an argument to log cannot be recycled because it is referenced by the static variable temp of Logger, and this kind of object persistence is what we call a Java memory leak.

In general, the main cause of memory leaks in memory management: object references that are retained but never used again.

three。 Several typical memory leaks

We know that memory leaks do exist in Java, so let's take a look at several typical leaks and find out why and how to solve them.

3.1 Global Collection

It is common for large applications to have a variety of global data warehouses, such as a JNDI-tree or a session table. In these cases, care must be taken to manage the size of the repository. There must be some mechanism to remove data from the repository that is no longer needed.

There are usually many different forms of solution, the most common of which is a periodic cleanup job. This job validates the data in the warehouse and clears all unnecessary data.

Another way to manage the repository is to use reverse link (referrer) counting. The collection is then responsible for counting the number of backlinks for each entry in the collection. This requires a backlink to tell the collection when to exit the entry. When the number of backlinks is 00:00, the element can be removed from the collection.

3.2 cach

Caching is a data structure used to quickly find the results of operations that have been performed. Therefore, if an operation requires more resources to execute and will be used multiple times, it is common practice to cache the results of commonly used input data operations so that the cached data can be used the next time the operation is called. Caching is usually implemented dynamically, and memory overflow will occur if the cache is not set correctly and a large number of caches are used, so the amount of memory used needs to be balanced with the speed at which data is retrieved.

A common solution is to use the java.lang.ref.SoftReference class to insist on caching objects. This method ensures that references to these objects can be released when the virtual machine runs out of memory or needs more heap.

Class 3.3 loader

The use of Java class loaders provides many opportunities for memory leaks. Generally speaking, class loaders have a complex structure, because class loaders are related not only to "regular" object references, but also to references within objects. Such as data variables, methods and categories. This means that as long as there are classloaders for data variables, methods, various classes, and objects, the classloader will reside in JVM. Since class loaders can be associated with many classes as well as static data variables, a considerable amount of memory may leak.

four。 How to detect and handle memory leaks

There are generally two steps to find out the causes of memory leaks: the first is to arrange experienced programmers to check and analyze the code to find out the location of memory leaks; the second is to use special memory leak testing tools for testing.

In the first step, in the work of code inspection, developers who are familiar with the system business and development language tools can be arranged to cross-check the application code. try to find out the fault codes in the code, such as database connection declaration, result set not closed, code redundancy and so on.

The second step is to detect memory leaks in Java. Here we usually use some tools to check for memory leaks in Java programs. There are several professional tools on the market to check Java memory leaks, and their basic working principles are more or less the same. They all count, analyze and visualize all the information of memory management by monitoring the application and release of all objects when the Java program is running. The developer will use this information to determine whether the program has a memory leak. These tools include Optimizeit Profiler,JProbe Profiler,JinSight, Purify of Rational and so on.

4.1 detect the presence of memory leaks

Here we will briefly describe the process we are using to check with Optimizeit. Usually after knowing that a memory leak has occurred, the first step is to figure out what data was leaked and which class of objects caused the leak.

Generally speaking, the memory usage of a normal system is basically stable after its operation is stable, and it should not grow indefinitely. Similarly, there is a relatively stable upper limit on the number of objects in any class, which should not continue to grow. According to this basic assumption, we continuously observe the amount of memory used by the system and the number of instances. If the memory size continues to grow, there is a memory leak in the system. If the number of instance objects of a particular class increases over time (the so-called "growth rate"), it means that there may be leaks in the instances of this class.

On the other hand, the first sign of a memory leak that usually occurs is the presence of OutOfMemoryError in the application. In this case, you need to use some less expensive tools to monitor and find memory leaks. Although it is possible that the OutOfMemoryError application is actually using so much memory, in this case you can increase the number of heaps available to JVM, or make some change to the application so that it uses less memory.

However, in many cases, OutOfMemoryError is a sign of a memory leak. One way to find out is to continuously monitor GC activity to determine if memory usage increases over time. If so, a memory leak may have occurred.

4.2 ways to deal with memory leaks

Once you know that a memory leak has occurred, you need more professional tools to find out why it happened. JVM won't tell you himself. These professional tools basically have two ways to get memory system information from JVM: JVMTI and bytecode technology (byte code instrumentation). The Java virtual machine tool interface (Java Virtual Machine Tools Interface,JVMTI) and its predecessor, the Java virtual machine monitor interface (Java Virtual Machine Profiling Interface,JVMPI), are standardized interfaces for external tools to communicate with JVM and collect information from JVM. Bytecode technology refers to the technology that uses detectors to process bytecode to obtain the information needed by the tool.

Optimizeit is a product of Borland, which is mainly used to assist in code optimization and fault diagnosis of software systems, and Optimizeit Profiler is mainly used to analyze memory leaks. The heap view of Profiler is used to observe the amount of memory used by the system to run and the number of instances allocated for each class.

First, Profiler does trend analysis to find out which class's objects are leaking. The system can get four memory snapshots after running for a long time. Based on a comprehensive analysis of the four memory snapshots, if the memory usage of each snapshot is higher than that of the previous one, it can be determined that there is a memory leak in the system and find out the classes in which the number of instances keeps growing in the four snapshots. These classes can be initially identified as leaks. Through data collection and preliminary analysis, we can draw a preliminary conclusion: whether there is a memory leak in the system and which objects are leaked (leaked).

Next, see what other classes are associated with the objects of the leaked class. As mentioned earlier, memory leaks in Java are useless object persistence, simply because coding errors lead to the existence of a reference chain that should not exist (thus preventing referenced objects from being released), so the task of memory leak analysis is to find this redundant reference chain and find out why it is formed. It is useful to see where objects are assigned. At the same time, it is not enough to know how they relate to other objects (that is, which objects reference them), and information about where they are created is also useful.

Finally, take a closer look at individual objects to see how they relate to each other. With the Profiler tool, code in an application can be dynamically added at allocation time to create a stack trace. There is also a dynamic stack trace for all object allocations in the system. These stack traces can be accumulated and analyzed in the tool. For each leaked instance object, there must be a reference chain from a towed object to that object. After being ejected from the stack, the traction object in the stack space loses its traction ability and becomes a non-traction object. Therefore, after running for a long time, the leaked objects are basically pulled by the traction objects as static variables of the class.

In a word, although Java has the function of automatically reclaiming management memory, memory leakage can not be ignored, and it is often an important factor to destroy the stability of the system.

The above is the example analysis of JAVA memory leak, and the editor believes that there are some knowledge points that we may see or use in our daily work. I hope you can learn more from this article. For more details, please follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.