您好,登錄后才能下訂單哦!
這篇文章將為大家詳細(xì)講解有關(guān)Java 8 的頭疼問題都有哪些,文章內(nèi)容質(zhì)量較高,因此小編分享給大家做個參考,希望大家閱讀完這篇文章后對相關(guān)知識有一定的了解。
1. 并行Streams實(shí)際上可能會降低你的性能
Java8帶來了最讓人期待的新特性之–并行。parallelStream() 方法在集合和流上實(shí)現(xiàn)了并行。它將它們分解成子問題,然后分配給不同的線程進(jìn)行處理,這些任務(wù)可以分給不同的CPU核心處理,完成后再合并到一起。實(shí)現(xiàn)原理主要是使用了fork/join框架。好吧,聽起來很酷對吧!那一定可以在多核環(huán)境下使得操作大數(shù)據(jù)集合速度加快咯,對嗎?
不,如果使用不正確的話實(shí)際上會使得你的代碼運(yùn)行的更慢。我們進(jìn)行了一些基準(zhǔn)測試,發(fā)現(xiàn)要慢15%,甚至可能更糟糕。假設(shè)我們已經(jīng)運(yùn)行了多個線程,然后使用.parallelStream() 來增加更多的線程到線程池中,這很容易就超過多核心CPU處理的上限,從而增加了上下文切換次數(shù),使得整體都變慢了。
基準(zhǔn)測試將一個集合分成不同的組(主要/非主要的):
Map<Boolean, List<Integer>> groupByPrimary = numbers .parallelStream().collect(Collectors.groupingBy(s -> Utility.isPrime(s)));
使得性能降低也有可能是其他的原因。假如我們分成多個任務(wù)來處理,其中一個任務(wù)可能因?yàn)槟承┰蚴沟锰幚頃r(shí)間比其他的任務(wù)長很多。.parallelStream() 將任務(wù)分解處理,可能要比作為一個完整的任務(wù)處理要慢。來看看這篇文章, Lukas Krecan給出的一些例子和代碼 。
提醒:并行帶來了很多好處,但是同樣也會有一些其他的問題需要考慮到。當(dāng)你已經(jīng)在多線程環(huán)境中運(yùn)行了,記住這點(diǎn),自己要熟悉背后的運(yùn)行機(jī)制。
2. Lambda 表達(dá)式的缺點(diǎn)
lambda表達(dá)式。哦,lambda表達(dá)式。沒有l(wèi)ambda表達(dá)式我們也能做到幾乎一切事情,但是lambda是那么的優(yōu)雅,擺脫了煩人的代碼,所以很容易就愛上lambda。比如說早上起來我想遍歷世界杯的球員名單并且知道具體的人數(shù)(有趣的事實(shí):加起來有254個)。
List lengths = new ArrayList(); for (String countries : Arrays.asList(args)) { lengths.add(check(country)); }
現(xiàn)在我們用一個漂亮的lambda表達(dá)式來實(shí)現(xiàn)同樣的功能:
Stream lengths = countries.stream().map(countries -< check(country));
哇塞!這真是超級厲害。增加一些像lambda表達(dá)式這樣的新元素到Java當(dāng)中,盡管看起來更像是一件好事,但是實(shí)際上卻是偏離了Java原本的規(guī)范。字節(jié)碼是完全面向?qū)ο蟮?,伴隨著lambda的加入 ,這使得實(shí)際的代碼與運(yùn)行時(shí)的字節(jié)碼結(jié)構(gòu)上差異變大。閱讀更多關(guān)于lambda表達(dá)式的負(fù)面影響可以看Tal Weiss這篇文章。
從更深層次來看,你寫什么代碼和調(diào)試什么代碼是兩碼事。堆棧跟蹤越來越大,使得難以調(diào)試代碼。一些很簡單的事情譬如添加一個空字符串到list中,本來是這樣一個很短的堆棧跟
at LmbdaMain.check(LmbdaMain.java:19) at LmbdaMain.main(LmbdaMain.java:34)
變成這樣:
at LmbdaMain.check(LmbdaMain.java:19) at LmbdaMain.lambda$0(LmbdaMain.java:37) at LmbdaMain$$Lambda$1/821270929.apply(Unknown Source) at java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193) at java.util.Spliterators$ArraySpliterator.forEachRemaining(Spliterators.java:948) at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:512) at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:502) at java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708) at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) at java.util.stream.LongPipeline.reduce(LongPipeline.java:438) at java.util.stream.LongPipeline.sum(LongPipeline.java:396) at java.util.stream.ReferencePipeline.count(ReferencePipeline.java:526) at LmbdaMain.main(LmbdaMain.java:39
lambda表達(dá)式帶來的另一個問題是關(guān)于重載:使用他們調(diào)用一個方法時(shí)會有一些傳參,這些參數(shù)可能是多種類型的,這樣會使得在某些情況下導(dǎo)致一些引起歧義的調(diào)用。Lukas Eder 用示例代碼進(jìn)行了說明。
提醒:要意識到這一點(diǎn),跟蹤有時(shí)候可能會很痛苦,但是這不足以讓我們遠(yuǎn)離寶貴的lambda表達(dá)式。
3. Default方法令人分心
Default方法允許一個功能接口中有一個默認(rèn)實(shí)現(xiàn),這無疑是Java8新特性中最酷的一個,但是它與我們之前使用的方式有些沖突。那么既然如此,為什么要引入default方法呢?如果不引入呢?
Defalut方法背后的主要動機(jī)是,如果我們要給現(xiàn)有的接口增加一個方法,我們可以不用重寫實(shí)現(xiàn)來達(dá)到這個目的,并且使它與舊版本兼容。例如,拿這段來自O(shè)racle Java教程中添加指定一個時(shí)區(qū)功能的代碼來說:
public interface TimeClient { // ... static public ZoneId getZoneId (String zoneString) { try { return ZoneId.of(zoneString); } catch (DateTimeException e) { System.err.println("Invalid time zone: " + zoneString + "; using default time zone instead."); return ZoneId.systemDefault(); } } default public ZonedDateTime getZonedDateTime(String zoneString) { return ZonedDateTime.of(getLocalDateTime(), getZoneId(zoneString)); } }
就是這樣,問題迎刃而解了。是這樣么?Default方法將接口和實(shí)現(xiàn)分離混合了。似乎我們不用再糾結(jié)他們本身的分層結(jié)構(gòu)了,現(xiàn)在我們需要解決新的問題了。想要了解更多,閱讀Oleg Shelajev在RebelLabs上發(fā)表的文章吧。
提醒:當(dāng)你手上有一把錘子的時(shí)候,看什么都像是釘子。記住它們原本的用法,保持原來的接口而重構(gòu)引入新的抽象類是沒有意義的。
4. 該如何拯救你,Jagsaw?
Jigsaw項(xiàng)目的目標(biāo)是使Java模塊化,將JRE分拆成可以相互操作的組件。這背后最主要的動機(jī)是渴望有一個更好、更快、更強(qiáng)大的Java嵌入式。我試圖避免提及“物聯(lián)網(wǎng)”,但我還是說了。減少JAR的體積,改進(jìn)性能,增強(qiáng)安全性等等是這個雄心勃勃的項(xiàng)目所承諾的。
但是,它在哪呢?Oracle的***Java架構(gòu)師, Mark Reinhold說: Jigsaw,通過了探索階段 ,最近才進(jìn)入第二階段,現(xiàn)在開始進(jìn)行產(chǎn)品的設(shè)計(jì)與實(shí)現(xiàn)。該項(xiàng)目原本計(jì)劃在Java8完成。現(xiàn)在推遲到Java9,有可能成為其最主要的新特性。
提醒:如果這正是你在等待的, Java9應(yīng)該在2016年間發(fā)布。同時(shí),想要密切關(guān)注甚至參與其中的話,你可以加入到這個郵件列表。
5. 那些仍然存在的問題
受檢異常
沒有人喜歡繁瑣的代碼,那也是為什么lambdas表達(dá)式那么受歡迎的的原因。想想討厭的異常,無論你是否需要在邏輯上catch或者要處理受檢異常,你都需要catch它們。即使有些永遠(yuǎn)也不會發(fā)生,像下面這個異常就是永遠(yuǎn)也不會發(fā)生的:
try { httpConn.setRequestMethod("GET"); } catch (ProtocolException pe) { /* Why don’t you call me anymore? */ }
原始類型
它們依然還在,想要正確使用它們是一件很痛苦的事情。原始類型導(dǎo)致Java沒能夠成為一種純面向?qū)ο笳Z言,而移除它們對性能也沒有顯著的影響。順便提一句,新的JVM語言都沒有包含原始類型。
運(yùn)算符重載
James Gosling,Java之父,曾經(jīng)在接受采訪時(shí)說:“我拋棄運(yùn)算符重載是因?yàn)槲覀€人主觀的原因,因?yàn)樵贑++中我見過太多的人在濫用它?!庇械览?,但是很多人持不同的觀點(diǎn)。其他的JVM語言也提供這一功能,但是另一方面,它導(dǎo)致有些代碼像下面這樣:
javascriptEntryPoints <<= (sourceDirectory in Compile)(base => ((base / "assets" ** "*.js") --- (base / "assets" ** "_*")).get )
事實(shí)上這行代碼來自Scala Play框架,我現(xiàn)在都有點(diǎn)暈了。
提醒:這些是真正的問題么?我們都有自己的怪癖,而這些就是Java的怪癖。在未來的版本中可能有會發(fā)生一些意外,它將會改變,但向后兼容性等等使得它們現(xiàn)在還在使用。
6. 函數(shù)式編程–為時(shí)尚早
函數(shù)式編程出現(xiàn)在java之前,但是它相當(dāng)?shù)膶擂?。Java8在這方面有所改善例如lambdas等等。這是讓人受歡迎的,但卻不如早期所描繪的那樣變化巨大。肯定比Java7更優(yōu)雅,但是仍需要努力增加一些真正需要的功能。
其中一個在這個問題上最激烈的評論來自Pierre-yves Saumont,他寫了一系列的文章詳細(xì)的講述了函數(shù)式編程規(guī)范和其在Java中實(shí)現(xiàn)的差異。
所以,選擇Java還是Scala呢?Java采用現(xiàn)代函數(shù)范式是對使用多年Lambda的Scala的一種肯定。Lambdas讓我們覺得很迷惑,但是也有許多像traits,lazy evaluation和immutables等一些特性,使得它們相當(dāng)?shù)牟煌?/p>
提醒:不要為lambdas分心,在Java8中使用函數(shù)式編程仍然是比較麻煩的。
關(guān)于Java 8 的頭疼問題都有哪些就分享到這里了,希望以上內(nèi)容可以對大家有一定的幫助,可以學(xué)到更多知識。如果覺得文章不錯,可以把它分享出去讓更多的人看到。
免責(zé)聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點(diǎn)不代表本網(wǎng)站立場,如果涉及侵權(quán)請聯(lián)系站長郵箱:is@yisu.com進(jìn)行舉報(bào),并提供相關(guān)證據(jù),一經(jīng)查實(shí),將立刻刪除涉嫌侵權(quán)內(nèi)容。