為什么要關注JDK1.8

作者：xcbeyond
瘋狂源自夢想，技術成就輝煌！微信公眾號：《程序猿技術大咖》號主，專注后端開發(fā)多年，擁有豐富的研發(fā)經驗，樂于技術輸出、分享，現階段從事微服務架構項目的研發(fā)工作，涉及架構設計、技術選型、業(yè)務研發(fā)等工作。對于Java、微服務、數據庫、Docker有深入了解，并有大量的調優(yōu)經驗。

自1996年JDK1.0（Java1.0）發(fā)布以來，Java已經受到了學生、程序員、整個軟件行業(yè)人員等一大批活躍用戶的歡迎。這一語言極富活力，不斷被用在大大小小的項目里。從Java1.1（1997年） 一直到Java 7（2011年），Java通過增加新功能，不斷得到良好的升級。Java 8則是在2014年3月發(fā)布的……

版本的不斷更新、升級，無非是對bug的修復、新功能的增加、優(yōu)化等，在JDK版本中，JDK1.8變得備受關注，也成了各大公司面試中常常被問及的話題。

代碼更少、更簡潔
之所以備受關注的最原因是，JDK1.8所做的改變，在許多方面比Java歷史上任何一次改變都深遠。而且好消息是，這些改變會讓你編起程來更容易，用不著再寫類似下面這種啰嗦的程序了。(對peopleList中人的年齡進行排序)

Collections.sort(peopleList, new Comparator<People>() {
    public int compare(People o1, People o2) {
        if (o1.getAge() > o2.getAge()) {
            return 1;
        } else {
            return -1;
        }
    }
});

而在JDK1.8里，你可以編寫如下更為簡潔的代碼：

Collections.sort(peopleList, Comparator.comparingInt(People::getAge));

自從接觸JDK1.8后，這樣類似簡潔的代碼你將會非常喜歡的。

更好的利用多核處理器
JDK1.8對多核處理器有更好的處理:平時我們用的電腦或服務器的CPU都是多核的，但是,絕大多數現有的Java程序都只使用其中一個內核，而其他的都是處于閑置狀態(tài)。

在JDK1.8之前，可能有人會告訴你,必須使用多線程才能使用多個內核。問題是，線程用起來比較難,也容易出現錯誤。從JDK的版本演變來看，它一直致力于讓并發(fā)編程更容易、出錯更少。JDK1.0里有線程和鎖，甚至有一個內存模型——這是當時的最佳做法，但事實證明，不具備專門知識的項目團隊很難可靠地使用這些基本模型。JDK1.5添加了如線程池和并發(fā)集合。JDK1.7添加了分支/合并（fork/join）框架，使得并行變得更實用，但仍然很困難。而JDK1.8中對并行有了一個更簡單的新思路，但需要遵循一些規(guī)則。

JDK1.8提供了一個新的API(稱為“流”,Stream)，它支持許多處理數據的并行操作，其思路和在數據庫查詢語言中的思路類似：用更高級的方式表達想要的東西，而由“實現”（在這里
是Streams庫）來選擇最佳低級執(zhí)行機制。這樣就可以避免用synchronized編寫代碼，這一代碼不僅容易出錯，而且在多核CPU上執(zhí)行所需的成本也比你想象的要高。

速度更快
如果你的開發(fā)環(huán)境裝的就是JDK1.8，那么你就已經在無形中享用JDK1.8的新特性了。

JDK1.8對于底層的數據結構上做了些更新和改動，對垃圾回收機制（內存結構）也做了一定的改變，以及對于并行/并行流，并行的操作能夠很容易的進行使用，對并行做了一些擴展和支持。

我們一起了解一下它是怎么讓底層的數據結構“速度更快”呢？我們都知道底層數據結構最核心的一個就是HashMap，那么它對HashMap做了怎樣的改動呢？

原來的HashMap是怎樣的呢？（數組+鏈表）

1.8之后的HashMap是怎樣的呢？（數組+鏈表+紅黑樹）

當鏈表長度太長（默認超過8）時，鏈表就轉換為紅黑樹。紅黑樹的改進解決了什么問題呢？

HashMap碰撞處理的優(yōu)化，針對超長鏈的檢查，時間復雜度從O(n)降到了O(log2n)。

HashMap的優(yōu)化，只是體現JDK1.8速度更快的典型代表之一，其他優(yōu)化之處在此就不一一說明。

總結
看了上面這幾點，你應該知道為什么要關注JDK1.8的原因了吧。因為它給我們開發(fā)、系統(tǒng)帶來前所未有的好處，在后續(xù)的使用中，你會發(fā)現它的種種優(yōu)點。