When you think of JAVA, you know it has a virtual machine, so it can be cross-platform, written once, run anywhere. But how does it work? As a JAVA white, you don’t know!

Principle 2 Structure 1 Class loader 2 Execution engine 3 Runtime data areaCopy the code

The JVM implements the most important feature of the JAVA language: platform independence. How it works: Java programs are not executed directly on the operating system, but by the JVM. The JVM shields platform-specific information so that JAVA programs simply compile into object code (.class) that is suitable for the JVM and can run on the JVM, which is then responsible for interpreting the execution of platform-specific machine instructions. At the same time, the JVM also performs security checks and is the security checking engine for Java programs.

The JVM is made up of three parts:

Class loader 2. Execution engine 3. Runtime data areaCopy the code

1. The class loader simply loads the. Class file into the JVM and the program runs correctly. However, when the JVM starts up, it does not load all of the.class files at once. Instead, it loads them dynamically as needed.

The parent delegate model is used for class loading:

1) The current class loader first checks its own load list and returns it if it exists; 2) If not found, delegate the parent class loader to load; The parent class loader repeats action 1, recursing to the parent bootstrap ClassLoder. Bootstrap; 3) None, still loaded by the current class loader and included in its own cache.Copy the code

The parental delegation model is used to better ensure the security of the Java platform. By security, we mean that Java’s core classes are not replaced by user-written classes. Because the core classes are loaded at vm initialization and are checked for existence each time a class is loaded, you can avoid replacing the core classes.

Various class loaders:



Bootstrap class loader: the parent class

This class loader is created when the Java virtual machine is running and is responsible for loading the core libraries of the virtual machine, such as java.lang.*. For example, java.lang.Object is loaded by the root class loader. Note that the classloader is not written in the Java language, but in C/C++.

Extension Class Loader: This loader loads Extension classes beyond the base API.

AppClass Loader (SystemAppClass) : loads application programs and programmer – defined classes.

2. The function of the execution engine: execute Java compiled bytecode, or execute native methods

The JVM Runtime Area (JVM Runtime Area) refers to the memory space allocated by the JVM during Runtime. At runtime, the JVM divides the data into six regions for storage:

Program Counter (PC) Register: Java Virtual Machine Stacks stack Memory: Method Area: Method area run-time Constant Pool Native Method StacksCopy the code

All the programs we write are loaded here and stored in different categories

Heap memory Java virtual machine stack local method stack program counter method areaCopy the code

1) Understand the Java Runtime Area from a threading perspective

A. Thread private: program counter Java virtual machine stack local method stack, life cycle consistent with thread;

These three memory areas do not require garbage collection. Because their life cycle is synchronized with the thread, their memory is automatically released as the thread is destroyed.

B. Thread sharing: heap memory, method area, runtime constant pool, lifetime consistent with JVM.

The method area and heap memory need to be garbage collected for objects that do not have any references.

2) Understand the Java Runtime Area from the storage contents

The method area and constant pool store information about the class

Heap memory stores object information

Program counters, Java virtual machine stacks, and local method stacks store thread information

3) The heap memory, method area, and runtime constant method area are used to store the structure information of Java classes. When we create an object instance, the object type information is stored in the method area, and the instance data is stored in the heap memory.

The runtime constant pool is part of the method area and is therefore shared globally. It is used to store symbolic information in the constant pool of Java class files.

A constant pool (non-runtime constant pool) exists in the class file, which is determined at compile time; The JVM specification has a strict specification for class file structures, and class files that conform to this specification must be accepted and loaded by the JVM.

The runtime constant pool holds symbolic references described in class files, as well as direct references translated from these symbolic references.

The Runtime constant pool is dynamic compared to the Class constant pool. The Java specification does not require that constants be generated only at runtime. That is to say, the contents of the runtime constant pool do not come from the Class constant pool, and the class constant pool is not the only data input of the runtime constant pool. Constants can be generated at run time through code and put into a pool of runtime constants.

As with the method area, OutOfMemoryError is thrown when the run-time constant pool cannot claim new memory.

Direct Memory is not the Memory managed by the JVM, but the machine Memory outside the JVM. For example, if you have 4 gigabytes of memory and the JVM takes up 1 gigabyte, the remaining 3 gigabytes are direct memory.

In the JDK, there is a Channel – and buffer-based memory allocation. Native libraries implemented by C are allocated in direct memory and referenced by DirectByteBuffers stored in the JVM heap. OutOfMemoryError exceptions may also occur because the direct memory is limited to the memory of the machine.