Windows
Native的c++應(yīng)用大量使用了DLL技術(shù)。"動態(tài)鏈接"這幾字指明了DLLs是如何工作的。對于常規(guī)的函數(shù)庫,鏈接器從中拷貝它需要的所有庫函數(shù),并把確切的函數(shù)地址傳送給調(diào)用這些函數(shù)的程序。而對于DLLs,函數(shù)儲存在一個獨立的動態(tài)鏈接庫文件中。在創(chuàng)建Windows程序時,鏈接過程并不把DLLs文件鏈接到程序上。直到程
序運行并調(diào)用一個DLLs中的函數(shù)時,該程序才要求這個函數(shù)的地址。此時Windows才在DLLs中尋找被調(diào)用函數(shù),并把它的地址傳送給調(diào)用程序。采用這種方法,DLLs達到了復(fù)用代碼的極限。
對于DLL,
關(guān)鍵一點是,所有run on windows
system 的程序可以共用同一個DLL庫,從而達到最大限度的代碼復(fù)用。并且,由于DLL并不拷貝它需要的所有庫函數(shù)
, 這樣的話Native的C++程序
executable image size 會比較小。
從modularity的角度,如果要在Java的應(yīng)用里尋找相對應(yīng)的DLL的概念,我們會自然地想到jar包。JAR包可以被
Class Loader動態(tài)裝載進JVM,
不過要幾點區(qū)別需要說明的是:
第一、從本質(zhì)上來講,JAR包是存在于磁盤上的一些data而已(由JVM解釋執(zhí)行),而DLL是executable
的image。
第二、Class
Data Sharing (CDS)作為一個新的feature,在Java5才被引入,其做法就是:把
system jar 文件打包成為"shared
archive",這些"shared
archive"會作為memory-mapped
in文件存在,共享于不同的JVM
進程間,以減少JVM的footprint,加快Java應(yīng)用的啟動時間。
值得一提的是:兩者都有所謂的HELL問題(JAR HELL vs DLL HELL),新老版本的兼容問題始終讓人頭疼。
詳見解釋:
http://en.wikipedia.org/wiki/DLL_hell
http://en.wikipedia.org/wiki/JAR_hell#JAR_hell