Atitit. Improving stability-----Analyzing memory leaks PermGen oom and the solution ... Java

Atitit. Improved stability ----- Analyzing memory leaks PermGen oom and the solution ... Java

1. Partitioning of memory Area 1

2. PermGen Memory overflow in-depth analysis 1

3. PermGen OOM Reason summary 2

4. Summary of common ClassLoader and type offload possibilities 2

5. PermGen Memory Overflow Response 3

6. The second is to use Oracle 's BEA JDK, because the JVM in this is not PermGen space 3

7. Reference 3

1. Partitioning of memory areas

The memory leaks in Java are basically divided into areas of memory:

1 Heap memory leaks: We're all familiar.

2 stack memory leak: Too much information such as intermediate variables maintained during the current thread's run, such as a common dead loop that causes stack over flow

3 Method Area (permanent heap) memory leak: Analysis of the reasons for the article less, the focus of this article.

Author :: old Wow's paw attilax Ayron, email:[email protected]

Reprint please indicate source: Http://blog.csdn.net/attilax

2. PermGenmemory overflow in-depth analysis

In this section, first to explain the necessary prerequisite knowledge, which also for the understanding of the following test procedures to pave the way.

Prerequisite knowledge

4 Types loaded by different class loader instances can be equivalent to completely different types, even when different instances of the same type ClassLoader are loaded, allocating the appropriate space in the PermGen area to store type information

5 When a new type is loaded, the appropriate space is requested in the PermGen area to store the type information, and the garbage collection on the PermGen area frees the corresponding memory space after the type is unloaded. PermGen area and ordinary heap space, but also follow the law of garbage collection, so, a lot of information on the web about the size of the PermGen area space is not correct, the following will be used to verify and analyze the corresponding test code.

61 types are unloaded if the ClassLoader instance of this type is loaded into an unreachable (unreachable) state,

7 combined with the above [Virtual Runtime data area of the introduction |], you can conclude: the type corresponding to the ordinary instance, the type corresponding to the Java.lang.Class instance, loading this type of ClassLoader instance, any one or more of the three is reachable state, Then this type cannot be uninstalled.

The 8 JMX protocol provides a corresponding API interface for querying the memory usage and type loading information of the current virtual machine instance at run time. This is also the basis for many Java performance monitoring and analysis tools, and the corresponding code in the later test programs uses the JMX protocol.

9

3. PermGen OOMSummary of Causes

Through the above test program analysis, we found that PermGen oom occurred in the reason and type loading, type unloading has a direct relationship to the cause of PermGen oom to do the following general summary:

10 The heap space allocated for the PermGen area is too small and can be resolved by reasonable setting of-xx:permsize parameters and-xx:maxpermsize parameters.

11 type unloading is not timely, outdated invalid type information takes up space, we might call it a "permanent heap" of memory leaks, we need to drill down into the principle of type unloading to find the corresponding precautions

4. Summary of common class loaders and types of uninstallation possibilities

From the previous discussion, we know that if loading a class loader instance of a type is not in the unreachable state, then the type will not be unloaded and the type will not be unloaded, and the heap memory occupied by the corresponding type information in the PermGen zone will not be freed. Below, for a typical Java application classification, analyze the possibility that the types loaded by the common ClassLoader are downloaded.

System ClassLoader: The type that is responsible for loading the program class path, the type that is loaded by it is basically impossible to unload during the whole program running, the PermGen area heap space that the corresponding type information occupies is basically impossible to be released.
User-defined ClassLoader: for the type it loads, the likelihood of satisfying type unloading requirements is more manageable, as long as its instance itself is in the unreachable state, its loaded type is unloaded, and the corresponding space occupancy in the PermGen area is released.

5. PermGenMemory Overflow response measures

Through the analysis of the reasons for PermGen oom above, it is not difficult to see the corresponding response measures:

12 reasonable setting of-xx:permsize and-xx:maxpermsize parameters (main effective measures)

13 Effective utilization of virtual machine type offload mechanisms (tuning for programs)

6. The second is the use ofOracleof theBEA JDK, because the inside of theJVMNoPermGen Space

Such an area, so there is no such overflow problem. But because JRockit consumes more

Resources, so I only recommend the use of the production environment, the development environment or Sun's comparative province.

From this point of view, the Sun JVM does not dynamically increase the size of the PermGen space

7. Reference

Java Memory Overflow PermGen OOM in- depth analysis -Zhu Xing- Blog Park . htm

Explore the new features of Java 8 (ix) with OOM:permgen say goodbye - push cool . htm

Atitit. Improving stability-----Analyzing memory leaks PermGen oom and the solution ... Java