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