“This is the first day of my participation in the First Challenge 2022. For details: First Challenge 2022.”

preface

Friends, I came back to more text, in fact, is approaching the Spring Festival free time, ha ha.

Class loading is far away from us and we do not need to pay attention to it at all.

But if you think about it, you interact with it all the time, such as dynamic proxy based annotations (@Transactional), developing necessary hot loading tools (Jrebal), troubleshooting tools (arthas), and so on. That’s enough to make it important.

This column was inspired by my desire to build a wheel similar to the SpringBootDevTool. If you’re curious about class loading, but you’re new to it and don’t know how it works. Don’t panic, this Jvm series will help you understand.

Class loading steps

The overall class loading process is divided into seven steps

  1. loading
  2. validation
  3. To prepare
  4. parsing
  5. Initialize the
  6. use
  7. uninstall

Of these seven steps, there are, of course, only three. Of course, for the sake of space, this article is about loading.

What is class loading

  1. After a class is created, the JVM compiler will.javaFile compiled into.ClassBytecode files.
  2. Then, when the JVM starts, the data describing the class is transferred from.ClassFiles are (not required) loaded into memory, and the data is validated, transformed, parsed, and initialized.
  3. The result is Java types that can be used directly by the JVM and placed in various memory areas of the JVM.

Bytecode source

The Class file is loaded into memory. Is there any other way? Look down!

  1. Read from the ZIP package. Example: JAR packages
  2. Obtained from the network. Reference: UrlClassLoader(covered in the next JVM series)
  3. Runtime compute generation. Dynamic proxy technology: AOP
  4. Generated by other files. Example: Jsp files
  5. Read from the database. I’ve never tried…

Class loader

Since we need to load classes, we naturally need some kind of tool. In the JVM, this is known as a classloader.

In our code design, there are design principles of low coupling and high cohesion. In the class loader, in order to distinguish the responsibility, and ensure that the JDK basic code and the project of business from a variety of reasons, such as the JVM defines the different class loaders: BootstrapClassLoader, ExtensionClassLoader, AppClassLoader. Each of them has its own load path and load time.

Bootstrap ClassLoader

  1. Loading path: lib/rt.jar etc
  2. Load time: when the JVM starts

Add the command -xx :+TraceClassLoading when starting the JVM to see the loaded classes. Do you find the following classes familiar

Extension ClassLoader

  1. The loading path is jre/lib/ext. If the user-defined Jar package is in the same path, it will be loaded as well
  2. Load time: when the JVM starts

App ClassLoader

  1. Load path: the current path of the application
  2. Loading time: class to be loaded when the system starts, for example, Controller under SpringBoot. Or classes loaded at project runtime

The custom this

  1. Load path: Where the class loader is set
  2. Loading time: Manually triggered

At the end

That’s the end of this article. This article introduces what class loading is, and gives a rough introduction to the class loading tool -> class loader. The next article will focus on how the JVM makes clever use of these classloaders, which are implementations of the parent delegate model.

Give this article a thumbs up and see you next time!!