java深度历险记-第4话

Java 程式在編譯之後會產生許多的執行單位(.class
檔)，當我們執行主要類別時(有 public static void main(String arga[])方法的
那個類別)，才由虛擬機器一一載入所有需要的執行單位，變成一個邏輯上為一
體的 Java應用程式。因此接下來，我們將細部討論這整個流程。

  當我們在命令列輸入 java xxx.class 的時候，java.exe 根據
過的邏輯找到了JRE(Java Runtime Environment)，接著找到位
jvm.dll(真正的 Java虛擬機器)，最後載入這個動態聯結函式庫，
擬機器。

  虛擬機器一啟動，會先做一些初始化的動作，比方說抓取系統參數等。一旦
初始化動作完成之後，就會產生第一個類別載入器，即所謂的 Bootstrap
Loader，Bootstrap Loader 是由 C++所撰寫而成(所以前面我們說，以 Java
的觀點來看，邏輯上並不存在Bootstrap Loader 的類別實體，所以在 Java程
式碼裡試圖印出其內容的時候，我們會看到的輸出為 null)，這個 Bootstrap
Loader所做的初始工作中，除了也做一些基本的初始化動作之外，最重要的就
是載入定義在 sun.misc 命名空間底下的 Launcher.java 之中的
ExtClassLoader( 因為是 inner class ，所以編譯之後會變成
Launcher$ExtClassLoader.class)，並設定其Parent 為 null，代表其父載入器
為 Bootstrap Loader。然後 Bootstrap Loader 再要求載入定義於 sun.misc 命
名空間底下的 Launcher.java 之中的 AppClassLoader(因為是 inner class，
所以編譯之後會變成 Launcher$AppClassLoader.class)，並設定其 Parent
為之前產生的 ExtClassLoader 實體。這裡要請大家注意的是，
Launcher$ExtClassLoader.class 與 Launcher$AppClassLoader.class 都是
由 Bootstrap Loader 所載入，所以 Parent 和由哪個類別載入器載入沒有關係。





AppClassLoader 在 Sun 官方文件中常常又被稱做系統載入器(System
Loader)，但是在本文中為了避免混淆，所以還是稱作 AppClassLoader。最後
一個步驟，是由 AppClassLoader 負責載入我們在命令列之中所輸入的
xxx.class(注意:實際上 xxx.class 很可能由 ExtClassLoader 或 Bootstrap
Loader載入，請參考底下「委派模型」一節)，然後開始一個 Java 應用程式的
生命週期。上述整個流程如下圖所示: