java類加載過程分為哪些步驟

Java 8之前的類加載器

啟動類加載器（Bootstrap Class-Loader），加載jre/lib下面的jar文件，如rt.jar。它是個超級公民，即使是在開啟了Security Manager的時候，JDK仍賦予了它加載的程序AllPermission。

對于做底層開發(fā)的工程師，有的時候可能不得不去試圖修改JDK的基礎代碼，也就是通常意義上的核心類庫，我們可以使用下面的命令行參數(shù)。

# 指定新的 bootclasspath，替換 java.* 包的內部實現(xiàn)
java -Xbootclasspath:<your_boot_classpath> your_App

# a 意味著 append，將指定目錄添加到 bootclasspath 后面
java -Xbootclasspath/a:<your_dir> your_App

# p 意味著 prepend，將指定目錄添加到 bootclasspath 前面
java -Xbootclasspath/p:<your_dir> your_App

用法其實很易懂，例如，使用最常見的“/p”，既然是前置，就有機會替換個別基礎類的實現(xiàn)。

我們一般可以使用下面方法獲取父加載器，但是在通常的JDK/JRE實現(xiàn)中，擴展類加載器getParent()都只能返回null。

public final ClassLoader getParent()

擴展類加載器（Extension or Ext Class-Loader），負責加載我們放到jre/lib/ext目錄下面的jar包，這就是所謂的extension機制。該目錄也可以通過設置“java.ext.dirs”來覆蓋

java -Djava.ext.dirs=your_ext_dir HelloWorld

應用類加載器（Application or App Class-Loader），就是加載我們最熟悉的classpath的內容。這里有一個容易混淆的概念，系統(tǒng)（System）類加載器，通常來說，其默認就是JDK內建的應用類加載器，但是它同樣是可能修改的，比如：

java -Djava.system.class.loader=com.yourcorp.YourClassLoader HelloWorld

如果我們指定了這個參數(shù)，JDK內建的應用類加載器就會成為定制加載器的父親，這種方式通常用在類似需要改變雙親委派模式的場景。

具體參考下圖：

雙親委派模型

談到類加載一個躲不開的話題就是“雙親委派模型”，簡單說就是當類加載器（Class-Loader）試圖加載某個類型的時候，除非父加載器找不到相應的類型，否則盡量將這個任務代理給當前加載器的父加載器去做。

參考上面這個結構圖就很容易理解了。試想，如果不同類加載器都自己加載需要的某個類型，那么就會出現(xiàn)多次重復加載，完全是種浪費。

通常類加載器機制有三個基本特征：

• 雙親委派模型。但不是所有類加載都遵守這個模型，有的時候，啟動類加載器所加載的類型，是可能要加載用戶代碼的。比如JDK內部的ServiceProvider/ServiceLoader機制，用戶可以在標準API框架上，提供自己的實現(xiàn)，JDK也需要提供些默認的參考實現(xiàn)。例如，Java中JNDI、JDBC、文件系統(tǒng)、Cipher等很多方面，都是利用的這種機制，這種情況就不會用雙親委派模型去加載，而是利用所謂的上下文加載器。

• 可見性。子加載器可以訪問父加載器加載的類型，但是反過來是不允許的。不然，因為缺少必要的隔離，我們就沒有辦法利用類加載器去實現(xiàn)容器的邏輯。

• 單一性。由于父加載器的類型對于子加載器是可見的，所以父加載器中加載過的類型，就不會在子加載器中重復加載。但是注意，類加載器“鄰居”間，同一類型仍然可以被加載多次，因為互相不可見。