一個計算機專業學生幾年的編程經驗彙總（轉載）

原地址： http://www.blogjava.net/ITdavid/archive/2008/01/23/177209.html

來學習Java也有兩個年頭了，永遠不敢說多麼精通，但也想談談本身的感覺，寫給軟件學院的同仁們，幫助你們在技術的道路上少一點彎路。說得偉大一點是但願你們爲軟件學院爭氣，其實最主要的仍是你們自身的進步提高??

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.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程序員才能針對統一的接口進行程序設計，最終不用改變代碼只是由於使用了不一樣廠商的實現類而有不一樣的特性罷了，本質上說，不管哪種廠商實現都完成了職責範圍內的工做。這個就是筆者想一直強調的，針對接口編程的思想。  

        接口到底有什麼好處呢？咱們這樣設想，如今有AppleMp三、SonyMp三、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、Struts二、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應該轉發給哪一個後端控制器Controlle 

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)  

        如今來簡短的介紹一下筆者用過的一些持久化框架和技術，之因此前面強調那麼多共通的知識，是但願你們不要盲從流行框架，必定要把握它的本質和卓越的思想好在哪裏。  
        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的過渡。更多的細節是能夠從官方文檔和書籍中學到的，但咱們應該更加看中它們設計思想的來源和閃光點，不是盲從它們的使用方法。