JAVA編程經(jīng)驗(yàn)匯總（四）
學(xué)習(xí)Java比C++更容易理解OOP的思想，畢竟C++還混合了不少面向過程的成分。本系列文章，介紹JAVA編程經(jīng)驗(yàn)。建議閱讀上一篇：JAVA編程經(jīng)驗(yàn)匯總（三）
1．關(guān)于序列化和反序列化
應(yīng)該大家都大概知道Java中序列化和反序列化的意思，序列化就是把一個(gè)Java對(duì)象轉(zhuǎn)換成二進(jìn)制進(jìn)行磁盤上傳輸或者網(wǎng)絡(luò)流的傳輸，反序列化的意思就是把這個(gè)接受到的二進(jìn)制流重新組裝成原來的對(duì)象逆過程。它們?cè)贘ava中分別是通過ObjectInputStream和 ObjectOutStream這兩個(gè)類來實(shí)現(xiàn)的（以下分別用ois和oos來簡(jiǎn)稱）。
oos的writeObject()方法用來執(zhí)行序列化的過程，ois的readObject()用來執(zhí)行反序列化的過程，在傳輸二進(jìn)制流之前，需要講這兩個(gè)高層流對(duì)象連接到同一個(gè)Channel上，這個(gè)Channel可以是磁盤文件，也可以是socket底層流。所以無論用哪種方式，底層流對(duì)象都是以構(gòu)造函數(shù)參數(shù)的形式傳遞進(jìn)oos和ois這兩個(gè)高層流，連接完畢了才可以進(jìn)行二進(jìn)制數(shù)據(jù)傳輸?shù)摹＠樱?/p>
可以是文件流通道：
- file = new File(“C:/data.dat”);
- oos = new ObjectOutputStream(new FileOutputStream(file));
- ois = new ObjectInputStream(new FileInputStream(file));
或者網(wǎng)絡(luò)流通道
- oos = new ObjectOutputStream(socket.getOutputStream());
- ois = new ObjectInputStream(socket.getInputStream());
不知道大家是否注意到oos總是在ois之前定義，這里不希望大家誤解這個(gè)順序是固定的么？回答是否定的，那么有順序要求么？回答是肯定的。原則是什么呢？
原則是互相對(duì)接的輸入/輸出流之間必須是output流先初始化然后再input流初始化，否則就會(huì)拋異常。
大家肯定會(huì)問為什么？只要稍微看一看這兩個(gè)類的源代碼文件就大概知道了，output流的任務(wù)很簡(jiǎn)單，只要把對(duì)象轉(zhuǎn)換成二進(jìn)制往通道中寫就可以了，但input流需要做很多準(zhǔn)備工作來接受并最終重組這個(gè)Object，所以O(shè)bjectInputStream的構(gòu)造函數(shù)中就需要用到output初始化發(fā)送過來的header信息，這個(gè)方法叫做 readStreamHeader()，它將會(huì)去讀兩個(gè)Short值用于決定用多大的緩存來存放通道發(fā)送過來的二進(jìn)制流，這個(gè)緩存的size因jre的版本不同是不一樣的。
所以output如果不先初始化，input的構(gòu)造函數(shù)首先就無法正確運(yùn)行。
對(duì)于上面兩個(gè)例子，第一個(gè)順序是嚴(yán)格的，第二個(gè)因?yàn)閛os和ois連接的已經(jīng)不是對(duì)方了，而是socket另外一端的流，需要嚴(yán)格按照另外一方對(duì)接的output流先于對(duì)接的input流打開才能順利運(yùn)行。
這個(gè)writeObject和readObject本身就是線程安全的，傳輸過程中是不允許被并發(fā)訪問的。所以對(duì)象能一個(gè)一個(gè)接連不斷的傳過來，有很多人在運(yùn)行的時(shí)候會(huì)碰到EOFException, 然后百思不得其解，去各種論壇問解決方案。其實(shí)筆者這里想說，這個(gè)異常不是必須聲明的，也就是說它雖然是異常，但其實(shí)是正常運(yùn)行結(jié)束的標(biāo)志。EOF表示讀到了文件尾，發(fā)送結(jié)束自然連接也就斷開了。
如果這影響到了你程序的正確性的話，請(qǐng)各位靜下心來看看自己程序的業(yè)務(wù)邏輯，而不要把注意力狹隘的聚集在發(fā)送和接受的方法上。因?yàn)楣P者也被這樣的bug困擾了1整天，被很多論壇的帖子誤解了很多次最后得出的教訓(xùn)。如果在while循環(huán)中去readObject，本質(zhì)上是沒有問題的，有對(duì)象數(shù)據(jù)來就會(huì)讀，沒有就自動(dòng)阻塞。
那么拋出EOFException一定是因?yàn)檫B接斷了還在繼續(xù)read，什么原因?qū)е逻B接斷了呢？一定是業(yè)務(wù)邏輯哪里存在錯(cuò)誤，比如NullPoint、 ClassCaseException、ArrayOutofBound，即使程序較大也沒關(guān)系，最多只要單步調(diào)適一次就能很快發(fā)現(xiàn)bug并且解決它。
難怪一位程序大師說過：解決問題90％靠經(jīng)驗(yàn)，5％靠技術(shù)，剩下5％靠運(yùn)氣！真是金玉良言，筆者大概查閱過不下30篇討論在while循環(huán)中使用 readObject拋出EOFExceptionde 的帖子，大家都盲目的去關(guān)注解釋這個(gè)名詞、反序列化的行為或反對(duì)這樣寫而沒有一個(gè)人認(rèn)為EOF是正確的行為，它其實(shí)很老實(shí)的在做它的事情。為什么大家都忽略了真正出錯(cuò)誤的地方呢？?jī)蓚€(gè)字，經(jīng)驗(yàn)！
2．關(guān)于Java的多線程編程
關(guān)于Java的線程，初學(xué)或者接觸不深的大概也能知道一些基本概念，同時(shí)又會(huì)很迷惑線程到底是怎么回事？如果有人認(rèn)為自己已經(jīng)懂了不妨來回答下面的問題：
a. A對(duì)象實(shí)現(xiàn)Runnable接口，A.start()運(yùn)行后所謂的線程對(duì)象是誰？是A么？
b. 線程的wait()、notify()方法到底是做什么時(shí)候用的，什么時(shí)候用？
c. 為什么線程的suspend方法會(huì)被標(biāo)注過時(shí)，不推薦再使用，線程還能掛起么？
d. 為了同步我們會(huì)對(duì)線程方法聲明Synchronized來加鎖在對(duì)象上，那么如果父類的f()方法加了Synchronized，子類重寫f()方法必須也加Synchronized么？如果子類的f()方法重寫時(shí)聲明Synchronized并調(diào)用super.f()，那么子類對(duì)象上到底有幾把鎖呢？會(huì)因?yàn)楦?jìng)爭(zhēng)產(chǎn)生死鎖么？
呵呵，各位能回答上來幾道呢？如果這些都能答上來，說明對(duì)線程的概念還是滿清晰的，雖說還遠(yuǎn)遠(yuǎn)不能算精通。筆者這里一一做回答，礙于篇幅的原因，筆者盡量說得簡(jiǎn)介一點(diǎn)，如果大家有疑惑的歡迎一起討論。
首先第一點(diǎn)，線程跟對(duì)象完全是兩回事，雖然我們也常說線程對(duì)象。但當(dāng)你用run()和start()來啟動(dòng)一個(gè)線程之后，線程其實(shí)跟這個(gè)繼承了 Thread或?qū)崿F(xiàn)了Runnable的對(duì)象已經(jīng)沒有關(guān)系了，對(duì)象只能算內(nèi)存中可用資源而對(duì)象的方法只能算內(nèi)存正文區(qū)可以執(zhí)行的代碼段而已。
既然是資源和代碼段，另外一個(gè)線程當(dāng)然也可以去訪問，main函數(shù)執(zhí)行就至少會(huì)啟動(dòng)兩個(gè)線程，一個(gè)我們稱之為主線程，還一個(gè)是垃圾收集器的線程，主線程結(jié)束就意味著程序結(jié)束，可垃圾收集器線程很可能正在工作。
第二點(diǎn)，wait()和sleep()類似，都是讓線程處于阻塞狀態(tài)暫停一段時(shí)間，不同之處在于wait會(huì)釋放當(dāng)前線程占有的所有的鎖，而 sleep不會(huì)。我們知道獲得鎖的唯一方法是進(jìn)入了Synchronized保護(hù)代碼段，所以大家會(huì)發(fā)現(xiàn)只有Synchronized方法中才會(huì)出現(xiàn) wait，直接寫會(huì)給警告沒有獲得當(dāng)前對(duì)象的鎖。
所以notify跟wait配合使用，notify會(huì)重新把鎖還給阻塞的線程重而使其繼續(xù)執(zhí)行，當(dāng)有多個(gè)對(duì)象wait了，notify不能確定喚醒哪一個(gè)，必經(jīng)鎖只有一把，所以一般用notifyAll()來讓它們自己根據(jù)優(yōu)先級(jí)等競(jìng)爭(zhēng)那唯一的一把鎖，競(jìng)爭(zhēng)到的線程執(zhí)行，其他線程只要繼續(xù)wait。
從前Java允許在一個(gè)線程之外把線程掛起，即調(diào)用suspend方法，這樣的操作是極不安全的。根據(jù)面向?qū)ο蟮乃枷朊總€(gè)對(duì)象必須對(duì)自己的行為負(fù)責(zé)，而對(duì)自己的權(quán)力進(jìn)行封裝。如果任何外步對(duì)象都能使線程被掛起而阻塞的話，程序往往會(huì)出現(xiàn)混亂導(dǎo)致崩潰，所以這樣的方法自然是被斃掉了啦。
最后一個(gè)問題比較有意思，首先回答的是子類重寫f()方法可以加Synchronized也可以不加，如果加了而且還內(nèi)部調(diào)用了super.f ()的話理論上是應(yīng)該對(duì)同一對(duì)象加兩把鎖的，因?yàn)槊看握{(diào)用Synchronized方法都要加一把，調(diào)用子類的f首先就加了一把，進(jìn)入方法內(nèi)部調(diào)用父類的 f又要加一把，加兩把不是互斥的么？那么調(diào)父類f加鎖不就必須永遠(yuǎn)等待已經(jīng)加的鎖釋放而造成死鎖么？
實(shí)際上是不會(huì)的，這個(gè)機(jī)制叫重進(jìn)入，當(dāng)父類的f方法試圖在本對(duì)象上再加一把鎖的時(shí)候，因?yàn)楫?dāng)前線程擁有這個(gè)對(duì)象的鎖，也可以理解為開啟它的鑰匙，所以同一個(gè)線程在同一對(duì)象上還沒釋放之前加第二次鎖是不會(huì)出問題的，這個(gè)鎖其實(shí)根本就沒有加，它有了鑰匙，不管加幾把還是可以進(jìn)入鎖保護(hù)的代碼段，暢通無阻，所以叫重進(jìn)入，我們可以簡(jiǎn)單認(rèn)為第二把鎖沒有加上去。
總而言之，Synchronized的本質(zhì)是不讓其他線程在同一對(duì)象上再加一把鎖。
請(qǐng)看下一篇：
【編輯推薦】
