摘要
本文主要介紹 Java 類加載器的原理和應(yīng)用場景。
What is ClassLoader?
ClassLoader的具體作用就是將class文件加載到j(luò)vm虛擬機中去。
為什么需要類加載器？
jvm啟動的時候，并不會一次性加載所有的class文件，而是根據(jù)需要去動態(tài)加載。
你想啊，假如一次性全部加載項目中的所有的 jar 包，那么多class，那內(nèi)存還不崩潰？
其實，我們在搭建JDK開發(fā)環(huán)境的時候，就配置了CLASSPATH環(huán)境變量，就是為了 JVM 啟動需要的加載的JDK開發(fā)jar包組：
CLASSPATH=.;%JAVA_HOME%\lib;%JAVA_HOME%\lib\tools.jar
JAVA類加載流程
三個類加載器
Java語言系統(tǒng)自帶有三個類加載器:
Bootstrap ClassLoader
最頂層的加載類，主要加載核心類庫，%JRE_HOME%\lib下的rt.jar、resources.jar、charsets.jar和class等。
Bootstrap ClassLoader是由C/C++編寫的，它本身是虛擬機的一部分，所以它并不是一個JAVA類，也就是無法在java代碼中獲取它的引用，JVM啟動時通過Bootstrap類加載器加載rt.jar等核心jar包中的class文件，之前的int.class,String.class都是由它加載。然后呢，我們前面已經(jīng)分析了，JVM初始化sun.misc.Launcher并創(chuàng)建Extension ClassLoader和AppClassLoader實例。并將ExtClassLoader設(shè)置為AppClassLoader的父加載器。Bootstrap沒有父加載器，但是它卻可以作用一個ClassLoader的父加載器。
另外需要注意的是可以通過啟動jvm時指定-Xbootclasspath和路徑來改變Bootstrap ClassLoader的加載目錄。比如java -Xbootclasspath/a:path被指定的文件追加到默認的bootstrap路徑中。我們可以打開我的電腦，在上面的目錄下查看，看看這些jar包是不是存在于這個目錄。
Extention ClassLoader
擴展的類加載器，加載目錄%JRE_HOME%\lib\ext目錄下的jar包和class文件。還可以加載-D java.ext.dirs選項指定的目錄。
AppClassLoader
也稱為 SystemAppClass 加載當前應(yīng)用的classpath的所有類。
我們上面簡單介紹了3個ClassLoader。說明了它們加載的路徑。并且還提到了-Xbootclasspath和-D java.ext.dirs這兩個虛擬機參數(shù)選項。
加載順序？
Bootstrap CLassloder => Extention ClassLoader => AppClassLoader
為了更好的理解，我們可以查看源碼。
雙親委托
一個類加載器查找class和resource時，是通過“委托模式”進行的。
它首先判斷這個class是不是已經(jīng)加載成功，如果沒有的話它并不是自己進行查找，而是先通過父加載器，然后遞歸下去，直到Bootstrap ClassLoader，
如果Bootstrap classloader找到了，直接返回，如果沒有找到，則一級一級返回，最后到達自身去查找這些對象。
這種機制就叫做雙親委托。
源代碼注釋
java.lang public abstract class ClassLoader
extends Object
A class loader is an object that is responsible for loading classes.
The class ClassLoader is an abstract class. Given the binary name of a class, a class loader should attempt to locate or generate data that constitutes a definition for the class.
A typical strategy is to transform the name into a file name and then read a "class file" of that name from a file system.
Every Class object contains a reference to the ClassLoader that defined it.
Class objects for array classes are not created by class loaders, but are created automatically as required by the Java runtime. The class loader for an array class, as returned by Class.getClassLoader() is the same as the class loader for its element type; if the element type is a primitive type, then the array class has no class loader.
Applications implement subclasses of ClassLoader in order to extend the manner in which the Java virtual machine dynamically loads classes.
Class loaders may typically be used by security managers to indicate security domains.
In addition to loading classes, a class loader is also responsible for locating resources. A resource is some data (a ".class" file, configuration data, or an image for example) that is identified with an abstract '/'-separated path name. Resources are typically packaged with an application or library so that they can be located by code in the application or library. In some cases, the resources are included so that they can be located by other libraries.
The ClassLoader class uses a delegation model to search for classes and resources. Each instance of ClassLoader has an associated parent class loader. When requested to find a class or resource, a ClassLoader instance will usually delegate the search for the class or resource to its parent class loader before attempting to find the class or resource itself.
Class loaders that support concurrent loading of classes are known as parallel capable class loaders and are required to register themselves at their class initialization time by invoking the ClassLoader.registerAsParallelCapable method. Note that the ClassLoader class is registered as parallel capable by default. However, its subclasses still need to register themselves if they are parallel capable. In environments in which the delegation model is not strictly hierarchical, class loaders need to be parallel capable, otherwise class loading can lead to deadlocks because the loader lock is held for the duration of the class loading process (see loadClass methods).
Run-time Built-in Class Loaders
The Java run-time has the following built-in class loaders:
Bootstrap class loader. It is the virtual machine's built-in class loader, typically represented as null, and does not have a parent.
Platform class loader. All platform classes are visible to the platform class loader that can be used as the parent of a ClassLoader instance. Platform classes include Java SE platform APIs, their implementation classes and JDK-specific run-time classes that are defined by the platform class loader or its ancestors.
To allow for upgrading/overriding of modules defined to the platform class loader, and where upgraded modules read modules defined to class loaders other than the platform class loader and its ancestors, then the platform class loader may have to delegate to other class loaders, the application class loader for example. In other words, classes in named modules defined to class loaders other than the platform class loader and its ancestors may be visible to the platform class loader.
System class loader. It is also known as application class loader and is distinct from the platform class loader. The system class loader is typically used to define classes on the application class path, module path, and JDK-specific tools. The platform class loader is a parent or an ancestor of the system class loader that all platform classes are visible to it.
Normally, the Java virtual machine loads classes from the local file system in a platform-dependent manner. However, some classes may not originate from a file; they may originate from other sources, such as the network, or they could be constructed by an application. The method defineClass converts an array of bytes into an instance of class Class. Instances of this newly defined class can be created using Class.newInstance.
The methods and constructors of objects created by a class loader may reference other classes. To determine the class(es) referred to, the Java virtual machine invokes the loadClass method of the class loader that originally created the class.
For example, an application could create a network class loader to download class files from a server. Sample code might look like:
ClassLoader loader = new NetworkClassLoader(host, port);
Object main = loader.loadClass("Main", true).newInstance();
. . .
The network class loader subclass must define the methods findClass and loadClassData to load a class from the network. Once it has downloaded the bytes that make up the class, it should use the method defineClass to create a class instance. A sample implementation is:
class NetworkClassLoader extends ClassLoader {
String host;
int port;
public Class findClass(String name) {
byte[] b = loadClassData(name);
return defineClass(name, b, 0, b.length);
}
private byte[] loadClassData(String name) {
// load the class data from the connection
. . .
}
}
Binary names
Any class name provided as a String parameter to methods in ClassLoader must be a binary name as defined by The Java? Language Specification.
Examples of valid class names include:
"java.lang.String"
"javax.swing.JSpinner$DefaultEditor"
"java.security.KeyStore$Builder$FileBuilder$1"
"java.net.URLClassLoader$3$1"
Any package name provided as a String parameter to methods in ClassLoader must be either the empty string (denoting an unnamed package) or a fully qualified name as defined by The Java? Language Specification.
Since: 1.0
See Also: resolveClass(Class)
