Java編程經驗彙總

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程序也算是客戶環境下的一種測試。


深copy和淺copy

你必須瞭解的是 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的結果。



native關鍵字修飾的方法，說明依賴於操做系統的實現。



關於重載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()方法的做用。



關於序列化和反序列化

應該你們都大概知道Java中序列化和反序列化的意思，序列化就是把一個Java對象轉換成二進制進行磁盤上傳輸或者網絡流的傳輸，反序列化的意思就是把這個接受到的二進制流從新組裝成原來的對象逆過程。它們在Java中分別是經過ObjectInputStream和 ObjectOutStream這兩個類來實現的（如下分別用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是正確的行爲，它其實很老實的在作它的事情。爲何你們都忽略了真正出錯誤的地方呢？兩個字，經驗！



關於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的本質是不讓其餘線程在同一對象上再加一把鎖。