你以前聽到的談?wù)撽P(guān)于Java8的所有都是圍繞lambda表達(dá)式. 但它僅僅是Java8的一部分. Java 8 有許多新特性—一些強(qiáng)大的新類和語(yǔ)法, 還有其他的從一開始就應(yīng)該具有的東西.

我將要介紹我認(rèn)為值得了解的10個(gè)精華特性. 它們中最少也會(huì)有一個(gè)或兩個(gè)你想要試一試, 所以我們開始吧！

1. 默認(rèn)方法

Java語(yǔ)言一個(gè)新添加的特性是你可以為接口(interface)的方法添加方法體(稱為默認(rèn)方法). 這些方法會(huì)被隱式地添加到實(shí)現(xiàn)這個(gè)接口的類中.

這能使你在不破壞代碼的情況下為已存在的庫(kù)添加新功能. 這很明顯是個(gè)提升. 但另一方面這會(huì)混淆接口與類之間的界限, 因?yàn)榻涌谟糜诙x契約, 而類用于定義具體實(shí)現(xiàn). 從好的方面來說, 它會(huì)以一種優(yōu)雅的方式使接口更智能, 并且避免了重復(fù)和擴(kuò)展庫(kù). 但壞的方面, 我們稍后就會(huì)看到, 接口方法要查詢this并將它轉(zhuǎn)換成具體類. Shivers….

2. 進(jìn)程終止

啟動(dòng)一個(gè)外部進(jìn)程是你所做的事情中的一半－當(dāng)這個(gè)進(jìn)程崩潰, 掛起或消耗100% CPU時(shí)你要返回來對(duì)它進(jìn)行調(diào)試. 現(xiàn)在Process類裝備了兩個(gè)新方法來幫助你控制不守規(guī)矩的進(jìn)程.

第一個(gè)是 isAlive(), 它會(huì)讓你不需要等待進(jìn)程運(yùn)行完畢就可以檢查這個(gè)進(jìn)程是否仍在運(yùn)行. 第二個(gè)更強(qiáng)大的方法是destroyForcibly() , 它能讓你強(qiáng)制殺死超時(shí)或不再需要的進(jìn)程.

3. StampedLocks

現(xiàn)在有一些令人激動(dòng)的東西了. 沒有人喜歡同步代碼. 它是降低你的應(yīng)用的吞吐量的罪魁禍?zhǔn)?特別是可擴(kuò)展的應(yīng)用), 或者更嚴(yán)重–導(dǎo)致應(yīng)用掛掉. 盡管如此,在某些時(shí)候你別無(wú)選擇.

有很多方法來限制多線程同步訪問臨界資源.  其中最著名的是讀寫鎖(ReadWriteLock)和與它相關(guān)的實(shí)現(xiàn). 它通過允許多線程訪問同一資源但阻塞操作資源的線程來減少資源爭(zhēng)奪. 這聽起來在理論上很不錯(cuò), 但實(shí)際上這個(gè)鎖是相當(dāng)慢的, 特別是當(dāng)有大量寫線程時(shí).

注: 讀寫鎖中將資源訪問者分為兩類:讀者和寫者, 讀者對(duì)資源進(jìn)行只讀操作, 寫者可操作資源.

Java 8 引入了一種全新的稱為StampedLock的讀寫鎖. 這個(gè)鎖不僅速度更快, 它更為樂觀鎖提供了一組強(qiáng)大的API, 通過它你可以以最小的代價(jià)取得一個(gè)讀者鎖, 甚至在選擇期間不希望發(fā)生寫操作.  在選擇結(jié)束后你可以通過查詢這個(gè)鎖來查看在選擇期間是否有寫操作, 在這種情況下你可以選擇是否重試, 更新鎖還是放棄.

這個(gè)鎖是個(gè)很強(qiáng)大的工具, 它需要一篇專門的文章來描述. 我對(duì)這個(gè)新玩意兒興奮得頭都暈了–做得好!

更多詳情請(qǐng)參閱這里

4. Concurrent Adders

對(duì)從事多線程應(yīng)用的人來說這是另一件小寶貝. 這是一個(gè)用于多線程計(jì)數(shù)器的簡(jiǎn)單高效的新API, 它比使用AtomicInteger更快. 真他媽酷!

5. Optional Values

哦, 空指針, 所有Java開發(fā)者的噩夢(mèng). 從一開始(或最少在1965)它可能就是最流行的異常了.

借鑒自Scale和Hashell, Java 8 擁有一個(gè)新的稱為Optional的模板, 用于封裝可能為null的引用. 它絕不是終結(jié)null的銀彈, 它更是一種方式－讓API設(shè)計(jì)者從代碼級(jí)別(而不是文檔級(jí)別)表明一個(gè)null值可能會(huì)傳入一個(gè)方法或從一個(gè)方法中返回, 以讓調(diào)用者為null值做好準(zhǔn)備. 因此, 這只能在新API下工作, 并且假設(shè)調(diào)用者不會(huì)讓引用逃脫這個(gè)封裝從而導(dǎo)致不安全的解引用.

我不得不說我對(duì)這個(gè)特性很矛盾. 一方面null有很大問題, 所以我傾向于在null發(fā)生前做好所有事. 但另一方面我很懷疑它能否成功.這是因?yàn)槭褂肙ptional需要全公司不斷的努力，但它并沒有直接的價(jià)值。除非雷厲風(fēng)行，否則它很可能會(huì)被放棄.

更多關(guān)于Optional請(qǐng)點(diǎn)擊這里

6. 注解任何東西

另外一個(gè)Java語(yǔ)言小改進(jìn)是 annotations 現(xiàn)在能夠添加在你代碼的 幾乎所有東西 上。以前， annotations 只能加在像類或者方法聲明上。使用 Java 8 的 annotations 可以加在變量和參數(shù)聲明中，不僅在傳遞一個(gè)值給指定類型時(shí)，甚至是分配空間給一個(gè)新的對(duì)象的時(shí)候。這是通過靜態(tài)分析和向?qū)Чぞ?(比如 FindBugs) 讓Java 語(yǔ)言更友好，集中精力 (沿著 Java 文檔工具和 API 改進(jìn)) 的一部分 。這是個(gè)很棒的特性，但是更多的是像Java 7 引入的 invokeDynamic ，其真正的價(jià)值決定在于 社區(qū)用它來做什么。

7. 溢出操作

現(xiàn)在這里有了一系列從一開始就應(yīng)該包含在核心庫(kù)中的方法. 我最喜歡的一個(gè)習(xí)慣是調(diào)試當(dāng)int超過2^32時(shí)的溢出, 然后繼續(xù)隨機(jī)地創(chuàng)建這個(gè)臭名昭著的bug(例如 “我是怎么得到這個(gè)奇怪的值的?”).

這次也沒有銀彈, 但卻有一系列操作數(shù)字的函數(shù), 這些函數(shù)當(dāng)以一種比隱式引起溢出的標(biāo)準(zhǔn)的+/*操作符更不能容忍的方式發(fā)生溢出時(shí)就會(huì)拋出異常.. 如果是我的話,我會(huì)將它設(shè)為JVM的默認(rèn)模式, 使用允許算數(shù)溢出的顯式函數(shù)(而不是+ *運(yùn)算符).

8. 文件夾遍歷

迭代目錄樹的內(nèi)容在google搜索上很早就出現(xiàn)了(在這種情況下你可能會(huì)使用Apache.FileUtils). Java 8

為Files添加了10個(gè)新方法. 我最喜歡的是walk() ,它創(chuàng)建了一個(gè)懶惰流(對(duì)于大型文件系統(tǒng)很重要)來迭代

目錄結(jié)構(gòu)的內(nèi)容.

9. 強(qiáng)隨機(jī)數(shù)生成

現(xiàn)今關(guān)于密碼和密鑰的脆弱性的談話短不了. 程序安全是個(gè)棘手的問題而且很容易犯錯(cuò)誤. 這也是我喜歡

在JVM中能夠自動(dòng)挑選最強(qiáng)隨機(jī)數(shù)生成器的新SecureRandom.getinstanceStrong()方法的原因. 它降低

了取得生成器失敗, 或默認(rèn)取得一個(gè)弱生成器從而導(dǎo)致密鑰或加密值容易被破解的機(jī)率.

10. Date.toInstant()

Java 8 引入一個(gè)全新的  date time API。 因?yàn)橐延械腶pi并不好，這是相當(dāng)可以理解的?，F(xiàn)在 Joda 已經(jīng)專注和深入 Java 的 date time API 好多年。但是，就算用新的API仍有個(gè)大問題存在—— 有數(shù)以噸計(jì)的代碼和庫(kù)在使用舊的API。

我們都知道面臨這個(gè)問題，那么要做些什么?

因?yàn)?Java 8 已經(jīng)做得相當(dāng)優(yōu)雅，在Date類中添加了一個(gè)新的方法toInstant() ， 用來將其轉(zhuǎn)化成為新的API。就算使用舊的Date API (在可預(yù)見的未來也是一樣) , 也能讓你快速升級(jí)到新的API。

如果你覺得文章還有什么該有的特性沒提到，抑或是不同意我們的分析？請(qǐng)?jiān)u論給我們——這就是發(fā)文的目的 ！

以上就是對(duì)Java 8新特性的資料整理，后續(xù)繼續(xù)補(bǔ)充相關(guān)資料謝謝大家對(duì)本站的支持！

最新評(píng)論