Describe your understanding of the evolution process and internal structure of the method area

We've known before “ Run time data area ” The program counter of 、 Virtual machine stack 、 Local method stack and heap space , Today, let's take a look at the last module —— Method area .

brief introduction

Memory allocation diagram when creating objects

《Java Virtual machine specification 》 It is clearly stated in ：“ Although all method areas are logically part of the heap , But some simple implementations may not choose to do garbage collection or compression .”

although  Java  The virtual machine specification describes the method area as a logical part of the heap , But it has an alias called  Non-Heap（ Non heap ）, The purpose should be with  Java  Heap differentiation . therefore , The method area can be seen as a piece of

Independent

On  Java  Heap memory space .

Methods area and  Java  Pile up , Is an area of memory Shared by each thread . Methods in  JVM  It will be created at startup , And its actual physical memory space can

Discontinuous

Of , close  JVM  This will free the memory in this area .

Forever 、 Meta space

《java Virtual machine specification 》 How to implement the method area , No unified requirements . for example ：BEA JRockit/IBM J9  There's no concept of permanent generation in this . And for  HotSpot  Come on , stay  jdk7  And before , Traditionally, the implementation of the method area is called

Forever

, And from  jdk8  Start , Use

Meta space

Replaced the permanent generation .

The method area is  Java  Concepts in the virtual machine specification , The permanent generation and meta space are  HotSpot  An implementation of virtual machine to method area . Popular point ： If you compare a method area to an interface , The permanent generation and meta space can be compared to the implementation class that implements the interface .

Direct memory

Forever 、 Meta space is not just a name change , The internal structure has also been adjusted . The permanent substitute is  JVM  Of memory , Meta space uses local direct memory .

Direct memory is not  JVM  Part of the runtime data area , Therefore, it will not be affected by  Java  Pile limits . However, it is limited by the total memory size of the machine and the addressing space of the processor , So if this part of memory is also used frequently , It will still lead to  OOM  The appearance of mistakes .

The size of the method area

The size of the method area can be set , You can choose fixed size or expand .

jdk7  And before

-XX:PermSize=N // Method area  ( Forever )  Initial allocation space , The default value is  20.75M
-XX:MaxPermSize=N // Method area  ( Forever )  Maximum allocable space .32 Bit machine default is 64M,64 Bit machine default is 82M


jdk8 And later

The default is platform dependent ,windows Next ：

-XX:MetaspaceSize=N // Method area  ( Meta space )  Initial allocation space , If this flag is not specified , Then the meta space will be dynamically resized according to the application requirements of the runtime .
-XX:MaxMetaspaceSize=N // Method area  ( Meta space )  Maximum allocable space , The default value is  -1, There is no limit


A big difference from the permanent generation is , If you don't specify the size , With the creation of more classes , The virtual machine runs out of all available system memory .

The size of the method area determines how many classes the system can hold , If the system defines too many classes , such as ： Load a large number of third parties  jar  package 、Tomcat  Too many projects deployed 、 A large number of dynamically generated reflection classes will lead to method area overflow , Throw a memory overflow error .

• Forever ：OutOfMemoryError:PermGen space

• Meta space ：OutOfMemoryError:Metaspace

As for how to solve  OOM  abnormal , It will be explained in a later article ！

jvisualvm

We can go through  JDK  Self contained  

jvisualvm

  Tool to view the class file loaded by the program ：

example

public class MethodAreaDemo1 {
 public static void main(String[] args) {
 System.out.println("start...");
 try {
 Thread.sleep(1000000);
 } catch (InterruptedException e) {
 e.printStackTrace();
 }
 System.out.println("end...");
 }
}


Run the program , You can see that a simple program needs to load so many class files .

High water level

For one 64 Bit of the server side  JVM  Come on ,

XX：MetaspaceSize=21

  Is the initial high water mark , Once you touch this water line ,Full GC  Will trigger and unload useless classes （ That is, the class loaders corresponding to these classes no longer exist ）, Then this high water mark will reset .

The value of the new high water mark depends on  GC  How much meta space has been released after ：

• If you don't have enough free space , Then not more than  MaxMetaspaceSize  when , Increase the value properly ;

• If you release too much space , Then lower the value appropriately .

If the initial high water mark is set too low , High water mark adjustment can occur many times . You can see from the garbage collector's log that  Full GC  Multiple calls . To avoid frequent GC, It is suggested that  

-XX ：MetaspaceSize

  Set to a relatively high value .

internal structure

《 In depth understanding of Java virtual machine 》 The storage content of the method area in the book is described as follows ： It is used to store type information that has been loaded by the virtual machine 、 Constant 、 Static variables 、 Just in time compiler compiled code cache and so on . Next, let's take a look at its internal structure .

Type information

For each type of load （  class  class、 Interface  interface、 enumeration  enum、 annotation  annotation）,JVM  The following types of information must be stored in the method area ：

• The full valid name of this type （ full name = Package name . Class name ）

• The fully valid name of the direct parent of this type （ about  interface  or  java. lang.Object , None of them has a parent ）

• This type of modifier （ public , abstract, final  Some subset of ）

• This type of direct interface has a sequence table

Domain （Field） Information

• JVM All fields of type must be saved in the method area （field, Also known as attribute ） And the declaration order of the domain ;

• Domain related information includes ： Domain name 、  Domain type 、 Domain modifier （public, private,protected, static, final, volatile, transient  Some subset of ）

Method （Method） Information

JVM  The following information must be kept for all methods , As with domain information, it includes the order of declaration ：

• Method name

• Return type of method （ or void）

• Number and type of method parameters （ According to the order ）

• Method modifier （public, private, protected, static, final,synchronized, native , abstract  A subset of ）

• Bytecode of method （bytecodes）、 The stack of operands 、 Local variable table and size （ abstract  and  native  Methods except ）

• Anomaly table （ abstract  and  native  Methods except ） Where each exception begins 、 End position 、 The code deals with the offset address in the program counter 、 Constant pool index of the caught exception class

non-final  Class variables

• Static variables are associated with classes , Load as class loads , They become a logical part of class data

• Class variables are shared by all instances of the class , Even if there is no class instance, you can access it .

We can see through examples ：

public class MethodAreaDemo2 {
 public static void main(String[] args) {
 Order order = null;
 order.hello();
 System.out.println(order.count);
 }
}

class Order {
 public static int count = 1;
 public static final int number = 2;

 public static void hello() {
 System.out.println("hello!");
 }
}


The running result is ：

hello!
1


Can open  IDEA  Of  Terminal  window , stay  MethodAreaDemo2.class  Under the path , Input  

javap -v -p MethodAreaDemo2.class

  command

Through the picture, we can see that it is declared as  final  The processing method of class variables is different , Global constants are assigned at compile time .

Runtime constant pool

Speaking of the runtime constant pool , Let's first understand what a constant pool table is .

Constant pool table

A valid bytecode file contains the version information of the class 、 Field 、 Methods and interfaces , There's also one piece of information, which is the constant pool table （Constant Pool Table）, It stores

Quantity is worth

、

A string value

、

Class reference

、

Field reference

and

Method reference

.

Why do bytecode files need constant pools ？

java  Classes in the source file 、 Interface , After compilation, a bytecode file will be generated . Bytecode files need data support , Usually this kind of data is very big , So that it can't be stored directly in bytecode . Another way , You can point to these data

Symbol reference

Save to the constant pool of bytecode file , In this way, bytecode can be passed at run time by using only constant pool

Dynamic links

Find the appropriate data and use .

Runtime constant pool

Runtime constant pool （ 

Runtime Constant Pool

） Is part of the method area , Class loader loading bytecode file , Load the constant pool table into the runtime constant pool of the method area . The runtime constant pool contains many different constants , Including the literal values that have been defined at compile time , It also includes method or field references that can only be obtained after runtime parsing . This is no longer the symbolic address in the constant pool , Here it is

real

Address .

Runtime constant pool , be relative to  Class  Another important feature of the file constant pool is ： Be dynamic , such as  

String.intern()

.

Evolution details

Aiming at  

Hotspot

  Virtual machine ：

• jdk1.6  And before ： Yes
  Forever
   , Static variables are stored on permanent generations ;

• jdk1.7： Yes
  Forever
  , But gradually “ To the eternal generation ”, String constant pool 、 Static variable removal , Keep it in the pile ;

• jdk1.8 And after ：  There is no permanent generation , Type information 、 Field 、 Method 、 Constants are stored in local memory
  Meta space
  , But string constant pool 、 Static variables are still in the heap ;

Evolution example diagram

Why replace permanent substitution with meta space ?

• The permanent substitute is  JVM  Of memory , suffer  JVM  Set the memory size limit ; Meta space uses local direct memory , Its maximum allocable space is the available memory space of the system . Because what is stored in the meta space is class
  Metadata
  , So as the memory space increases , There are more classes that can be loaded , The corresponding overflow probability will be greatly reduced .

• stay  JDK8, Merge  HotSpot  and  JRockit  When the code ,JRockit  There has never been a thing called the permanent generation , After the merger, there is no need to set up such a permanent place .

• Tuning permanent generations is difficult .

StringTable  Why adjust

Because the recycling efficiency of permanent generation is very low , stay  full gc  It will trigger . and  full GC  It's the lack of space in the old days 、 It will only be triggered when the permanent generation is insufficient . And that leads to this

StringTable

  Recycling efficiency is not high . In our development, a lot of strings will be created , Recycling efficiency is low , Causes the permanent generation to run out of memory . Put it in the pile , Can reclaim memory in time .

Garbage collection

Relatively speaking , Garbage collection is relatively rare in this area , But it's not as soon as the data enters the method area “ Forever ” 了 . There are two parts of garbage collection in the method area ： Waste in the constant pool

Constant

And no longer used

type

.

The constant pool in the method area mainly stores literal and symbolic references ：

• The amount of words is close to  Java  The concept of constant at the language level , Such as text string 、 Be declared  final  Constant value of .

• Symbolic references are concepts of compilation principles , Include fully qualified names of classes and interfaces 、 Name and descriptor of the field 、 The name and descriptor of the method .

HotSpot  The constant pool recycling strategy of virtual machine is very clear , As long as the constants in the constant pool are not referenced anywhere , Can be recycled .

Type determination

Determine whether a constant is “ abandoned ” It's still relatively simple , To determine whether a type belongs to “ Classes that are no longer used ” The conditions are more stringent . The following three conditions need to be satisfied at the same time ：

• All of these
  example
  They have been recycled , That is to say  Java  There are no instances of this class and any of its derived subclasses in the heap ;

• Load the class
  Class loader
  Has been recovered , This condition is unless it is a well-designed alternative class loader scenario , Such as OSGi、JSP And so on , Otherwise, it's usually hard to achieve ;

• Corresponding to this class  java.lang.Class  The object is not referenced anywhere , The methods of the class cannot be accessed anywhere by reflection .

Java  The virtual machine is allowed to recycle useless classes that meet the above three conditions , This is just saying “ Allowed ”, Not like the object , If there is no reference, it will be recycled .

o  Q  Will continue to update  java  Practical articles , If you have a different opinion or a better one  idea, Welcome to contact ah  Q.

【 o  Q  Say code 】, Notable official account

The style of the article is changeable , The pictures are easy to understand , The story is vivid and interesting , Let's talk about technology ！