preface

Dear friends, I am Li Du, this is the sixth article about the JVM, the previous five articles about the JVM, are layer by layer with you to in-depth understanding of the JVM, the basic knowledge of the JVM has been explained.

This will be the final article on the JVM, both summarizing and adding to the points that haven’t been covered yet.

First, the opening article on the JVM, on how to read Into the THIRD Edition of the JVM virtual Machine: How to read into the Third Edition of the JVM in three days.

Then, a long time ago, I wrote a second article about the JVM’s runtime data area and GC algorithms: Still learning about the JVM? I’ve summed it up for you (with brain map).

This article is intended as a theoretical highlight, as it explores what the various parts of the JVM’s runtime data area do, as well as focusing on the JVM heap generation theory and the basic GC collection algorithm, all of which will serve as a foundation for subsequent Java heap tuning practices.

Then came the third and most important part of the tuning, which was about GC: Are you garbage? , how to determine whether an object is alive, and the types of common GC, the collocation of the young and old GC, the principle and characteristics of various GC, and the applicable scenarios, are all mentioned in this article.

With the run-time data section (part 2) and the GC rationale (part 3) in mind, then the JVM Tuning part (part 4) : JVM Tuning practical part I, this article is mainly around the JVM tuning practical tools, This includes the online Arthas tool, THE GUI tool (Visual VM), the memory analysis tool (MAT), and the original Linux commands JPS, jstack, jstat, jmap, jhat, etc.

After familiar with the JVM tuning tools, the fifth is the last practical tuning scenarios, cases, classic troubleshooting OOM, disk insufficient troubleshooting, CPU skyrocketing troubleshooting, deadlock troubleshooting, the purpose of tuning and theory has been tuning cases scenario analysis: JVM performance tuning actual battle (2)

Of these, the fifth is my longest, the most productive, and the most purposefully focused, learning about the JVM for tuning and getting a lot of attention from new readers.

So, read on in the order listed above to gain a deeper understanding of tuning techniques and theories.

Then, if you have the time, you can dig deep into The Third Edition of the JVM. Other books on the JVM I recommend: Java Virtual Machine Specifications, Garbage Collection Algorithm Manual: The Art of Automatic Memory Management, Virtual Machines: Versatile Platforms for System and Processes can be read by anyone with the time and ability.

Finally, this is the last and sixth article on what we need for the JVM, and one more piece is the classloading subsystem that we haven’t covered yet, so for the sake of the article’s completeness, this one is mostly theoretical, complementing the JVM’s classloading subsystem.

Overview of the class loading subsystem

First, let’s talk about the JVM’s classloading subsystem. We know that our code is typed as a.Java class and then compiled to a bytecode file of type.class.

These bytecode files of type.class are loaded into the MEMORY of the JVM by the classloading system for our use. These files are also known as metadata.

Here is a diagram of how a class is loaded by the classloading system.

In this way, a Java class comes through the above layers of the process to the virtual machine of our JVM, first in the loading process of the.class file can be derived from the following aspects:

  • From a system file, such as our locally compiled class.
  • Get it from the network
  • Or calculated at runtime, such as using dynamic proxy techniques, generated at runtime.
  • Or it can be generated by another file, such as a JSP that generates the corresponding class file.

After class loading is completed by our classloading subsystem, this information (including class information, constants, static variables, method information, etc.) is stored in the method area memory (JDK 7 and before, JDK 8 and above moved to meta space, local memory) and then executed by the JVM’s execution engine.

In this process class loading acts as a middleman so that the JVM’s execution engine can execute these classes:.class -> JVM -> metadata template -> instance object.

So how does the class loader, the protagonist of the process, work when the JVM loads a class? Let’s talk about class loaders.

Class loader

Classic classloaders in the JVM are divided into three layers:

  1. Start the class loader (BootStrap this) : the loader is implemented by c + +, load < JAVA_HOME > \ lib file, under this kind of loading up will not be used directly, by Java program the loader loads generally package called Java, javax.mail and sun at the beginning of class.
  2. Extension ClassLoader: The Extension ClassLoader loads resources in the

    \lib\ext directory. It can be used to extend Java SE functionality. If the JAR package created by the user is placed in this directory, it will be loaded by the Extension ClassLoader.
  3. Application ClassLoader: This is responsible for loading all classes on the user’s ClassPath. Developers can also use this ClassLoader directly in their code.

In addition to the classic three layers above, there is a User ClassLoader, which can load the classes it needs in the program, so the full JVM ClassLoader looks like this:

Their relationships are not inherited, but often duplicate the code of the parent class loader in a composite relationship.

Class loading process

After we understand all kinds of class loaders, the next step is to understand the class loading process in detail. A complete class loading process mainly includes the following stages: loading -> verification -> preparation -> parsing -> initialization.

The loading phase isThe binary byte flow of the class file is transferred to the method area of the runtime data area by the full class name of the class and then by the class loader.

In addition, a java.lang.Class object is generated in memory as an entry point for the various data of this Class.

The validation phase is to verify that the bytecode in the bytecode class file is a service specification and that the bytecode in the bytecode class file does not harm the JVM itself.

The preparation phase is both the allocation of memory for class variables in the class (static, but not with final) and the initialization of the zero value of class variables, not including instance variables, which are allocated in the Java heap along with the object.

A zero value is the default initial value for data, such as int 0, Boolean false, float 0.0f, and null for reference types.

The resolution phase is the process of replacing the symbolic reference to the constant pool within the virtual machine with a direct reference. A symbolic reference can be a literal in any form, as long as it is targeted; A direct reference can be a pointer to the target and a handle to the target that is indirectly located by the relative offset.

Finally, there is initialization, which is the last stage of class loading and the stage at which the Java Virtual Machine actually starts executing the Java program code in the class.

As mentioned above, the variable is initialized to zero once in the preparation phase, so the variable is initialized to its subjective value in the program code during this phase.

Interviewer: Do you know how Java classes work? Asked me a face meng

Principle of parental delegation

The parent delegate principle is a way of working before the various loaders in order to make class loading more efficient.

When a class loader I received the request of the class is loaded, don’t you try to load the class, but the load request entrusted to the parent class, if no parent is looking for top class loader directly, if a parent, and parent and the parent class loader, in turn up, until the above is all parent cannot be finished loading, will be to load, An exception is thrown if the load fails.

The nice thing about it is that when you load a class, you don’t have to load it again, and when the parent class has already been loaded, you don’t have to load it for a second year, so there’s only one copy in memory.

Let’s look at the source code for the parent delegate implementation, which is mainly implemented in the loadClass() method of the Java.lang.classLoader:

protected synchronized Class<? > loadClass(String name, Boolean resolve) throws ClassNotFoundException {// Check whether the Class is loaded c = findLoadedClass(name); Boolean resolve) throws ClassNotFoundException {// Check whether the Class is loaded c = findLoadedClass(name); If (c == null) {try {// there is a parent class loader if (parent! = null) { c = parent.loadClass(name, false); } else {c = findBootstrapClassOrNull(name); c = findBootstrapClassOrNull(name); }} catch (ClassNotFoundException e) {if (ClassNotFoundException e) {if (ClassNotFoundException e) {if (ClassNotFoundException e) {if (ClassNotFoundException e) {if (ClassNotFoundException e) { C = findClass(name); } } if (resolve) { resolveClass(c); } return c; }Copy the code

Well, this article is the main content is finished, the text is relatively short, not as before the basic is 10,000 words, because the main content has been finished, this article is relatively simple, more inclined to write the JVM article summary before.

The following article begins the serials of the database, the main personal reading books are “Mysql 45 talk”, “Mysql Technology Insider InnoDB Storage Engine 2nd edition”, “high-performance Mysql 3rd edition”, well, this issue is here, we next period, need these information can add my wechat: Abc730500468.