1． 關于動态加載機制??
學習Java比C++更容易了解OOP的思想，畢竟C++還混合了不少面向過程的成分。很多人都能背出來Java語言的特點，所謂的動态加載機制等等。當然概念往往是先記住而後消化的，可有多少人真正去體會過動态加載的機制，試圖去尋找過其中的細節呢? 提供大家一個方法：
在指令行視窗運作Java程式的時候，加上這個很有用的參數：
java -verbose *.class
這樣會清晰的列印出被加載的類檔案，大部分是jdk自身運作需要的，最後幾行會明顯的看到自己用到的那幾個類檔案被加載進來的順序。即使你聲明了一個類對象，不執行個體化也不會加載，說明隻有真正用到那個類的執行個體即對象的時候，才會執行加載。這樣是不是大家稍微能明白一點動态加載了呢？^_^
2． 關于尋找class檔案原理??
建議大家在入門的時候在指令行視窗編譯和運作，不要借助JCreator或者Eclipse等IDE去幫助做那些事情。嘗試自己這樣做：
javac -classpath yourpath *.java
java -classpath yourpath *.class
也許很多人都能看懂，設定classpath的目的就是告訴編譯器去哪裡尋找你的class檔案. 不過至少筆者今日才弄懂JVM去查詢類的原理，編譯器加載類要依靠classloader，而classloader有3個級别，從高到低分别是BootClassLoader(名字可能不準确) , ExtClassLoader, AppClassLoader.
這3個加載器分别對應着編譯器去尋找類檔案的優先級别和不同的路徑：BootClassLoader對應jre/classes路徑，是編譯器最優先尋找class的地方
ExtClassLoader對應jre/lib/ext路徑，是編譯器次優先尋找class的地方
AppClassLoader對應目前路徑，是以也是編譯器預設找class的地方
其實大家可以自己寫個程式簡單的測試，對任何class，例如A,
調用new A().getClass().getClassLoader().toString() 列印出來就可以看到，把class檔案放在不同的路徑下再次執行，就會看到差別。特别注意的是如果列印出來是null就表示到了最進階 BootClassLoader, 因為它是C++編寫的，不存在Java對應的類加載器的名字。
尋找的順序是一種向上迂回的思想，即如果本級别找不到，就隻能去本級别之上的找，不會向下尋找。不過似乎從Jdk1.4到Jdk1.6這一特點又有改變，沒有找到詳細資料。是以就不舉例子了。告訴大家設計這種體系的是Sun公司曾經的技術核心宮力先生，一個純種華人哦！^_^
這樣希望大家不至于迷惑為什麼總報錯找不到類檔案，不管是自己寫的還是導入的第三方的jar檔案（J2ee中經常需要導入的）。
3． 關于jdk和jre??
大家肯定在安裝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的開發工具包，裡面包含了各種類庫和工具。當然也包括了另外一個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性質的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程式跑起來就可以了，那麼每個客戶還需要手動去設定環境變量多麻煩啊？是以安裝jre的時候安裝程式自動幫你把jre的java.exe添加到了系統變量中，驗證的方法很簡單，大家看到了系統環境變量的 path最前面有“%SystemRoot%/system32;%SystemRoot%;”這樣的配置，那麼再去Windows/system32下面去看看吧，發現了什麼？有一個java.exe。
如果強行能夠把jdk/bin挪到system32變量前面，當然也可以迫使使用jdk/jre裡面的java，不過除非有必要，我不建議大家這麼做。使用單獨的jre跑java程式也算是客戶環境下的一種測試。
這下大家應該更清楚jdk和jre内部的一些聯系和差別了吧？
PS: 其實還有滿多感想可以總結的，一次寫多了怕大家扔磚頭砸死我，怪我太羅唆。大家應該更加踏實更加務實的去做一些研究并互相分享心得，大方向和太前沿的技術讨論是必要的但最好不要太多，畢竟自己基礎都還沒打好，什麼都講最新版本其實是進步的一大障礙！
Java 學習雜談（二）
鑒于上回寫的一點感想大家不嫌棄，都鼓勵小弟繼續寫下去，好不容易等到國慶黃金周，實習總算有一個休息的階段，于是這就開始寫第二篇了。希望這次寫的仍然對志同道合的朋友們有所幫助。上回講了Java動态加載機制、classLoader原理和關于jdk和jre三個問題。這次延續着講一些具體的類庫??
1． 關于集合架構類
相信學過Java的各位對這個名詞并不陌生，對 java.util.*這個package肯定也不陌生。不知道大家查詢API的時候怎麼去審視或者分析其中的一個package，每個包最重要的兩個部分就是interfaces和classes，接口代表了它能做什麼，實作類則代表了它如何去做。關注實作類之前，我們應該先了解清楚它的來源接口，不管在j2se還是j2ee中，都應該是這樣。那麼我們先看這三個接口：List、Set、Map。
也許有些人不太熟悉這三個名字，但相信大部分人都熟悉ArrayList，LinkedList，TreeSet，HashSet，HashMap， Hashtable等實作類的名字。它們的差別也是滿容易了解的，List放可以重複的對象集合，Set放不可重複的對象組合，而Map則放 <Key,Value > 這樣的名值對， Key不可重複，Value可以。這裡有幾個容易混淆的問題：
到底Vector和ArrayList，Hashtable和HashMap有什麼差別？
很多面試官喜歡問這個問題，其實更專業一點應該這樣問：新集合架構和舊集合架構有哪些差別？新集合架構大家可以在這些包中找since jdk1.2的，之前的如vector和Hashtable都是舊的集合架構包括的類。那麼差別是？
a. 新集合架構的命名更加科學合理。例如List下的ArrayList和LinkedList
b. 新集合架構下全部都是非線程安全的。建議去jdk裡面包含的源代碼裡面自己去親自看看vector和ArrayList的差別吧。當然如果是jdk5.0之後的會比較難看一點，因為又加入了泛型的文法，類似c++的template文法。
那麼大家是否想過為什麼要從舊集合架構預設全部加鎖防止多線程通路更新到新集合架構全部取消鎖，預設方式支援多線程？(當然需要的時候可以使用collections的靜态方法加鎖達到線程安全)
筆者的觀點是任何技術的發展都未必是遵循它們的初衷的，很多重大改變是受到客觀環境的影響的。大家知道Java的初衷是為什麼而開發的麽？是為嵌入式程式開發的。記得上一篇講到classLoader機制麽？那正是為了節約嵌入式開發環境下記憶體而設計的。而走到今天，Java成了人們心中為網際網路誕生的語言。網際網路意味着什麼？多線程是必然的趨勢。客觀環境在變，Java技術也随着飛速發展，導緻越來越脫離它的初衷。據說Sun公司其實主打的是J2se，結果又是由于客觀環境影響，J2se幾乎遺忘，留在大家談論焦點的一直是j2ee。
技術的細節這裡就不多說了，隻有用了才能真正了解。解釋這些正是為了幫助大家了解正在學的和将要學的任何技術。之後講j2ee的時候還會再讨論。
多扯句題外話：幾十年前的IT巨人是IBM，Mainframe市場無人可比。微軟如何打敗IBM？正是由于硬體飛速發展，對個人PC的需求這個客觀環境，讓微軟通過OS稱為了第二個巨人。下一個打敗微軟的呢？Google。如何做到的？如果微軟并不和IBM争大型機，Google借着網際網路飛速發展這個客觀環境作為決定性因素，避開跟微軟争OS，而是走搜尋引擎這條路，稱為第3個巨人。那麼第4個巨人是誰呢？很多專家預言将在亞洲或者中國出現， Whatever，客觀環境變化趨勢才是決定大方向的關鍵。當然筆者也希望會出現在中國，^_^~~
2． 關于Java設計模式
身邊的很多在看GOF的23種設計模式，似乎學習它無論在學校還是在職場，都成了一種流行風氣。我不想列舉解釋這23種Design Pattern， 我寫這些的初衷一直都是談自己的經曆和看法，希望能幫助大家了解。
首先我覺得設計模式隻是對一類問題的一種通用解決辦法，隻要是面向對象的程式設計預言都可以用得上這23種。了解它們最好的方法就是親自去寫每一種，哪怕是一個簡單的應用就足夠了。如果代碼實作也記不住的話，記憶它們對應的UML圖會是一個比較好的辦法，當然前提是必須了解UML。
同時最好能利用Java自身的類庫幫助記憶，例如比較常用的觀察者模式，在java.util.*有現成的Observer接口和Observable這個實作類，看看源代碼相信就足夠了解觀察者模式了。再比如裝飾器模式，大家隻要寫幾個關于java.io.*的程式就可以完全了解什麼是裝飾器模式了。有很多人覺得剛入門的時候不該接觸設計模式，比如圖靈設計叢書系列很出名的那本《Java設計模式》，作者: Steven John Metsker，大部分例子老實說令現在的我也很迷惑。但我仍然不同意入門跟學習設計模式有任何沖突，隻是我們需要知道每種模式的概念的和典型的應用，這樣我們在第一次編寫 FileOutputStream、BufferedReader、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方法的時候直接把原對象序列化到磁盤上再反序列化回來，這樣不用判斷就可以得到一個深copy的結果。如果大家不了解序列化的作法建議看一看 ObjectOutputStream和ObjectInputStream
歸根結底，模式隻是思想上的東西，把它當成前人總結的經驗其實一點都不為過。鼓勵大家動手自己去寫，例如代理模式，可以簡單的寫一個Child類， Adult類。Child要買任何東西由Adult來代理實作。簡單來說就是Adult裡的buy()内部實際調用的是Child的buy()，可是暴露在main函數的卻是Adult.buy()。這樣一個簡單的程式就足夠了解代理模式的基本含義了。
Java 雜談（三）
這已經筆者寫的第三篇Java雜記了，慶幸前兩篇一直得到論壇朋友們的支援鼓勵，還望大家繼續指正不足之處。筆者也一直渴望通過這樣方式清醒的自審，來尋找自己技術上的不足之處，希望和共同愛好Java的同仁們一起提高。
前兩次分别講述了關于jvm、jdk、jre、collection、classLoader和一些Design Pattern的自我了解。這次仍然不準備開始過渡到j2ee中，因為覺得還有一些瑣碎的j2se的問題沒有總結完畢。
1． 關于Object類了解
大家都知道Object是所有Java類的基類， 意味着所有的Java類都會繼承了Object的11個方法。建議大家去看看Object的 11個成員函數的源代碼，就會知道預設的實作方式。比如equals方法，預設實作就是用"=="來比較，即直接比較記憶體位址，傳回true 或者 false。而toString()方法，傳回的串組成方式是??
"getClass().getName() + "@" + Integer.toHexString(hashCode())"
其實不用我過多的解釋，大家都能看懂這個串的組成。接下來再看看hashCode()：
public native int hashCode()；
由于是native方法，跟OS的處理方式相關，源代碼裡僅僅有一個聲明罷了。我們有興趣的話完全可以去深究它的hashCode到底是由OS怎麼樣産生的呢？但筆者建議最重要的還是先記住使用它的幾條原則吧！首先如果equals()方法相同的對象具有相通的hashCode，但equals ()對象不相通的時候并不保證hashCode()方法傳回不同的整數。而且下一次運作同一個程式，同一個對象未必還是當初的那個hashCode() 哦。
其餘的方法呢？nofigy()、notifyAll()、clone()、wait()都是native方法的，說明依賴于作業系統的實作。最後一個有趣的方法是finalize()，類似C++的析構函數，簽名是protected，證明隻有繼承擴充了才能使用，方法體是空的，默示什麼也不做。它的作用據筆者的了解僅僅是通知JVM此對象不再使用，随時可以被銷毀，而實際的銷毀權還是在于虛拟機手上。那麼它真的什麼也不做麽？未必，實際上如果是線程對象它會導緻在一定範圍内該線程的優先級别提高，導緻更快的被銷毀來節約記憶體提高性能。其實從常理來說，我們也可以大概這樣猜測出jvm做法的目的。
2． 關于重載hashCode()與Collection架構的關系
筆者曾經聽一位搞Java教育訓練多年的前輩說在他看來hashCode方法沒有任何意義，僅僅是為了配合證明具有同樣的hashCode會導緻equals 方法相等而存在的。連有的前輩都犯這樣的錯誤，其實說明它還是滿容易被忽略的。那麼hashCode()方法到底做什麼用？
學過資料結構的課程大家都會知道有一種結構叫hash table，目的是通過給每個對象配置設定一個唯一的索引來提高查詢的效率。那麼Java也不會肆意扭曲改變這個概念，是以hashCode唯一的作用就是為支援資料結構中的哈希表結構而存在的，換句話說，也就是隻有用到集合架構的 Hashtable、HashMap、HashSet的時候，才需要重載hashCode()方法，
這樣才能使得我們能人為的去控制在哈希結構中索引是否相等。筆者舉一個例子：
曾經為了寫一個求解類程式，需要随機列出1,2,3,4組成的不同排列組合，是以筆者寫了一個數組類用int[]來存組合結果，然後把随機産生的組合加入一個HashSet中，就是想利用HashSet不包括重複元素的特點。可是HashSet怎麼判斷是不是重複的元素呢？當然是通過 hashCode()傳回的結果是否相等來判斷啦，可做一下這個實驗：
int[] A = {1,2,3,4};
int[] B = {1,2,3,4};
System.out.println(A.hashCode());
System.out.println(B.hashCode());
這明明是同一種組合，卻是不同的hashCode，加入Set的時候會被當成不同的對象。這個時候我們就需要自己來重寫hashCode()方法了，如何寫呢？其實也是基于原始的hashCode()，畢竟那是作業系統的實作， 找到相通對象唯一的辨別，實作方式很多，筆者的實作方式是：
首先重寫了toString()方法:
return A[0]“+” A[1]“+” A[2]“+” A[3]; //顯示上比較直覺
然後利用toString()來計算hashCode()：
return this.toString().hashCode()；
這樣上述A和B傳回的就都是”1234”，在測試toString().hashCode()，由于String在記憶體中的副本是一樣的，”1234”.hashCode()傳回的一定是相同的結果。
說到這，相信大家能了解得比我更好，今後千萬不要再誤解hashCode()方法的作用。
3． 關于Class類的成員函數與Java反射機制
很早剛接觸Java就聽很多老師說過Java的動态運作時機制、反射機制等。确實它們都是Java的顯著特點，運作時加載筆者在第一篇介紹過了，現在想講講反射機制。在Java中，主要是通過java.lang包中的Class類和Method類來實作記憶體反射機制的。
熟悉C++的人一定知道下面這樣在C++中是做不到的：運作時以字元串參數傳遞一個類名，就可以得到這個類的所有資訊，包括它所有的方法，和方法的詳細資訊。還可以執行個體化一個對象，并通過查到的方法名來調用該對象的任何方法。這是因為Java的類在記憶體中除了C++中也有的靜态動态資料區之外，還包括一份對類自身的描述，也正是通過這描述中的資訊，才能幫助我們才運作時讀取裡面的内容，得到需要加載目标類的所有資訊，進而實作反射機制。大家有沒有想過當我們需要得到一個JavaBean的執行個體的時候，怎麼知道它有哪些屬性呢？再明顯簡單不過的例子就是自己寫一個JavaBean的解析器：
a. 通過Class.forName(“Bean的類名”)得到Class對象，例如叫ABeanClass
b. 通過ABeanClass的getMethods()方法，得到Method[]對象
c. 按照規範所有get方法名後的單詞就代表着該Bean的一個屬性
d. 當已經知道一個方法名，可以調用newInstance()得到一個執行個體，然後通過invoke()方法将方法的名字和方法需要用的參數傳遞進去，就可以動态調用此方法。
當然還有更複雜的應用，這裡就不贅述，大家可以參考Class類和Method類的方法。
4． 坦言Synchronize的本質
Synchronize大家都知道是同步、加鎖的意思，其實它的本質遠沒有大家想得那麼複雜。聲明Synchronize的方法被調用的時候，鎖其實是加載對象上，當然如果是靜态類則是加在類上的鎖，調用結束鎖被解除。它的實作原理很簡單，僅僅是不讓第二把鎖再次被加在同一個對象或類上，僅此而已。一個簡單的例子足以說明問題：
class A{
synchronized void f(){}
void g(){}
}
當A的一個對象a被第一個線程調用其f()方法的時候，第二個線程不能調用a的synchronized方法例如f()，因為那是在試圖在對象上加第二把鎖。但調用g()卻是可以的，因為并沒有在同一對象上加兩把鎖的行為産生。
這樣大家能了解了麽？明白它的原理能更好的幫助大家設計同步機制，不要濫用加鎖。
PS：下篇筆者計劃開始對J2ee接觸到的各個方面來進行總結，談談自己的經驗和想法。希望大家還能一如既往的支援筆者寫下去，指正不足之處。
Java雜談（四）
不知不覺已經寫到第四篇了，論壇裡面不斷的有朋友鼓勵我寫下去。堅持自己的作風，把一切迷惑不容易理清楚的知識講出來，講到大家都能聽懂，那麼自己就真的懂了。最近在公司實習的時候Trainer跟我講了很多經典事迹，對還未畢業的我來說是筆不小的财富，我自己的信念是：人在逆境中成長的速度要遠遠快過順境中，這樣來看一切都能欣然接受了。
好了，閑話不說了，第三篇講的是反射機制集合架構之類的，這次打算講講自己對反序列化和多線程的了解。希望能對大家學習Java起到幫助??
1．關于序列化和反序列化
應該大家都大概知道Java中序列化和反序列化的意思，序列化就是把一個Java對象轉換成二進制進行磁盤上傳輸或者網絡流的傳輸，反序列化的意思就是把這個接受到的二進制流重新組裝成原來的對象逆過程。它們在Java中分别是通過ObjectInputStream和 ObjectInputStream這兩個類來實作的（以下分别用ois和oos來簡稱）。
oos的writeObject()方法用來執行序列化的過程，ois的readObject()用來執行反序列化的過程，在傳輸二進制流之前，需要講這兩個高層流對象連接配接到同一個Channel上，這個Channel可以是磁盤檔案，也可以是socket底層流。是以無論用哪種方式，底層流對象都是以構造函數參數的形式傳遞進oos和ois這兩個高層流，連接配接完畢了才可以進行二進制資料傳輸的。例子：
可以是檔案流通道
file = new File(“C:/data.dat”);
oos = new ObjectOutputStream(new FileOutputStream(file));
ois = new ObjectInputStream(new FileInputStream(file));
或者網絡流通道
oos = new ObjectOutputStream(socket.getOutputStream());
ois = new ObjectInputStream(socket.getInputStream());
不知道大家是否注意到oos總是在ois之前定義，這裡不希望大家誤解這個順序是固定的麼？回答是否定的，那麼有順序要求麼？回答是肯定的。原則是什麼呢？
原則是互相對接的輸入/輸出流之間必須是output流先初始化然後再input流初始化，否則就會抛異常。大家肯定會問為什麼？隻要稍微看一看這兩個類的源代碼檔案就大概知道了，output流的任務很簡單，隻要把對象轉換成二進制往通道中寫就可以了，但input流需要做很多準備工作來接受并最終重組這個Object，是以ObjectInputStream的構造函數中就需要用到output初始化發送過來的header資訊，這個方法叫做 readStreamHeader()，它将會去讀兩個Short值用于決定用多大的緩存來存放通道發送過來的二進制流，這個緩存的size因jre的版本不同是不一樣的。是以output如果不先初始化，input的構造函數首先就無法正确運作。
對于上面兩個例子，第一個順序是嚴格的，第二個因為oos和ois連接配接的已經不是對方了，而是socket另外一端的流，需要嚴格按照另外一方對接的output流先于對接的input流打開才能順利運作。
這個writeObject和readObject本身就是線程安全的，傳輸過程中是不允許被并發通路的。是以對象能一個一個接連不斷的傳過來，有很多人在運作的時候會碰到EOFException, 然後百思不得其解，去各種論壇問解決方案。其實筆者這裡想說，這個異常不是必須聲明的，也就是說它雖然是異常，但其實是正常運作結束的标志。EOF表示讀到了檔案尾，發送結束自然連接配接也就斷開了。如果這影響到了你程式的正确性的話，請各位靜下心來看看自己程式的業務邏輯，而不要把注意力狹隘的聚集在發送和接受的方法上。因為筆者也被這樣的bug困擾了1整天，被很多論壇的文章誤解了很多次最後得出的教訓。如果在while循環中去readObject，本質上是沒有問題的，有對象資料來就會讀，沒有就自動阻塞。那麼抛出EOFException一定是因為連接配接斷了還在繼續read，什麼原因導緻連接配接斷了呢？一定是業務邏輯哪裡存在錯誤，比如NullPoint、 ClassCaseException、ArrayOutofBound，即使程式較大也沒關系，最多隻要單步調适一次就能很快發現bug并且解決它。
難怪一位程式大師說過：解決問題90％靠經驗，5％靠技術，剩下5％靠運氣！真是金玉良言，筆者大概查閱過不下30篇讨論在while循環中使用 readObject抛出EOFExceptionde 的文章，大家都盲目的去關注解釋這個名詞、反序列化的行為或反對這樣寫而沒有一個人認為EOF是正确的行為，它其實很老實的在做它的事情。為什麼大家都忽略了真正出錯誤的地方呢？兩個字，經驗！
2．關于Java的多線程程式設計
關于Java的線程，初學或者接觸不深的大概也能知道一些基本概念，同時又會很迷惑線程到底是怎麼回事？如果有人認為自己已經懂了不妨來回答下面的問題：
a. A對象實作Runnable接口，A.start()運作後所謂的線程對象是誰？是A麼？
b. 線程的wait()、notify()方法到底是做什麼時候用的，什麼時候用？
c. 為什麼線程的suspend方法會被标注過時，不推薦再使用，線程還能挂起麼？
d. 為了同步我們會對線程方法聲明Synchronized來加鎖在對象上，那麼如果父類的f()方法加了Synchronized，子類重寫f()方法必須也加Synchronized麼？如果子類的f()方法重寫時聲明Synchronized并調用super.f()，那麼子類對象上到底有幾把鎖呢？會因為競争産生死鎖麼？
呵呵，各位能回答上來幾道呢？如果這些都能答上來，說明對線程的概念還是滿清晰的，雖說還遠遠不能算精通。筆者這裡一一做回答，礙于篇幅的原因，筆者盡量說得簡介一點，如果大家有疑惑的歡迎一起讨論。
首先第一點，線程跟對象完全是兩回事，雖然我們也常說線程對象。但當你用run()和start()來啟動一個線程之後，線程其實跟這個繼承了 Thread或實作了Runnable的對象已經沒有關系了，對象隻能算記憶體中可用資源而對象的方法隻能算記憶體正文區可以執行的代碼段而已。既然是資源和代碼段，另外一個線程當然也可以去通路，main函數執行就至少會啟動兩個線程，一個我們稱之為主線程，還一個是垃圾收集器的線程，主線程結束就意味着程式結束，可垃圾收集器線程很可能正在工作。
第二點，wait()和sleep()類似，都是讓線程處于阻塞狀态暫停一段時間，不同之處在于wait會釋放目前線程占有的所有的鎖，而 sleep不會。我們知道獲得鎖的唯一方法是進入了Synchronized保護代碼段，是以大家會發現隻有Synchronized方法中才會出現 wait，直接寫會給警告沒有獲得目前對象的鎖。是以notify跟wait配合使用，notify會重新把鎖還給阻塞的線程重而使其繼續執行，當有多個對象wait了，notify不能确定喚醒哪一個，必經鎖隻有一把，是以一般用notifyAll()來讓它們自己根據優先級等競争那唯一的一把鎖，競争到的線程執行，其他線程隻要繼續wait。
從前Java允許在一個線程之外把線程挂起，即調用suspend方法，這樣的操作是極不安全的。根據面向對象的思想每個對象必須對自己的行為負責，而對自己的權力進行封裝。如果任何外步對象都能使線程被挂起而阻塞的話，程式往往會出現混亂導緻崩潰，是以這樣的方法自然是被斃掉了啦。
最後一個問題比較有意思，首先回答的是子類重寫f()方法可以加Synchronized也可以不加，如果加了而且還内部調用了super.f ()的話理論上是應該對同一對象加兩把鎖的，因為每次調用Synchronized方法都要加一把，調用子類的f首先就加了一把，進入方法内部調用父類的 f又要加一把，加兩把不是互斥的麼？那麼調父類f加鎖不就必須永遠等待已經加的鎖釋放而造成死鎖麼？實際上是不會的，這個機制叫重進入，當父類的f方法試圖在本對象上再加一把鎖的時候，因為目前線程擁有這個對象的鎖，也可以了解為開啟它的鑰匙，是以同一個線程在同一對象上還沒釋放之前加第二次鎖是不會出問題的，這個鎖其實根本就沒有加，它有了鑰匙，不管加幾把還是可以進入鎖保護的代碼段，暢通無阻，是以叫重進入，我們可以簡單認為第二把鎖沒有加上去。
總而言之，Synchronized的本質是不讓其他線程在同一對象上再加一把鎖。
Java雜談（五）
本來預計J2se隻講了第四篇就收尾了，可是版主厚愛把文章置頂長期讓大家浏覽讓小弟倍感責任重大，務必追求最到更好，是以關于J2se一些沒有提到的部分，決定再寫幾篇把常用的部分經驗全部寫出來供大家讨論切磋。這一篇準備講一講Xml解析包和Java Swing，然後下一篇再講java.security包關于Java沙箱安全機制和RMI機制，再進入J2ee的部分，暫時就做這樣的計劃了。如果由于實習繁忙更新稍微慢了一些，希望各位見諒！
1． Java關于XML的解析
相信大家對XML都不陌生，含義是可擴充标記語言。本身它也就是一個資料的載體以樹狀表現形式出現。後來慢慢的資料變成了資訊，差別是資訊可以包括可變的狀态進而針對程式寫死的做法變革為針對統一接口寫死而可變狀态作為資訊進入了XML中存儲。這樣改變狀态實作擴充的唯一工作是在XML中添加一段文本資訊就可以了，代碼不需要改動也不需要重新編譯。這個靈活性是XML誕生時候誰也沒想到的。
當然，如果接口要能提取XML中配置的資訊就需要程式能解析規範的XML檔案，Java中當然要提高包對這個行為進行有利支援。筆者打算講到的兩個包是 org.w3c.dom和javax.xml.parsers和。（大家可以浏覽一下這些包中間的接口和類定義）
Javax.xml.parsers包很簡單，沒有接口，兩個工廠配兩個解析器。顯然解析XML是有兩種方式的：DOM解析和SAX解析。本質上并沒有誰好誰不好，隻是實作的思想不一樣罷了。給一個XML檔案的例子：
<?xml version=”1.0” encoding=”UTF-8” >
<root >
<child name=”Kitty” >
A Cat
</child >
</root >
所謂DOM解析的思路是把整個樹狀圖存入記憶體中，需要那個節點隻需要在樹上搜尋就可以讀到節點的屬性，内容等，這樣的好處是所有節點皆在記憶體可以反複搜尋重複使用，缺點是需要消耗相應的記憶體空間。
自然SAX解析的思路就是為了克服DOM的缺點，以事件觸發為基本思路，順序的搜尋下來，碰到了Element之前觸發什麼事件，碰到之後做什麼動作。由于需要自己來寫觸發事件的處理方案，是以需要借助另外一個自定義的Handler，處于org.xml.sax.helpers包中。它的優點當然是不用整個包都讀入記憶體，缺點也是隻能順序搜尋，走完一遍就得重來。
大家很容易就能猜到，接觸到的J2ee架構用的是哪一種，顯然是DOM。因為類似Struts，Hibernate架構配置檔案畢竟是很小的一部配置設定置資訊，而且需要頻繁搜尋來讀取，當然會采用DOM方式（其實SAX内部也是用DOM采用的結構來存儲節點資訊的）。現在無論用什麼架構，還真難發現使用 SAX來解析XML的技術了，如果哪位仁兄知道，請讓筆者也學習學習。
既然解析方式有了，那麼就需要有解析的存儲位置。不知道大家是否發現org.w3c.dom這個包是沒有實作類全部都是接口的。這裡筆者想說一下Java 如何對XML解析是Jdk應該考慮的事，是它的責任。而w3c組織是維護定義XML标準的組織，是以一個XML結構是怎麼樣的由w3c說了算，它不關心 Java如何去實作，于是乎規定了所有XML存儲的結構應該遵循的規則，這就是org.w3c.dom裡全部的接口目的所在。在筆者看來，簡單了解接口的概念就是實作者必須遵守的原則。
整個XML對應的結構叫Document、子元素對應的叫做Element、還有節點相關的Node、NodeList、Text、Entity、 CharacterData、CDATASection等接口，它們都可以在XML的文法中間找到相對應的含義。由于這裡不是講解XML基本文法，就不多介紹了。如果大家感興趣，筆者也可以專門寫一篇關于XML的文法規則帖與大家分享一下。
2． Java Swing
Swing是一個讓人又愛又恨的東西，可愛之處在于上手很容易，較AWT比起來Swing提供的界面功能更加強大，可恨之處在于編複雜的界面工作量實在是巨大。筆者寫過超過3000行的Swing界面，感覺使用者體驗還不是那麼優秀。最近又寫過超過6000行的，由于功能子產品多了，整體效果還隻是一般。體會最深的就一個字：累! 是以大家現在都陸續不怎麼用Swing在真正開發的項目上了，太多界面技術可以取代它了。筆者去寫也是迫于無奈組裡面大家都沒寫過，我不入地域誰入？
盡管Swing慢慢的在被人忽略，特别是随着B/S慢慢的在淹沒C/S，筆者倒是很願意站出來為Swing正身。每一項技術的掌握絕不是為了流行時尚跟風。真正喜歡Java的朋友們還是應該好好體會一下Swing，相信在校的很多學生也很多在學習它。很可能從Jdk 1.1、1.2走過來的很多大學老師可能是最不熟悉它的。
Swing提供了一組輕元件統稱為JComponent，它們與AWT元件的最大差別是JComponent全部都是Container，而 Container的特點是裡面可以裝載别的元件。在Swing元件中無論是JButton、JLabel、JPanel、JList等都可以再裝入任何其他元件。好處是程式員可以對Swing元件實作“再開發”，針對特定需求建構自己的按鈕、标簽、畫闆、清單之類的特定元件。
有輕自然就有重，那麼輕元件和重元件差別是？重元件表現出來的形态因作業系統不同而異，輕元件是Swing自己提供GUI，在跨平台的時候最大程度的保持一緻。
那麼在程式設計的時候要注意一些什麼呢？筆者談談自己的幾點經驗：
a. 明确一個概念，隻有Frame元件才可以單獨顯示的，也許有人會說JOptionPane裡面的靜态方法就實作了單獨視窗出現，但追尋源代碼會發現其實作實出來的Dialog也需要依托一個Frame窗體，如果沒有指定就會預設産生一個然後裝載這個Dialog顯示出來。
b. JFrame是由這麼幾部分組成：
最底下一層JRootPane，上面是glassPane (一個JPanel)和layeredPane (一個JLayeredPane)，而layeredPane又由contentPane(一個JPanel)和menuBar構成。我們的元件都是加在 contentPane上，而背景圖檔隻能加在layeredPane上面。至于glassPane是一個透明的覆寫了contentPane的一層，在特定效果中将被利用到來記錄滑鼠坐标或掩飾元件。
c. 為了增強使用者體驗，我們會在一些按鈕上添加快捷鍵，但Swing裡面通常隻能識别鍵盤的Alt鍵，要加入其他的快捷鍵，必須自己實作一個ActionListener。
d. 通過setLayout(null)可以使得所有元件以setBounds()的四個參數來精确定位各自的大小、位置，但不推薦使用，因為好的程式設計風格不應該在Swing代碼中寫死具體數字，所有的數字應該以常數的形式統一存在一個靜态無執行個體資源類檔案中。這個靜态無執行個體類統一負責Swing界面的風格，包括字型和顔色都應該包括進去。
e. 好的界面設計有一條Golden Rule: 使用者不用任何手冊通過少數嘗試就能學會使用軟體。是以盡量把按鈕以菜單的形式（不管是右鍵菜單還是窗體自帶頂部菜單）呈現給顧客，除非是頻繁點選的按鈕才有必要直接呈現在界面中。
其實Swing的功能是相當強大的，隻是現在應用不廣泛，專門去研究大概是要花不少時間的。筆者在各網站論壇浏覽關于Swing的技巧文章還是比較可信的，自己所學非常有限，各人體會對Swing各個元件的掌握就是一個實踐積累的過程。筆者隻用到過以上這些，是以隻能談談部分想法，還望大家見諒！
Java雜談（六）
這篇是筆者打算寫的J2se部分的最後一篇了，這篇結束之後，再寫J2ee部分，不知道是否還合适寫在這個版塊？大家可以給點意見，謝謝大家對小弟這麼鼓勵一路寫完前六篇Java雜談的J2se部分。最後這篇打算談一談Java中的RMI機制和JVM沙箱安全架構。
1． Java中的RMI機制
RMI的全稱是遠端方法調用，相信不少朋友都聽說過，基本的思路可以用一個經典比方來解釋：A計算機想要計算一個兩個數的加法，但A自己做不了，于是叫另外一台計算機B幫忙，B有計算加法的功能，A調用它就像調用這個功能是自己的一樣友善。這個就叫做遠端方法調用了。
遠端方法調用是EJB實作的支柱，建立分布式應用的核心思想。這個很好了解，再拿上面的計算加法例子，A隻知道去call計算機B的方法，自己并沒有B的那些功能，是以A計算機端就無法看到B執行這段功能的過程和代碼，因為看都看不到，是以既沒有機會竊取也沒有機會去改動方法代碼。EJB正式基于這樣的思想來完成它的任務的。當簡單的加法變成複雜的資料庫操作和電子商務交易應用的時候，這樣的安全性和分布式應用的便利性就表現出來優勢了。
好了，回到細節上，要如何實作遠端方法調用呢？我希望大家學習任何技術的時候可以試着依賴自己的下意識判斷，隻要你的想法是合理健壯的，那麼很可能實際上它就是這麼做的，畢竟真理都蘊藏在平凡的生活細節中。這樣隻要帶着一些薄弱的Java基礎來思考RMI，其實也可以想出個大概來。
a) 需要有一個伺服器角色，它擁有真正的功能代碼方法。例如B，它提供加法服務
b) 如果想遠端使用B的功能，需要知道B的IP位址
c) 如果想遠端使用B的功能，還需要知道B中那個特定服務的名字
我們很自然可以想到這些，雖然不完善，但已經很接近正确的做法了。實際上RMI要得以實作還得意于Java一個很重要的特性，就是Java反射機制。我們需要知道服務的名字，但又必須隐藏實作的代碼，如何去做呢？答案就是：接口！
舉個例子：
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!”);}
}
用戶端：Person p = Naming.lookup(“PersonService”);
p.sayHello();
就這幾段代碼就包含了幾乎所有的實作技術，大家相信麼？用戶端請求一個say hello服務，伺服器運作時接到這個請求，利用Java反射機制的Class.newInstance()傳回一個對象，但用戶端不知道伺服器傳回的是 ImplA還是ImplB，它接受用的參數簽名是Person，它知道實作了Person接口的對象一定有sayHello()方法，這就意味着用戶端并不知道伺服器真正如何去實作的，但它通過了解Person接口明确了它要用的服務方法名字叫做sayHello()。
如此類推，伺服器隻需要暴露自己的接口出來供用戶端，所有用戶端就可以自己選擇需要的服務。這就像餐館隻要拿出自己的菜單出來讓客戶選擇，就可以在背景廚房一道道的按需做出來，它怎麼做的通常是不讓客戶知道的！（祖傳菜單吧，^_^）
最後一點是我調用lookup，查找一個叫PersonService名字的對象，伺服器隻要看到這個名字，在自己的目錄（相當于電話簿）中找到對應的對象名字提供服務就可以了，這個目錄就叫做JNDI (Java命名與目錄接口），相信大家也聽過的。
有興趣的朋友不妨自己做個RMI的應用，很多前輩的部落格中有簡單的例子。提示一下利用Jdk的bin目錄中rmi.exe和 rmiregistry.exe兩個指令就可以自己建起一個伺服器，提供遠端服務。因為例子很容易找，我就不自己舉例子了！
2． JVM沙箱&架構
RMI羅唆得太多了，實在是盡力想把它說清楚，希望對大家有幫助。最後的最後，給大家簡單講一下JVM架構，我們叫做Java沙箱。Java沙箱的基本元件如下：
a) 類裝載器結構
b) class檔案檢驗器
c) 内置于Java虛拟機的安全特性
d) 安全管理器及Java API
其中類裝載器在3個方面對Java沙箱起作用：
a. 它防止惡意代碼去幹涉善意的代碼
b. 它守護了被信任的類庫邊界
c. 它将代碼歸入保護域，确定了代碼可以進行哪些操作
虛拟機為不同的類加載器載入的類提供不同的命名空間，命名空間由一系列唯一的名稱組成，每一個被裝載的類将有一個名字，這個命名空間是由Java虛拟機為每一個類裝載器維護的，它們互相之間甚至不可見。
我們常說的包（package）是在Java虛拟機第2版的規範第一次出現，正确定義是由同一個類裝載器裝載的、屬于同一個包、多個類型的集合。類裝載器采用的機制是雙親委派模式。具體的加載器架構我在Java雜談（一）中已經解釋過了，當時說最外層的加載器是AppClassLoader，其實算上網絡層的話AppClassLoader也可以作為parent，還有更外層的加載器URLClassLoader。為了防止惡意攻擊由URL加載進來的類檔案我們當然需要分不同的通路命名空間，并且制定最安全的加載次序，簡單來說就是兩點：
a. 從最内層JVM自帶類加載器開始加載，外層惡意同名類得不到先加載而無法使用
b. 由于嚴格通過包來區分了通路域，外層惡意的類通過内置代碼也無法獲得權限通路到内層類，破壞代碼就自然無法生效。
附：關于Java的平台無關性，有一個例子可以很明顯的說明這個特性：
一般來說，C或C++中的int占位寬度是根據目标平台的字長來決定的，這就意味着針對不同的平台編譯同一個C++程式在運作時會有不同的行為。然而對于 Java中的int都是32位的二進制補碼辨別的有符号整數，而float都是遵守IEEE 754浮點标準的32位浮點數。
PS: 這個小弟最近也沒時間繼續研究下去了，隻是想抛磚引玉的提供給大家一個初步認識JVM的印象。有機會了解一下JVM的内部結構對今後做Java開發是很有好處的。
Java雜談（七）－－接口& 元件、容器
終于又靜下來繼續寫這個主題的續篇，前六篇主要講了一些J2se方面的經驗和感受，眼下Java應用範圍已經被J2ee占據了相當大的一塊領域，有些人甚至聲稱Java被J2ee所取代了。不知道大家如何來了解所謂的J2ee (Java2 Enterprise Edition)，也就是Java企業級應用？
筆者的觀點是，技術的發展是順應世界變化的趨勢的，從C/S過渡到B/S模式，從用戶端的角度考慮企業級應用或者說電子商務領域不在關心用戶端維護問題，這個任務已經交給了任何一台PC都會有的浏覽器去維護；從伺服器端的角度考慮，以往C/S中的TCP/IP協定實作載體ServerSocket被Web Server Container所取代，例如大家都很熟悉的Tomcat、JBoss、WebLogic等等。總之一切的轉變都是為了使得Java技術能更好的為人類生産生活所服務。
有人會問，直接去學J2ee跳過J2se行否？筆者是肯定不贊成的，實際上确實有人走這條路，但筆者自身體會是正是由于J2se的基礎很牢固，才會導緻在J2ee學習的道路上順風順水，知識點上不會有什麼迷惑的地方。舉個簡單的例子吧：
筆者曾經跟大學同學讨論下面這兩種寫法的差別：
ArrayList list = new ArrayList(); //筆者不說反對，但至少不贊成
List list = new ArrayList(); //筆者支援
曾經筆者跟同學争論了幾個小時，他非說第一種寫法更科學，第二種完全沒有必要。我無法完全說服他，但筆者認為良好的習慣和意識是任何時候都應該針對接口程式設計，以達到解耦合和可擴充性的目的。下面就以接口開始進入J2ee的世界吧：
1. J2ee與接口
每一個版本的J2ee都對應着一個确定版本的JDK，J2ee1.4對應Jdk1.4，現在比較新的是JDK5.0，自然也會有J2EE 5.0。其實筆者一直在用的是J2EE1.4，不過沒什麼關系，大家可以下任何一個版本的J2ee api來稍微浏覽一下。筆者想先聲明一個概念，J2ee也是源自Java，是以底層的操作依然調用到很多J2se的庫，是以才建議大家先牢牢掌握J2se 的主流技術。
J2ee api有一個特點，大家比較熟悉的幾個包java.jms、javax.servlet.http、javax.ejb等都以interface居多，實作類較少。其實大家真正在用的時候百分之六十以上都在反複的查着javax.servlet.http這個包下面幾個實作類的api函數，其他的包很少問津。筆者建議在學習一種技術之前，對整體的架構有一個了解是很有必要的，J2ee旨在通過interface的聲明來規範實作的行為，任何第三方的廠商想要提供自己品牌的實作前提也是遵循這些接口定義的規則。如果在從前J2se學習的道路上對接口的了解很好的話，這裡的體會将是非常深刻的，舉個簡單的例子：
public interface Mp3{
public void play();
public void record();
public void stop();
}
如果我定義這個簡單的接口，釋出出去，規定任何第三方的公司想推出自己的名字為Mp3的産品都必須實作這個接口，也就是至少提供接口中方法的具體實作。這個意義已經遠遠不止是面向對象的多态了，隻有廠商遵循J2ee的接口定義，世界上的J2ee程式員才能針對統一的接口進行程式設計，最終不用改變代碼隻是因為使用了不同廠商的實作類而有不同的特性罷了，本質上說，無論哪一種廠商實作都完成了職責範圍内的工作。這個就是筆者想一直強調的，針對接口程式設計的思想。
接口到底有什麼好處呢？我們這樣設想，現在有AppleMp3、SonyMp3、SamsungMp3都實作了這個Mp3的接口，于是都有了play、 record、stop這三個功能。我們将Mp3産品座位一個元件的時候就不需要知道它的具體實作，隻要看到接口定義知道這個對象有3個功能就可以使用了。那麼類似下面這樣的業務就完全可以在任何時間從3個品牌擴充到任意個品牌，開個玩笑的說，項目經理高高在上的寫完10個接口裡的方法聲明，然後就丢給手下的程式員去寫裡面的細節，由于接口已經統一（即每個方法傳入和傳出的格式已經統一），經理隻需關注全局的業務就可以天天端杯咖啡走來走去了，^_^：
public Mp3 create();
public void copy(Mp3 mp3);
public Mp3 getMp3();
最後用一個簡單的例子說明接口：一個5号電池的手電筒，可以裝入任何牌子的5号電池，隻要它符合5号電池的規範，裝入之後任何看不到是什麼牌子，隻能感受到手電筒在完成它的功能。那麼生産手電筒的廠商和生産5号電池的廠商就可以完全解除依賴關系，可以各自自由開發自己的産品，因為它們都遵守5号電池應有的形狀、正負極位置等約定。這下大家能對接口多一點體會了麼？
2. 元件和容器
針對接口是筆者特意強調的J2ee學習之路必備的思想，另外一個就是比較正常的元件和容器的概念了。很多教材和專業網站都說J2EE的核心是一組規範與指南，強調J2ee的核心概念就是元件+容器，這确實是無可厚非的。随着越來越多的J2ee架構出現，相應的每種架構都一般有與之對應的容器。
容器，是用來管理元件行為的一個集合工具，元件的行為包括與外部環境的互動、元件的生命周期、元件之間的合作依賴關系等等。J2ee包含的容器種類大約有 Web容器、Application Client容器、EJB容器、Applet用戶端容器等。但在筆者看來，現在容器的概念變得有點模糊了，大家耳熟能詳是那些功能強大的開源架構，比如 Hibernate、Struts2、Spring、JSF等，其中Hibernate就基于JDBC的基礎封裝了對事務和會話的管理，大大友善了對資料庫操作的繁瑣代碼，從這個意義上來說它已經接近容器的概念了，EJB的實體Bean也逐漸被以Hibernate為代表的持久化架構所取代。
元件，本意是指可以重用的代碼單元，一般代表着一個或者一組可以獨立出來的功能子產品，在J2ee中元件的種類有很多種，比較常見的是EJB元件、DAO元件、用戶端元件或者應用程式元件等，它們有個共同特點是分别會打包成.war，.jar，.jar，.ear，每個元件由特定格式的xml描述符檔案進行描述，而且伺服器端的元件都需要被部署到應用伺服器上面才能夠被使用。
稍微了解完元件和容器，還有一個重要的概念就是分層模型，最著名的當然是MVC三層模型。在一個大的工程或項目中，為了讓前台和背景各個子產品的程式設計人員能夠同時進行工作提高開發效率，最重要的就是實作層與層之間的耦合關系，許多分層模型的宗旨和開源架構所追求的也就是這樣的效果。在筆者看來，一個完整的 Web項目大概有以下幾個層次：
a) 表示層（Jsp、Html、Javascript、Ajax、Flash等等技術對其支援）
b) 控制層（Struts、JSF、WebWork等等架構在基于Servlet的基礎上支援，負責把具體的請求資料（有時解除安裝重新裝載）導向适合處理它的模型層對象）
c) 模型層（筆者認為目前最好的架構是Spring，實質就是處理表示層經由控制層轉發過來的資料，包含着大量的業務邏輯）
d) 資料層（Hibernate、JDBC、EJB等，由模型層處理完了持久化到資料庫中）
當然，這僅僅是筆者個人的觀點，僅僅是供大家學習做一個參考，如果要實作這些層之間的完全分離，那麼一個大的工程，可以僅僅通過增加人手就來完成任務。雖然《人月神話》中已經很明确的闡述了增加人手并不能是效率增加，很大程度上是因為彼此做的工作有順序上的依賴關系或者說難度和工作量上的巨大差距。當然理想狀态在真實世界中是不可能達到的，但我們永遠應該朝着這個方向去不斷努力。最開始所提倡的針對接口來程式設計，哪怕是小小的細節，寫一條List list= = new ArrayList()語句也能展現着處處皆使用接口的思想在裡面。Anyway，這隻是個開篇，筆者會就自己用過的J2ee技術和架構再細化談一些經驗.
Java雜談（八）－－Servlet/Jsp
終于正式進入J2ee的細節部分了，首當其沖的當然是Servlet和Jsp了，上篇曾經提到過J2ee隻是一個規範和指南，定義了一組必須要遵循的接口，核心概念是元件和容器。曾經有的人問筆者Servlet的Class檔案是哪裡來的？他認為是J2ee官方提供的，我舉了一個簡單的反例：稍微檢查了一下Tomcat5.0裡面的Servlet.jar檔案和JBoss裡面的Servlet.jar檔案大小，很明顯是不一樣的，至少已經說明了它們不是源自同根的吧。其實Servlet是由容器根據J2ee的接口定義自己來實作的，實作的方式當然可以不同，隻要都遵守J2ee規範和指南。
上述隻是一個常見的誤區罷了，告訴我們要編譯運作Servlet，是要依賴于實作它的容器的，不然連jar檔案都沒有，編譯都無法進行。那麼Jsp呢？ Java Server Page的簡稱，是為了開發動态網頁而誕生的技術，其本質也是Jsp，在編寫完畢之後會在容器啟動時經過編譯成對應的Servlet。隻是我們利用Jsp 的很多新特性，可以更加專注于前背景的分離，早期Jsp做前台是滿流行的，畢竟裡面支援Html代碼，這讓前台美勞工員可以更有效率的去完成自己的工作。然後Jsp将請求轉發到背景的Servlet，由Servlet處理業務邏輯，再轉發回另外一個Jsp在前台顯示出來。這似乎已經成為一種常用的模式，最初筆者學習J2ee的時候，大量時間也在編寫這樣的代碼。
盡管現在做前台的技術越來越多，例如Flash、Ajax等，已經有很多人不再認為Jsp重要了。筆者覺得Jsp帶來的不僅僅是前後端分離的設計理念，它的另外一項技術成就了我們今天用的很多架構，那就是Tag标簽技術。是以與其說是在學習Jsp，不如更清醒的告訴自己在不斷的了解Tag标簽的意義和本質。
1． Servlet以及Jsp的生命周期
Servlet是Jsp的實質，盡管容器對它們的處理有所差別。Servlet有init()方法初始化，service()方法進行Web服務， destroy()方法進行銷毀，從生到滅都由容器來掌握，是以這些方法除非你想自己來實作Servlet，否則是很少會接觸到的。正是由于很少接觸，才容易被廣大初學者所忽略，希望大家至少記住Servlet生命周期方法都是回調方法。回調這個概念簡單來說就是把自己注入另外一個類中，由它來調用你的方法，所謂的另外一個類就是Web容器，它隻認識接口和接口的方法，注入進來的是怎樣的對象不管，它隻會根據所需調用這個對象在接口定義存在的那些方法。由容器來調用的Servlet對象的初始化、服務和銷毀方法，是以叫做回調。這個概念對學習其他J2ee技術相當關鍵！
那麼Jsp呢？本事上是Servlet，還是有些差別的，它的生命周期是這樣的：
a) 一個用戶端的Request到達伺服器 ->
b) 判斷是否第一次調用 -> 是的話編譯Jsp成Servlet
c) 否的話再判斷此Jsp是否有改變 -> 是的話也重新編譯Jsp成Servlet
d) 已經編譯最近版本的Servlet裝載所需的其他Class
e) 釋出Servlet，即調用它的Service()方法
是以Jsp号稱的是第一次Load緩慢，以後都會很快的運作。從它的生命的周期确實不難看出來這個特點，用戶端的操作很少會改變Jsp的源碼，是以它不需要編譯第二次就一直可以為用戶端提供服務。這裡稍微解釋一下Http的無狀态性，因為發現很多人誤解，Http的無狀态性是指每次一張頁面顯示出來了，與伺服器的連接配接其實就已經斷開了，當再次有送出動作的時候，才會再次與伺服器進行連接配接請求提供服務。當然還有現在比較流行的是Ajax與伺服器異步通過 xml互動的技術，在做前台的領域潛力巨大，筆者不是Ajax的高手，這裡無法為大家解釋。
2． Tag标簽的本質
筆者之前說了，Jsp本身初衷是使得Web應用前背景的開發可以脫離耦合分開有效的進行，可惜這個理念的貢獻反倒不如它帶來的Tag技術對J2ee的貢獻要大。也許已經有很多人開始使用Tag技術了卻并不了解它。是以才建議大家在學習J2ee開始的時候一定要認真學習Jsp，其實最重要的就是明白标簽的本質。
Html标簽我們都很熟悉了，有 <html> 、 <head> 、 <body> 、 <title> ，Jsp帶來的Tag标簽遵循同樣的格式，或者說更嚴格的Xml格式規範，例如 <jsp:include> 、 <jsp:useBean> 、 <c:if> 、 <c:forEach> 等等。它們沒有什麼神秘的地方，就其源頭也還是Java Class而已，Tag标簽的實質也就是一段Java代碼，或者說一個Class檔案。當配置檔案設定好去哪裡尋找這些Class的路徑後，容器負責将頁面中存在的标簽對應到相應的Class上，執行那段特定的Java代碼，如此而已。
說得明白一點的話還是舉幾個簡單的例子說明一下吧：
<jsp:include> 去哪裡找執行什麼class呢?首先這是個jsp類庫的标簽，當然要去jsp類庫尋找相應的class了，同樣它也是由Web容器來提供，例如 Tomcat就應該去安裝目錄的lib檔案夾下面的jsp-api.jar裡面找，有興趣的可以去找一找啊！
<c:forEach> 又去哪裡找呢？這個是由Jsp2.0版本推薦的和核心标記庫的内容，例如 <c:if> 就對應在頁面中做if判斷的功能的一斷Java代碼。它的class檔案在jstl.jar這個類庫裡面，往往還需要和一個standard.jar類庫一起導入，放在具體Web項目的WEB-INF的lib目錄下面就可以使用了。
順便羅唆一句，Web Project的目錄結構是相對固定的，因為容器會按照固定的路徑去尋找它需要的配置檔案和資源，這個任何一本J2ee入門書上都有，這裡就不介紹了。了解Tag的本質還要了解它的工作原理，是以大家去J2ee的API裡找到并研究這個包：javax.servlet.jsp.tagext。它有一些接口，和一些實作類，專門用語開發Tag，隻有自己親自寫出幾個不同功能的标簽，才算是真正了解了标簽的原理。别忘記了自己開發的标簽要自己去完成配置檔案，容器隻是內建了去哪裡尋找jsp标簽對應class的路徑，自己寫的标簽庫當然要告訴容器去哪裡找啦。
說了這麼多，我們為什麼要用标簽呢？完全在Jsp裡面來個 <% %> 就可以在裡面任意寫Java代碼了，但是長期實踐發現頁面代碼統一都是與html同風格的标記語言更加有助于美勞工員進行開發前台，它不需要懂Java，隻要Java程式員給個清單告訴美工什麼标簽可以完成什麼邏輯功能，他就可以專注于美工，也算是進一步隔離了前背景的工作吧！
3． 成就Web架構
架構是什麼？曾經看過這樣的定義：與模式類似，架構也是解決特定問題的可重用方法，架構是一個描述性的建構塊和服務集合，開發人員可以用來達成某個目标。一般來說，架構提供了解決某類問題的基礎設施，是用來建立解決方案的工具，而不是問題的解決方案。
正是由于Tag的出現，成就了以後出現的那麼多Web架構，它們都開發了自己成熟實用的一套标簽，然後由特定的Xml檔案來配置加載資訊，力圖使得Web 應用的開發變得更加高效。下面這些标簽相應對很多人來說相當熟悉了：
<html:password>
<logic:equal>
<bean:write>
<f:view>
<h:form>
<h:message>
它們分别來自Struts和JSF架構，最強大的功能在于控制轉發，就是MVC三層模型中間完成控制器的工作。Struts-1實際上并未做到真正的三層隔離，這一點在Struts-2上得到了很大的改進。而Jsf向來以比較完善合理的标簽庫受到人們推崇。
今天就大概講這麼多吧，再次需要強調的是Servlet/Jsp是學習J2ee必經之路，也是最基礎的知識，希望大家給與足夠的重視！
Java雜談（九）－－Struts
J2ee的開源架構很多，筆者隻能介紹自己熟悉的幾個，其他的目前在中國IT行業應用得不是很多。希望大家對新出的架構不要盲目的推崇，首先一定要熟悉它比舊的到底好在哪裡，新的理念和特性是什麼？然後再決定是否要使用它。
這期的主題是Struts，直譯過來是支架。Struts的第一個版本是在2001年5月釋出的，它提供了一個Web應用的解決方案，如何讓Jsp和 servlet共存去提供清晰的分離視圖和業務應用邏輯的架構。在Struts之前，通常的做法是在Jsp中加入業務邏輯，或者在Servlet中生成視圖轉發到前台去。Struts帶着MVC的新理念當時退出幾乎成為業界公認的Web應用标準，于是當代IT市場上也出現了衆多熟悉Struts的程式員。即使有新的架構再出來不用，而繼續用Struts的理由也加上了一條低風險，因為中途如果開發人員變動，很容易的招進新的會Struts的IT民工啊， ^_^!
筆者之前說的都是Struts-1，因為新出了Struts-2，使得每次談到Struts都必須注明它是Struts-1還是2。筆者先談比較熟悉的 Struts-1，下次再介紹一下與Struts－2的差別：
1． Struts架構整體結構
Struts-1的核心功能是前端控制器，程式員需要關注的是後端控制器。前端控制器是是一個Servlet，在Web.xml中間配置所有 Request都必須經過前端控制器，它的名字是ActionServlet，由架構來實作和管理。所有的視圖和業務邏輯隔離都是應為這個 ActionServlet，它就像一個交通警察，所有過往的車輛必須經過它的法眼，然後被送往特定的通道。所有，對它的了解就是分發器，我們也可以叫做Dispatcher，其實了解Servlet程式設計的人自己也可以寫一個分發器，加上攔截request的Filter，其實自己實作一個struts架構并不是很困難。主要目的就是讓編寫視圖的和背景邏輯的可以脫離緊耦合，各自同步的完成自己的工作。
那麼有了ActionServlet在中間負責轉發，前端的視圖比如說是Jsp，隻需要把所有的資料Submit，這些資料就會到達适合處理它的後端控制器Action，然後在裡面進行處理，處理完畢之後轉發到前台的同一個或者不同的視圖Jsp中間，傳回前台利用的也是Servlet裡面的forward 和redirect兩種方式。是以到目前為止，一切都隻是借用了Servlet的API搭建起了一個友善的架構而已。這也是Struts最顯著的特性?? 控制器。
那麼另外一個特性，可以說也是Struts-1帶來的一個比較成功的理念，就是以xml配置代替寫死配置資訊。以往決定Jsp往哪個servlet送出，是要寫進Jsp代碼中的，也就是說一旦這個送出路徑要改，我們必須改寫代碼再重新編譯。而Struts提出來的思路是，編碼的隻是一個邏輯名字，它對應哪個class檔案寫進了xml配置檔案中，這個配置檔案記錄着所有的映射關系，一旦需要改變路徑，改變xml檔案比改變代碼要容易得多。這個理念可以說相當成功，以緻于後來的架構都延續着這個思路，xml所起的作用也越來越大。
大緻上來說Struts當初給我們帶來的新鮮感就這麼多了，其他的所有特性都是基于友善的控制轉發和可擴充的xml配置的基礎之上來完成它們的功能的。
下面将分别介紹Action和FormBean， 這兩個是Struts中最核心的兩個元件。
2． 後端控制器Action
Action就是我們說的後端控制器，它必須繼承自一個Action父類，Struts設計了很多種Action，例如DispatchAction、 DynaValidationAction。它們都有一個處理業務邏輯的方法execute()，傳入的request, response, formBean和actionMapping四個對象，傳回actionForward對象。到達Action之前先會經過一個 RequestProcessor來初始化配置檔案的映射關系，這裡需要大家注意幾點：
1) 為了確定線程安全，在一個應用的生命周期中，Struts架構隻會為每個Action類建立一個Action執行個體，所有的客戶請求共享同一個Action 執行個體，并且所有線程可以同時執行它的execute()方法。是以當你繼承父類Action，并添加了private成員變量的時候，請記住這個變量可以被多個線程通路，它的同步必須由程式員負責。(所有我們不推薦這樣做)。在使用Action的時候，保證線程安全的重要原則是在Action類中僅僅使用局部變量，謹慎的使用執行個體變量。局部變量是對每個線程來說私有的，execute方法結束就被銷毀，而執行個體變量相當于被所有線程共享。
2) 當ActionServlet執行個體接收到Http請求後，在doGet()或者doPost()方法中都會調用process()方法來處理請求。 RequestProcessor類包含一個HashMap，作為存放所有Action執行個體的緩存，每個Action執行個體在緩存中存放的屬性key為 Action類名。在RequestProcessor類的processActionCreate()方法中，首先檢查在HashMap中是否存在 Action執行個體。建立Action執行個體的代碼位于同步代碼塊中，以保證隻有一個線程建立Action執行個體。一旦線程建立了Action執行個體并把它存放到 HashMap中，以後所有的線程會直接使用這個緩存中的執行個體。
3) <action> 元素的 <roles> 屬性指定通路這個Action使用者必須具備的安全角色，多個角色之間逗号隔開。RequestProcessor類在預處理請求時會調用自身的 processRoles()方法，檢查配置檔案中是否為Action配置了安全角色，如果有，就調用HttpServletRequest的 isUserInRole()方法來判斷使用者是否具備了必要的安全性角色，如果不具備，就直接向用戶端傳回錯誤。(傳回的視圖通過 <input> 屬性來指定)
3． 資料傳輸對象FormBean
Struts并沒有把模型層的業務對象直接傳遞到視圖層，而是采用DTO（Data Transfer Object）來傳輸資料，這樣可以減少傳輸資料的備援，提高傳輸效率；還有助于實作各層之間的獨立，使每個層分工明确。Struts的DTO就是 ActionForm，即formBean。由于模型層應該和Web應用層保持獨立。由于ActionForm類中使用了Servlet API，是以不提倡把ActionForm傳遞給模型層， 而應該在控制層把ActionForm Bean的資料重新組裝到自定義的DTO中，再把它傳遞給模型層。它隻有兩個scope，分别是session和request。（預設是session）一個ActionForm标準的生命周期是：
1) 控制器收到請求 ->
2) 從request或session中取出ActionForm執行個體，如不存在就建立一個 ->
3) 調用ActionForm的reset()方法 ->
4) 把執行個體放入session或者request中 ->
5) 将使用者輸入表達資料組裝到ActionForm中 ->
6) 如眼張方法配置了就調用validate()方法 ->
7) 如驗證錯誤就轉發給 <input> 屬性指定的地方，否則調用execute()方法
validate()方法調用必須滿足兩個條件：
1) ActionForm 配置了Action映射而且name屬性比對
2) <aciton> 元素的validate屬性為true
如果ActionForm在request範圍内，那麼對于每個新的請求都會建立新的ActionForm執行個體，屬性被初始化為預設值，那麼reset ()方法就顯得沒有必要；但如果ActionForm在session範圍内，同一個ActionForm執行個體會被多個請求共享，reset()方法在這種情況下極為有用。
4． 驗證架構和國際化
Struts有許多自己的特性，但是基本上大家還是不太常用，說白了它們也是基于JDK中間的很多Java基礎包來完成工作。例如國際化、驗證架構、插件自擴充功能、與其他架構的內建、因為各大架構基本都有提供這樣的特性，Struts也并不是做得最好的一個，這裡也不想多說。Struts的驗證架構，是通過一個validator.xml的配置檔案讀入驗證規則，然後在validation-rules.xml裡面找到驗證實作通過自動為Jsp插入 Javascript來實作，可以說做得相當簡陋。彈出來的JavaScript框不但難看還很多備援資訊，筆者甯願用formBean驗證或者 Action的saveErrors()，驗證邏輯雖然要自己寫，但頁面隐藏/浮現的警告提示更加人性化和美觀一些。
至于Struts的國際化，其實無論哪個架構的國際化，java.util.Locale類是最重要的Java I18N類。在Java語言中，幾乎所有的對國際化和本地化的支援都依賴于這個類。如果Java類庫中的某個類在運作的時候需要根據Locale對象來調整其功能，那麼就稱這個類是本地敏感的(Locale-Sensitive)，例如java.text.DateFormat類就是，依賴于特定Locale。
建立Locale對象的時候，需要明确的指定其語言和國家的代碼，語言代碼遵從的是ISO-639規範，國家代碼遵從ISO-3166規範，可以從
http://www.unicode.org/unicode/onlinedat/languages.html
http://www.unicode.org/unicode/onlinedat/countries.htm
Struts的國際化是基于properties的message/key對應來實作的，筆者曾寫過一個程式，所有Jsp頁面上沒有任何Text文本串，全部都用的是 <bean:message> 去Properties檔案裡面讀，這個時候其實隻要指定不同的語言區域讀不同的Properties檔案就實作了國際化。需要注意的是不同語言的字元寫進Properties檔案的時候需要轉化成Unicode碼，JDK已經帶有轉換的功能。JDK的bin目錄中有native2ascii這個指令，可以完成對*.txt和*.properties的Unicode碼轉換。
OK，今天就說到這裡，本文中的很多内容也不是筆者的手筆，是筆者一路學習過來自己抄下來的筆記，希望對大家有幫助！Java雜談一路走來，感謝大家持續的關注，大概再有個2到3篇續篇就改完結了！筆者盡快整理完成後續的寫作吧……^_^
Java雜談（九）－－Struts2
最近業餘時間筆者一直Java Virtual Machine的研究，由于實習配置設定到項目組裡面，不想從前那麼閑了，好不容易才抽出時間來繼續這個話題的文章。我打算把J2ee的部分結束之後，再談談 JVM和JavaScript，隻要筆者有最新的學習筆記總結出來，一定會拿來及時和大家分享的。衷心希望與熱愛Java的關大同仁共同進步……
這次準備繼續上次的話題先講講Struts-2，手下簡短回顧一段曆史：随着時間的推移，Web應用架構經常變化的需求，産生了幾個下一代 Struts的解決方案。其中的Struts Ti 繼續堅持 MVC模式的基礎上改進，繼續Struts的成功經驗。 WebWork項目是在2002年3月釋出的，它對Struts式架構進行了革命性改進，引進了不少新的思想，概念和功能，但和原Struts代碼并不相容。WebWork是一個成熟的架構，經過了好幾次重大的改進與釋出。在2005年12月，WebWork與Struts Ti決定合拼， 再此同時， Struts Ti 改名為 Struts Action Framework 2.0,成為Struts真正的下一代。
看看Struts-2的處理流程：
1) Browser産生一個請求并送出架構來處理：根據配置決定使用哪些攔截器、action類和結果等。
2) 請求經過一系列攔截器：根據請求的級别不同攔截器做不同的處理。這和Struts-1的RequestProcessor類很相似。
3) 調用Action: 産生一個新的action執行個體，調用業務邏輯方法。
4) 調用産生結果：比對result class并調用産生執行個體。
5) 請求再次經過一系列攔截器傳回：過程也可配置減少攔截器數量
6) 請求傳回使用者：從control傳回servlet，生成Html。
這裡很明顯的一點是不存在FormBean的作用域封裝，直接可以從Action中取得資料。 這裡有一個Strut-2配置的web.xml檔案：
<filter>
<filter-name> controller </filter-name>
<filter-class> org.apache.struts.action2.dispatcher.FilterDispatcher </filter-class>
</filter>
<filter-mapping>
<filter-name> cotroller </filter-name>
<url-pattern> /* </url-pattern>
</filter-mapping>
注意到以往的servlet變成了filter，ActionServlet變成了FilterDispatcher，*.do變成了/*。filter 配置定義了名稱(供關聯)和filter的類。filter mapping讓URI比對成功的的請求調用該filter。預設情況下，擴充名為 ".action "。這個是在default.properties檔案裡的 "struts.action.extension "屬性定義的。
default.properties是屬性定義檔案，通過在項目classpath路徑中包含一個名為“struts.properties”的檔案來設定不同的屬性值。而Struts-2的預設配置檔案名為struts.xml。由于1和2的action擴充名分别為.do和.action，是以很友善能共存。我們再來看一個Struts-2的action代碼：
public class MyAction {
public String execute() throws Exception {
//do the work
return "success ";
}
}
很明顯的差別是不用再繼承任何類和接口，傳回的隻是一個String，無參數。實際上在Struts-2中任何傳回String的無參數方法都可以通過配置來調用action。所有的參數從哪裡來獲得呢？答案就是Inversion of Control技術（控制反轉）。筆者盡量以最通俗的方式來解釋，我們先試圖讓這個Action獲得reuqest對象，這樣可以提取頁面送出的任何參數。那麼我們把request設為一個成員變量，然後需要一個對它的set方法。由于大部分的action都需要這麼做，我們把這個set方法作為接口來實作。
public interface ServletRequestAware {
public void setServletRequest(HttpServletRequest request);
}
public class MyAction implements ServletRequestAware {
private HttpServletRequest request;
public void setServletRequest(HttpServletRequest request) {
this.request = request;
}
public String execute() throws Exception {
// do the work directly using the request
return Action.SUCCESS;
}
}
那麼誰來調用這個set方法呢？也就是說誰來控制這個action的行為，以往我們都是自己在适當的地方寫上一句 action.setServletRequest(…)，也就是控制權在程式員這邊。然而控制反轉的思想是在哪裡調用交給正在運作的容器來決定，隻要利用Java反射機制來獲得Method對象然後調用它的invoke方法傳入參數就能做到，這樣控制權就從程式員這邊轉移到了容器那邊。程式員可以減輕很多繁瑣的工作更多的關注業務邏輯。Request可以這樣注入到action中，其他任何對象也都可以。為了保證action的成員變量線程安全， Struts-2的action不是單例的，每一個新的請求都會産生一個新的action執行個體。
那麼有人會問，到底誰來做這個對象的注入工作呢？答案就是攔截器。攔截器又是什麼東西？筆者再來盡量通俗的解釋攔截器的概念。大家要了解攔截器的話，首先一定要了解GOF23種設計模式中的Proxy模式。
A對象要調用f()，它希望代理給B來做，那麼B就要獲得A對象的引用，然後在B的f()中通過A對象引用調用A對象的f()方法，最終達到A的f()被調用的目的。有沒有人會覺得這樣很麻煩，為什麼明明隻要A.f()就可以完成的一定要封裝到B的f()方法中去？有哪些好處呢？
1) 這裡我們隻有一個A，當我們有很多個A的時候，隻需要監視B一個對象的f()方法就可以從全局上控制所有被調用的f()方法。
2) 另外，既然代理人B能獲得A對象的引用，那麼B可以決定在真正調A對象的f()方法之前可以做哪些前置工作，調完傳回前可有做哪些後置工作。
講到這裡，大家看出來一點攔截器的概念了麼？它攔截下一調f()方法的請求，然後統一的做處理（處理每個的方式還可以不同，解析A對象就可以辨識），處理完畢再放行。這樣像不像對流動的河水橫切了一刀，對所有想通過的水分子進行搜身，然後再放行？這也就是AOP（Aspect of Programming面向切面程式設計）的思想。
Anyway，Struts-2隻是利用了AOP和IoC技術來減輕action和架構的耦合關系，力圖到最大程度重用action的目的。在這樣的技術促動下，Struts-2的action成了一個簡單被架構使用的POJO（Plain Old Java Object）罷了。實事上AOP和IoC的思想已經遍布新出來的每一個架構上，他們并不是多麼新的技術，利用的也都是JDK早已可以最到的事情，它們代表的是更加面向接口程式設計，提高重用，增加擴充性的一種思想。Struts-2隻是部分的使用這兩種思想來設計完成的，另外一個最近很火的架構 Spring，更大程度上代表了這兩種設計思想，筆者将于下一篇來進一步探讨Spring的結構。
PS: 關于Struts-2筆者也沒真正怎麼用過，這裡是看了網上一些前輩的文章之後寫下自己的學習體驗，不足之處請見諒！
Java雜談（十）－－Spring
筆者最近比較忙，一邊在實習一邊在尋找明年畢業更好的工作，不過論壇裡的朋友非常支援小弟繼續寫，今天是周末，泡上一杯咖啡，繼續與大家分享J2ee部分的學習經驗。今天的主題是目前很流行也很好的一個開源架構－Spring。
引用《Spring2.0技術手冊》上的一段話：
Spring的核心是個輕量級容器，它是實作IoC容器和非侵入性的架構，并提供AOP概念的實作方式；提供對持久層、事務的支援；提供MVC Web架構的實作，并對于一些常用的企業服務API提供一緻的模型封裝，是一個全方位的應用程式架構，除此之外，對于現存的各種架構，Spring也提供了與它們相整合的方案。
接下來筆者先談談自己的一些了解吧，Spring架構的發起者之前一本很著名的書名字大概是《J2ee Development without EJB》，他提倡用輕量級的元件代替重量級的EJB。筆者還沒有看完那本著作，隻閱讀了部分章節。其中有一點分析覺得是很有道理的：
EJB裡在伺服器端有Web Container和EJB Container，從前的觀點是各層之間應該在實體上隔離，Web Container處理視圖功能、在EJB Container中處理業務邏輯功能、然後也是EBJ Container控制資料庫持久化。這樣的層次是很清晰，但是一個很嚴重的問題是Web Container和EJB Container畢竟是兩個不同的容器，它們之間要通信就得用的是RMI機制和JNDI服務，同樣都在服務端，卻實體上隔離，而且每次業務請求都要遠端調用，有沒有必要呢？看來并非隔離都是好的。
再看看輕量級和重量級的差別，筆者看過很多種說法，覺得最有道理的是輕量級代表是POJO + IoC，重量級的代表是Container + Factory。（EJB2.0是典型的重量級元件的技術）我們盡量使用輕量級的Pojo很好了解，意義就在于相容性和可适應性，移植不需要改變原來的代碼。而Ioc與Factory比起來，Ioc的優點是更大的靈活性，通過配置可以控制很多注入的細節，而Factory模式，行為是相對比較封閉固定的，生産一個對象就必須接受它全部的特點，不管是否需要。其實輕量級和重量級都是相對的概念，使用資源更少、運作負載更小的自然就算輕量。
話題扯遠了，因為Spring架構帶來了太多可以探讨的地方。比如它的非侵入性：指的是它提供的架構實作可以讓程式員程式設計卻感覺不到架構的存在，這樣所寫的代碼并沒有和架構綁定在一起，可以随時抽離出來，這也是Spring設計的目标。Spring是唯一可以做到真正的針對接口程式設計，處處都是接口，不依賴綁定任何實作類。同時，Spring還設計了自己的事務管理、對象管理和Model2 的MVC架構，還封裝了其他J2ee的服務在裡面，在實作上基本都在使用依賴注入和AOP的思想。由此我們大概可以看到Spring是一個什麼概念上的架構，代表了很多優秀思想，值得深入學習。筆者強調，學習并不是架構，而是架構代表的思想，就像我們當初學Struts一樣……
1．Spring MVC
關于IoC和AOP筆者在上篇已經稍微解釋過了，這裡先通過Spring的MVC架構來給大家探讨一下Spring的特點吧。（畢竟大部分人已經很熟悉Struts了，對比一下吧）
衆所周知MVC的核心是控制器。類似Struts中的ActionServlet，Spring裡面前端控制器叫做DispatcherServlet。裡面充當Action的元件叫做Controller，傳回的視圖層對象叫做ModelAndView，送出和傳回都可能要經過過濾的元件叫做 Interceptor。
讓我們看看一個從請求到傳回的流程吧：
(1) 前台Jsp或Html通過點選submit，将資料裝入了request域
(2) 請求被Interceptor攔截下來，執行preHandler()方法出前置判斷
(3) 請求到達DispathcerServlet
(4) DispathcerServlet通過Handler Mapping來決定每個reuqest應該轉發給哪個後端控制器Controller
Java雜談（十一）ORM
這是最後一篇Java雜談了，以ORM架構的談論收尾，也算是把J2ee的最後一方面給涵蓋到了，之是以這麼晚才總結出ORM這方面，一是筆者這兩周比較忙，另一方面也想善始善終，仔細的先自己好好研究一下ORM架構技術，不想草率的敷衍了事。
其實J2ee的規範指南裡面就已經包括了一些對象持久化技術，例如JDO（Java Data Object）就是Java對象持久化的新規範，一個用于存取某種資料倉庫中的對象的标準化API，提供了透明的對象存儲，對開發人員來說，存儲資料對象完全不需要額外的代碼（如JDBC API的使用）。這些繁瑣的工作已經轉移到JDO産品提供商身上，使開發人員解脫出來，進而集中時間和精力在業務邏輯上。另外，JDO很靈活，因為它可以在任何資料底層上運作。JDBC隻是面向關系資料庫（RDBMS）JDO更通用，提供到任何資料底層的存儲功能，比如關系資料庫、檔案、XML以及對象資料庫（ODBMS）等等，使得應用可移植性更強。我們如果要了解對象持久化技術，首先要問自己一個問題：為什麼傳統的JDBC來持久化不再能滿足大家的需求了呢？
筆者認為最好是能用JDBC真正編寫過程式了才能真正體會ORM的好處，同樣的道理，真正拿Servlet/Jsp做過項目了才能體會到Struts、 Spring等架構的友善之處。很幸運的是筆者這兩者都曾經經曆過，用混亂的内嵌Java代碼的Jsp加Servlet轉發寫過完整的Web項目，也用 JDBC搭建過一個完整C/S項目的背景。是以現在接觸到新架構才更能體會它們思想和實作的優越之處，回顧從前的代碼，真是醜陋不堪啊。^_^
回到正題，我們來研究一下為什麼要從JDBC發展到ORM。簡單來說，傳統的JDBC要花大量的重複代碼在初始化資料庫連接配接上，每次增删改查都要獲得 Connection對象，初始化Statement，執行得到ResultSet再封裝成自己的List或者Object，這樣造成了在每個資料通路方法中都含有大量備援重複的代碼，考慮到安全性的話，還要加上大量的事務控制和log記錄。雖然我們學習了設計模式之後，可以自己定義Factory來幫助減少一部分重複的代碼，但是仍然無法避免備援的問題。其次，随着OO思想深入人心，連典型的過程化語言Perl等都冠冕堂皇的加上了OO的外殼，何況是 Java中繁雜的資料庫通路持久化技術呢？強調面向對象程式設計的結果就是找到一個橋梁，使得關系型資料庫存儲的資料能準确的映射到Java的對象上，然後針對Java對象來設計對象和方法，如果我們把資料庫的Table當作Class，Record當作Instance的話，就可以完全用面向對象的思想來編寫資料層的代碼。于是乎，Object Relationship Mapping的概念開始普遍受到重視，盡管很早很早就已經有人提出來了。
缺點我們已經大概清楚了，那麼如何改進呢？對症下藥，首先我們要解決的是如何從Data Schema準備完美的映射到Object Schema，另外要提供對資料庫連接配接對象生命周期的管理，對事務不同粒度的控制和考慮到擴充性後提供對XML、Properties等可配置化的檔案的支援。到目前為止，有很多架構和技術在嘗試着這樣做。例如似乎是封裝管理得過了頭的EJB、很早就出現目前已經不在開發和更新了的Apache OJB、首先支援Manual SQL的iBATIS，還有公認非常優秀的Hibernate等等。在分别介紹它們之前，我還想反複強調這些架構都在試圖做什麼：
畢竟Java Object和資料庫的每一條Record還是有很大的差別，就是類型上來說，DB是沒有Boolean類型的。而Java也不得不用封裝類（Integer、Double等）為了能映射上資料庫中為null的情況，畢竟Primitive類型是沒有null值的。還有一個比較明顯的問題是，資料庫有主鍵和外鍵，而Java中仍然隻能通過基本類型來對應字段值而已，無法規定Unique等特征，更别提外鍵限制、事務控制和級聯操作了。另外，通過Java Object預設某Field值去取資料庫記錄，是否在這樣的記錄也是不能保證的。真的要設計到完全映射的話，Java的Static被所有對象共享的變量怎麼辦？在資料庫中如何表現出來……
我們能看到大量的問題像一座座大山橫在那些架構設計者們面前，他們并不是沒有解決辦法，而是從不同的角度去考慮，會得到很多不同的解決方案，問題是應該采取哪一種呢？甚至隻有等到真正設計出來了投入生産使用了，才能印證出當初的設想是否真的能為項目開發帶來更多的益處。筆者引用一份文檔中提到一個健壯的持久化架構應該具有的特點：
A robust persistence layer should support----
1. Several types of persistence mechanism
2. Full encapsulation of the persistence mechanism.
3. Multi-object actions
4. Transactions Control
5. Extensibility
6. Object identifiers
7. Cursors: logical connection to the persistence mechanism
8. Proxies: commonly used when the results of a query are to be displayed in a list
9. Records: avoid the overhead of converting database records to objects and then back to records
10. Multi architecture
11. Various database version and/or vendors
12. Multiple connections
13. Native and non-native drivers
14. Structured query language queries(SQL)
Java雜談（十一） ORM
現在來簡短的介紹一下筆者用過的一些持久化架構和技術，之是以前面強調那麼多共通的知識，是希望大家不要盲從流行架構，一定要把握它的本質和卓越的思想好在哪裡。
1． Apache OJB
OJB代表Apache Object Relational Bridge，是Apache開發的一個資料庫持久型架構。它是基于J2ee規範指南下的持久型架構技術而設計開發的，例如實作了ODMG 3.0規範的API，實作了JDO規範的API， 核心實作是Persistence Broker API。OJB使用XML檔案來實作映射并動态的在Metadata layer聽過一個Meta-Object-Protocol(MOP)來改變底層資料的行為。更進階的特點包括對象緩存機制、鎖管理機制、 Virtual 代理、事務隔離性級别等等。舉個OJB Mapping的簡單例子ojb-repository.xml：
<class-descriptor class=”com.ant.Employee” table=”EMPLOYEE”>
<field-descriptor name=”id” column=”ID”
jdbc-type=”INTEGER” primarykey=”true” autoincrement=”true”/>
<field-descriptor name=”name” column=”NAME” jdbc-type=”VARCHAR”/>
</class-descrptor>
<class-descriptor class=”com.ant.Executive” table=”EXECUTIVE”>
<field-descriptor name=”id” column=”ID”
jdbc-type=”INTEGER” primarykey=”true” autoincrement=”true”/>
<field-descriptor name=”department” column=”DEPARTMENT” jdbc-type=”VARCHAR”/>
<reference-descriptor name=”super” class-ref=”com.ant.Employee”>
<foreignkey field-ref=”id”/>
</reference-descriptor>
</class-descrptor>
2． iBATIS
iBATIS最大的特點就是允許使用者自己定義SQL來組配Bean的屬性。因為它的SQL語句是直接寫入XML檔案中去的，是以可以最大程度上利用到 SQL文法本身能控制的全部特性，同時也能允許你使用特定資料庫伺服器的額外特性，并不局限于類似SQL92這樣的标準，它最大的缺點是不支援枚舉類型的持久化，即把枚舉類型的幾個對象屬性拼成與資料庫一個字段例如VARCHAR對應的行為。這裡也舉一個Mapping檔案的例子sqlMap.xml：
<sqlMap>
<typeAlias type=”com.ant.Test” alias=”test”/>
<resultMap class=”test” id=”result”>
<result property=”testId” column=”TestId”/>
<result property=”name” column=”Name”/>
<result property=”date” column=”Date”/>
</resultMap>
<select id=”getTestById” resultMap=”result” parameterClass=”int”>
select * from Test where TestId=#value#
</select>
<update id=”updateTest” parameterClass=”test”>
Update Tests set Name=#name#, Date=”date” where TestId=#testId#
</update>
</sqlMap>
3． Hibernate
Hibernate無疑是應用最廣泛最受歡迎的持久型架構，它生成的SQL語句是非常優秀。雖然一度因為不能支援手工SQL而性能受到局限，但随着新一代 Hibernate 3.x推出，很多缺點都被改進，Hibernate也是以變得更加通用而時尚。同樣先看一個Mapping檔案的例子customer.hbm.xml來有一個大概印象：
<hibernate-mapping>
<class name=”com.ant.Customer” table=”Customers”>
<id name=”customerId” column=”CustomerId” type=”int” unsaved-value=”0”>
<generator class=”sequence”>
<param name=”sequence”> Customers_CustomerId_Seq </param>
</generator>
</id>
<property name=”firstName” column=”FirstName”/>
<property name=”lastName” column=”LastName”/>
<set name=”addresses” outer-join=”true”>
<key column=”Customer”/>
<one-to-many class=”com.ant.Address”/>
</set>
</class>
</hibernate-mapping>
Hibernate有很多顯著的特性，最突出的就是它有自己的查詢語言叫做HQL，在HQL中select from的不是Table而是類名，一方面更加面向對象，另外一方面通過在hibernate.cfg.xml中配置Dialect為HQL可以使得整個背景與資料庫脫離耦合，因為不管用那種資料庫我都是基于HQL來查詢，Hibernate架構負責幫我最終轉換成特定資料庫裡的SQL語句。另外 Hibernate在Object-Caching這方面也做得相當出色，它同時管理兩個級别的緩存，當資料被第一次取出後，真正使用的時候對象被放在一級緩存管理，這個時候任何改動都會影響到資料庫；而空閑時候會把對象放在二級緩存管理，雖然這個時候與資料庫字段能對應上但未綁定在一起，改動不會影響到資料庫的記錄，主要目的是為了在重複讀取的時候更快的拿到資料而不用再次請求連接配接對象。其實關于這種緩存的設計建議大家研究一下Oracle的存儲機制（原理是相通的），Oracle犧牲了空間換來時間依賴于很健壯的緩存算法來保證最優的企業級資料庫通路速率。
以上是一些Mapping的例子，真正在Java代碼中使用多半是繼承各個架構中預設的Dao實作類，然後可以通過Id來查找對象，或者通過 Example來查找，更流行的是更具Criteria查找對象。Criteria是完全封裝了SQL條件查詢文法的一個工具類，任何一個查詢條件都可以在Criteria中找到方法與之對應，這樣可以在Java代碼級别實作SQL的完全控制。另外，現在許多ORM架構的最新版本随着JDk 5.0加入Annotation特性都開始支援用XDoclet來自動根據Annotation來生成XML配置檔案了。
筆者不可能詳細的講解每一個架構，也許更多的人在用Hibernate，筆者是從OJB開始接觸ORM技術的，它很原始卻更容易讓人了解從JDBC到 ORM的過渡。更多的細節是可以從官方文檔和書籍中學到的，但我們應該更加看中它們設計思想的來源和閃光點，不是盲從它們的使用方法。
![Java小案例——随機數猜測随機數猜測[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)