轉載自http://blog.csdn.net/yuekun1172006/archive/2007/06/02/1634878.aspx

類裝入器是 JVM 用來裝入類的類，它對于 Java 編程是非常重要的一個概念。一般情況下，程序員在編寫程序的時候都可以忽略類裝入器的存在性。但是對于服務器端編程或者是一些特殊情況下時候，深入了解類裝入器的機制以及其在不同情況下的實現還是非常必要的。

首先，當一個 JVM 啟動的時候，Java 缺省開始使用三個類裝入器。它們分別是：

• 引導（Bootstrap）類裝入器；
• 擴展（Extension）類裝入器；
• 系統（System）類裝入器；

它們分別實現如下的功能：

• 引導類裝入器是用本地代碼實現的類裝入器。它負責將 <Java_Runtime_Home>/lib 下面的類庫加載到內存中。
• 擴展類裝入器是由 Sun 的 ExtClassLoader 實現的。它負責將 < Java_Runtime_Home >/lib/ext 或者由系統變量 java.ext.dir 指定位置中的類庫加載到內存中。
• 系統類裝入器又叫應用程序類裝入器，是由 Sun 的 AppClassLoader 實現的。它負責將系統類路徑（CLASSPATH）中指定的類庫加載到內存中。

當應用程序需要加載某個類到內存中的時候，類裝入器是如何工作的呢？這就設計到類裝入器的一個重要方面：代理機制。每一個類裝入器，除了引導類裝入器以外，都有一個父類裝入器。對于系統缺省定義的三個類裝入器，引導類裝入器是擴展類裝入器的父類裝入器，而擴展類裝入器是系統類裝入器的父類裝入器。當然，應用程序也可以使用自己的類裝入器來使用特定的方法來裝載類，因此，整個系統中的類裝入器就形成一個樹狀結構。

當使用某個類裝入器來試圖裝載某個類的時候，該類裝入器會首先使用其父類裝入器來試圖裝載該類。對于每一個裝載進來的類，JVM 都會給其分配一個唯一的 ID。因此，不同類裝入器可以裝載同一個類到 JVM 中。例如，對于如下圖結構的 ClassLoaderA 和 ClassLoaderB：

假設類 C 在系統類裝入器指定的類路徑中，則無論是使用 ClassLoaderA 還是使用 ClassLoaderB，都只會得到同樣一個類 C。

但是如果類 C 分別在 ClassLoaderA 以及 ClassLoaderB 指定的類庫中，則使用 ClassLoaderA 得到到類 C 實例會不同于 ClassLoaderB 得到的類 C 實例。盡管兩個類裝入器在同一個 JVM 中。

上面的類裝入器的向上代理結構看上去很完美了，但是，當系統變得復雜的時候，就還是顯得不夠用了。

例如，當 Java 引入了 JNDI 以后，JNDI 核心部分是通過引導 類裝入器在 JVM 啟動的時候裝載進入 JVM 的。而 JDNI 核心部分是通過配置信息來在運行時候裝載定義在用戶的類路徑中的特定類來完成特定需要。而這是上面定義的類裝入器的向上代理模式所不能支持的。

為了解決這個問題，Java 2 中引入了線程上下文（Thread Content）類裝入器的概念，每一個線程有一個 Context 類裝入器。這個 Context 類裝入器是通過方法 Thread.setContextClassLoader() 設置的，如果當前線程在創建后沒有調用這個方法設置 Context 類裝入器，則當前線程從他的父線程繼承 Context 類裝入器。如果整個應用都沒有設置 Context 類裝入器，則系統類裝入器被設置為所有線程的 Context 類裝入器。

對于我們上面所說 JNDI 的情況，引導 類裝入器裝載進入的 JNDI 核心類會使用 Context 類裝入器來裝載其所需要的 JNDI 實現類，而不是將該裝載任務代理給其父類裝入器來完成。這樣，就解決了上面的問題?？梢哉J為 Context 類裝入器在傳統的 Java 向上代理機制上打開了一個后門。Context 類裝入器在 J2EE 中使用的很廣泛，比如 Java 命名服務（JNDI），Java API for XML Parsing(JAXP)（注：在 Java1.4 中 JAXP 才作為 Java 的核心類的一部分，它才開始使用 Context 類裝入器來加載不同的實現類）等。

簡單而言，Java 中的類裝入器就是上面幾種，但是，在具體使用中，還是有很多變化，我們下面分別對于一些情況進行說明。