Runtime data area-method area
Preface
The method area is the last part of the runtime data area.
From the perspective of thread sharing:
ThreadLocal: How to ensure the safety of multiple threads in a concurrent environment? Typical scenarios are database connection management and session management.
Interaction between stack, heap, and method area
The following involves the access location of the object:
- The .class information of the Person class is stored in the method area;
- The person variable is stored in the local variable table of the Java stack;
- The real person object is stored in the Java heap;
- In the person object, there is a pointer to the person type data in the method area, indicating that the person object is new from the Person class in the method area.
Understanding of the method area
Official document: https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-2.html#jvms-2.5.4
Where is the method area:
- The "Java Virtual Machine Specification" clearly states: Although all method areas are logically part of the heap, some simple implementations may not choose to perform garbage collection or compression. But for HotSpot JVM, the method area also has an alias called Non-Heap (non-heap), the purpose is to separate from the heap.
- Therefore, the method area can be regarded as a memory space independent of the Java heap .
The basic understanding of the method area : The method area mainly stores the Class, and the heap mainly stores the instantiated objects. - The Method Area, like the Java heap, is a memory area shared by all threads. When multiple threads load a single class at the same time, only one thread can load the class, and other threads can only wait for the thread to finish loading, and then use the class directly, that is, the class can only be loaded once.
- The method area is created when the JVM starts, and its actual physical memory space can be discontinuous like the Java heap area.
- The size of the method area, the same as the heap space, can be fixed or expandable.
- The size of the method area determines how many classes the system can save. If the system defines too many classes and the method area overflows, the virtual machine will also throw a memory overflow error: java.lang.OutofMemoryError: PermGen space or java.lang. OutOfMemoryError: Metaspace. The following situations can cause memory overflow errors:
(1) Load a large number of third-party jar packages;
(2) Too many projects for Tomcat deployment (30-50);
(3) A large number of dynamic reflection classes are generated. - Closing the JVM will release the memory in this area.
for example:
public class MethodAreaDemo {
public static void main(String[] args) {
System.out.println("start...");
try {
Thread.sleep(1000000);
} catch (InterruptedException e) {
e.printStackTrace();
}
System.out.println("end...");
}
}
The above simple program loads more than 2000 classes! !
HotSpot method area evolution
- In JDK7 and before, it is customary to call the method area the permanent generation. Starting from JDK8, the permanent generation has been replaced by metaspace. We can compare the method area to the interface in Java, and the permanent generation or metaspace to the specific implementation class in Java;
- In essence, the method area and the permanent generation are not equivalent. Only for Hotspot can be regarded as equivalent. The "Java Virtual Machine Specification" does not make uniform requirements on how to implement the method area. For example: there is no concept of permanent generation in BEAJRockit/IBM J9;
- In JDK8, the concept of permanent generation was finally completely abandoned, and replaced with Metaspace, which is implemented in local memory like JRockit and J9;
- The nature of the metaspace is similar to the permanent generation, and both are the realization of the method area in the JVM specification. However, the biggest difference between metaspace and permanent generation is that metaspace is not in the memory set by the virtual machine, but uses local memory ;
- Both the permanent generation and the metaspace have not only changed their names, but also adjusted their internal structure;
- According to the "Java Virtual Machine Specification", if the method area cannot meet the new memory allocation requirements, an OOM exception will be thrown.
Setting method area size and OOM
The size of the method area does not need to be fixed, the JVM can dynamically adjust it according to the needs of the application.
JDK7 and before (permanent generation):
- Use -XX:Permsize to set the initial allocation space of the permanent generation. The default value is 20.75M;
- -XX:MaxPermsize to set the maximum allocable space of the permanent generation. The default is 64M for 32-bit machines, and 82M for 64-bit machines;
- When the capacity of the class information loaded by the JVM exceeds this value, an exception OutofMemoryError: PermGen space will be reported.
JDK8 and later (meta space):
- The size of the metadata area can be specified with the parameters -XX:MetaspaceSize and -XX:MaxMetaspaceSize.
- The default value depends on the platform. Under Windows, -XX:MetaspaceSize is about 21M, and the value of -XX:MaxMetaspaceSize is -1, which means there is no limit.
- Unlike the permanent generation, if you do not specify the size, the virtual machine will use up all available system memory by default. If the metadata area overflows, the virtual machine will also throw the exception OutOfMemoryError: Metaspace.
- -XX:MetaspaceSize: Set the initial metaspace size. For a 64-bit server-side JVM, the default -XX:MetaspaceSize value is 21MB. This is the initial high water mark. Once this water mark is touched, Full GC will be triggered and unload useless classes (that is, the class loader corresponding to these classes is no longer alive), and then this high water mark will be reset. The value of the new high water mark depends on how much space is released after GC. If the released space is insufficient, increase the value appropriately when it does not exceed MaxMetaspaceSize. If the free space is too much, lower the value appropriately.
- If the initialized high-water mark is set too low, the above-mentioned high-water mark adjustment will happen many times. Through the log of the garbage collector, it can be observed that Full GC is called multiple times. In order to avoid frequent GC, it is recommended to set -XX:MetaspaceSize to a relatively high value.
Method area OOM
Code sample: OOMTest class inherits the ClassLoader class and obtains the defineClass() method, which can load the class by itself.
/**
* jdk6/7中：
* -XX:PermSize=10m -XX:MaxPermSize=10m
*
* jdk8中：
* -XX:MetaspaceSize=10m -XX:MaxMetaspaceSize=10m
*
*/
public class OOMTest extends ClassLoader {
public static void main(String[] args) {
int j = 0;
try {
OOMTest test = new OOMTest();
for (int i = 0; i < 10000; i++) {
//创建ClassWriter对象，用于生成类的二进制字节码
ClassWriter classWriter = new ClassWriter(0);
//指明版本号，修饰符，类名，包名，父类，接口
classWriter.visit(Opcodes.V1_8, Opcodes.ACC_PUBLIC, "Class" + i, null, "java/lang/Object", null);
//返回byte[]
byte[] code = classWriter.toByteArray();
//类的加载
test.defineClass("Class" + i, code, 0, code.length);//Class对象
j++;
}
} finally {
System.out.println(j);
}
}
}
Do not set the upper limit of the metaspace: use the default JVM parameters, and do not set the upper limit for the metaspace.
Output result:
10000
Set the upper limit of the meta space: Parameters: -XX:MetaspaceSize=10m -XX:MaxMetaspaceSize=10m
Output result:
8531
Exception in thread "main" java.lang.OutOfMemoryError: Metaspace
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:763)
at java.lang.ClassLoader.defineClass(ClassLoader.java:642)
at com.heu.method.OOMTest.main(OOMTest.java:29)
How to solve OOM
This is a tuning issue, let’s briefly talk about it here.
- To solve the OOM or heap space anomaly, the general method is to first analyze the heap dump snapshot from the dump through a memory image analysis tool (such as Ec1ipse MemoryAnalyzer). The focus is to confirm whether the objects in the memory are necessary, that is, We must first distinguish whether there is a memory leak (Memory Leak) or a memory overflow (Memory Overflow);
- Memory leak is that there are a large number of references to certain objects, but these objects will not be used in the future, but because they are still associated with GC ROOT, these objects will not be recycled in the future. This is the problem of memory leaks;
- If it is a memory leak, you can further check the reference chain of the leaked object to the GC Roots through the tool. Then you can find out how the leaked objects are related to GC Roots and cause the garbage collector to be unable to automatically collect them. Knowing the type information of the leaked object and the information of the GCRoots reference chain, you can locate the location of the leaked code more accurately.
- If there is no memory leak, in other words all objects in the memory must still be alive, then the heap parameters of the virtual machine (-Xmx and -Xms) should be checked and compared with the physical memory of the machine to see if it can be increased. From the code, check whether there are some objects with too long life cycle and holding state for too long, and try to reduce the memory consumption during the running of the program.