【51CTO獨(dú)家特稿】在Java中使用new關(guān)鍵字創(chuàng)建對象變得很容易了，事實(shí)上，對這些事情你是不需要考慮的。需要訪問一個文件嗎？只需要創(chuàng)建一個新的File實(shí)例：new File(“build.properties”)，對于大多數(shù)Java開發(fā)人員而言，這就是他們需要知道的一切，是不是很簡單呢？！但當(dāng)你使用了多個類加載器時，問題就不一樣了。

這是我一年多來的第一反應(yīng)，我就是不想知道這些東西，但奇怪的是，類加載器其實(shí)非常簡單，大多數(shù)Java開發(fā)人員都知道編譯時通過Java文件生成.class類文件，然后由Java虛擬機(jī)（JVM）載入這些編譯后的類，這就是類加載器最基本的功能，但是和線程一樣，問題不是理解他們做什么，而是讓它們一起工作。

你聽到過多少次“這是類加載器的問題”？我承認(rèn)我聽到過很多次，我自己也說過很多次。只要你的應(yīng)用程序中不止一個類加載器，你不得不擔(dān)心哪些類可以相互看到對方，這很容易成為一場噩夢。有關(guān)類加載器行為我將另外用一篇文章來說，現(xiàn)在我們還是回到new關(guān)鍵字吧。

當(dāng)你創(chuàng)建一個新對象時，JVM首先加載類，當(dāng)你使用new時這是透明的，問題是使用什么類加載器？以及為什么要使用它？
設(shè)想一個Grails情景，我們有一套基于Gant的構(gòu)建系統(tǒng)，載入構(gòu)建腳本并執(zhí)行它們，我們以實(shí)例化一個Jetty服務(wù)器并啟動它作為示例，對象的創(chuàng)建順序是這樣的：

 
對象的創(chuàng)建順序

事實(shí)上，上圖展示的僅僅是一個簡化的真實(shí)情況。

前3個類都在我們將要調(diào)用的生成類加載器的類路徑下，因此是一次性將生成時需要用到的所有類全部加載了，但Jetty的Server類怎么加載呢？最重要的是要知道Server類必須要通過加載Grails Web應(yīng)用程序相同的類加載器加載，雖然你可以將你自己的類加載器嵌入到服務(wù)器中，如果與加載Server的不一樣，將會出現(xiàn)可怕的類加載器問題。

考慮到這一點(diǎn)，讓我們看看如果RunApp腳本使用new創(chuàng)建服務(wù)器實(shí)例會發(fā)生什么：

def server = new org.mortbay.jetty.Server()  
...  
server.start() 

現(xiàn)在你應(yīng)該問你自己“加載Server類該使用什么類加載器？”，這是一個關(guān)鍵問題，因?yàn)樗鼪Q定了使用什么類加載器加載整個Web應(yīng)用程序，也就決定了應(yīng)用程序的運(yùn)行時應(yīng)該使用和依賴的類路徑，在這種情況下，無論使用什么類加載器加載RunApp腳本，new操作符都會有效地授權(quán)給

this.getClass().getClassLoader() 

我們的例子是什么意思呢？它意味著生成類加載器被用于加載Server類，因此也必須用于加載Web應(yīng)用程序類，換句話說，所有應(yīng)用程序的運(yùn)行時依賴必須包括在生成類加載器中。你可能會問，這樣會不會有問題？回答是有一個潛在的問題和一個實(shí)際的問題。
潛在的問題是類沖突，如果Web應(yīng)用程序依賴一個已經(jīng)存在于生成系統(tǒng)中不同版本的庫會怎么樣？如果所有Apache XML API庫都在類路徑下，這是一個特殊的問題，絕對會導(dǎo)致大破壞。

實(shí)際的問題是在類路徑中JAR文件越多，JVM尋找類的時間就越長，這意味著啟動時間就越長，這也是OSGi設(shè)計(jì)要解決的問題之一，為什么要將JAR放在生成類路徑下呢？生成時本身是不需要它們的。

解決辦法是確定類加載器的邊界，使用映射實(shí)例化你的對象：

def runtimeClassLoader = new URLClassLoader(...)  
def server = runtimeClassLoader.loadClass("org.mortbay.jetty.Server").newInstance()  
...  
server.start()