想來(lái)學(xué)習(xí)Java也有兩個(gè)年頭了，永遠(yuǎn)不敢說(shuō)多么精通，但也想談?wù)勛约旱母惺?，?xiě)給軟件學(xué)院的同仁們，幫助大家在技術(shù)的道路上少一點(diǎn)彎路。說(shuō)得偉大一點(diǎn)是希望大家為軟件學(xué)院爭(zhēng)氣，其實(shí)最主要的還是大家自身的進(jìn)步提升??

1． 關(guān)于動(dòng)態(tài)加載機(jī)制??
學(xué)習(xí)Java比C++更容易理解OOP的思想，畢竟C++還混合了不少面向過(guò)程的成分。很多人都能背出來(lái)Java語(yǔ)言的特點(diǎn)，所謂的動(dòng)態(tài)加載機(jī)制等等。當(dāng)然概念往往是先記住而后消化的，可有多少人真正去體會(huì)過(guò)動(dòng)態(tài)加載的機(jī)制，試圖去尋找過(guò)其中的細(xì)節(jié)呢? 提供大家一個(gè)方法：
在命令行窗口運(yùn)行Java程序的時(shí)候，加上這個(gè)很有用的參數(shù)：

java -verbose *.class

這樣會(huì)清晰的打印出被加載的類(lèi)文件，大部分是jdk自身運(yùn)行需要的，最后幾行會(huì)明顯的看到自己用到的那幾個(gè)類(lèi)文件被加載進(jìn)來(lái)的順序。即使你聲明了一個(gè)類(lèi)對(duì)象，不實(shí)例化也不會(huì)加載，說(shuō)明只有真正用到那個(gè)類(lèi)的實(shí)例即對(duì)象的時(shí)候，才會(huì)執(zhí)行加載。這樣是不是大家稍微能明白一點(diǎn)動(dòng)態(tài)加載了呢？^_^

2． 關(guān)于尋找class文件原理??
建議大家在入門(mén)的時(shí)候在命令行窗口編譯和運(yùn)行，不要借助JCreator或者Eclipse等IDE去幫助做那些事情。嘗試自己這樣做：
javac -classpath yourpath *.java
java -classpath yourpath *.class
也許很多人都能看懂，設(shè)置classpath的目的就是告訴編譯器去哪里尋找你的class文件. 不過(guò)至少筆者今日才弄懂JVM去查詢(xún)類(lèi)的原理，編譯器加載類(lèi)要依靠classloader， 而classloader有3個(gè)級(jí)別，從高到低分別是BootClassLoader(名字可能不準(zhǔn)確) , ExtClassLoader, AppClassLoader.

這3個(gè)加載器分別對(duì)應(yīng)著編譯器去尋找類(lèi)文件的優(yōu)先級(jí)別和不同的路徑：BootClassLoader對(duì)應(yīng)jre/classes路徑，是編譯器最優(yōu)先尋找class的地方
ExtClassLoader對(duì)應(yīng)jre/lib/ext路徑，是編譯器次優(yōu)先尋找class的地方
AppClassLoader對(duì)應(yīng)當(dāng)前路徑，所以也是編譯器默認(rèn)找class的地方

其實(shí)大家可以自己寫(xiě)個(gè)程序簡(jiǎn)單的測(cè)試，對(duì)任何class，例如A,
調(diào)用new A().getClass().getClassLoader().toString() 打印出來(lái)就可以看到，把class文件放在不同的路徑下再次執(zhí)行，就會(huì)看到區(qū)別。特別注意的是如果打印出來(lái)是null就表示到了最高級(jí) BootClassLoader, 因?yàn)樗荂++編寫(xiě)的，不存在Java對(duì)應(yīng)的類(lèi)加載器的名字。

尋找的順序是一種向上迂回的思想，即如果本級(jí)別找不到，就只能去本級(jí)別之上的找，不會(huì)向下尋找。不過(guò)似乎從Jdk1.4到Jdk1.6這一特點(diǎn)又有改變，沒(méi)有找到詳細(xì)資料。所以就不舉例子了。告訴大家設(shè)計(jì)這種體系的是Sun公司曾經(jīng)的技術(shù)核心宮力先生，一個(gè)純種華人哦！^_^

這樣希望大家不至于迷惑為什么總報(bào)錯(cuò)找不到類(lèi)文件，不管是自己寫(xiě)的還是導(dǎo)入的第三方的jar文件（J2ee中經(jīng)常需要導(dǎo)入的）。

3． 關(guān)于jdk和jre??
大家肯定在安裝JDK的時(shí)候會(huì)有選擇是否安裝單獨(dú)的jre，一般都會(huì)一起安裝，我也建議大家這樣做。因?yàn)檫@樣更能幫助大家弄清楚它們的區(qū)別：

Jre 是java runtime environment, 是java程序的運(yùn)行環(huán)境。既然是運(yùn)行，當(dāng)然要包含jvm，也就是大家熟悉的虛擬機(jī)啦， 還有所有java類(lèi)庫(kù)的class文件，都在lib目錄下打包成了jar。大家可以自己驗(yàn)證。至于在windows上的虛擬機(jī)是哪個(gè)文件呢？ 學(xué)過(guò)MFC的都知道什么是dll文件吧，那么大家看看jre/bin/client里面是不是有一個(gè)jvm.dll呢？那就是虛擬機(jī)。

Jdk 是java development kit，是java的開(kāi)發(fā)工具包，里面包含了各種類(lèi)庫(kù)和工具。當(dāng)然也包括了另外一個(gè)Jre. 那么為什么要包括另外一個(gè)Jre呢？而且jdk/jre/bin同時(shí)有client和server兩個(gè)文件夾下都包含一個(gè)jvm.dll。 說(shuō)明是有兩個(gè)虛擬機(jī)的。這一點(diǎn)不知道大家是否注意到了呢？

相信大家都知道jdk的bin下有各種java程序需要用到的命令，與jre的bin目錄最明顯的區(qū)別就是jdk下才有javac，這一點(diǎn)很好理解，因?yàn)?jre只是一個(gè)運(yùn)行環(huán)境而已。與開(kāi)發(fā)無(wú)關(guān)，正因?yàn)槿绱?，具備開(kāi)發(fā)功能的jdk自己的jre下才會(huì)同時(shí)有client性質(zhì)的jvm和server性質(zhì)的 jvm， 而僅僅作為運(yùn)行環(huán)境的jre下只需要client性質(zhì)的jvm.dll就夠了。

記得在環(huán)境變量path中設(shè)置jdk/bin路徑麼？這應(yīng)該是大家學(xué)習(xí)Java的第一步吧， 老師會(huì)告訴大家不設(shè)置的話javac和java是用不了的。確實(shí)jdk/bin目錄下包含了所有的命令?？墒怯袥](méi)有人想過(guò)我們用的java命令并不是 jdk/bin目錄下的而是jre/bin目錄下的呢？不信可以做一個(gè)實(shí)驗(yàn)，大家可以把jdk/bin目錄下的java.exe剪切到別的地方再運(yùn)行 java程序，發(fā)現(xiàn)了什么？一切OK！

那么有人會(huì)問(wèn)了？我明明沒(méi)有設(shè)置jre/bin目錄到環(huán)境變量中?。?

試想一下如果java為了提供給大多數(shù)人使用，他們是不需要jdk做開(kāi)發(fā)的，只需要jre能讓java程序跑起來(lái)就可以了，那么每個(gè)客戶(hù)還需要手動(dòng)去設(shè)置環(huán)境變量多麻煩啊？所以安裝jre的時(shí)候安裝程序自動(dòng)幫你把jre的java.exe添加到了系統(tǒng)變量中，驗(yàn)證的方法很簡(jiǎn)單，大家看到了系統(tǒng)環(huán)境變量的 path最前面有“%SystemRoot%\system32;%SystemRoot%;”這樣的配置，那么再去Windows/system32下面去看看吧，發(fā)現(xiàn)了什么？有一個(gè)java.exe。

如果強(qiáng)行能夠把jdk/bin挪到system32變量前面，當(dāng)然也可以迫使使用jdk/jre里面的java，不過(guò)除非有必要，我不建議大家這么做。使用單獨(dú)的jre跑java程序也算是客戶(hù)環(huán)境下的一種測(cè)試。

這下大家應(yīng)該更清楚jdk和jre內(nèi)部的一些聯(lián)系和區(qū)別了吧？

PS: 其實(shí)還有滿多感想可以總結(jié)的，一次寫(xiě)多了怕大家扔磚頭砸死我，怪我太羅唆。大家應(yīng)該更加踏實(shí)更加務(wù)實(shí)的去做一些研究并互相分享心得，大方向和太前沿的技術(shù)討論是必要的但最好不要太多，畢竟自己基礎(chǔ)都還沒(méi)打好，什么都講最新版本其實(shí)是進(jìn)步的一大障礙！


Java 學(xué)習(xí)雜談（二）?

鑒于上回寫(xiě)的一點(diǎn)感想大家不嫌棄，都鼓勵(lì)小弟繼續(xù)寫(xiě)下去，好不容易等到國(guó)慶黃金周，實(shí)習(xí)總算有一個(gè)休息的階段，于是這就開(kāi)始寫(xiě)第二篇了。希望這次寫(xiě)的仍然對(duì)志同道合的朋友們有所幫助。上回講了Java動(dòng)態(tài)加載機(jī)制、classLoader原理和關(guān)于jdk和jre三個(gè)問(wèn)題。這次延續(xù)著講一些具體的類(lèi)庫(kù)??

1． 關(guān)于集合框架類(lèi)
相信學(xué)過(guò)Java的各位對(duì)這個(gè)名詞并不陌生，對(duì) java.util.*這個(gè)package肯定也不陌生。不知道大家查詢(xún)API的時(shí)候怎么去審視或者分析其中的一個(gè)package，每個(gè)包最重要的兩個(gè)部分就是interfaces和classes，接口代表了它能做什么，實(shí)現(xiàn)類(lèi)則代表了它如何去做。關(guān)注實(shí)現(xiàn)類(lèi)之前，我們應(yīng)該先理解清楚它的來(lái)源接口，不管在j2se還是j2ee中，都應(yīng)該是這樣。那么我們先看這三個(gè)接口：List、Set、Map。
也許有些人不太熟悉這三個(gè)名字，但相信大部分人都熟悉ArrayList，LinkedList，TreeSet，HashSet，HashMap， Hashtable等實(shí)現(xiàn)類(lèi)的名字。它們的區(qū)別也是滿容易理解的，List放可以重復(fù)的對(duì)象集合，Set放不可重復(fù)的對(duì)象組合，而Map則放 <Key,Value > 這樣的名值對(duì)， Key不可重復(fù)，Value可以。這里有幾個(gè)容易混淆的問(wèn)題：

到底Vector和ArrayList，Hashtable和HashMap有什么區(qū)別？
很多面試官喜歡問(wèn)這個(gè)問(wèn)題，其實(shí)更專(zhuān)業(yè)一點(diǎn)應(yīng)該這樣問(wèn)：新集合框架和舊集合框架有哪些區(qū)別？新集合框架大家可以在這些包中找since jdk1.2的，之前的如vector和Hashtable都是舊的集合框架包括的類(lèi)。那么區(qū)別是？
a. 新集合框架的命名更加科學(xué)合理。例如List下的ArrayList和LinkedList
b. 新集合框架下全部都是非線程安全的。建議去jdk里面包含的源代碼里面自己去親自看看vector和ArrayList的區(qū)別吧。當(dāng)然如果是jdk5.0之后的會(huì)比較難看一點(diǎn)，因?yàn)橛旨尤肓朔盒偷恼Z(yǔ)法，類(lèi)似c++的template語(yǔ)法。

那么大家是否想過(guò)為什么要從舊集合框架默認(rèn)全部加鎖防止多線程訪問(wèn)更新到新集合框架全部取消鎖，默認(rèn)方式支持多線程？(當(dāng)然需要的時(shí)候可以使用collections的靜態(tài)方法加鎖達(dá)到線程安全)
筆者的觀點(diǎn)是任何技術(shù)的發(fā)展都未必是遵循它們的初衷的，很多重大改變是受到客觀環(huán)境的影響的。大家知道Java的初衷是為什么而開(kāi)發(fā)的麼？是為嵌入式程序開(kāi)發(fā)的。記得上一篇講到classLoader機(jī)制麼？那正是為了節(jié)約嵌入式開(kāi)發(fā)環(huán)境下內(nèi)存而設(shè)計(jì)的。而走到今天，Java成了人們心中為互聯(lián)網(wǎng)誕生的語(yǔ)言?；ヂ?lián)網(wǎng)意味著什么？多線程是必然的趨勢(shì)。客觀環(huán)境在變，Java技術(shù)也隨著飛速發(fā)展，導(dǎo)致越來(lái)越脫離它的初衷。據(jù)說(shuō)Sun公司其實(shí)主打的是J2se，結(jié)果又是由于客觀環(huán)境影響，J2se幾乎遺忘，留在大家談?wù)摻裹c(diǎn)的一直是j2ee。

技術(shù)的細(xì)節(jié)這里就不多說(shuō)了，只有用了才能真正理解。解釋這些正是為了幫助大家理解正在學(xué)的和將要學(xué)的任何技術(shù)。之后講j2ee的時(shí)候還會(huì)再討論。
多扯句題外話：幾十年前的IT巨人是IBM，Mainframe市場(chǎng)無(wú)人可比。微軟如何打敗IBM？正是由于硬件飛速發(fā)展，對(duì)個(gè)人PC的需求這個(gè)客觀環(huán)境，讓微軟通過(guò)OS稱(chēng)為了第二個(gè)巨人。下一個(gè)打敗微軟的呢？Google。如何做到的？如果微軟并不和IBM爭(zhēng)大型機(jī)，Google借著互聯(lián)網(wǎng)飛速發(fā)展這個(gè)客觀環(huán)境作為決定性因素，避開(kāi)跟微軟爭(zhēng)OS，而是走搜索引擎這條路，稱(chēng)為第3個(gè)巨人。那么第4個(gè)巨人是誰(shuí)呢？很多專(zhuān)家預(yù)言將在亞洲或者中國(guó)出現(xiàn)， Whatever，客觀環(huán)境變化趨勢(shì)才是決定大方向的關(guān)鍵。當(dāng)然筆者也希望會(huì)出現(xiàn)在中國(guó)，^_^~~

2． 關(guān)于Java設(shè)計(jì)模式
身邊的很多在看GOF的23種設(shè)計(jì)模式，似乎學(xué)習(xí)它無(wú)論在學(xué)校還是在職場(chǎng)，都成了一種流行風(fēng)氣。我不想列舉解釋這23種Design Pattern， 我寫(xiě)這些的初衷一直都是談自己的經(jīng)歷和看法，希望能幫助大家理解。
首先我覺(jué)得設(shè)計(jì)模式只是對(duì)一類(lèi)問(wèn)題的一種通用解決辦法，只要是面向?qū)ο蟮木幊填A(yù)言都可以用得上這23種。理解它們最好的方法就是親自去寫(xiě)每一種，哪怕是一個(gè)簡(jiǎn)單的應(yīng)用就足夠了。如果代碼實(shí)現(xiàn)也記不住的話，記憶它們對(duì)應(yīng)的UML圖會(huì)是一個(gè)比較好的辦法，當(dāng)然前提是必須了解UML。
同時(shí)最好能利用Java自身的類(lèi)庫(kù)幫助記憶，例如比較常用的觀察者模式，在java.util.*有現(xiàn)成的Observer接口和Observable這個(gè)實(shí)現(xiàn)類(lèi)，看看源代碼相信就足夠理解觀察者模式了。再比如裝飾器模式，大家只要寫(xiě)幾個(gè)關(guān)于java.io.*的程序就可以完全理解什么是裝飾器模式了。有很多人覺(jué)得剛?cè)腴T(mén)的時(shí)候不該接觸設(shè)計(jì)模式，比如圖靈設(shè)計(jì)叢書(shū)系列很出名的那本《Java設(shè)計(jì)模式》，作者: Steven John Metsker，大部分例子老實(shí)說(shuō)令現(xiàn)在的我也很迷惑。但我仍然不同意入門(mén)跟學(xué)習(xí)設(shè)計(jì)模式有任何沖突，只是我們需要知道每種模式的概念的和典型的應(yīng)用，這樣我們?cè)诘谝淮尉帉?xiě) FileOutputStream、BufferedReader、PrintWriter的時(shí)候就能感覺(jué)到原來(lái)設(shè)計(jì)模式離我們?nèi)绱酥?，而且并不是多么神秘的東西。

另外，在學(xué)習(xí)某些模式的同時(shí)，反而更能幫助我們理解java類(lèi)庫(kù)的某些特點(diǎn)。例如當(dāng)你編寫(xiě)原型(Prototype)模式的時(shí)候，你必須了解的是 java.lang.Cloneable這個(gè)接口和所有類(lèi)的基類(lèi)Object的clone()這個(gè)方法。即深copy和淺copy的區(qū)別：
Object.clone()默認(rèn)實(shí)現(xiàn)的是淺copy，也就是復(fù)制一份對(duì)象拷貝，但如果對(duì)象包含其他對(duì)象的引用，不會(huì)復(fù)制引用，所以原對(duì)象和拷貝共用那個(gè)引用的對(duì)象。
深copy當(dāng)然就是包括對(duì)象的引用都一起復(fù)制啦。這樣原對(duì)象和拷貝對(duì)象，都分別擁有一份引用對(duì)象。如果要實(shí)現(xiàn)深copy就必須首先實(shí)現(xiàn) java.lang.Cloneable接口，然后重寫(xiě)clone()方法。因?yàn)樵贠bject中的clone()方法是protected簽名的，而 Cloneable接口的作用就是把protected放大到public，這樣clone()才能被重寫(xiě)。

那么又有個(gè)問(wèn)題了？如果引用的對(duì)象又引用了其他對(duì)象呢？這樣一直判斷并復(fù)制下去，是不是顯得很麻煩？曾經(jīng)有位前輩告訴我的方法是重寫(xiě)clone方法的時(shí)候直接把原對(duì)象序列化到磁盤(pán)上再反序列化回來(lái)，這樣不用判斷就可以得到一個(gè)深copy的結(jié)果。如果大家不了解序列化的作法建議看一看 ObjectOutputStream和ObjectInputStream

歸根結(jié)底，模式只是思想上的東西，把它當(dāng)成前人總結(jié)的經(jīng)驗(yàn)其實(shí)一點(diǎn)都不為過(guò)。鼓勵(lì)大家動(dòng)手自己去寫(xiě)，例如代理模式，可以簡(jiǎn)單的寫(xiě)一個(gè)Child類(lèi)， Adult類(lèi)。Child要買(mǎi)任何東西由Adult來(lái)代理實(shí)現(xiàn)。簡(jiǎn)單來(lái)說(shuō)就是Adult里的buy()內(nèi)部實(shí)際調(diào)用的是Child的buy()，可是暴露在main函數(shù)的卻是Adult.buy()。這樣一個(gè)簡(jiǎn)單的程序就足夠理解代理模式的基本含義了。

Java 雜談（三）?

這已經(jīng)筆者寫(xiě)的第三篇Java雜記了，慶幸前兩篇一直得到論壇朋友們的支持鼓勵(lì)，還望大家繼續(xù)指正不足之處。筆者也一直渴望通過(guò)這樣方式清醒的自審，來(lái)尋找自己技術(shù)上的不足之處，希望和共同愛(ài)好Java的同仁們一起提高。
前兩次分別講述了關(guān)于jvm、jdk、jre、collection、classLoader和一些Design Pattern的自我理解。這次仍然不準(zhǔn)備開(kāi)始過(guò)渡到j(luò)2ee中，因?yàn)橛X(jué)得還有一些瑣碎的j2se的問(wèn)題沒(méi)有總結(jié)完畢。

1． 關(guān)于Object類(lèi)理解
大家都知道Object是所有Java類(lèi)的基類(lèi)， 意味著所有的Java類(lèi)都會(huì)繼承了Object的11個(gè)方法。建議大家去看看Object的 11個(gè)成員函數(shù)的源代碼，就會(huì)知道默認(rèn)的實(shí)現(xiàn)方式。比如equals方法，默認(rèn)實(shí)現(xiàn)就是用"=="來(lái)比較，即直接比較內(nèi)存地址，返回true 或者 false。而toString()方法，返回的串組成方式是??
"getClass().getName() + "@" + Integer.toHexString(hashCode())"
其實(shí)不用我過(guò)多的解釋?zhuān)蠹叶寄芸炊@個(gè)串的組成。接下來(lái)再看看hashCode()：
public native int hashCode()；

由于是native方法，跟OS的處理方式相關(guān)，源代碼里僅僅有一個(gè)聲明罷了。我們有興趣的話完全可以去深究它的hashCode到底是由OS怎么樣產(chǎn)生的呢？但筆者建議最重要的還是先記住使用它的幾條原則吧！首先如果equals()方法相同的對(duì)象具有相通的hashCode，但equals ()對(duì)象不相通的時(shí)候并不保證hashCode()方法返回不同的整數(shù)。而且下一次運(yùn)行同一個(gè)程序，同一個(gè)對(duì)象未必還是當(dāng)初的那個(gè)hashCode() 哦。
其余的方法呢？nofigy()、notifyAll()、clone()、wait()都是native方法的，說(shuō)明依賴(lài)于操作系統(tǒng)的實(shí)現(xiàn)。最后一個(gè)有趣的方法是finalize()，類(lèi)似C++的析構(gòu)函數(shù)，簽名是protected，證明只有繼承擴(kuò)展了才能使用，方法體是空的，默示什么也不做。它的作用據(jù)筆者的了解僅僅是通知JVM此對(duì)象不再使用，隨時(shí)可以被銷(xiāo)毀，而實(shí)際的銷(xiāo)毀權(quán)還是在于虛擬機(jī)手上。那么它真的什么也不做麼？未必，實(shí)際上如果是線程對(duì)象它會(huì)導(dǎo)致在一定范圍內(nèi)該線程的優(yōu)先級(jí)別提高，導(dǎo)致更快的被銷(xiāo)毀來(lái)節(jié)約內(nèi)存提高性能。其實(shí)從常理來(lái)說(shuō)，我們也可以大概這樣猜測(cè)出jvm做法的目的。

2． 關(guān)于重載hashCode()與Collection框架的關(guān)系
筆者曾經(jīng)聽(tīng)一位搞Java培訓(xùn)多年的前輩說(shuō)在他看來(lái)hashCode方法沒(méi)有任何意義，僅僅是為了配合證明具有同樣的hashCode會(huì)導(dǎo)致equals 方法相等而存在的。連有的前輩都犯這樣的錯(cuò)誤，其實(shí)說(shuō)明它還是滿容易被忽略的。那么hashCode()方法到底做什么用？

學(xué)過(guò)數(shù)據(jù)結(jié)構(gòu)的課程大家都會(huì)知道有一種結(jié)構(gòu)叫hash table，目的是通過(guò)給每個(gè)對(duì)象分配一個(gè)唯一的索引來(lái)提高查詢(xún)的效率。那么Java也不會(huì)肆意扭曲改變這個(gè)概念，所以hashCode唯一的作用就是為支持?jǐn)?shù)據(jù)結(jié)構(gòu)中的哈希表結(jié)構(gòu)而存在的，換句話說(shuō)，也就是只有用到集合框架的 Hashtable、HashMap、HashSet的時(shí)候，才需要重載hashCode()方法，
這樣才能使得我們能人為的去控制在哈希結(jié)構(gòu)中索引是否相等。筆者舉一個(gè)例子：
曾經(jīng)為了寫(xiě)一個(gè)求解類(lèi)程序，需要隨機(jī)列出1,2,3,4組成的不同排列組合，所以筆者寫(xiě)了一個(gè)數(shù)組類(lèi)用int[]來(lái)存組合結(jié)果，然后把隨機(jī)產(chǎn)生的組合加入一個(gè)HashSet中，就是想利用HashSet不包括重復(fù)元素的特點(diǎn)?？墒荋ashSet怎么判斷是不是重復(fù)的元素呢？當(dāng)然是通過(guò) hashCode()返回的結(jié)果是否相等來(lái)判斷啦，可做一下這個(gè)實(shí)驗(yàn)：
int[] A = {1,2,3,4};
int[] B = {1,2,3,4};
System.out.println(A.hashCode());
System.out.println(B.hashCode());

這明明是同一種組合，卻是不同的hashCode，加入Set的時(shí)候會(huì)被當(dāng)成不同的對(duì)象。這個(gè)時(shí)候我們就需要自己來(lái)重寫(xiě)hashCode()方法了，如何寫(xiě)呢？其實(shí)也是基于原始的hashCode()，畢竟那是操作系統(tǒng)的實(shí)現(xiàn)， 找到相通對(duì)象唯一的標(biāo)識(shí)，實(shí)現(xiàn)方式很多，筆者的實(shí)現(xiàn)方式是：
首先重寫(xiě)了toString()方法:
return A[0]“+” A[1]“+” A[2]“+” A[3]; //顯示上比較直觀
然后利用toString()來(lái)計(jì)算hashCode()：
return this.toString().hashCode()；
這樣上述A和B返回的就都是”1234”，在測(cè)試toString().hashCode()，由于String在內(nèi)存中的副本是一樣的，”1234”.hashCode()返回的一定是相同的結(jié)果。

說(shuō)到這，相信大家能理解得比我更好，今后千萬(wàn)不要再誤解hashCode()方法的作用。

3． 關(guān)于Class類(lèi)的成員函數(shù)與Java反射機(jī)制
很早剛接觸Java就聽(tīng)很多老師說(shuō)過(guò)Java的動(dòng)態(tài)運(yùn)行時(shí)機(jī)制、反射機(jī)制等。確實(shí)它們都是Java的顯著特點(diǎn)，運(yùn)行時(shí)加載筆者在第一篇介紹過(guò)了，現(xiàn)在想講講反射機(jī)制。在Java中，主要是通過(guò)java.lang包中的Class類(lèi)和Method類(lèi)來(lái)實(shí)現(xiàn)內(nèi)存反射機(jī)制的。
熟悉C++的人一定知道下面這樣在C++中是做不到的： 運(yùn)行時(shí)以字符串參數(shù)傳遞一個(gè)類(lèi)名，就可以得到這個(gè)類(lèi)的所有信息，包括它所有的方法，和方法的詳細(xì)信息。還可以實(shí)例化一個(gè)對(duì)象，并通過(guò)查到的方法名來(lái)調(diào)用該對(duì)象的任何方法。這是因?yàn)镴ava的類(lèi)在內(nèi)存中除了C++中也有的靜態(tài)動(dòng)態(tài)數(shù)據(jù)區(qū)之外，還包括一份對(duì)類(lèi)自身的描述，也正是通過(guò)這描述中的信息，才能幫助我們才運(yùn)行時(shí)讀取里面的內(nèi)容，得到需要加載目標(biāo)類(lèi)的所有信息，從而實(shí)現(xiàn)反射機(jī)制。大家有沒(méi)有想過(guò)當(dāng)我們需要得到一個(gè)JavaBean的實(shí)例的時(shí)候，怎么知道它有哪些屬性呢？再明顯簡(jiǎn)單不過(guò)的例子就是自己寫(xiě)一個(gè)JavaBean的解析器：

a. 通過(guò)Class.forName(“Bean的類(lèi)名”)得到Class對(duì)象，例如叫ABeanClass
b. 通過(guò)ABeanClass的getMethods()方法，得到Method[]對(duì)象
c. 按照規(guī)范所有g(shù)et方法名后的單詞就代表著該Bean的一個(gè)屬性
d. 當(dāng)已經(jīng)知道一個(gè)方法名，可以調(diào)用newInstance()得到一個(gè)實(shí)例，然后通過(guò)invoke()方法將方法的名字和方法需要用的參數(shù)傳遞進(jìn)去，就可以動(dòng)態(tài)調(diào)用此方法。

當(dāng)然還有更復(fù)雜的應(yīng)用，這里就不贅述，大家可以參考Class類(lèi)和Method類(lèi)的方法。

4． 坦言Synchronize的本質(zhì)
Synchronize大家都知道是同步、加鎖的意思，其實(shí)它的本質(zhì)遠(yuǎn)沒(méi)有大家想得那么復(fù)雜。聲明Synchronize的方法被調(diào)用的時(shí)候，鎖其實(shí)是加載對(duì)象上，當(dāng)然如果是靜態(tài)類(lèi)則是加在類(lèi)上的鎖，調(diào)用結(jié)束鎖被解除。它的實(shí)現(xiàn)原理很簡(jiǎn)單，僅僅是不讓第二把鎖再次被加在同一個(gè)對(duì)象或類(lèi)上，僅此而已。一個(gè)簡(jiǎn)單的例子足以說(shuō)明問(wèn)題：
class A{
synchronized void f(){}
void g(){}
}

當(dāng)A的一個(gè)對(duì)象a被第一個(gè)線程調(diào)用其f()方法的時(shí)候，第二個(gè)線程不能調(diào)用a的synchronized方法例如f()，因?yàn)槟鞘窃谠噲D在對(duì)象上加第二把鎖。但調(diào)用g()卻是可以的，因?yàn)椴](méi)有在同一對(duì)象上加兩把鎖的行為產(chǎn)生。
這樣大家能理解了麼？明白它的原理能更好的幫助大家設(shè)計(jì)同步機(jī)制，不要濫用加鎖。

PS：下篇筆者計(jì)劃開(kāi)始對(duì)J2ee接觸到的各個(gè)方面來(lái)進(jìn)行總結(jié)，談?wù)勛约旱慕?jīng)驗(yàn)和想法。希望大家還能一如既往的支持筆者寫(xiě)下去，指正不足之處。

Java雜談（四）

不知不覺(jué)已經(jīng)寫(xiě)到第四篇了，論壇里面不斷的有朋友鼓勵(lì)我寫(xiě)下去。堅(jiān)持自己的作風(fēng)，把一切迷惑不容易理清楚的知識(shí)講出來(lái)，講到大家都能聽(tīng)懂，那么自己就真的懂了。最近在公司實(shí)習(xí)的時(shí)候Trainer跟我講了很多經(jīng)典事跡，對(duì)還未畢業(yè)的我來(lái)說(shuō)是筆不小的財(cái)富，我自己的信念是：人在逆境中成長(zhǎng)的速度要遠(yuǎn)遠(yuǎn)快過(guò)順境中，這樣來(lái)看一切都能欣然接受了。
好了，閑話不說(shuō)了，第三篇講的是反射機(jī)制集合框架之類(lèi)的，這次打算講講自己對(duì)反序列化和多線程的理解。希望能對(duì)大家學(xué)習(xí)Java起到幫助??

1．關(guān)于序列化和反序列化
應(yīng)該大家都大概知道Java中序列化和反序列化的意思，序列化就是把一個(gè)Java對(duì)象轉(zhuǎn)換成二進(jìn)制進(jìn)行磁盤(pán)上傳輸或者網(wǎng)絡(luò)流的傳輸，反序列化的意思就是把這個(gè)接受到的二進(jìn)制流重新組裝成原來(lái)的對(duì)象逆過(guò)程。它們?cè)贘ava中分別是通過(guò)ObjectInputStream和 ObjectInputStream這兩個(gè)類(lèi)來(lái)實(shí)現(xiàn)的（以下分別用ois和oos來(lái)簡(jiǎn)稱(chēng)）。

oos的writeObject()方法用來(lái)執(zhí)行序列化的過(guò)程，ois的readObject()用來(lái)執(zhí)行反序列化的過(guò)程，在傳輸二進(jìn)制流之前，需要講這兩個(gè)高層流對(duì)象連接到同一個(gè)Channel上，這個(gè)Channel可以是磁盤(pán)文件，也可以是socket底層流。所以無(wú)論用哪種方式，底層流對(duì)象都是以構(gòu)造函數(shù)參數(shù)的形式傳遞進(jìn)oos和ois這兩個(gè)高層流，連接完畢了才可以進(jìn)行二進(jìn)制數(shù)據(jù)傳輸?shù)?。例子?
可以是文件流通道
file = new File(“C:/data.dat”);
oos = new ObjectOutputStream(new FileOutputStream(file));
ois = new ObjectInputStream(new FileInputStream(file));

或者網(wǎng)絡(luò)流通道
oos = new ObjectOutputStream(socket.getOutputStream());
ois = new ObjectInputStream(socket.getInputStream());

不知道大家是否注意到oos總是在ois之前定義，這里不希望大家誤解這個(gè)順序是固定的么？回答是否定的，那么有順序要求么？回答是肯定的。原則是什么呢？
原則是互相對(duì)接的輸入/輸出流之間必須是output流先初始化然后再input流初始化，否則就會(huì)拋異常。大家肯定會(huì)問(wèn)為什么？只要稍微看一看這兩個(gè)類(lèi)的源代碼文件就大概知道了，output流的任務(wù)很簡(jiǎn)單，只要把對(duì)象轉(zhuǎn)換成二進(jìn)制往通道中寫(xiě)就可以了，但input流需要做很多準(zhǔn)備工作來(lái)接受并最終重組這個(gè)Object，所以O(shè)bjectInputStream的構(gòu)造函數(shù)中就需要用到output初始化發(fā)送過(guò)來(lái)的header信息，這個(gè)方法叫做 readStreamHeader()，它將會(huì)去讀兩個(gè)Short值用于決定用多大的緩存來(lái)存放通道發(fā)送過(guò)來(lái)的二進(jìn)制流，這個(gè)緩存的size因jre的版本不同是不一樣的。所以output如果不先初始化，input的構(gòu)造函數(shù)首先就無(wú)法正確運(yùn)行。

對(duì)于上面兩個(gè)例子，第一個(gè)順序是嚴(yán)格的，第二個(gè)因?yàn)閛os和ois連接的已經(jīng)不是對(duì)方了，而是socket另外一端的流，需要嚴(yán)格按照另外一方對(duì)接的output流先于對(duì)接的input流打開(kāi)才能順利運(yùn)行。

這個(gè)writeObject和readObject本身就是線程安全的，傳輸過(guò)程中是不允許被并發(fā)訪問(wèn)的。所以對(duì)象能一個(gè)一個(gè)接連不斷的傳過(guò)來(lái)，有很多人在運(yùn)行的時(shí)候會(huì)碰到EOFException, 然后百思不得其解，去各種論壇問(wèn)解決方案。其實(shí)筆者這里想說(shuō)，這個(gè)異常不是必須聲明的，也就是說(shuō)它雖然是異常，但其實(shí)是正常運(yùn)行結(jié)束的標(biāo)志。EOF表示讀到了文件尾，發(fā)送結(jié)束自然連接也就斷開(kāi)了。如果這影響到了你程序的正確性的話，請(qǐng)各位靜下心來(lái)看看自己程序的業(yè)務(wù)邏輯，而不要把注意力狹隘的聚集在發(fā)送和接受的方法上。因?yàn)楣P者也被這樣的bug困擾了1整天，被很多論壇的帖子誤解了很多次最后得出的教訓(xùn)。如果在while循環(huán)中去readObject，本質(zhì)上是沒(méi)有問(wèn)題的，有對(duì)象數(shù)據(jù)來(lái)就會(huì)讀，沒(méi)有就自動(dòng)阻塞。那么拋出EOFException一定是因?yàn)檫B接斷了還在繼續(xù)read，什么原因?qū)е逻B接斷了呢？一定是業(yè)務(wù)邏輯哪里存在錯(cuò)誤，比如NullPoint、 ClassCaseException、ArrayOutofBound，即使程序較大也沒(méi)關(guān)系，最多只要單步調(diào)適一次就能很快發(fā)現(xiàn)bug并且解決它。

難怪一位程序大師說(shuō)過(guò)：解決問(wèn)題90％靠經(jīng)驗(yàn)，5％靠技術(shù)，剩下5％靠運(yùn)氣！真是金玉良言，筆者大概查閱過(guò)不下30篇討論在while循環(huán)中使用 readObject拋出EOFExceptionde 的帖子，大家都盲目的去關(guān)注解釋這個(gè)名詞、反序列化的行為或反對(duì)這樣寫(xiě)而沒(méi)有一個(gè)人認(rèn)為EOF是正確的行為，它其實(shí)很老實(shí)的在做它的事情。為什么大家都忽略了真正出錯(cuò)誤的地方呢？?jī)蓚€(gè)字，經(jīng)驗(yàn)！

2．關(guān)于Java的多線程編程
關(guān)于Java的線程，初學(xué)或者接觸不深的大概也能知道一些基本概念，同時(shí)又會(huì)很迷惑線程到底是怎么回事？如果有人認(rèn)為自己已經(jīng)懂了不妨來(lái)回答下面的問(wèn)題：
a. A對(duì)象實(shí)現(xiàn)Runnable接口，A.start()運(yùn)行后所謂的線程對(duì)象是誰(shuí)？是A么？
b. 線程的wait()、notify()方法到底是做什么時(shí)候用的，什么時(shí)候用？
c. 為什么線程的suspend方法會(huì)被標(biāo)注過(guò)時(shí)，不推薦再使用，線程還能掛起么？
d. 為了同步我們會(huì)對(duì)線程方法聲明Synchronized來(lái)加鎖在對(duì)象上，那么如果父類(lèi)的f()方法加了Synchronized，子類(lèi)重寫(xiě)f()方法必須也加Synchronized么？如果子類(lèi)的f()方法重寫(xiě)時(shí)聲明Synchronized并調(diào)用super.f()，那么子類(lèi)對(duì)象上到底有幾把鎖呢？會(huì)因?yàn)楦?jìng)爭(zhēng)產(chǎn)生死鎖么？

呵呵，各位能回答上來(lái)幾道呢？如果這些都能答上來(lái)，說(shuō)明對(duì)線程的概念還是滿清晰的，雖說(shuō)還遠(yuǎn)遠(yuǎn)不能算精通。筆者這里一一做回答，礙于篇幅的原因，筆者盡量說(shuō)得簡(jiǎn)介一點(diǎn)，如果大家有疑惑的歡迎一起討論。

首先第一點(diǎn)，線程跟對(duì)象完全是兩回事，雖然我們也常說(shuō)線程對(duì)象。但當(dāng)你用run()和start()來(lái)啟動(dòng)一個(gè)線程之后，線程其實(shí)跟這個(gè)繼承了 Thread或?qū)崿F(xiàn)了Runnable的對(duì)象已經(jīng)沒(méi)有關(guān)系了，對(duì)象只能算內(nèi)存中可用資源而對(duì)象的方法只能算內(nèi)存正文區(qū)可以執(zhí)行的代碼段而已。既然是資源和代碼段，另外一個(gè)線程當(dāng)然也可以去訪問(wèn)，main函數(shù)執(zhí)行就至少會(huì)啟動(dòng)兩個(gè)線程，一個(gè)我們稱(chēng)之為主線程，還一個(gè)是垃圾收集器的線程，主線程結(jié)束就意味著程序結(jié)束，可垃圾收集器線程很可能正在工作。

第二點(diǎn)，wait()和sleep()類(lèi)似，都是讓線程處于阻塞狀態(tài)暫停一段時(shí)間，不同之處在于wait會(huì)釋放當(dāng)前線程占有的所有的鎖，而 sleep不會(huì)。我們知道獲得鎖的唯一方法是進(jìn)入了Synchronized保護(hù)代碼段，所以大家會(huì)發(fā)現(xiàn)只有Synchronized方法中才會(huì)出現(xiàn) wait，直接寫(xiě)會(huì)給警告沒(méi)有獲得當(dāng)前對(duì)象的鎖。所以notify跟wait配合使用，notify會(huì)重新把鎖還給阻塞的線程重而使其繼續(xù)執(zhí)行，當(dāng)有多個(gè)對(duì)象wait了，notify不能確定喚醒哪一個(gè)，必經(jīng)鎖只有一把，所以一般用notifyAll()來(lái)讓它們自己根據(jù)優(yōu)先級(jí)等競(jìng)爭(zhēng)那唯一的一把鎖，競(jìng)爭(zhēng)到的線程執(zhí)行，其他線程只要繼續(xù)wait。

從前Java允許在一個(gè)線程之外把線程掛起，即調(diào)用suspend方法，這樣的操作是極不安全的。根據(jù)面向?qū)ο蟮乃枷朊總€(gè)對(duì)象必須對(duì)自己的行為負(fù)責(zé)，而對(duì)自己的權(quán)力進(jìn)行封裝。如果任何外步對(duì)象都能使線程被掛起而阻塞的話，程序往往會(huì)出現(xiàn)混亂導(dǎo)致崩潰，所以這樣的方法自然是被斃掉了啦。

最后一個(gè)問(wèn)題比較有意思，首先回答的是子類(lèi)重寫(xiě)f()方法可以加Synchronized也可以不加，如果加了而且還內(nèi)部調(diào)用了super.f ()的話理論上是應(yīng)該對(duì)同一對(duì)象加兩把鎖的，因?yàn)槊看握{(diào)用Synchronized方法都要加一把，調(diào)用子類(lèi)的f首先就加了一把，進(jìn)入方法內(nèi)部調(diào)用父類(lèi)的 f又要加一把，加兩把不是互斥的么？那么調(diào)父類(lèi)f加鎖不就必須永遠(yuǎn)等待已經(jīng)加的鎖釋放而造成死鎖么？實(shí)際上是不會(huì)的，這個(gè)機(jī)制叫重進(jìn)入，當(dāng)父類(lèi)的f方法試圖在本對(duì)象上再加一把鎖的時(shí)候，因?yàn)楫?dāng)前線程擁有這個(gè)對(duì)象的鎖，也可以理解為開(kāi)啟它的鑰匙，所以同一個(gè)線程在同一對(duì)象上還沒(méi)釋放之前加第二次鎖是不會(huì)出問(wèn)題的，這個(gè)鎖其實(shí)根本就沒(méi)有加，它有了鑰匙，不管加幾把還是可以進(jìn)入鎖保護(hù)的代碼段，暢通無(wú)阻，所以叫重進(jìn)入，我們可以簡(jiǎn)單認(rèn)為第二把鎖沒(méi)有加上去。

總而言之，Synchronized的本質(zhì)是不讓其他線程在同一對(duì)象上再加一把鎖。?

Java雜談（五）

本來(lái)預(yù)計(jì)J2se只講了第四篇就收尾了，可是版主厚愛(ài)把帖子置頂長(zhǎng)期讓大家瀏覽讓小弟倍感責(zé)任重大，務(wù)必追求最到更好，所以關(guān)于J2se一些沒(méi)有提到的部分，決定再寫(xiě)幾篇把常用的部分經(jīng)驗(yàn)全部寫(xiě)出來(lái)供大家討論切磋。這一篇準(zhǔn)備講一講Xml解析包和Java Swing，然后下一篇再講java.security包關(guān)于Java沙箱安全機(jī)制和RMI機(jī)制，再進(jìn)入J2ee的部分，暫時(shí)就做這樣的計(jì)劃了。如果由于實(shí)習(xí)繁忙更新稍微慢了一些，希望各位見(jiàn)諒！

1． Java關(guān)于XML的解析
相信大家對(duì)XML都不陌生，含義是可擴(kuò)展標(biāo)記語(yǔ)言。本身它也就是一個(gè)數(shù)據(jù)的載體以樹(shù)狀表現(xiàn)形式出現(xiàn)。后來(lái)慢慢的數(shù)據(jù)變成了信息，區(qū)別是信息可以包括可變的狀態(tài)從而針對(duì)程序硬編碼的做法變革為針對(duì)統(tǒng)一接口硬編碼而可變狀態(tài)作為信息進(jìn)入了XML中存儲(chǔ)。這樣改變狀態(tài)實(shí)現(xiàn)擴(kuò)展的唯一工作是在XML中添加一段文本信息就可以了，代碼不需要改動(dòng)也不需要重新編譯。這個(gè)靈活性是XML誕生時(shí)候誰(shuí)也沒(méi)想到的。

當(dāng)然，如果接口要能提取XML中配置的信息就需要程序能解析規(guī)范的XML文件，Java中當(dāng)然要提高包對(duì)這個(gè)行為進(jìn)行有利支持。筆者打算講到的兩個(gè)包是 org.w3c.dom和javax.xml.parsers和。（大家可以瀏覽一下這些包中間的接口和類(lèi)定義）

Javax.xml.parsers包很簡(jiǎn)單，沒(méi)有接口，兩個(gè)工廠配兩個(gè)解析器。顯然解析XML是有兩種方式的：DOM解析和SAX解析。本質(zhì)上并沒(méi)有誰(shuí)好誰(shuí)不好，只是實(shí)現(xiàn)的思想不一樣罷了。給一個(gè)XML文件的例子：
<?xml version=”1.0” encoding=”UTF-8” >
<root >
<child name=”Kitty” >
A Cat
</child >
</root >

所謂DOM解析的思路是把整個(gè)樹(shù)狀圖存入內(nèi)存中，需要那個(gè)節(jié)點(diǎn)只需要在樹(shù)上搜索就可以讀到節(jié)點(diǎn)的屬性，內(nèi)容等，這樣的好處是所有節(jié)點(diǎn)皆在內(nèi)存可以反復(fù)搜索重復(fù)使用，缺點(diǎn)是需要消耗相應(yīng)的內(nèi)存空間。

自然SAX解析的思路就是為了克服DOM的缺點(diǎn)，以事件觸發(fā)為基本思路，順序的搜索下來(lái)，碰到了Element之前觸發(fā)什么事件，碰到之后做什么動(dòng)作。由于需要自己來(lái)寫(xiě)觸發(fā)事件的處理方案，所以需要借助另外一個(gè)自定義的Handler，處于org.xml.sax.helpers包中。它的優(yōu)點(diǎn)當(dāng)然是不用整個(gè)包都讀入內(nèi)存，缺點(diǎn)也是只能順序搜索，走完一遍就得重來(lái)。

大家很容易就能猜到，接觸到的J2ee框架用的是哪一種，顯然是DOM。因?yàn)轭?lèi)似Struts，Hibernate框架配置文件畢竟是很小的一部分配置信息，而且需要頻繁搜索來(lái)讀取，當(dāng)然會(huì)采用DOM方式（其實(shí)SAX內(nèi)部也是用DOM采用的結(jié)構(gòu)來(lái)存儲(chǔ)節(jié)點(diǎn)信息的）?，F(xiàn)在無(wú)論用什么框架，還真難發(fā)現(xiàn)使用 SAX來(lái)解析XML的技術(shù)了，如果哪位仁兄知道，請(qǐng)讓筆者也學(xué)習(xí)學(xué)習(xí)。

既然解析方式有了，那么就需要有解析的存儲(chǔ)位置。不知道大家是否發(fā)現(xiàn)org.w3c.dom這個(gè)包是沒(méi)有實(shí)現(xiàn)類(lèi)全部都是接口的。這里筆者想說(shuō)一下Java 如何對(duì)XML解析是Jdk應(yīng)該考慮的事，是它的責(zé)任。而w3c組織是維護(hù)定義XML標(biāo)準(zhǔn)的組織，所以一個(gè)XML結(jié)構(gòu)是怎么樣的由w3c說(shuō)了算，它不關(guān)心 Java如何去實(shí)現(xiàn)，于是乎規(guī)定了所有XML存儲(chǔ)的結(jié)構(gòu)應(yīng)該遵循的規(guī)則，這就是org.w3c.dom里全部的接口目的所在。在筆者看來(lái)，簡(jiǎn)單理解接口的概念就是實(shí)現(xiàn)者必須遵守的原則。

整個(gè)XML對(duì)應(yīng)的結(jié)構(gòu)叫Document、子元素對(duì)應(yīng)的叫做Element、還有節(jié)點(diǎn)相關(guān)的Node、NodeList、Text、Entity、 CharacterData、CDATASection等接口，它們都可以在XML的語(yǔ)法中間找到相對(duì)應(yīng)的含義。由于這里不是講解XML基本語(yǔ)法，就不多介紹了。如果大家感興趣，筆者也可以專(zhuān)門(mén)寫(xiě)一篇關(guān)于XML的語(yǔ)法規(guī)則帖與大家分享一下。

2． Java Swing
Swing是一個(gè)讓人又愛(ài)又恨的東西，可愛(ài)之處在于上手很容易，較AWT比起來(lái)Swing提供的界面功能更加強(qiáng)大，可恨之處在于編復(fù)雜的界面工作量實(shí)在是巨大。筆者寫(xiě)過(guò)超過(guò)3000行的Swing界面，感覺(jué)用戶(hù)體驗(yàn)還不是那么優(yōu)秀。最近又寫(xiě)過(guò)超過(guò)6000行的，由于功能模塊多了，整體效果還只是一般般。體會(huì)最深的就一個(gè)字：累! 所以大家現(xiàn)在都陸續(xù)不怎么用Swing在真正開(kāi)發(fā)的項(xiàng)目上了，太多界面技術(shù)可以取代它了。筆者去寫(xiě)也是迫于無(wú)奈組里面大家都沒(méi)寫(xiě)過(guò)，我不入地域誰(shuí)入？

盡管Swing慢慢的在被人忽略，特別是隨著B(niǎo)/S慢慢的在淹沒(méi)C/S，筆者倒是很愿意站出來(lái)為Swing正身。每一項(xiàng)技術(shù)的掌握絕不是為了流行時(shí)尚跟風(fēng)。真正喜歡Java的朋友們還是應(yīng)該好好體會(huì)一下Swing，相信在校的很多學(xué)生也很多在學(xué)習(xí)它。很可能從Jdk 1.1、1.2走過(guò)來(lái)的很多大學(xué)老師可能是最不熟悉它的。
Swing提供了一組輕組件統(tǒng)稱(chēng)為JComponent，它們與AWT組件的最大區(qū)別是JComponent全部都是Container，而 Container的特點(diǎn)是里面可以裝載別的組件。在Swing組件中無(wú)論是JButton、JLabel、JPanel、JList等都可以再裝入任何其他組件。好處是程序員可以對(duì)Swing組件實(shí)現(xiàn)“再開(kāi)發(fā)”，針對(duì)特定需求構(gòu)建自己的按鈕、標(biāo)簽、畫(huà)板、列表之類(lèi)的特定組件。

有輕自然就有重，那么輕組件和重組件區(qū)別是？重組件表現(xiàn)出來(lái)的形態(tài)因操作系統(tǒng)不同而異，輕組件是Swing自己提供GUI，在跨平臺(tái)的時(shí)候最大程度的保持一致。
那么在編程的時(shí)候要注意一些什么呢？筆者談?wù)勛约旱膸c(diǎn)經(jīng)驗(yàn)：

a. 明確一個(gè)概念，只有Frame組件才可以單獨(dú)顯示的，也許有人會(huì)說(shuō)JOptionPane里面的靜態(tài)方法就實(shí)現(xiàn)了單獨(dú)窗口出現(xiàn)，但追尋源代碼會(huì)發(fā)現(xiàn)其實(shí)現(xiàn)實(shí)出來(lái)的Dialog也需要依托一個(gè)Frame窗體，如果沒(méi)有指定就會(huì)默認(rèn)產(chǎn)生一個(gè)然后裝載這個(gè)Dialog顯示出來(lái)。

b. JFrame是由這么幾部分組成：
最底下一層JRootPane，上面是glassPane (一個(gè)JPanel)和layeredPane (一個(gè)JLayeredPane)，而layeredPane又由contentPane(一個(gè)JPanel)和menuBar構(gòu)成。我們的組件都是加在 contentPane上，而背景圖片只能加在layeredPane上面。 至于glassPane是一個(gè)透明的覆蓋了contentPane的一層，在特定效果中將被利用到來(lái)記錄鼠標(biāo)坐標(biāo)或掩飾組件。

c. 為了增強(qiáng)用戶(hù)體驗(yàn)，我們會(huì)在一些按鈕上添加快捷鍵，但Swing里面通常只能識(shí)別鍵盤(pán)的Alt鍵，要加入其他的快捷鍵，必須自己實(shí)現(xiàn)一個(gè)ActionListener。

d. 通過(guò)setLayout(null)可以使得所有組件以setBounds()的四個(gè)參數(shù)來(lái)精確定位各自的大小、位置，但不推薦使用，因?yàn)楹玫木幊田L(fēng)格不應(yīng)該在Swing代碼中硬編碼具體數(shù)字，所有的數(shù)字應(yīng)該以常數(shù)的形式統(tǒng)一存在一個(gè)靜態(tài)無(wú)實(shí)例資源類(lèi)文件中。這個(gè)靜態(tài)無(wú)實(shí)例類(lèi)統(tǒng)一負(fù)責(zé)Swing界面的風(fēng)格，包括字體和顏色都應(yīng)該包括進(jìn)去。

e. 好的界面設(shè)計(jì)有一條Golden Rule: 用戶(hù)不用任何手冊(cè)通過(guò)少數(shù)嘗試就能學(xué)會(huì)使用軟件。所以盡量把按鈕以菜單的形式（不管是右鍵菜單還是窗體自帶頂部菜單）呈現(xiàn)給顧客，除非是頻繁點(diǎn)擊的按鈕才有必要直接呈現(xiàn)在界面中。

其實(shí)Swing的功能是相當(dāng)強(qiáng)大的，只是現(xiàn)在應(yīng)用不廣泛，專(zhuān)門(mén)去研究大概是要花不少時(shí)間的。筆者在各網(wǎng)站論壇瀏覽關(guān)于Swing的技巧文章還是比較可信的，自己所學(xué)非常有限，各人體會(huì)對(duì)Swing各個(gè)組件的掌握就是一個(gè)實(shí)踐積累的過(guò)程。筆者只用到過(guò)以上這些，所以只能談?wù)劜糠窒敕ǎ€望大家見(jiàn)諒！?

Java雜談（六）

這篇是筆者打算寫(xiě)的J2se部分的最后一篇了，這篇結(jié)束之后，再寫(xiě)J2ee部分，不知道是否還合適寫(xiě)在這個(gè)版塊？大家可以給點(diǎn)意見(jiàn)，謝謝大家對(duì)小弟這么鼓勵(lì)一路寫(xiě)完前六篇Java雜談的J2se部分。最后這篇打算談一談Java中的RMI機(jī)制和JVM沙箱安全框架。

1． Java中的RMI機(jī)制
RMI的全稱(chēng)是遠(yuǎn)程方法調(diào)用，相信不少朋友都聽(tīng)說(shuō)過(guò)，基本的思路可以用一個(gè)經(jīng)典比方來(lái)解釋?zhuān)篈計(jì)算機(jī)想要計(jì)算一個(gè)兩個(gè)數(shù)的加法，但A自己做不了，于是叫另外一臺(tái)計(jì)算機(jī)B幫忙，B有計(jì)算加法的功能，A調(diào)用它就像調(diào)用這個(gè)功能是自己的一樣方便。這個(gè)就叫做遠(yuǎn)程方法調(diào)用了。

遠(yuǎn)程方法調(diào)用是EJB實(shí)現(xiàn)的支柱，建立分布式應(yīng)用的核心思想。這個(gè)很好理解，再拿上面的計(jì)算加法例子，A只知道去call計(jì)算機(jī)B的方法，自己并沒(méi)有B的那些功能，所以A計(jì)算機(jī)端就無(wú)法看到B執(zhí)行這段功能的過(guò)程和代碼，因?yàn)榭炊伎床坏剑约葲](méi)有機(jī)會(huì)竊取也沒(méi)有機(jī)會(huì)去改動(dòng)方法代碼。EJB正式基于這樣的思想來(lái)完成它的任務(wù)的。當(dāng)簡(jiǎn)單的加法變成復(fù)雜的數(shù)據(jù)庫(kù)操作和電子商務(wù)交易應(yīng)用的時(shí)候，這樣的安全性和分布式應(yīng)用的便利性就表現(xiàn)出來(lái)優(yōu)勢(shì)了。

好了，回到細(xì)節(jié)上，要如何實(shí)現(xiàn)遠(yuǎn)程方法調(diào)用呢？我希望大家學(xué)習(xí)任何技術(shù)的時(shí)候可以試著依賴(lài)自己的下意識(shí)判斷，只要你的想法是合理健壯的，那么很可能實(shí)際上它就是這么做的，畢竟真理都蘊(yùn)藏在平凡的生活細(xì)節(jié)中。這樣只要帶著一些薄弱的Java基礎(chǔ)來(lái)思考RMI，其實(shí)也可以想出個(gè)大概來(lái)。

a) 需要有一個(gè)服務(wù)器角色，它擁有真正的功能代碼方法。例如B，它提供加法服務(wù)
b) 如果想遠(yuǎn)程使用B的功能，需要知道B的IP地址
c) 如果想遠(yuǎn)程使用B的功能，還需要知道B中那個(gè)特定服務(wù)的名字

我們很自然可以想到這些，雖然不完善，但已經(jīng)很接近正確的做法了。實(shí)際上RMI要得以實(shí)現(xiàn)還得意于Java一個(gè)很重要的特性，就是Java反射機(jī)制。我們需要知道服務(wù)的名字，但又必須隱藏實(shí)現(xiàn)的代碼，如何去做呢？答案就是：接口！
舉個(gè)例子：
public interface Person(){
public void sayHello();
}

Public class PersonImplA implements Person{
public PersonImplA(){}

public void sayHello(){ System.out.println(“Hello!”);}
}

Public class PersonImplB implements Person{
public PersonImplB(){}

public void sayHello(){ System.out.println(“Nice to meet you!”);}
}

客戶(hù)端：Person p = Naming.lookup(“PersonService”);
p.sayHello();

就這幾段代碼就包含了幾乎所有的實(shí)現(xiàn)技術(shù)，大家相信么？客戶(hù)端請(qǐng)求一個(gè)say hello服務(wù)，服務(wù)器運(yùn)行時(shí)接到這個(gè)請(qǐng)求，利用Java反射機(jī)制的Class.newInstance()返回一個(gè)對(duì)象，但客戶(hù)端不知道服務(wù)器返回的是 ImplA還是ImplB，它接受用的參數(shù)簽名是Person，它知道實(shí)現(xiàn)了Person接口的對(duì)象一定有sayHello()方法，這就意味著客戶(hù)端并不知道服務(wù)器真正如何去實(shí)現(xiàn)的，但它通過(guò)了解Person接口明確了它要用的服務(wù)方法名字叫做sayHello()。

如此類(lèi)推，服務(wù)器只需要暴露自己的接口出來(lái)供客戶(hù)端，所有客戶(hù)端就可以自己選擇需要的服務(wù)。這就像餐館只要拿出自己的菜單出來(lái)讓客戶(hù)選擇，就可以在后臺(tái)廚房一道道的按需做出來(lái)，它怎么做的通常是不讓客戶(hù)知道的?。ㄗ?zhèn)鞑俗V吧，^_^）

最后一點(diǎn)是我調(diào)用lookup，查找一個(gè)叫PersonService名字的對(duì)象，服務(wù)器只要看到這個(gè)名字，在自己的目錄（相當(dāng)于電話簿）中找到對(duì)應(yīng)的對(duì)象名字提供服務(wù)就可以了，這個(gè)目錄就叫做JNDI (Java命名與目錄接口），相信大家也聽(tīng)過(guò)的。

有興趣的朋友不妨自己做個(gè)RMI的應(yīng)用，很多前輩的博客中有簡(jiǎn)單的例子。提示一下利用Jdk的bin目錄中rmi.exe和 rmiregistry.exe兩個(gè)命令就可以自己建起一個(gè)服務(wù)器，提供遠(yuǎn)程服務(wù)。因?yàn)槔雍苋菀渍?，我就不自己舉例子了！

2． JVM沙箱&框架
RMI羅唆得太多了，實(shí)在是盡力想把它說(shuō)清楚，希望對(duì)大家有幫助。最后的最后，給大家簡(jiǎn)單講一下JVM框架，我們叫做Java沙箱。Java沙箱的基本組件如下：
a) 類(lèi)裝載器結(jié)構(gòu)
b) class文件檢驗(yàn)器
c) 內(nèi)置于Java虛擬機(jī)的安全特性
d) 安全管理器及Java API

其中類(lèi)裝載器在3個(gè)方面對(duì)Java沙箱起作用：
a. 它防止惡意代碼去干涉善意的代碼
b. 它守護(hù)了被信任的類(lèi)庫(kù)邊界
c. 它將代碼歸入保護(hù)域，確定了代碼可以進(jìn)行哪些操作

虛擬機(jī)為不同的類(lèi)加載器載入的類(lèi)提供不同的命名空間，命名空間由一系列唯一的名稱(chēng)組成，每一個(gè)被裝載的類(lèi)將有一個(gè)名字，這個(gè)命名空間是由Java虛擬機(jī)為每一個(gè)類(lèi)裝載器維護(hù)的，它們互相之間甚至不可見(jiàn)。

我們常說(shuō)的包（package）是在Java虛擬機(jī)第2版的規(guī)范第一次出現(xiàn)，正確定義是由同一個(gè)類(lèi)裝載器裝載的、屬于同一個(gè)包、多個(gè)類(lèi)型的集合。類(lèi)裝載器采用的機(jī)制是雙親委派模式。具體的加載器框架我在Java雜談（一）中已經(jīng)解釋過(guò)了，當(dāng)時(shí)說(shuō)最外層的加載器是AppClassLoader，其實(shí)算上網(wǎng)絡(luò)層的話AppClassLoader也可以作為parent，還有更外層的加載器URLClassLoader。為了防止惡意攻擊由URL加載進(jìn)來(lái)的類(lèi)文件我們當(dāng)然需要分不同的訪問(wèn)命名空間，并且制定最安全的加載次序，簡(jiǎn)單來(lái)說(shuō)就是兩點(diǎn)：

a. 從最內(nèi)層JVM自帶類(lèi)加載器開(kāi)始加載，外層惡意同名類(lèi)得不到先加載而無(wú)法使用
b. 由于嚴(yán)格通過(guò)包來(lái)區(qū)分了訪問(wèn)域，外層惡意的類(lèi)通過(guò)內(nèi)置代碼也無(wú)法獲得權(quán)限訪問(wèn)到內(nèi)層類(lèi)，破壞代碼就自然無(wú)法生效。

附：關(guān)于Java的平臺(tái)無(wú)關(guān)性，有一個(gè)例子可以很明顯的說(shuō)明這個(gè)特性：
一般來(lái)說(shuō)，C或C++中的int占位寬度是根據(jù)目標(biāo)平臺(tái)的字長(zhǎng)來(lái)決定的，這就意味著針對(duì)不同的平臺(tái)編譯同一個(gè)C++程序在運(yùn)行時(shí)會(huì)有不同的行為。然而對(duì)于 Java中的int都是32位的二進(jìn)制補(bǔ)碼標(biāo)識(shí)的有符號(hào)整數(shù)，而float都是遵守IEEE 754浮點(diǎn)標(biāo)準(zhǔn)的32位浮點(diǎn)數(shù)。

PS: 這個(gè)小弟最近也沒(méi)時(shí)間繼續(xù)研究下去了，只是想拋磚引玉的提供給大家一個(gè)初步認(rèn)識(shí)JVM的印象。有機(jī)會(huì)了解一下JVM的內(nèi)部結(jié)構(gòu)對(duì)今后做Java開(kāi)發(fā)是很有好處的。

Java雜談（七）－－接口& 組件、容器

終于又靜下來(lái)繼續(xù)寫(xiě)這個(gè)主題的續(xù)篇，前六篇主要講了一些J2se方面的經(jīng)驗(yàn)和感受， 眼下Java應(yīng)用范圍已經(jīng)被J2ee占據(jù)了相當(dāng)大的一塊領(lǐng)域，有些人甚至聲稱(chēng)Java被J2ee所取代了。不知道大家如何來(lái)理解所謂的J2ee (Java2 Enterprise Edition)，也就是Java企業(yè)級(jí)應(yīng)用？

筆者的觀點(diǎn)是，技術(shù)的發(fā)展是順應(yīng)世界變化的趨勢(shì)的，從C/S過(guò)渡到B/S模式，從客戶(hù)端的角度考慮企業(yè)級(jí)應(yīng)用或者說(shuō)電子商務(wù)領(lǐng)域不在關(guān)心客戶(hù)端維護(hù)問(wèn)題，這個(gè)任務(wù)已經(jīng)交給了任何一臺(tái)PC都會(huì)有的瀏覽器去維護(hù)；從服務(wù)器端的角度考慮，以往C/S中的TCP/IP協(xié)議實(shí)現(xiàn)載體ServerSocket被Web Server Container所取代，例如大家都很熟悉的Tomcat、JBoss、WebLogic等等。總之一切的轉(zhuǎn)變都是為了使得Java技術(shù)能更好的為人類(lèi)生產(chǎn)生活所服務(wù)。

有人會(huì)問(wèn)，直接去學(xué)J2ee跳過(guò)J2se行否？筆者是肯定不贊成的，實(shí)際上確實(shí)有人走這條路，但筆者自身體會(huì)是正是由于J2se的基礎(chǔ)很牢固，才會(huì)導(dǎo)致在J2ee學(xué)習(xí)的道路上順風(fēng)順?biāo)?，知識(shí)點(diǎn)上不會(huì)有什么迷惑的地方。舉個(gè)簡(jiǎn)單的例子吧：

筆者曾經(jīng)跟大學(xué)同學(xué)討論下面這兩種寫(xiě)法的區(qū)別：
ArrayList list = new ArrayList(); //筆者不說(shuō)反對(duì)，但至少不贊成
List list = new ArrayList(); //筆者支持
曾經(jīng)筆者跟同學(xué)爭(zhēng)論了幾個(gè)小時(shí)，他非說(shuō)第一種寫(xiě)法更科學(xué)，第二種完全沒(méi)有必要。我無(wú)法完全說(shuō)服他，但筆者認(rèn)為良好的習(xí)慣和意識(shí)是任何時(shí)候都應(yīng)該針對(duì)接口編程，以達(dá)到解耦合和可擴(kuò)展性的目的。下面就以接口開(kāi)始進(jìn)入J2ee的世界吧：

1. J2ee與接口

每一個(gè)版本的J2ee都對(duì)應(yīng)著一個(gè)確定版本的JDK，J2ee1.4對(duì)應(yīng)Jdk1.4，現(xiàn)在比較新的是JDK5.0，自然也會(huì)有J2EE 5.0。其實(shí)筆者一直在用的是J2EE1.4，不過(guò)沒(méi)什么關(guān)系，大家可以下任何一個(gè)版本的J2ee api來(lái)稍微瀏覽一下。筆者想先聲明一個(gè)概念，J2ee也是源自Java，所以底層的操作依然調(diào)用到很多J2se的庫(kù)，所以才建議大家先牢牢掌握J(rèn)2se 的主流技術(shù)。

J2ee api有一個(gè)特點(diǎn)，大家比較熟悉的幾個(gè)包java.jms、javax.servlet.http、javax.ejb等都以interface居多，實(shí)現(xiàn)類(lèi)較少。其實(shí)大家真正在用的時(shí)候百分之六十以上都在反復(fù)的查著javax.servlet.http這個(gè)包下面幾個(gè)實(shí)現(xiàn)類(lèi)的api函數(shù)，其他的包很少問(wèn)津。筆者建議在學(xué)習(xí)一種技術(shù)之前，對(duì)整體的框架有一個(gè)了解是很有必要的，J2ee旨在通過(guò)interface的聲明來(lái)規(guī)范實(shí)現(xiàn)的行為，任何第三方的廠商想要提供自己品牌的實(shí)現(xiàn)前提也是遵循這些接口定義的規(guī)則。如果在從前J2se學(xué)習(xí)的道路上對(duì)接口的理解很好的話，這里的體會(huì)將是非常深刻的，舉個(gè)簡(jiǎn)單的例子：

public interface Mp3{
public void play();
public void record();
public void stop();
}

如果我定義這個(gè)簡(jiǎn)單的接口，發(fā)布出去，規(guī)定任何第三方的公司想推出自己的名字為Mp3的產(chǎn)品都必須實(shí)現(xiàn)這個(gè)接口，也就是至少提供接口中方法的具體實(shí)現(xiàn)。這個(gè)意義已經(jīng)遠(yuǎn)遠(yuǎn)不止是面向?qū)ο蟮亩鄳B(tài)了，只有廠商遵循J2ee的接口定義，世界上的J2ee程序員才能針對(duì)統(tǒng)一的接口進(jìn)行程序設(shè)計(jì)，最終不用改變代碼只是因?yàn)槭褂昧瞬煌瑥S商的實(shí)現(xiàn)類(lèi)而有不同的特性罷了，本質(zhì)上說(shuō)，無(wú)論哪一種廠商實(shí)現(xiàn)都完成了職責(zé)范圍內(nèi)的工作。這個(gè)就是筆者想一直強(qiáng)調(diào)的，針對(duì)接口編程的思想。

接口到底有什么好處呢？我們這樣設(shè)想，現(xiàn)在有AppleMp3、SonyMp3、SamsungMp3都實(shí)現(xiàn)了這個(gè)Mp3的接口，于是都有了play、 record、stop這三個(gè)功能。我們將Mp3產(chǎn)品座位一個(gè)組件的時(shí)候就不需要知道它的具體實(shí)現(xiàn)，只要看到接口定義知道這個(gè)對(duì)象有3個(gè)功能就可以使用了。那么類(lèi)似下面這樣的業(yè)務(wù)就完全可以在任何時(shí)間從3個(gè)品牌擴(kuò)展到任意個(gè)品牌，開(kāi)個(gè)玩笑的說(shuō)，項(xiàng)目經(jīng)理高高在上的寫(xiě)完10個(gè)接口里的方法聲明，然后就丟給手下的程序員去寫(xiě)里面的細(xì)節(jié)，由于接口已經(jīng)統(tǒng)一（即每個(gè)方法傳入和傳出的格式已經(jīng)統(tǒng)一），經(jīng)理只需關(guān)注全局的業(yè)務(wù)就可以天天端杯咖啡走來(lái)走去了，^_^：
public Mp3 create();
public void copy(Mp3 mp3);
public Mp3 getMp3();

最后用一個(gè)簡(jiǎn)單的例子說(shuō)明接口：一個(gè)5號(hào)電池的手電筒，可以裝入任何牌子的5號(hào)電池，只要它符合5號(hào)電池的規(guī)范，裝入之后任何看不到是什么牌子，只能感受到手電筒在完成它的功能。那么生產(chǎn)手電筒的廠商和生產(chǎn)5號(hào)電池的廠商就可以完全解除依賴(lài)關(guān)系，可以各自自由開(kāi)發(fā)自己的產(chǎn)品，因?yàn)樗鼈兌甲袷?號(hào)電池應(yīng)有的形狀、正負(fù)極位置等約定。這下大家能對(duì)接口多一點(diǎn)體會(huì)了么？

2. 組件和容器
針對(duì)接口是筆者特意強(qiáng)調(diào)的J2ee學(xué)習(xí)之路必備的思想，另外一個(gè)就是比較常規(guī)的組件和容器的概念了。很多教材和專(zhuān)業(yè)網(wǎng)站都說(shuō)J2EE的核心是一組規(guī)范與指南，強(qiáng)調(diào)J2ee的核心概念就是組件+容器，這確實(shí)是無(wú)可厚非的。隨著越來(lái)越多的J2ee框架出現(xiàn)，相應(yīng)的每種框架都一般有與之對(duì)應(yīng)的容器。

容器，是用來(lái)管理組件行為的一個(gè)集合工具，組件的行為包括與外部環(huán)境的交互、組件的生命周期、組件之間的合作依賴(lài)關(guān)系等等。J2ee包含的容器種類(lèi)大約有 Web容器、Application Client容器、EJB容器、Applet客戶(hù)端容器等。但在筆者看來(lái)，現(xiàn)在容器的概念變得有點(diǎn)模糊了，大家耳熟能詳是那些功能強(qiáng)大的開(kāi)源框架，比如 Hibernate、Struts2、Spring、JSF等，其中Hibernate就基于JDBC的基礎(chǔ)封裝了對(duì)事務(wù)和會(huì)話的管理，大大方便了對(duì)數(shù)據(jù)庫(kù)操作的繁瑣代碼，從這個(gè)意義上來(lái)說(shuō)它已經(jīng)接近容器的概念了，EJB的實(shí)體Bean也逐漸被以Hibernate為代表的持久化框架所取代。

組件，本意是指可以重用的代碼單元，一般代表著一個(gè)或者一組可以獨(dú)立出來(lái)的功能模塊，在J2ee中組件的種類(lèi)有很多種，比較常見(jiàn)的是EJB組件、DAO組件、客戶(hù)端組件或者應(yīng)用程序組件等，它們有個(gè)共同特點(diǎn)是分別會(huì)打包成.war，.jar，.jar，.ear，每個(gè)組件由特定格式的xml描述符文件進(jìn)行描述，而且服務(wù)器端的組件都需要被部署到應(yīng)用服務(wù)器上面才能夠被使用。

稍微理解完組件和容器，還有一個(gè)重要的概念就是分層模型，最著名的當(dāng)然是MVC三層模型。在一個(gè)大的工程或項(xiàng)目中，為了讓前臺(tái)和后臺(tái)各個(gè)模塊的編程人員能夠同時(shí)進(jìn)行工作提高開(kāi)發(fā)效率，最重要的就是實(shí)現(xiàn)層與層之間的耦合關(guān)系，許多分層模型的宗旨和開(kāi)源框架所追求的也就是這樣的效果。在筆者看來(lái)，一個(gè)完整的 Web項(xiàng)目大概有以下幾個(gè)層次：

a) 表示層（Jsp、Html、Javascript、Ajax、Flash等等技術(shù)對(duì)其支持）
b) 控制層（Struts、JSF、WebWork等等框架在基于Servlet的基礎(chǔ)上支持，負(fù)責(zé)把具體的請(qǐng)求數(shù)據(jù)（有時(shí)卸載重新裝載）導(dǎo)向適合處理它的模型層對(duì)象）
c) 模型層（筆者認(rèn)為目前最好的框架是Spring，實(shí)質(zhì)就是處理表示層經(jīng)由控制層轉(zhuǎn)發(fā)過(guò)來(lái)的數(shù)據(jù)，包含著大量的業(yè)務(wù)邏輯）
d) 數(shù)據(jù)層（Hibernate、JDBC、EJB等，由模型層處理完了持久化到數(shù)據(jù)庫(kù)中）

當(dāng)然，這僅僅是筆者個(gè)人的觀點(diǎn)，僅僅是供大家學(xué)習(xí)做一個(gè)參考，如果要實(shí)現(xiàn)這些層之間的完全分離，那么一個(gè)大的工程，可以?xún)H僅通過(guò)增加人手就來(lái)完成任務(wù)。雖然《人月神話》中已經(jīng)很明確的闡述了增加人手并不能是效率增加，很大程度上是因?yàn)楸舜俗龅墓ぷ饔许樞蛏系囊蕾?lài)關(guān)系或者說(shuō)難度和工作量上的巨大差距。當(dāng)然理想狀態(tài)在真實(shí)世界中是不可能達(dá)到的，但我們永遠(yuǎn)應(yīng)該朝著這個(gè)方向去不斷努力。最開(kāi)始所提倡的針對(duì)接口來(lái)編程，哪怕是小小的細(xì)節(jié)，寫(xiě)一條List list= = new ArrayList()語(yǔ)句也能體現(xiàn)著處處皆使用接口的思想在里面。Anyway，這只是個(gè)開(kāi)篇，筆者會(huì)就自己用過(guò)的J2ee技術(shù)和框架再細(xì)化談一些經(jīng)驗(yàn)

Java雜談（八）－－Servlet/Jsp
終于正式進(jìn)入J2ee的細(xì)節(jié)部分了，首當(dāng)其沖的當(dāng)然是Servlet和Jsp了，上篇曾經(jīng)提到過(guò)J2ee只是一個(gè)規(guī)范和指南，定義了一組必須要遵循的接口，核心概念是組件和容器。曾經(jīng)有的人問(wèn)筆者Servlet的Class文件是哪里來(lái)的？他認(rèn)為是J2ee官方提供的，我舉了一個(gè)簡(jiǎn)單的反例：稍微檢查了一下Tomcat5.0里面的Servlet.jar文件和JBoss里面的Servlet.jar文件大小，很明顯是不一樣的，至少已經(jīng)說(shuō)明了它們不是源自同根的吧。其實(shí)Servlet是由容器根據(jù)J2ee的接口定義自己來(lái)實(shí)現(xiàn)的，實(shí)現(xiàn)的方式當(dāng)然可以不同，只要都遵守J2ee規(guī)范和指南。

上述只是一個(gè)常見(jiàn)的誤區(qū)罷了，告訴我們要編譯運(yùn)行Servlet，是要依賴(lài)于實(shí)現(xiàn)它的容器的，不然連jar文件都沒(méi)有，編譯都無(wú)法進(jìn)行。那么Jsp呢？ Java Server Page的簡(jiǎn)稱(chēng)，是為了開(kāi)發(fā)動(dòng)態(tài)網(wǎng)頁(yè)而誕生的技術(shù)，其本質(zhì)也是Jsp，在編寫(xiě)完畢之后會(huì)在容器啟動(dòng)時(shí)經(jīng)過(guò)編譯成對(duì)應(yīng)的Servlet。只是我們利用Jsp 的很多新特性，可以更加專(zhuān)注于前后臺(tái)的分離，早期Jsp做前臺(tái)是滿流行的，畢竟里面支持Html代碼，這讓前臺(tái)美工人員可以更有效率的去完成自己的工作。然后Jsp將請(qǐng)求轉(zhuǎn)發(fā)到后臺(tái)的Servlet，由Servlet處理業(yè)務(wù)邏輯，再轉(zhuǎn)發(fā)回另外一個(gè)Jsp在前臺(tái)顯示出來(lái)。這似乎已經(jīng)成為一種常用的模式，最初筆者學(xué)習(xí)J2ee的時(shí)候，大量時(shí)間也在編寫(xiě)這樣的代碼。

盡管現(xiàn)在做前臺(tái)的技術(shù)越來(lái)越多，例如Flash、Ajax等，已經(jīng)有很多人不再認(rèn)為Jsp重要了。筆者覺(jué)得Jsp帶來(lái)的不僅僅是前后端分離的設(shè)計(jì)理念，它的另外一項(xiàng)技術(shù)成就了我們今天用的很多框架，那就是Tag標(biāo)簽技術(shù)。所以與其說(shuō)是在學(xué)習(xí)Jsp，不如更清醒的告訴自己在不斷的理解Tag標(biāo)簽的意義和本質(zhì)。

1． Servlet以及Jsp的生命周期
Servlet是Jsp的實(shí)質(zhì)，盡管容器對(duì)它們的處理有所區(qū)別。Servlet有init()方法初始化，service()方法進(jìn)行Web服務(wù)， destroy()方法進(jìn)行銷(xiāo)毀，從生到滅都由容器來(lái)掌握，所以這些方法除非你想自己來(lái)實(shí)現(xiàn)Servlet，否則是很少會(huì)接觸到的。正是由于很少接觸，才容易被廣大初學(xué)者所忽略，希望大家至少記住Servlet生命周期方法都是回調(diào)方法?；卣{(diào)這個(gè)概念簡(jiǎn)單來(lái)說(shuō)就是把自己注入另外一個(gè)類(lèi)中，由它來(lái)調(diào)用你的方法，所謂的另外一個(gè)類(lèi)就是Web容器，它只認(rèn)識(shí)接口和接口的方法，注入進(jìn)來(lái)的是怎樣的對(duì)象不管，它只會(huì)根據(jù)所需調(diào)用這個(gè)對(duì)象在接口定義存在的那些方法。由容器來(lái)調(diào)用的Servlet對(duì)象的初始化、服務(wù)和銷(xiāo)毀方法，所以叫做回調(diào)。這個(gè)概念對(duì)學(xué)習(xí)其他J2ee技術(shù)相當(dāng)關(guān)鍵！

那么Jsp呢？本事上是Servlet，還是有些區(qū)別的，它的生命周期是這樣的：
a) 一個(gè)客戶(hù)端的Request到達(dá)服務(wù)器 ->
b) 判斷是否第一次調(diào)用 -> 是的話編譯Jsp成Servlet
c) 否的話再判斷此Jsp是否有改變 -> 是的話也重新編譯Jsp成Servlet
d) 已經(jīng)編譯最近版本的Servlet裝載所需的其他Class
e) 發(fā)布Servlet，即調(diào)用它的Service()方法

所以Jsp號(hào)稱(chēng)的是第一次Load緩慢，以后都會(huì)很快的運(yùn)行。從它的生命的周期確實(shí)不難看出來(lái)這個(gè)特點(diǎn)，客戶(hù)端的操作很少會(huì)改變Jsp的源碼，所以它不需要編譯第二次就一直可以為客戶(hù)端提供服務(wù)。這里稍微解釋一下Http的無(wú)狀態(tài)性，因?yàn)榘l(fā)現(xiàn)很多人誤解，Http的無(wú)狀態(tài)性是指每次一張頁(yè)面顯示出來(lái)了，與服務(wù)器的連接其實(shí)就已經(jīng)斷開(kāi)了，當(dāng)再次有提交動(dòng)作的時(shí)候，才會(huì)再次與服務(wù)器進(jìn)行連接請(qǐng)求提供服務(wù)。當(dāng)然還有現(xiàn)在比較流行的是Ajax與服務(wù)器異步通過(guò) xml交互的技術(shù)，在做前臺(tái)的領(lǐng)域潛力巨大，筆者不是Ajax的高手，這里無(wú)法為大家解釋。

2． Tag標(biāo)簽的本質(zhì)
筆者之前說(shuō)了，Jsp本身初衷是使得Web應(yīng)用前后臺(tái)的開(kāi)發(fā)可以脫離耦合分開(kāi)有效的進(jìn)行，可惜這個(gè)理念的貢獻(xiàn)反倒不如它帶來(lái)的Tag技術(shù)對(duì)J2ee的貢獻(xiàn)要大。也許已經(jīng)有很多人開(kāi)始使用Tag技術(shù)了卻并不了解它。所以才建議大家在學(xué)習(xí)J2ee開(kāi)始的時(shí)候一定要認(rèn)真學(xué)習(xí)Jsp，其實(shí)最重要的就是明白標(biāo)簽的本質(zhì)。

Html標(biāo)簽我們都很熟悉了，有 <html> 、 <head> 、 <body> 、 <title> ，Jsp帶來(lái)的Tag標(biāo)簽遵循同樣的格式，或者說(shuō)更嚴(yán)格的Xml格式規(guī)范，例如 <jsp:include> 、 <jsp:useBean> 、 <c:if> 、 <c:forEach> 等等。它們沒(méi)有什么神秘的地方，就其源頭也還是Java Class而已，Tag標(biāo)簽的實(shí)質(zhì)也就是一段Java代碼，或者說(shuō)一個(gè)Class文件。當(dāng)配置文件設(shè)置好去哪里尋找這些Class的路徑后，容器負(fù)責(zé)將頁(yè)面中存在的標(biāo)簽對(duì)應(yīng)到相應(yīng)的Class上，執(zhí)行那段特定的Java代碼，如此而已。
說(shuō)得明白一點(diǎn)的話還是舉幾個(gè)簡(jiǎn)單的例子說(shuō)明一下吧：

<jsp:include> 去哪里找執(zhí)行什么class呢?首先這是個(gè)jsp類(lèi)庫(kù)的標(biāo)簽，當(dāng)然要去jsp類(lèi)庫(kù)尋找相應(yīng)的class了，同樣它也是由Web容器來(lái)提供，例如 Tomcat就應(yīng)該去安裝目錄的lib文件夾下面的jsp-api.jar里面找，有興趣的可以去找一找啊！

<c:forEach> 又去哪里找呢？這個(gè)是由Jsp2.0版本推薦的和核心標(biāo)記庫(kù)的內(nèi)容，例如 <c:if> 就對(duì)應(yīng)在頁(yè)面中做if判斷的功能的一斷Java代碼。它的class文件在jstl.jar這個(gè)類(lèi)庫(kù)里面，往往還需要和一個(gè)standard.jar類(lèi)庫(kù)一起導(dǎo)入，放在具體Web項(xiàng)目的WEB-INF的lib目錄下面就可以使用了。

順便羅唆一句，Web Project的目錄結(jié)構(gòu)是相對(duì)固定的，因?yàn)槿萜鲿?huì)按照固定的路徑去尋找它需要的配置文件和資源，這個(gè)任何一本J2ee入門(mén)書(shū)上都有，這里就不介紹了。了解Tag的本質(zhì)還要了解它的工作原理，所以大家去J2ee的API里找到并研究這個(gè)包：javax.servlet.jsp.tagext。它有一些接口，和一些實(shí)現(xiàn)類(lèi)，專(zhuān)門(mén)用語(yǔ)開(kāi)發(fā)Tag，只有自己親自寫(xiě)出幾個(gè)不同功能的標(biāo)簽，才算是真正理解了標(biāo)簽的原理。別忘記了自己開(kāi)發(fā)的標(biāo)簽要自己去完成配置文件，容器只是集成了去哪里尋找jsp標(biāo)簽對(duì)應(yīng)class的路徑，自己寫(xiě)的標(biāo)簽庫(kù)當(dāng)然要告訴容器去哪里找啦。

說(shuō)了這么多，我們?yōu)槭裁匆脴?biāo)簽?zāi)?？完全在Jsp里面來(lái)個(gè) <% %> 就可以在里面任意寫(xiě)Java代碼了，但是長(zhǎng)期實(shí)踐發(fā)現(xiàn)頁(yè)面代碼統(tǒng)一都是與html同風(fēng)格的標(biāo)記語(yǔ)言更加有助于美工人員進(jìn)行開(kāi)發(fā)前臺(tái)，它不需要懂Java，只要Java程序員給個(gè)列表告訴美工什么標(biāo)簽可以完成什么邏輯功能，他就可以專(zhuān)注于美工，也算是進(jìn)一步隔離了前后臺(tái)的工作吧！

3． 成就Web框架
框架是什么？曾經(jīng)看過(guò)這樣的定義：與模式類(lèi)似，框架也是解決特定問(wèn)題的可重用方法，框架是一個(gè)描述性的構(gòu)建塊和服務(wù)集合，開(kāi)發(fā)人員可以用來(lái)達(dá)成某個(gè)目標(biāo)。一般來(lái)說(shuō)，框架提供了解決某類(lèi)問(wèn)題的基礎(chǔ)設(shè)施，是用來(lái)創(chuàng)建解決方案的工具，而不是問(wèn)題的解決方案。

正是由于Tag的出現(xiàn)，成就了以后出現(xiàn)的那么多Web框架，它們都開(kāi)發(fā)了自己成熟實(shí)用的一套標(biāo)簽，然后由特定的Xml文件來(lái)配置加載信息，力圖使得Web 應(yīng)用的開(kāi)發(fā)變得更加高效。下面這些標(biāo)簽相應(yīng)對(duì)很多人來(lái)說(shuō)相當(dāng)熟悉了：
<html:password>
<logic:equal>
<bean:write>
<f:view>
<h:form>
<h:message>

它們分別來(lái)自Struts和JSF框架，最強(qiáng)大的功能在于控制轉(zhuǎn)發(fā)，就是MVC三層模型中間完成控制器的工作。Struts-1實(shí)際上并未做到真正的三層隔離，這一點(diǎn)在Struts-2上得到了很大的改進(jìn)。而Jsf向來(lái)以比較完善合理的標(biāo)簽庫(kù)受到人們推崇。

今天就大概講這么多吧，再次需要強(qiáng)調(diào)的是Servlet/Jsp是學(xué)習(xí)J2ee必經(jīng)之路，也是最基礎(chǔ)的知識(shí)，希望大家給與足夠的重視！
Java雜談（九）－－Struts

J2ee的開(kāi)源框架很多，筆者只能介紹自己熟悉的幾個(gè)，其他的目前在中國(guó)IT行業(yè)應(yīng)用得不是很多。希望大家對(duì)新出的框架不要盲目的推崇，首先一定要熟悉它比舊的到底好在哪里，新的理念和特性是什么？然后再?zèng)Q定是否要使用它。

這期的主題是Struts，直譯過(guò)來(lái)是支架。Struts的第一個(gè)版本是在2001年5月發(fā)布的，它提供了一個(gè)Web應(yīng)用的解決方案，如何讓Jsp和 servlet共存去提供清晰的分離視圖和業(yè)務(wù)應(yīng)用邏輯的架構(gòu)。在Struts之前，通常的做法是在Jsp中加入業(yè)務(wù)邏輯，或者在Servlet中生成視圖轉(zhuǎn)發(fā)到前臺(tái)去。Struts帶著MVC的新理念當(dāng)時(shí)退出幾乎成為業(yè)界公認(rèn)的Web應(yīng)用標(biāo)準(zhǔn)，于是當(dāng)代IT市場(chǎng)上也出現(xiàn)了眾多熟悉Struts的程序員。即使有新的框架再出來(lái)不用，而繼續(xù)用Struts的理由也加上了一條低風(fēng)險(xiǎn)，因?yàn)橹型救绻_(kāi)發(fā)人員變動(dòng)，很容易的招進(jìn)新的會(huì)Struts的IT民工啊， ^_^!