think about the following scenarios:

1. first of all, to distinguish between classes of the same name : suppose there is an application server with many independent applications deployed on it, and they have many different versions of class libraries with the same name. Just imagine, at this time, how can jvm load these classes while avoiding the difference detection of classes with the same name when dropping classes? of course, different applications have their own independent class loaders.
2. secondly, it is more convenient to enhance the ability of the class : the class loader can rewrite and overwrite the class during the load class, during which time you can enhance the functionality of the class. For example, add dynamic agents used in aspect-oriented programming, as well as the principles of debug. How to achieve the effect of modifying only one class library without affecting other class libraries? A convenient mode is that each class library can use a separate class loader

Summary:
jvm requires different classloaders, because on the one hand, it allows you to run different applications in a jvm, and on the other hand, it makes it easier for you to independently enhance different class libraries.

although the java virtual machine has not been studied, why java can not load all classes in one loader
obviously, it can also be implemented
, but it requires more code, and it is more difficult to optimize for various classes. In order to simplify the abstraction
, I will optimize this class when I know clearly that the class is the startup class.
if it is a custom class, such optimizations may not be made.
specialized code is simpler and more efficient than generic code when the purpose is clear.

Each class loader is designed to load classes from different locations. For instance, you can actually create a class loader that will load a class file from a networked server or download the binary of a class from a remote web server, etc. The logic that performs this operation is baked into the class loader itself and provides a consistent interface so that clients can load classes regardless of how the class loader actually performs the loading. The BootstrapClassLoader is capable of loading classes from the JVM_HOME/lib directory.but what if you need to load them from a different location??

In short, because there as an infinite (well, not quite) number of ways to load classes and there needs to be a flexible system to allow developers to load them however they want.

each class loader is designed to load classes in a different context. For example, you can load a class file from a networked server, or you can download binary classes from a remote web server. This is designed because we need the class loader to provide a consistent interface so that the client can load the class regardless of how the class loader is implemented. The startup classloader can load classes under JVM_HOME/lib, but what if we need to load classes in other cases? To put it simply, there are countless ways to load classes, and we need a flexible loader system to load classes as we want in certain situations.