Atitit. Improved stability ----- Analysis of Memory leakage PermGen OOM and solutions... java, permgen... java
Atitit. Improved stability ----- Analysis of Memory leakage PermGen OOM and solutions... java
1. Division of memory areas 1
2. PermGen memory overflow in-depth analysis 1
3. PermGen OOM reason summary 2
4. Summary of the possibility of common class loaders and type uninstallation 2
5. Countermeasures for PermGen memory overflow 3
6. The second method is to use bea jdk of oracle, because the JVM in this example does not have PermGen space 3
7. Reference 3
1. Division of memory areas
Java Memory leakage can be divided:
1 heap memory leakage: everyone is familiar
2 stack memory leakage: excessive information such as intermediate variables maintained during the running of the current thread, for example, stack over flow caused by common endless Loops
3. Memory leakage in the Method Area (permanent heap): there are few articles to analyze the cause, which is the focus of this article.
Author: old wow's paw Attilax iron, EMAIL: 1466519819@qq.com
Reprinted please indicate Source: http://blog.csdn.net/attilax
2. In-depth analysis of PermGen memory overflow
In this section, we will first explain the necessary prerequisites, which will pave the way for understanding the subsequent testing procedures.
Prerequisites
4. The types loaded by different classloaders can be equivalent to completely different types, even if different instances of the same type are loaded, all resources are allocated in the PermGen area to store type information.
5. When a new type is loaded, a space will be requested in the PermGen area to store the type information. After the type is detached, the garbage collection in the PermGen area will release the corresponding memory space. The PermGen area is the same as the normal heap space and also follows the garbage collection rule. Therefore, it is incorrect to say that the space size of the PermGen area is only increased or decreased on the Internet, the corresponding test code will be used for verification and analysis later.
6. the precondition for a type to be detached is that the instance that loads this type of Class Loader becomes unreachable,
7. Based on the preceding [Introduction to the Virtual Machine runtime data zone |], we can conclude that the common instance and java corresponding to the type. lang. if one or more of the Class instances and ClassLoader instances of this type are in the reachable state, this type cannot be detached.
8. The JMX protocol provides corresponding APIs to query the memory usage, type loading, and other information of the current Virtual Machine instance at runtime. This is also the basis of many Java performance monitoring and analysis tools, and the corresponding code in the subsequent test programs also uses the JMX protocol.
9
3. PermGen OOM reason Summary
Through the above test program analysis, we found that the cause of the PermGen OOM is directly related to the type loading and type Unloading. We can summarize the cause of the PermGen OOM as follows:
10 The heap space allocated for the PermGen area is too small. You can set the-XX: PermSize parameter and-XX: MaxPermSize parameter reasonably.
The 11th type of unmount is not timely, and the obsolete type information occupies space. We may call it a "permanent Heap" Memory leakage, you need to analyze the principle of Type detaching in depth to find corresponding preventive measures.
4. Summary of common classloaders and possible types for uninstallation
Through the previous discussion, we know that if a Class Loader instance is not in the unreachable status, this type will not be uninstalled and this type will not be uninstalled, the heap memory occupied by the corresponding type information in the PermGen region will not be released. Next, for typical Java application categories, we will analyze the possibility that the types loaded by common class loaders will be downloaded.
System Class Loader: responsible for loading the types above the program class path. The types loaded by the class cannot be uninstalled during the entire program running, the heap space in the PermGen region occupied by the corresponding type information is basically impossible to be released.
User-Defined Class Loader: it is easier to control the loading type that meets the type unload requirement. As long as its instance is in the unreachable status, its loading type will be uninstalled, the space occupied by the PermGen area is also released.
5. Countermeasures for PermGen memory overflow
Through the above PermGen OOM cause analysis, it is not difficult to see the corresponding countermeasures:
12 reasonably set the-XX: PermSize and-XX: MaxPermSize parameters (main effective measures)
13. An effective mechanism for uninstalling Virtual Machine types (program tuning)
6. The second method is to use bea jdk of oracle, because the JVM in this example does not have the PermGen space
So there is no such overflow problem. However, jrockit consumes a lot of resources.
Resources, so I only recommend that you use them in the production environment, and the development environment is relatively less than sun.
From this perspective, sun jvm cannot dynamically increase the PermGen space size.
7. Reference
PermGen OOM in-depth analysis of Java memory overflow-zhu xing-blog .htm
Java 8 new feature inquiry (9) Say goodbye to OOM: Permgen-Cool. htm