1、Java編譯原理1 關于動態加載機制學習Java比C+更容易理解OOP的思想，畢竟C+還混合了不少面向過程的成分。很多人都能背出來Java語言的特點，所謂的動態加載機制等等。當然概念往往是先記住而后消化的，可有多少人真正去體會過動態加載的機制，試圖去尋找過其中的細節呢? 提供大家一個方法：在命令行窗口運行Java程序的時候，加上這個很有用的參數：java verbose *.class這樣會清晰的打印出被加載的類文件，大部分是jdk自身運行需要的，最后幾行會明顯的看到自己用到的那幾個類文件被加載進來的順序。即使你聲明了一個類對象，不實例化也不會加載，說明只有真正用到那個類的實例即對象的時候，才

2、會執行加載。這樣是不是大家稍微能明白一點動態加載了呢？_2 關于尋找class文件原理建議大家在入門的時候在命令行窗口編譯和運行，不要借助JCreator或者Eclipse等IDE去幫助做那些事情。嘗試自己這樣做：javac -classpath yourpath *.javajava -classpath yourpath *.class也許很多人都能看懂，設置classpath的目的就是告訴編譯器去哪里尋找你的class文件. 不過至少筆者今日才弄懂JVM去查詢類的原理，編譯器加載類要依靠classloader， 而classloader有3個級別，從高到低分別是BootClassLoad

3、er(名字可能不準確) , ExtClassLoader, AppClassLoader.這3個加載器分別對應著編譯器去尋找類文件的優先級別和不同的路徑：BootClassLoader對應jre/classes路徑，是編譯器最優先尋找class的地方。ExtClassLoader對應jre/lib/ext路徑，是編譯器次優先尋找class的地方，AppClassLoader對應當前路徑，所以也是編譯器默認找class的地方其實大家可以自己寫個程序簡單的測試，對任何class，例如A, 調用new A().getClass().getClassLoader().toString() 打印出來就可

4、以看到，把class文件放在不同的路徑下再次執行，就會看到區別。特別注意的是如果打印出來是null就表示到了最高級 BootClassLoader, 因為它是C+編寫的，不存在Java對應的類加載器的名字。尋找的順序是一種向上迂回的思想，即如果本級別找不到，就只能去本級別之上的找，不會向下尋找。不過似乎從Jdk1.4到Jdk1.6這一特點又有改變，沒有找到詳細資料。所以就不舉例子了。告訴大家設計這種體系的是Sun公司曾經的技術核心宮力先生，一個純種華人哦！這樣希望大家不至于迷惑為什么總報錯找不到類文件，不管是自己寫的還是導入的第三方的jar文件（J2ee中經常需要導入的）。3 關于jdk和jr

5、e大家肯定在安裝JDK的時候會有選擇是否安裝單獨的jre，一般都會一起安裝，我也建議大家這樣做。因為這樣更能幫助大家弄清楚它們的區別：Jre 是java runtime environment, 是java程序的運行環境。既然是運行，當然要包含jvm，也就是大家熟悉的虛擬機啦，還有所有java類庫的class文件，都在lib目錄下打包成了jar。大家可以自己驗證。至于在windows上的虛擬機是哪個文件呢？ 學過MFC的都知道什么是dll文件吧，那么大家看看jre/bin/client里面是不是有一個jvm.dll呢？那就是虛擬機。Jdk 是java development kit，是java

6、的開發工具包，里面包含了各種類庫和工具。當然也包括了另外一個Jre. 那么為什么要包括另外一個Jre呢？而且jdk/jre/bin同時有client和server兩個文件夾下都包含一個jvm.dll。 說明是有兩個虛擬機的。這一點不知道大家是否注意到了呢？相信大家都知道jdk的bin下有各種java程序需要用到的命令，與jre的bin目錄最明顯的區別就是jdk下才有javac，這一點很好理解，因為 jre只是一個運行環境而已。與開發無關，正因為如此，具備開發功能的jdk自己的jre下才會同時有client性質的jvm和server性質的 jvm， 而僅僅作為運行環境的jre下只需要client

7、性質的jvm.dll就夠了。記得在環境變量path中設置jdk/bin路徑麼？這應該是大家學習Java的第一步吧， 老師會告訴大家不設置的話javac和java是用不了的。確實jdk/bin目錄下包含了所有的命令。可是有沒有人想過我們用的java命令并不是 jdk/bin目錄下的而是jre/bin目錄下的呢？不信可以做一個實驗，大家可以把jdk/bin目錄下的java.exe剪切到別的地方再運行 java程序，發現了什么？一切OK！那么有人會問了？我明明沒有設置jre/bin目錄到環境變量中啊？試想一下如果java為了提供給大多數人使用，他們是不需要jdk做開發的，只需要jre能讓java程序

8、跑起來就可以了，那么每個客戶還需要手動去設置環境變量多麻煩啊？所以安裝jre的時候安裝程序自動幫你把jre的java.exe添加到了系統變量中，驗證的方法很簡單，大家看到了系統環境變量的 path最前面有“%SystemRoot%system32;%SystemRoot%;”這樣的配置，那么再去Windows/system32下面去看看吧，發現了什么？有一個java.exe。如果強行能夠把jdk/bin挪到system32變量前面，當然也可以迫使使用jdk/jre里面的java，不過除非有必要，我不建議大家這么做。使用單獨的jre跑java程序也算是客戶環境下的一種測試。這下大家應該更清楚jd

9、k和jre內部的一些聯系和區別了吧？鑒于上回寫的一點感想大家不嫌棄，都鼓勵小弟繼續寫下去，好不容易等到國慶黃金周，實習總算有一個休息的階段，于是這就開始寫第二篇了。希望這次寫的仍然對志同道合的朋友們有所幫助。上回講了Java動態加載機制、classLoader原理和關于jdk和jre三個問題。這次延續著講一些具體的類庫。1 關于集合框架類相信學過Java的各位對這個名詞并不陌生，對 java.util.*這個package肯定也不陌生。不知道大家查詢API的時候怎么去審視或者分析其中的一個package，每個包最重要的兩個部分就是interfaces和classes，接口代表了它能做什么，實現

10、類則代表了它如何去做。關注實現類之前，我們應該先理解清楚它的來源接口，不管在j2se還是j2ee中，都應該是這樣。那么我們先看這三個接口：List、Set、Map。也許有些人不太熟悉這三個名字，但相信大部分人都熟悉ArrayList，LinkedList，TreeSet，HashSet，HashMap， Hashtable等實現類的名字。它們的區別也是滿容易理解的，List放可以重復的對象集合，Set放不可重復的對象組合，而Map則放 這樣的名值對， Key不可重復，Value可以。這里有幾個容易混淆的問題：到底Vector和ArrayList，Hashtable和HashMap有什么區別？很

11、多面試官喜歡問這個問題，其實更專業一點應該這樣問：新集合框架和舊集合框架有哪些區別？新集合框架大家可以在這些包中找since jdk1.2的，之前的如vector和Hashtable都是舊的集合框架包括的類。那么區別是？a. 新集合框架的命名更加科學合理。例如List下的ArrayList和LinkedListb. 新集合框架下全部都是非線程安全的。建議去jdk里面包含的源代碼里面自己去親自看看vector和ArrayList的區別吧。當然如果是jdk5.0之后的會比較難看一點，因為又加入了泛型的語法，類似c+的template語法。那么大家是否想過為什么要從舊集合框架默認全部加鎖防止多線程訪

12、問更新到新集合框架全部取消鎖，默認方式支持多線程？(當然需要的時候可以使用collections的靜態方法加鎖達到線程安全)筆者的觀點是任何技術的發展都未必是遵循它們的初衷的，很多重大改變是受到客觀環境的影響的。大家知道Java的初衷是為什么而開發的麼？是為嵌入式程序開發的。記得上一篇講到classLoader機制麼？那正是為了節約嵌入式開發環境下內存而設計的。而走到今天，Java成了人們心中為互聯網誕生的語言。互聯網意味著什么？多線程是必然的趨勢。客觀環境在變，Java技術也隨著飛速發展，導致越來越脫離它的初衷。據說Sun公司其實主打的是J2se，結果又是由于客觀環境影響，J2se幾乎遺忘，

13、留在大家談論焦點的一直是j2ee。技術的細節這里就不多說了，只有用了才能真正理解。解釋這些正是為了幫助大家理解正在學的和將要學的任何技術。之后講j2ee的時候還會再討論。多扯句題外話：幾十年前的IT巨人是IBM，Mainframe市場無人可比。微軟如何打敗IBM？正是由于硬件飛速發展，對個人PC的需求這個客觀環境，讓微軟通過OS稱為了第二個巨人。下一個打敗微軟的呢？Google。如何做到的？如果微軟并不和IBM爭大型機，Google借著互聯網飛速發展這個客觀環境作為決定性因素，避開跟微軟爭OS，而是走搜索引擎這條路，稱為第3個巨人。那么第4個巨人是誰呢？很多專家預言將在亞洲或者中國出現， Wh

14、atever，客觀環境變化趨勢才是決定大方向的關鍵。當然筆者也希望會出現在中國。2 關于Java設計模式身邊的很多在看GOF的23種設計模式，似乎學習它無論在學校還是在職場，都成了一種流行風氣。我不想列舉解釋這23種Design Pattern， 我寫這些的初衷一直都是談自己的經歷和看法，希望能幫助大家理解。首先我覺得設計模式只是對一類問題的一種通用解決辦法，只要是面向對象的編程預言都可以用得上這23種。理解它們最好的方法就是親自去寫每一種，哪怕是一個簡單的應用就足夠了。如果代碼實現也記不住的話，記憶它們對應的UML圖會是一個比較好的辦法，當然前提是必須了解UML。同時最好能利用Java自身的

15、類庫幫助記憶，例如比較常用的觀察者模式，在java.util.*有現成的Observer接口和Observable這個實現類，看看源代碼相信就足夠理解觀察者模式了。再比如裝飾器模式，大家只要寫幾個關于java.io.*的程序就可以完全理解什么是裝飾器模式了。有很多人覺得剛入門的時候不該接觸設計模式，比如圖靈設計叢書系列很出名的那本Java設計模式，作者: Steven John Metsker，大部分例子老實說令現在的我也很迷惑。但我仍然不同意入門跟學習設計模式有任何沖突，只是我們需要知道每種模式的概念的和典型的應用，這樣我們在第一次編寫 FileOutputStream、BufferedRe

16、ader、PrintWriter的時候就能感覺到原來設計模式離我們如此之近，而且并不是多么神秘的東西。另外，在學習某些模式的同時，反而更能幫助我們理解java類庫的某些特點。例如當你編寫原型(Prototype)模式的時候，你必須了解的是 java.lang.Cloneable這個接口和所有類的基類Object的clone()這個方法。即深copy和淺copy的區別：Object.clone()默認實現的是淺copy，也就是復制一份對象拷貝，但如果對象包含其他對象的引用，不會復制引用，所以原對象和拷貝共用那個引用的對象。深copy當然就是包括對象的引用都一起復制啦。這樣原對象和拷貝對象，都分別擁有一份引用對象。如果要實現深copy就必須首先實現 java.lang.Cloneable接口，然后重寫clone()方法。因為在Object中的clone()方法是protected簽名的，而 Cloneable接口的作用就是把protected放大到public，這樣clone()才能被重寫。那么又有個問題了？如果引用的對象又引用了其他對象呢？這樣一直判斷并復制下去，是不是顯得很麻煩？曾經有位前輩告訴我的方法是重寫clone方法的時候直接把原對象序列化到磁盤上再反序列化回來，這