What is the method area?
After understanding the program counter, virtual machine stack, local method stack and heap in the JVM memory structure, there is the last memory structure - the method area.
The method area is related to the method of our class from the name. It is true, but it is not a complete overview. The definition of the method area has its own advantages, but it is defined in the JVM specification.
From its definition, it can be obtained first that the method area is an area shared by all threads. Secondly, information related to the class structure (runtime constant pool) is stored in the method area, including member variables, method data, member methods, and code parts of construction methods.
The method area is created when the virtual machine starts, and it is logically a part of the heap. The method area is just a concept, not a specific implementation. The specific content of the method area is as follows:
In JDK1.6, the implementation of the method area uses a permanent generation implementation. In the permanent generation, class information can be stored, and there is another part of the class loader that is the runtime constant pool. There is a very important string pool in the constant pool. -StringTable. In 1.8, the implementation method of the method area using the permanent generation was abandoned, and it was implemented by a metaspace. The metaspace also contains class information, class loaders, and constant pools. At this time, the method area no longer occupies heap memory. In other words, the memory structure of the method area is not managed by the JVM at this time. It has been moved out to the local memory. The so-called local memory is the memory of the operating system. In 1.8, StringTable is no longer in the method area, but in the heap. .
Memory overflow problem in method area
The method area is to store the structural data of the class. When there are too many classes loaded, OutOfMemoryError will appear, that is, memory overflow. In version 1.8, because the metaspace is directly used by the operating system memory, and the memory of the operating system is generally 4G, 8G, 16G, so memory overflow is rare, but if you set the parameters of the virtual machine: -XX:MaxMetaspacesize+size , you can simulate the problem of memory overflow. Before 1.8, there was also a problem of memory overflow due to the size of the permanent generation space. You can also simulate the problem of memory overflow by setting the virtual machine parameter: -XX:MaxPermSize+size.
Nowadays, our commonly used frameworks, Spring and Mybatis, will generate a large number of classes at runtime. Before 1.8, it is easy to cause insufficient permanent generation space. After 1.8, because the metaspace uses system memory, it is relatively more abundant. Moreover, the garbage collection mechanism is also managed by the metaspace itself, which is not as inefficient as the permanent generation garbage collection.