《阿里巴巴Java開發手冊》更名《Java開發手冊》，涵蓋前所未有的三大升級

2019.06.19 《阿里巴巴Java開發手冊》時隔一年，發佈更新1.5.0華山版。同時，將改名爲《Java開發手冊》，涵蓋前所未有的三大升級

• 1）鑑於本手冊是社區開發者集體智慧的結晶，本版本移除阿里巴巴 Java 開發手冊的限定詞「阿里巴巴」。
• 2）新增 21 條新規約。好比，switch 的 NPE 問題、浮點數的比較、無泛型限制、鎖的使用方式、判斷表達式、日期格式等。
• 3）修改描述 112 處。好比，IFNULL 的判斷、集合的 toArray、日誌處理等。
• 4）完善若干處示例。好比，命名示例、衛語句示例、enum 示例、finally 的 return示例等。

新版手冊有哪些值得關注的亮點？

首先是關於新增的21條故障相關的規範，所有源於業界經典事實故障，通過廣大開發者深度討論提煉而成。表面看似簡單，實質是直擊代碼靈魂的考究，惟有內功深厚之人方能看透底層。隨手列舉其中三條，一塊兒來感覺下：

1.Lock 鎖的使用每每稍微不注意，可能致使死鎖的問題。

在使用阻塞等待獲取鎖的方式中，必須在 try 代碼塊以外，而且在加鎖方法與 try 代碼塊之間沒有任何可能拋出異常的方法調用，避免加鎖成功後，在 finally 中沒法解鎖。

若是在 lock 方法與 try 代碼塊之間的方法調用拋出異常，那麼沒法解鎖，形成其它線程沒法成功獲取鎖。若是 lock 方法在 try 代碼塊以內，可能因爲其它方法拋出異常，致使在 finally代碼塊中，unlock 對未加鎖的對象解鎖，它會調用 AQS 的 tryRelease 方法（取決於具體實現類），拋出 IllegalMonitorStateException 異常。在 Lock 對象的 lock方法實現中可能拋出 unchecked 異常。而在使用嘗試機制來獲取鎖的方式中，好比 tryLock()，在進入業務代碼塊以前，必須先判斷當前線程是否持有鎖。

鎖的釋放規則與鎖的阻塞等待方式相同。Lock 對象的 unlock 方法在執行時，它會調用 AQS 的 tryRelease 方法（取決於具體實現類），若是當前線程不持有鎖，則拋出 IllegalMonitorStateException 異常。

2.switch 的 NPE 問題。

當 switch 括號內的變量類型爲 String 而且此變量爲外部參數時，必須先進行 null 判斷。以下的代碼輸出是什麼？

publicclass SwitchString {
         publicstaticvoidmain(String[] args){
             method(null);
         }
 
         publicstaticvoidmethod(String param){
             switch(param){
                 // 確定不是進入這裏
                 case"sth":
                     System.out.println("it's sth");
                     break;
                 // 也不是進入這裏
                 case"null":
                     System.out.println("it's null");
                     break;
                 // 也不是進入這裏
                 default:
                     System.out.println("default");
             }
         }
     }

3.浮點數的比較問題。

1-0.9=0.1是天經地義的，但在計算機的世界裏，0.1偏偏是沒法精確表示的一個小數，只有2的冪次倍小數纔可以精確表示，如：0.五、0.2五、0.125等。因爲0.1是近似表達，在各類情形中的計算存在數位的取捨精度不同，因此1-0.9未必等於0.9-0.8，因此浮點數之間的等值判斷，基本數據類型不能用==來比較，包裝數據類型不能用equals來判斷。

說明：浮點數採用「尾數+階碼」的編碼方式，相似於科學計數法的「有效數字+指數」的表示方式。二進制沒法精確表示大部分的十進制小數，具體原理參考《碼出高效》。示例以下：

float a = 1.0f - 0.9f;
    float b = 0.9f - 0.8f;
 
    if (a == b) {
        // 預期進入此代碼塊，執行其它業務邏輯
        // 可是 a==b 的結果爲false
    }
 
    Float x = Float.valueOf(a);
    Float y = Float.valueOf(b);
    if (x.equals(y)) {
        // 預期進入此代碼塊，執行其它業務邏輯
        // 可是 x.equals(y) 的結果爲false
    }

《Java開發手冊》自始至終不是最完美的，可是有了業界全部開發者的關注與支持，咱們相信它在一步步走向完美。在廣大開發者的建議下，這次「華山版」修正了過往歷史版本的兩個錯誤。

1.集合轉數組時的傳入數組的空間設置。有讀者追蹤這個問題長達半年之久，你們能夠到P3C的ISSUE裏找到關於這段論戰的歷史軌跡。他指出，toArray 的數組長度必須設置爲0。後來咱們發如今高併發狀況下，他的說法是對的。

2.關於 ScheduleService 的刪除。關於這個方法建立線程池，雖然能夠模仿出來它的 OOM 狀況，可是找遍 JDK 沒有任何替代的方式。因此咱們回到它的原點問題上，深刻地思考會不會有人使用 ScheduleService 的方式，不斷地加入隊列中呢？它是一個定時執行的線程池，這種操做方式是否是過於暴力、爲賦新詞強說愁？權衡之下，最後新版手冊去掉這條規約的檢測。

爲了讓更多基礎入門的開發者能更快、準確理解規約背後的思路，這次新版也對部分略顯艱澀的示例作了更生動的解釋。以貼合實際生活場景的視角，幫助讀者理解代碼世界中的邏輯原理。

好比，關於衛語句的說明，原來的例子理解起來是有難度的，修正爲從女孩子相親的視角來看待。在嵌套語句的要求中，若是非得使用 if()…else if()…else…方式表達邏輯，請勿超過3層，超過請使用狀態設計模式。超過3層的 if-else 的邏輯判斷代碼可使用衛語句、策略模式、狀態模式等來實現，其中衛語句示例以下：

public class GuardSatementsDemo{
             public void findBoyfriend(Man man) {
                if(man.isBadTemper()) {
                     System.out.println(「月球有多遠，你就給我滾多遠.」);
                     return;
                 }
 
                 if (man.isShort()) {
                     System.out.println(「我不須要武大郎同樣的男朋友.」);
                     return;
                 }
 
                 if (man.isPoor()) {
                     System.out.println(「貧賤夫妻百事哀.」);
                     return;
                 }
 
                 System.out.println(「能夠先交往一段時間看看.」);
             }
         }

看了這麼多新特性，那必須得花上喝咖啡的時間，學習一下，爲本身寫的程序保駕護航。

最新版的領取方式：微信關注"Java技術乾貨"，回覆"book001"，便可下載。趕快學起來咯~~~