給學Java的大學生們分享一些經(jīng)驗.doc

想來學習Java也有兩個年頭了，永遠不敢說多么精通，但也想談?wù)勛约旱母惺?，寫給軟件學院的同仁們，幫助大家在技術(shù)的道路上少一點彎路。說得偉大一點是希望大家為軟件學院爭氣，其實最主要的還是大家自身的進步提升 1 關(guān)于動態(tài)加載機制 學習Java比C+更容易理解OOP的思想，畢竟C+還混合了不少面向過程的成分。很多人都能背出來Java語言的特點，所謂的動態(tài)加載機制等等。當然概念往往是先記住而后消化的，可有多少人真正去體會過動態(tài)加載的機制，試圖去尋找過其中的細節(jié)呢? 提供大家一個方法： 在命令行窗口運行Java程序的時候，加上這個很有用的參數(shù)： java verbose *.class 這樣會清晰的打印出被加載的類文件，大部分是jdk自身運行需要的，最后幾行會明顯的看到自己用到的那幾個類文件被加載進來的順序。即使你聲明了一個類對象，不實例化也不會加載，說明只有真正用到那個類的實例即對象的時候，才會執(zhí)行加載。這樣是不是大家稍微能明白一點動態(tài)加載了呢？_ 2 關(guān)于尋找class文件原理 建議大家在入門的時候在命令行窗口編譯和運行，不要借助JCreator或者Eclipse等IDE去幫助做那些事情。嘗試自己這樣做： javac -classpath yourpath *.java java -classpath yourpath *.class 也許很多人都能看懂，設(shè)置classpath的目的就是告訴編譯器去哪里尋找你的class文件. 不過至少筆者今日才弄懂JVM去查詢類的原理，編譯器加載類要依靠classloader， 而classloader有3個級別，從高到低分別是BootClassLoader(名字可能不準確) , ExtClassLoader, AppClassLoader. 這3個加載器分別對應(yīng)著編譯器去尋找類文件的優(yōu)先級別和不同的路徑：BootClassLoader對應(yīng)jre/classes路徑，是編譯器最優(yōu)先尋找class的地方 ExtClassLoader對應(yīng)jre/lib/ext路徑，是編譯器次優(yōu)先尋找class的地方 AppClassLoader對應(yīng)當前路徑，所以也是編譯器默認找class的地方 其實大家可以自己寫個程序簡單的測試，對任何class，例如A, 調(diào)用new A().getClass().getClassLoader().toString() 打印出來就可以看到，把class文件放在不同的路徑下再次執(zhí)行，就會看到區(qū)別。特別注意的是如果打印出來是null就表示到了最高級BootClassLoader, 因為它是C+編寫的，不存在Java對應(yīng)的類加載器的名字。 尋找的順序是一種向上迂回的思想，即如果本級別找不到，就只能去本級別之上的找，不會向下尋找。不過似乎從Jdk1.4到Jdk1.6這一特點又有改變，沒有找到詳細資料。所以就不舉例子了。告訴大家設(shè)計這種體系的是Sun公司曾經(jīng)的技術(shù)核心宮力先生，一個純種華人哦！_ 這樣希望大家不至于迷惑為什么總報錯找不到類文件，不管是自己寫的還是導入的第三方的jar文件（J2ee中經(jīng)常需要導入的）。 3 關(guān)于jdk和jre 大家肯定在安裝JDK的時候會有選擇是否安裝單獨的jre，一般都會一起安裝，我也建議大家這樣做。因為這樣更能幫助大家弄清楚它們的區(qū)別： Jre 是java runtime environment, 是java程序的運行環(huán)境。既然是運行，當然要包含jvm，也就是大家熟悉的虛擬機啦， 還有所有java類庫的class文件，都在lib目錄下打包成了jar。大家可以自己驗證。至于在windows上的虛擬機是哪個文件呢？ 學過MFC的都知道什么是dll文件吧，那么大家看看jre/bin/client里面是不是有一個jvm.dll呢？那就是虛擬機。 Jdk 是java development kit，是java的開發(fā)工具包，里面包含了各種類庫和工具。當然也包括了另外一個Jre. 那么為什么要包括另外一個Jre呢？而且jdk/jre/bin同時有client和server兩個文件夾下都包含一個jvm.dll。 說明是有兩個虛擬機的。這一點不知道大家是否注意到了呢？ 相信大家都知道jdk的bin下有各種java程序需要用到的命令，與jre的bin目錄最明顯的區(qū)別就是jdk下才有javac，這一點很好理解，因為jre只是一個運行環(huán)境而已。與開發(fā)無關(guān)，正因為如此，具備開發(fā)功能的jdk自己的jre下才會同時有client性質(zhì)的jvm和server性質(zhì)的jvm， 而僅僅作為運行環(huán)境的jre下只需要client性質(zhì)的jvm.dll就夠了。 記得在環(huán)境變量path中設(shè)置jdk/bin路徑麼？這應(yīng)該是大家學習Java的第一步吧， 老師會告訴大家不設(shè)置的話javac和java是用不了的。確實jdk/bin目錄下包含了所有的命令?？墒怯袥]有人想過我們用的java命令并不是jdk/bin目錄下的而是jre/bin目錄下的呢？不信可以做一個實驗，大家可以把jdk/bin目錄下的java.exe剪切到別的地方再運行java程序，發(fā)現(xiàn)了什么？一切OK！ 那么有人會問了？我明明沒有設(shè)置jre/bin目錄到環(huán)境變量中?。?試想一下如果java為了提供給大多數(shù)人使用，他們是不需要jdk做開發(fā)的，只需要jre能讓java程序跑起來就可以了，那么每個客戶還需要手動去設(shè)置環(huán)境變量多麻煩啊？所以安裝jre的時候安裝程序自動幫你把jre的java.exe添加到了系統(tǒng)變量中，驗證的方法很簡單，大家看到了系統(tǒng)環(huán)境變量的path最前面有“%SystemRoot%system32;%SystemRoot%;”這樣的配置，那么再去Windows/system32下面去看看吧，發(fā)現(xiàn)了什么？有一個java.exe。 如果強行能夠把jdk/bin挪到system32變量前面，當然也可以迫使使用jdk/jre里面的java，不過除非有必要，我不建議大家這么做。使用單獨的jre跑java程序也算是客戶環(huán)境下的一種測試。 這下大家應(yīng)該更清楚jdk和jre內(nèi)部的一些聯(lián)系和區(qū)別了吧？ PS: 其實還有滿多感想可以總結(jié)的，一次寫多了怕大家扔磚頭砸死我，怪我太羅唆。大家應(yīng)該更加踏實更加務(wù)實的去做一些研究并互相分享心得，大方向和太前沿的技術(shù)討論是必要的但最好不要太多，畢竟自己基礎(chǔ)都還沒打好，什么都講最新版本其實是進步的一大障礙！Java學習雜談（二） 鑒于上回寫的一點感想大家不嫌棄，都鼓勵小弟繼續(xù)寫下去，好不容易等到國慶黃金周，實習總算有一個休息的階段，于是這就開始寫第二篇了。希望這次寫的仍然對志同道合的朋友們有所幫助。上回講了Java動態(tài)加載機制、classLoader原理和關(guān)于jdk和jre三個問題。這次延續(xù)著講一些具體的類庫 1關(guān)于集合框架類 相信學過Java的各位對這個名詞并不陌生，對java.util.*這個package肯定也不陌生。不知道大家查詢API的時候怎么去審視或者分析其中的一個package，每個包最重要的兩個部分就是interfaces和classes，接口代表了它能做什么，實現(xiàn)類則代表了它如何去做。關(guān)注實現(xiàn)類之前，我們應(yīng)該先理解清楚它的來源接口，不管在j2se還是j2ee中，都應(yīng)該是這樣。那么我們先看這三個接口：List、Set、Map。 也許有些人不太熟悉這三個名字，但相信大部分人都熟悉ArrayList，LinkedList，TreeSet，HashSet，HashMap，Hashtable等實現(xiàn)類的名字。它們的區(qū)別也是滿容易理解的，List放可以重復(fù)的對象集合，Set放不可重復(fù)的對象組合，而Map則放 這樣的名值對，Key不可重復(fù)，Value可以。這里有幾個容易混淆的問題： 到底Vector和ArrayList，Hashtable和HashMap有什么區(qū)別？ 很多面試官喜歡問這個問題，其實更專業(yè)一點應(yīng)該這樣問：新集合框架和舊集合框架有哪些區(qū)別？新集合框架大家可以在這些包中找sincejdk1.2的，之前的如vector和Hashtable都是舊的集合框架包括的類。那么區(qū)別是？ a.新集合框架的命名更加科學合理。例如List下的ArrayList和LinkedList b.新集合框架下全部都是非線程安全的。建議去jdk里面包含的源代碼里面自己去親自看看vector和ArrayList的區(qū)別吧。當然如果是jdk5.0之后的會比較難看一點，因為又加入了泛型的語法，類似c+的template語法。 那么大家是否想過為什么要從舊集合框架默認全部加鎖防止多線程訪問更新到新集合框架全部取消鎖，默認方式支持多線程？(當然需要的時候可以使用collections的靜態(tài)方法加鎖達到線程安全) 筆者的觀點是任何技術(shù)的發(fā)展都未必是遵循它們的初衷的，很多重大改變是受到客觀環(huán)境的影響的。大家知道Java的初衷是為什么而開發(fā)的麼？是為嵌入式程序開發(fā)的。記得上一篇講到classLoader機制麼？那正是為了節(jié)約嵌入式開發(fā)環(huán)境下內(nèi)存而設(shè)計的。而走到今天，Java成了人們心中為互聯(lián)網(wǎng)誕生的語言?；ヂ?lián)網(wǎng)意味著什么？多線程是必然的趨勢?？陀^環(huán)境在變，Java技術(shù)也隨著飛速發(fā)展，導致越來越脫離它的初衷。據(jù)說Sun公司其實主打的是J2se，結(jié)果又是由于客觀環(huán)境影響，J2se幾乎遺忘，留在大家談?wù)摻裹c的一直是j2ee。 技術(shù)的細節(jié)這里就不多說了，只有用了才能真正理解。解釋這些正是為了幫助大家理解正在學的和將要學的任何技術(shù)。之后講j2ee的時候還會再討論。 多扯句題外話：幾十年前的IT巨人是IBM，Mainframe市場無人可比。微軟如何打敗IBM？正是由于硬件飛速發(fā)展，對個人PC的需求這個客觀環(huán)境，讓微軟通過OS稱為了第二個巨人。下一個打敗微軟的呢？Google。如何做到的？如果微軟并不和IBM爭大型機，Google借著互聯(lián)網(wǎng)飛速發(fā)展這個客觀環(huán)境作為決定性因素，避開跟微軟爭OS，而是走搜索引擎這條路，稱為第3個巨人。那么第4個巨人是誰呢？很多專家預(yù)言將在亞洲或者中國出現(xiàn)，Whatever，客觀環(huán)境變化趨勢才是決定大方向的關(guān)鍵。當然筆者也希望會出現(xiàn)在中國，_ 2關(guān)于Java設(shè)計模式 身邊的很多在看GOF的23種設(shè)計模式，似乎學習它無論在學校還是在職場，都成了一種流行風氣。我不想列舉解釋這23種DesignPattern，我寫這些的初衷一直都是談自己的經(jīng)歷和看法，希望能幫助大家理解。 首先我覺得設(shè)計模式只是對一類問題的一種通用解決辦法，只要是面向?qū)ο蟮木幊填A(yù)言都可以用得上這23種。理解它們最好的方法就是親自去寫每一種，哪怕是一個簡單的應(yīng)用就足夠了。如果代碼實現(xiàn)也記不住的話，記憶它們對應(yīng)的UML圖會是一個比較好的辦法，當然前提是必須了解UML。 同時最好能利用Java自身的類庫幫助記憶，例如比較常用的觀察者模式，在java.util.*有現(xiàn)成的Observer接口和Observable這個實現(xiàn)類，看看源代碼相信就足夠理解觀察者模式了。再比如裝飾器模式，大家只要寫幾個關(guān)于java.io.*的程序就可以完全理解什么是裝飾器模式了。有很多人覺得剛?cè)腴T的時候不該接觸設(shè)計模式，比如圖靈設(shè)計叢書系列很出名的那本Java設(shè)計模式，作者:StevenJohnMetsker，大部分例子老實說令現(xiàn)在的我也很迷惑。但我仍然不同意入門跟學習設(shè)計模式有任何沖突，只是我們需要知道每種模式的概念的和典型的應(yīng)用，這樣我們在第一次編寫FileOutputStream、BufferedReader、PrintWriter的時候就能感覺到原來設(shè)計模式離我們?nèi)绱酥?，而且并不是多么神秘的東西。 另外，在學習某些模式的同時，反而更能幫助我們理解java類庫的某些特點。例如當你編寫原型(Prototype)模式的時候，你必須了解的是java.lang.Cloneable這個接口和所有類的基類Object的clone()這個方法。即深copy和淺copy的區(qū)別： Object.clone()默認實現(xiàn)的是淺copy，也就是復(fù)制一份對象拷貝，但如果對象包含其他對象的引用，不會復(fù)制引用，所以原對象和拷貝共用那個引用的對象。 深copy當然就是包括對象的引用都一起復(fù)制啦。這樣原對象和拷貝對象，都分別擁有一份引用對象。如果要實現(xiàn)深copy就必須首先實現(xiàn)java.lang.Cloneable接口，然后重寫clone()方法。因為在Object中的clone()方法是protected簽名的，而Cloneable接口的作用就是把protected放大到public，這樣clone()才能被重寫。 那么又有個問題了？如果引用的對象又引用了其他對象呢？這樣一直判斷并復(fù)制下去，是不是顯得很麻煩？曾經(jīng)有位前輩告訴我的方法是重寫clone方法的時候直接把原對象序列化到磁盤上再反序列化回來，這樣不用判斷就可以得到一個深copy的結(jié)果。如果大家不了解序列化的作法建議看一看ObjectOutputStream和ObjectInputStream 歸根結(jié)底，模式只是思想上的東西，把它當成前人總結(jié)的經(jīng)驗其實一點都不為過。鼓勵大家動手自己去寫，例如代理模式，可以簡單的寫一個Child類，Adult類。Child要買任何東西由Adult來代理實現(xiàn)。簡單來說就是Adult里的buy()內(nèi)部實際調(diào)用的是Child的buy()，可是暴露在main函數(shù)的卻是Adult.buy()。這樣一個簡單的程序就足夠理解代理模式的基本含義了。Java雜談（三） 這已經(jīng)筆者寫的第三篇Java雜記了，慶幸前兩篇一直得到論壇朋友們的支持鼓勵，還望大家繼續(xù)指正不足之處。筆者也一直渴望通過這樣方式清醒的自審，來尋找自己技術(shù)上的不足之處，希望和共同愛好Java的同仁們一起提高。 前兩次分別講述了關(guān)于jvm、jdk、jre、collection、classLoader和一些DesignPattern的自我理解。這次仍然不準備開始過渡到j(luò)2ee中，因為覺得還有一些瑣碎的j2se的問題沒有總結(jié)完畢。 1關(guān)于Object類理解 大家都知道Object是所有Java類的基類，意味著所有的Java類都會繼承了Object的11個方法。建議大家去看看Object的11個成員函數(shù)的源代碼，就會知道默認的實現(xiàn)方式。比如equals方法，默認實現(xiàn)就是用=來比較，即直接比較內(nèi)存地址，返回true或者false。而toString()方法，返回的串組成方式是 getClass().getName()+Integer.toHexString(hashCode() 其實不用我過多的解釋，大家都能看懂這個串的組成。接下來再看看hashCode()： publicnativeinthashCode()； 由于是native方法，跟OS的處理方式相關(guān)，源代碼里僅僅有一個聲明罷了。我們有興趣的話完全可以去深究它的hashCode到底是由OS怎么樣產(chǎn)生的呢？但筆者建議最重要的還是先記住使用它的幾條原則吧！首先如果equals()方法相同的對象具有相通的hashCode，但equals()對象不相通的時候并不保證hashCode()方法返回不同的整數(shù)。而且下一次運行同一個程序，同一個對象未必還是當初的那個hashCode()哦。 其余的方法呢？nofigy()、notifyAll()、clone()、wait()都是native方法的，說明依賴于操作系統(tǒng)的實現(xiàn)。最后一個有趣的方法是finalize()，類似C+的析構(gòu)函數(shù)，簽名是protected，證明只有繼承擴展了才能使用，方法體是空的，默示什么也不做。它的作用據(jù)筆者的了解僅僅是通知JVM此對象不再使用，隨時可以被銷毀，而實際的銷毀權(quán)還是在于虛擬機手上。那么它真的什么也不做麼？未必，實際上如果是線程對象它會導致在一定范圍內(nèi)該線程的優(yōu)先級別提高，導致更快的被銷毀來節(jié)約內(nèi)存提高性能。其實從常理來說，我們也可以大概這樣猜測出jvm做法的目的。 2關(guān)于重載hashCode()與Collection框架的關(guān)系 筆者曾經(jīng)聽一位搞Java培訓多年的前輩說在他看來hashCode方法沒有任何意義，僅僅是為了配合證明具有同樣的hashCode會導致equals方法相等而存在的。連有的前輩都犯這樣的錯誤，其實說明它還是滿容易被忽略的。那么hashCode()方法到底做什么用？ 學過數(shù)據(jù)結(jié)構(gòu)的課程大家都會知道有一種結(jié)構(gòu)叫hashtable，目的是通過給每個對象分配一個唯一的索引來提高查詢的效率。那么Java也不會肆意扭曲改變這個概念，所以hashCode唯一的作用就是為支持數(shù)據(jù)結(jié)構(gòu)中的哈希表結(jié)構(gòu)而存在的，換句話說，也就是只有用到集合框架的Hashtable、HashMap、HashSet的時候，才需要重載hashCode()方法， 這樣才能使得我們能人為的去控制在哈希結(jié)構(gòu)中索引是否相等。筆者舉一個例子： 曾經(jīng)為了寫一個求解類程序，需要隨機列出1,2,3,4組成的不同排列組合，所以筆者寫了一個數(shù)組類用int來存組合結(jié)果，然后把隨機產(chǎn)生的組合加入一個HashSet中，就是想利用HashSet不包括重復(fù)元素的特點?？墒荋ashSet怎么判斷是不是重復(fù)的元素呢？當然是通過hashCode()返回的結(jié)果是否相等來判斷啦，可做一下這個實驗： intA=1,2,3,4; intB=1,2,3,4; System.out.println(A.hashCode(); System.out.println(B.hashCode(); 這明明是同一種組合，卻是不同的hashCode，加入Set的時候會被當成不同的對象。這個時候我們就需要自己來重寫hashCode()方法了，如何寫呢？其實也是基于原始的hashCode()，畢竟那是操作系統(tǒng)的實現(xiàn)，找到相通對象唯一的標識，實現(xiàn)方式很多，筆者的實現(xiàn)方式是： 首先重寫了toString()方法: returnA0“+”A1“+”A2“+”A3;/顯示上比較直觀 然后利用toString()來計算hashCode()： returnthis.toString().hashCode()； 這樣上述A和B返回的就都是”1234”，在測試toString().hashCode()，由于String在內(nèi)存中的副本是一樣的，”1234”.hashCode()返回的一定是相同的結(jié)果。 說到這，相信大家能理解得比我更好，今后千萬不要再誤解hashCode()方法的作用。 3關(guān)于Class類的成員函數(shù)與Java反射機制 很早剛接觸Java就聽很多老師說過Java的動態(tài)運行時機制、反射機制等。確實它們都是Java的顯著特點，運行時加載筆者在第一篇介紹過了，現(xiàn)在想講講反射機制。在Java中，主要是通過java.lang包中的Class類和Method類來實現(xiàn)內(nèi)存反射機制的。 熟悉C+的人一定知道下面這樣在C+中是做不到的：運行時以字符串參數(shù)傳遞一個類名，就可以得到這個類的所有信息，包括它所有的方法，和方法的詳細信息。還可以實例化一個對象，并通過查到的方法名來調(diào)用該對象的任何方法。這是因為Java的類在內(nèi)存中除了C+中也有的靜態(tài)動態(tài)數(shù)據(jù)區(qū)之外，還包括一份對類自身的描述，也正是通過這描述中的信息，才能幫助我們才運行時讀取里面的內(nèi)容，得到需要加載目標類的所有信息，從而實現(xiàn)反射機制。大家有沒有想過當我們需要得到一個JavaBean的實例的時候，怎么知道它有哪些屬性呢？再明顯簡單不過的例子就是自己寫一個JavaBean的解析器： a.通過Class.forName(“Bean的類名”)得到Class對象，例如叫ABeanClass b.通過ABeanClass的getMethods()方法，得到Method對象 c.按照規(guī)范所有g(shù)et方法名后的單詞就代表著該Bean的一個屬性 d.當已經(jīng)知道一個方法名，可以調(diào)用newInstance()得到一個實例，然后通過invoke()方法將方法的名字和方法需要用的參數(shù)傳遞進去，就可以動態(tài)調(diào)用此方法。 當然還有更復(fù)雜的應(yīng)用，這里就不贅述，大家可以參考Class類和Method類的方法。 4坦言Synchronize的本質(zhì) Synchronize大家都知道是同步、加鎖的意思，其實它的本質(zhì)遠沒有大家想得那么復(fù)雜。聲明Synchronize的方法被調(diào)用的時候，鎖其實是加載對象上，當然如果是靜態(tài)類則是加在類上的鎖，調(diào)用結(jié)束鎖被解除。它的實現(xiàn)原理很簡單，僅僅是不讓第二把鎖再次被加在同一個對象或類上，僅此而已。一個簡單的例子足以說明問題： classA synchronizedvoidf() voidg() 當A的一個對象a被第一個線程調(diào)用其f()方法的時候，第二個線程不能調(diào)用a的synchronized方法例如f()，因為那是在試圖在對象上加第二把鎖。但調(diào)用g()卻是可以的，因為并沒有在同一對象上加兩把鎖的行為產(chǎn)生。 這樣大家能理解了麼？明白它的原理能更好的幫助大家設(shè)計同步機制，不要濫用加鎖。 PS：下篇筆者計劃開始對J2ee接觸到的各個方面來進行總結(jié)，談?wù)勛约旱慕?jīng)驗和想法。希望大家還能一如既往的支持筆者寫下去，指正不足之處。Java雜談（四） 不知不覺已經(jīng)寫到第四篇了，論壇里面不斷的有朋友鼓勵我寫下去。堅持自己的作風，把一切迷惑不容易理清楚的知識講出來，講到大家都能聽懂，那么自己就真的懂了。最近在公司實習的時候Trainer跟我講了很多經(jīng)典事跡，對還未畢業(yè)的我來說是筆不小的財富，我自己的信念是：人在逆境中成長的速度要遠遠快過順境中，這樣來看一切都能欣然接受了。 好了，閑話不說了，第三篇講的是反射機制集合框架之類的，這次打算講講自己對反序列化和多線程的理解。希望能對大家學習Java起到幫助 1關(guān)于序列化和反序列化 應(yīng)該大家都大概知道Java中序列化和反序列化的意思，序列化就是把一個Java對象轉(zhuǎn)換成二進制進行磁盤上傳輸或者網(wǎng)絡(luò)流的傳輸，反序列化的意思就是把這個接受到的二進制流重新組裝成原來的對象逆過程。它們在Java中分別是通過ObjectInputStream和ObjectInputStream這兩個類來實現(xiàn)的（以下分別用ois和oos來簡稱）。 oos的writeObject()方法用來執(zhí)行序列化的過程，ois的readObject()用來執(zhí)行反序列化的過程，在傳輸二進制流之前，需要講這兩個高層流對象連接到同一個Channel上，這個Channel可以是磁盤文件，也可以是socket底層流。所以無論用哪種方式，底層流對象都是以構(gòu)造函數(shù)參數(shù)的形式傳遞進oos和ois這兩個高層流，連接完畢了才可以進行二進制數(shù)據(jù)傳輸?shù)?。例子?可以是文件流通道 file=newFile(“C:/data.dat”); oos=newObjectOutputStream(newFileOutputStream(file); ois=newObjectInputStream(newFileInputStream(file); 或者網(wǎng)絡(luò)流通道 oos=newObjectOutputStream(socket.getOutputStream(); ois=newObjectInputStream(socket.getInputStream(); 不知道大家是否注意到oos總是在ois之前定義，這里不希望大家誤解這個順序是固定的么？回答是否定的，那么有順序要求么？回答是肯定的。原則是什么呢？ 原則是互相對接的輸入/輸出流之間必須是output流先初始化然后再input流初始化，否則就會拋異常。大家肯定會問為什么？只要稍微看一看這兩個類的源代碼文件就大概知道了，output流的任務(wù)很簡單，只要把對象轉(zhuǎn)換成二進制往通道中寫就可以了，但input流需要做很多準備工作來接受并最終重組這個Object，所以O(shè)bjectInputStream的構(gòu)造函數(shù)中就需要用到output初始化發(fā)送過來的header信息，這個方法叫做readStreamHeader()，它將會去讀兩個Short值用于決定用多大的緩存來存放通道發(fā)送過來的二進制流，這個緩存的size因jre的版本不同是不一樣的。所以output如果不先初始化，input的構(gòu)造函數(shù)首先就無法正確運行。 對于上面兩個例子，第一個順序是嚴格的，第二個因為oos和ois連接的已經(jīng)不是對方了，而是socket另外一端的流，需要嚴格按照另外一方對接的output流先于對接的input流打開才能順利運行。 這個writeObject和readObject本身就是線程安全的，傳輸過程中是不允許被并發(fā)訪問的。所以對象能一個一個接連不斷的傳過來，有很多人在運行的時候會碰到EOFException,然后百思不得其解，去各種論壇問解決方案。其實筆者這里想說，這個異常不是必須聲明的，也就是說它雖然是異常，但其實是正常運行結(jié)束的標志。EOF表示讀到了文件尾，發(fā)送結(jié)束自然連接也就斷開了。如果這影響到了你程序的正確性的話，請各位靜下心來看看自己程序的業(yè)務(wù)邏輯，而不要把注意力狹隘的聚集在發(fā)送和接受的方法上。因為筆者也被這樣的bug困擾了1整天，被很多論壇的帖子誤解了很多次最后得出的教訓。如果在while循環(huán)中去readObject，本質(zhì)上是沒有問題的，有對象數(shù)據(jù)來就會讀，沒有就自動阻塞。那么拋出EOFException一定是因為連接斷了還在繼續(xù)read，什么原因?qū)е逻B接斷了呢？一定是業(yè)務(wù)邏輯哪里存在錯誤，比如NullPoint、ClassCaseException、ArrayOutofBound，即使程序較大也沒關(guān)系，最多只要單步調(diào)適一次就能很快發(fā)現(xiàn)bug并且解決它。 難怪一位程序大師說過：解決問題90靠經(jīng)驗，5靠技術(shù)，剩下5靠運氣！真是金玉良言，筆者大概查閱過不下30篇討論在while循環(huán)中使用readObject拋出EOFExceptionde的帖子，大家都盲目的去關(guān)注解釋這個名詞、反序列化的行為或反對這樣寫而沒有一個人認為EOF是正確的行為，它其實很老實的在做它的事情。為什么大家都忽略了真正出錯誤的地方呢？兩個字，經(jīng)驗！ 2關(guān)于Java的多線程編程 關(guān)于Java的線程，初學或者接觸不深的大概也能知道一些基本概念，同時又會很迷惑線程到底是怎么回事？如果有人認為自己已經(jīng)懂了不妨來回答下面的問題： a.A對象實現(xiàn)Runnable接口，A.start()運行后所謂的線程對象是誰？是A么？ b.線程的wait()、notify()方法到底是做什么時候用的，什么時候用？ c.為什么線程的suspend方法會被標注過時，不推薦再使用，線程還能掛起么？ d.為了同步我們會對線程方法聲明Synchronized來加鎖在對象上，那么如果父類的f()方法加了Synchronized，子類重寫f()方法必須也加Synchronized么？如果子類的f()方法重寫時聲明Synchronized并調(diào)用super.f()，那么子類對象上到底有幾把鎖呢？會因為競爭產(chǎn)生死鎖么？ 呵呵，各位能回答上來幾道呢？如果這些都能答上來，說明對線程的概念還是滿清晰的，雖說還遠遠不能算精通。筆者這里一一做回答，礙于篇幅的原因，筆者盡量說得簡介一點，如果大家有疑惑的歡迎一起討論。 首先第一點，線程跟對象完全是兩回事，雖然我們也常說線程對象。但當你用run()和start()來啟動一個線程之后，線程其實跟這個繼承了Thread或?qū)崿F(xiàn)了Runnable的對象已經(jīng)沒有關(guān)系了，對象只能算內(nèi)存中可用資源而對象的方法只能算內(nèi)存正文區(qū)可以執(zhí)行的代碼段而已。既然是資源和代碼段，另外一個線程當然也可以去訪問，main函數(shù)執(zhí)行就至少會啟動兩個線程，一個我們稱之為主線程，還一個是垃圾收集器的線程，主線程結(jié)束就意味著程序結(jié)束，可垃圾收集器線程很可能正在工作。 第二點，wait()和sleep()類似，都是讓線程處于阻塞狀態(tài)暫停一段時間，不同之處在于wait會釋放當前線程占有的所有的鎖，而sleep不會。我們知道獲得鎖的唯一方法是進入了Synchronized保護代碼段，所以大家會發(fā)現(xiàn)只有Synchronized方法中才會出現(xiàn)wait，直接寫會給警告沒有獲得當前對象的鎖。所以notify跟wait配合使用，notify會重新把鎖還給阻塞的線程重而使其繼續(xù)執(zhí)行，當有多個對象wait了，notify不能確定喚醒哪一個，必經(jīng)鎖只有一把，所以一般用notifyAll()來讓它們自己根據(jù)優(yōu)先級等競爭那唯一的一把鎖，競爭到的線程執(zhí)行，其他線程只要繼續(xù)wait。 從前Java允許在一個線程之外把線程掛起，即調(diào)用suspend方法，這樣的操作是極不安全的。根據(jù)面向?qū)ο蟮乃枷朊總€對象必須對自己的行為負責，而對自己的權(quán)力進行封裝。如果任何外步對象都能使線程被掛起而阻塞的話，程序往往會出現(xiàn)混亂導致崩潰，所以這樣的方法自然是被斃掉了啦。 最后一個問題比較有意思，首先回答的是子類重寫f()方法可以加Synchronized也可以不加，如果加了而且還內(nèi)部調(diào)用了super.f()的話理論上是應(yīng)該對同一對象加兩把鎖的，因為每次調(diào)用Synchronized方法都要加一把，調(diào)用子類的f首先就加了一把，進入方法內(nèi)部調(diào)用父類的f又要加一把，加兩把不是互斥的么？那么調(diào)父類f加鎖不就必須永遠等待已經(jīng)加的鎖釋放而造成死鎖么？實際上是不會的，這個機制叫重進入，當父類的f方法試圖在本對象上再加一把鎖的時候，因為當前線程擁有這個對象的鎖，也可以理解為開啟它的鑰匙，所以同一個線程在同一對象上還沒釋放之前加第二次鎖是不會出問題的，這個鎖其實根本就沒有加，它有了鑰匙，不管加幾把還是可以進入鎖保護的代碼段，暢通無阻，所以叫重進入，我們可以簡單認為第二把鎖沒有加上去。 總而言之，Synchronized的本質(zhì)是不讓其他線程在同一對象上再加一把鎖。Java雜談（五）本來預(yù)計J2se只講了第四篇就收尾了，可是版主厚愛把帖子置頂長期讓大家瀏覽讓小弟倍感責任重大，務(wù)必追求最到更好，所以關(guān)于J2se一些沒有提到的部分，決定再寫幾篇把常用的部分經(jīng)驗全部寫出來供大家討論切磋。這一篇準備講一講Xml解析包和JavaSwing，然后下一篇再講java.security包關(guān)于Java沙箱安全機制和RMI機制，再進入J2ee的部分，暫時就做這樣的計劃了。如果由于實習繁忙更新稍微慢了一些，希望各位見諒！ 1Java關(guān)于XML的解析 相信大家對XML都不陌生，含義是可擴展標記語言。本身它也就是一個數(shù)據(jù)的載體以樹狀表現(xiàn)形式出現(xiàn)。后來慢慢的數(shù)據(jù)變成了信息，區(qū)別是信息可以包括可變的狀態(tài)從而針對程序硬編碼的做法變革為針對統(tǒng)一接口硬編碼而可變狀態(tài)作為信息進入了XML中存儲。這樣改變狀態(tài)實現(xiàn)擴展的唯一工作是在XML中添加一段文本信息就可以了，代碼不需要改動也不需要重新編譯。這個靈活性是XML誕生時候誰也沒想到的。 當然，如果接口要能提取XML中配置的信息就需要程序能解析規(guī)范的XML文件，Java中當然要提高包對這個行為進行有利支持。筆者打算講到的兩個包是org.w3c.dom和javax.xml.parsers和。（大家可以瀏覽一下這些包中間的接口和類定義） Javax.xml.parsers包很簡單，沒有接口，兩個工廠配兩個解析器。顯然解析XML是有兩種方式的：DOM解析和SAX解析。本質(zhì)上并沒有誰好誰不好，只是實現(xiàn)的思想不一樣罷了。給一個XML文件的例子： ACat 所謂DOM解析的思路是把整個樹狀圖存入內(nèi)存中，需要那個節(jié)點只需要在樹上搜索就可以讀到節(jié)點的屬性，內(nèi)容等，這樣的好處是所有節(jié)點皆在內(nèi)存可以反復(fù)搜索重復(fù)使用，缺點是需要消耗相應(yīng)的內(nèi)存空間。 自然SAX解析的思路就是為了克服DOM的缺點，以事件觸發(fā)為基本思路，順序的搜索下來，碰到了Element之前觸發(fā)什么事件，碰到之后做什么動作。由于需要自己來寫觸發(fā)事件的處理方案，所以需要借助另外一個自定義的Handler，處于org.xml.sax.helpers包中。它的優(yōu)點當然是不用整個包都讀入內(nèi)存，缺點也是只能順序搜索，走完一遍就得重來。 大家很容易就能猜到，接觸到的J2ee框架用的是哪一種，顯然是DOM。因為類似Struts，Hibernate框架配置文件畢竟是很小的一部分配置信息，而且需要頻繁搜索來讀取，當然會采用DOM方式（其實SAX內(nèi)部也是用DOM采用的結(jié)構(gòu)來存儲節(jié)點信息的）?，F(xiàn)在無論用什么框架，還真難發(fā)現(xiàn)使用SAX來解析XML的技術(shù)了，如果哪位仁兄知道，請讓筆者也學習學習。 既然解析方式有了，那么就需要有解析的存儲位置。不知道大家是否發(fā)現(xiàn)org.w3c.dom這個包是沒有實現(xiàn)類全部都是接口的。這里筆者想說一下Java如何對XML解析是Jdk應(yīng)該考慮的事，是它的責任。而w3c組織是維護定義XML標準的組織，所以一個XML結(jié)構(gòu)是怎么樣的由w3c說了算，它不關(guān)心Java如何去實現(xiàn)，于是乎規(guī)定了所有XML存儲的結(jié)構(gòu)應(yīng)該遵循的規(guī)則，這就是org.w3c.dom里全部的接口目的所在。在筆者看來，簡單理解接口的概念就是實現(xiàn)者必須遵守的原則。 整個XML對應(yīng)的結(jié)構(gòu)叫Document、子元素對應(yīng)的叫做Element、還有節(jié)點相關(guān)的Node、NodeList、Text、Entity、CharacterData、CDATASection等接口，它們都可以在XML的語法中間找到相對應(yīng)的含義。由于這里不是講解XML基本語法，就不多介紹了。如果大家感興趣，筆者也可以專門寫一篇關(guān)于XML的語法規(guī)則帖與大家分享一下。 2JavaSwing Swing是一個讓人又愛又恨的東西，可愛之處在于上手很容易，較AWT比起來Swing提供的界面功能更加強大，可恨之處在于編復(fù)雜的界面工作量實在是巨大。筆者寫過超過3000行的Swing界面，感覺用戶體驗還不是那么優(yōu)秀。最近又寫過超過6000行的，由于功能模塊多了，整體效果還只是一般般。體會最深的就一個字：累!所以大家現(xiàn)在都陸續(xù)不怎么用Swing在真正開發(fā)的項目上了，太多界面技術(shù)可以取代它了。筆者去寫也是迫于無奈組里面大家都沒寫過，我不入地域誰入？ 盡管Swing慢慢的在被人忽略，特別是隨著B/S慢慢的在淹沒C/S，筆者倒是很愿意站出來為Swing正身。每一項技術(shù)的掌握絕不是為了流行時尚跟風。真正喜歡Java的朋友們還是應(yīng)該好好體會一下Swing，相信在校的很多學生也很多在學習它。很可能從Jdk1.1、1.2走過來的很多大學老師可能是最不熟悉它的。 Swing提供了一組輕組件統(tǒng)稱為JComponent，它們與AWT組件的最大區(qū)別是JComponent全部都是Container，而Container的特點是里面可以裝載別的組件。在Swing組件中無論是JButton、JLabel、JPanel、JList等都可以再裝入任何其他組件。好處是程序員可以對Swing組件實現(xiàn)“再開發(fā)”，針對特定需求構(gòu)建自己的按鈕、標簽、畫板、列表之類的特定組件。 有輕自然就有重，那么輕組件和重組件區(qū)別是？重組件表現(xiàn)出來的形態(tài)因操作系統(tǒng)不同而異，輕組件是Swing自己提供GUI，在跨平臺的時候最大程度的保持一致。 那么在編程的時候要注意一些什么呢？筆者談?wù)勛约旱膸c經(jīng)驗： a.明確一個概念，只有Frame組件才可以單獨顯示的，也許有人會說JOptionPane里面的靜態(tài)方法就實現(xiàn)了單獨窗口出現(xiàn)，但追尋源代碼會發(fā)現(xiàn)其實現(xiàn)實出來的Dialog也需要依托一個Frame窗體，如果沒有指定就會默認產(chǎn)生一個然后裝載這個Dialog顯示出來。 b.JFrame是由這么幾部分組成： 最底下一層JRootPane，上面是glassPane(一個JPanel)和layeredPane(一個JLayeredPane)，而layeredPane又由contentPane(一個JPanel)和menuBar構(gòu)成。我們的組件都是加在contentPane上，而背景圖片只能加在layeredPane上面。至于glassPane是一個透明的覆蓋了contentPane的一層，在特定效果中將被利用到來記錄鼠標坐標或掩飾組件。 c.為了增強用戶體驗，我們會在一些按鈕上添加快捷鍵，但Swing里面通常只能識別鍵盤的Alt鍵，要加入其他的快捷鍵，必須自己實現(xiàn)一個ActionListener。 d.通過setLayout(null)可以使得所有組件以setBounds()的四個參數(shù)來精確定位各自的大小、位置，但不推薦使用，因為好的編程風格不應(yīng)該在Swing代碼中硬編碼具體數(shù)字，所有的數(shù)字應(yīng)該以常數(shù)的形式統(tǒng)一存在一個靜態(tài)無實例資源類文件中。這個靜態(tài)無實例類統(tǒng)一負責Swing界面的風格，包括字體和顏色都應(yīng)該包括進去。 e.好的界面設(shè)計有一條GoldenRule:用戶不用任何手冊通過少數(shù)嘗試就能學會使用軟件。所以盡量把按鈕以菜單的形式（不管是右鍵菜單還是窗體自帶頂部菜單）呈現(xiàn)給顧客，除非是頻繁點擊的按鈕才有必要直接呈現(xiàn)在界面中。 其實Swing的功能是相當強大的，只是現(xiàn)在應(yīng)用不廣泛，專門去研究大概是要花不少時間的。筆者在各網(wǎng)站論壇瀏覽關(guān)于Swing的技巧文章還是比較可信的，自己所學非常有限，各人體會對Swing各個組件的掌握就是一個實踐積累的過程。筆者只用到過以上這些，所以只能談?wù)劜糠窒敕?，還望大家見諒！Java雜談（六）這篇是筆者打算寫的J2se部分的最后一篇了，這篇結(jié)束之后，再寫J2ee部分，不知道是否還合適寫在這個版塊？大家可以給點意見，謝謝大家對小弟這么鼓勵一路寫完前六篇Java雜談的J2se部分。最后這篇打算談一談Java中的RMI機制和JVM沙箱安全框架。 1Java中的RMI機制 RMI的全稱是遠程方法調(diào)用，相信不少朋友都聽說過，基本的思路可以用一個經(jīng)典比方來解釋：A計算機想要計算一個兩個數(shù)的加法，但A自己做不了，于是叫另外一臺計算機B幫忙，B有計算加法的功能，A調(diào)用它就像調(diào)用這個功能是自己的一樣方便。這個就叫做遠程方法調(diào)用了。 遠程方法調(diào)用是EJB實現(xiàn)的支柱，建立分布式應(yīng)用的核心思想。這個很好理解，再拿上面的計算加法例子，A只知道去call計算機B的方法，自己并沒有B的那些功能，所以A計算機端就無法看到B執(zhí)行這段功能的過程和代碼，因為看都看不到，所以既沒有機會竊取也沒有機會去改動方法代碼。EJB正式基于這樣的思想來完成它的任務(wù)的。當簡單的加法變成復(fù)雜的數(shù)據(jù)庫操作和電子商務(wù)交易應(yīng)用的時候，這樣的安全性和分布式應(yīng)用的便利性就表現(xiàn)出來優(yōu)勢了。 好了，回到細節(jié)上，要如何實現(xiàn)遠程方法調(diào)用呢？我希望大家學習任何技術(shù)的時候可以試著依賴自己的下意識判斷，只要你的想法是合理健壯的，那么很可能實際上它就是這么做的，畢竟真理都蘊藏在平凡的生活細節(jié)中。這樣只要帶著一些薄弱的Java基礎(chǔ)來思考RMI，其實也可以想出個大概來。 a)需要有一個服務(wù)器角色，它擁有真正的功能代碼方法。例如B，它提供加法服務(wù) b)如果想遠程使用B的功能，需要知道B的IP地址 c)如果想遠程使用B的功能，還需要知道B中那個特定服務(wù)的名字 我們很自然可以想到這些，雖然不完善，但已經(jīng)很接近正確的做法了。實際上RMI要得以實現(xiàn)還得意于Java一個很重要的特性，就是Java反射機制。我們需要知道服務(wù)的名字，但又必須隱藏實現(xiàn)的代碼，如何去做呢？答案就是：接口！ 舉個例子： publicinterfacePe