日韩无码专区无码一级三级片|91人人爱网站中日韩无码电影|厨房大战丰满熟妇|AV高清无码在线免费观看|另类AV日韩少妇熟女|中文日本大黄一级黄色片|色情在线视频免费|亚洲成人特黄a片|黄片wwwav色图欧美|欧亚乱色一区二区三区

統(tǒng)計(jì)數(shù)據(jù)來自Java“死亡”競(jìng)賽——一個(gè)針對(duì)開發(fā)者的迷你測(cè)驗(yàn)

幾個(gè)月前，我們?cè)谝粋€(gè)小型網(wǎng)站上發(fā)布了一個(gè)稱為Java“死亡競(jìng)賽”的新項(xiàng)目。測(cè)驗(yàn)發(fā)布后，超過20000位開發(fā)者參加了測(cè)驗(yàn)。網(wǎng)站以20道關(guān)于Java的多選題為主。我們得到了眾多開發(fā)者的測(cè)驗(yàn)統(tǒng)計(jì)數(shù)據(jù)，今天，我們非常樂意將其中的一些數(shù)據(jù)和答案與你們分享。

我們從20個(gè)題目中得到了61872個(gè)答案，大約每個(gè)題目有3094個(gè)答案。每個(gè)Java“死亡”測(cè)驗(yàn)都會(huì)隨機(jī)地從20個(gè)題目中抽取5個(gè)題目，然后每個(gè)題目有90 秒的時(shí)間作答。每個(gè)問題有四個(gè)可能的選項(xiàng)。經(jīng)常有人向我們抱怨說這些題目太難了。所以，我們的測(cè)驗(yàn)被稱為Java“死亡”競(jìng)賽并不是沒有理由的哦！從測(cè)驗(yàn) 結(jié)果的統(tǒng)計(jì)數(shù)據(jù)中，我們能知道哪些問題是最難的，哪些是最簡(jiǎn)單的。在這篇博客中，我想與你們分享5個(gè)從我們的測(cè)驗(yàn)中挑選出的最難的問題，然后一起解決它 們。

平均來看，開發(fā)者給出的答案中大約41%是正確的，這個(gè)結(jié)果可一點(diǎn)不差。每個(gè)問題的索引和它的作答統(tǒng)計(jì)結(jié)果可以從這里得到。這篇博客所用的統(tǒng)計(jì)數(shù)據(jù)是在7月26日得到的。從這里可以嘗試我們的Java“死亡”競(jìng)賽測(cè)驗(yàn)。

1、Java“死亡競(jìng)賽”中最難的問題

讓我們從最難啃的骨頭開始吧。這個(gè)問題由來自羅馬尼亞首都布加勒斯特的 Alexandru-Constantin Bledea提供。這個(gè)問題確實(shí)是一個(gè)腦筋急轉(zhuǎn)彎，只有約20%的參與者答對(duì)這道題，這意味著瞎選都能提高你回答正確的概率。這道題是關(guān)于Java泛型的。

題目大意：

這段代碼錯(cuò)在哪兒？

a.編譯錯(cuò)誤，因?yàn)闆]有SQLException被拋出

b.拋出ClassCastException，因?yàn)镾QLException并不是RuntimeException的一個(gè)實(shí)例

c.沒有錯(cuò)誤，程序打印出拋出的SQLException堆棧跟蹤信息

d.編譯錯(cuò)誤，因?yàn)槲覀儾荒軐QLException類型轉(zhuǎn)換成RuntimeException

好，我們能從題目中得到什么信息？題目中的泛型涉及到了類型擦除，以及一些異常。這里需要回憶一些知識(shí)：

RuntimeException和SQLException都繼承自Exception，但是在這個(gè)代碼中RuntimeException是未檢查的異常，而SQLException是受檢異常。

2.Java的泛型并不是具體化的。這意味著在編譯時(shí)，泛型的類型信息會(huì)“丟失”，并且泛型參數(shù)像是被它的限定類型替換了一樣，或者當(dāng)限定類型不存在時(shí)，泛型參數(shù)被替換成了Object。這就是大家所說的類型“擦除”。

我們天真地希望第七行能產(chǎn)生一個(gè)編譯錯(cuò)誤，因?yàn)槲覀儾荒軐QLException轉(zhuǎn)換成RuntimeException，但是這并不會(huì)發(fā)生。發(fā)生的是將T替換成了Exception，所以我們有：

throw (Exception) t; // t is also an Exception

pleaseThrow方法期望一個(gè)Exception，并且T被替換成了Exception，因此類型轉(zhuǎn)換被擦除了，就像沒寫這個(gè)代碼一樣。這一點(diǎn)我們可從下面的字節(jié)碼中得到佐證：

private pleaseThrow(Ljava/lang/Exception;)V throws java/lang/Exception

L0

LINENUMBER 8 L0

ALOAD 1

ATHROW

L1

LOCALVARIABLE this LTemp; L0 L1 0

// signature LTemp;

// declaration: Temp

LOCALVARIABLE t Ljava/lang/Exception; L0 L1 1

MAXSTACK = 1

MAXLOCALS = 2

我們?cè)倏匆幌?，如果代碼中沒有涉及泛型，那么編譯產(chǎn)生的字節(jié)碼是什么樣的，我們看到，在ATHROW前會(huì)有如下的代碼：

CHECKCAST java/lang/RuntimeException

現(xiàn)在，我們可以確信，代碼中并沒有涉及到類型轉(zhuǎn)換，因此我們可以排除下面這兩個(gè)選項(xiàng)：

“編譯錯(cuò)誤，因?yàn)槲覀儾荒軐QLException類型轉(zhuǎn)換為RuntimeException”

“拋出ClassCastException，因?yàn)镾QLException不是RuntimeException的一個(gè)實(shí)例”

因此畢竟我們拋出了SQLException，然后你希望它能被catch代碼塊捕獲，然后打印它的堆棧跟蹤信息。然而，事與愿違。

這個(gè)代碼具有欺騙性，它使得編譯器和我們一樣變得困惑。這段代碼讓編譯器認(rèn)為catch代碼塊是不能到達(dá)的。對(duì)于不知情的旁觀者來說，代碼中并沒有 SQLException。所以，正確答案是：編譯失敗，因?yàn)榫幾g器認(rèn)為SQLException不會(huì)從try代碼塊中拋出－但是實(shí)際上它確實(shí)能拋出！

再次感謝Alexandru與我們分享這個(gè)問題！我們可以用另一個(gè)很酷的方式來查看代碼中的錯(cuò)誤以及SQLException實(shí)際上是怎樣拋出的，這個(gè)方法是：修改catch代碼塊，把它修改為接收一個(gè)RuntimeException。這樣你就可以看到SQLException的堆棧信息了。（實(shí)際上SQLException也并沒有被catch代碼段捕獲，而是被虛擬機(jī)捕獲并打印出異常棧的信息。）

2、問題的關(guān)鍵在于，是否使用了toString()

這道題只有24%的正確率，它的困難程度是這20道題中的亞軍。

題目大意：這個(gè)程序的打印結(jié)果是？

a.m1 & new name

b.以上都是錯(cuò)誤的

c.m1&m1

d.new name & new name

這道題實(shí)際上簡(jiǎn)單得多，我們只要看到第十二行，它直接打印了m1和m2，而不是m1.name和m2.name。這段代碼狡猾的地方在于，當(dāng)我們要 打印一個(gè)對(duì)象時(shí)，Java使用的是toString方法?！皀ame”屬性是我們自己加入的，如果你忘記這點(diǎn)，其他地方都判斷正確的話，你可能會(huì)錯(cuò)誤地選 擇m1&new name這個(gè)答案。

這行代碼將兩個(gè)對(duì)象的name屬性都賦值為”m1”。

m1.name = m2.name = “m1";

然后callMe方法將m2對(duì)象的name屬性設(shè)置成”new name”，然后代碼就結(jié)束了。

但是，這個(gè)代碼片段實(shí)際上將會(huì)打印出如下信息，包括類名稱以及它們的哈希碼：

MyClass@3d0bc85 & MyClass@7d08c1b7

所以正確的答案是“None of the above”

3、Google Guava類庫(kù)中的Sets

題目大意：

這道題目不妥的地方在哪？

a.不能編譯

b.沒有問題

c.可能造成內(nèi)存溢出

d.可能造成***循環(huán)

這個(gè)問題實(shí)際上并不特別需要關(guān)于Guava sets類庫(kù)的專業(yè)知識(shí)，但卻使絕大多數(shù)的開發(fā)者產(chǎn)生困惑。只有25%的參與者給出了正確的答案，和瞎選的正確率是一樣的。

那么我們能從這段代碼中看出什么呢？我們有一個(gè)方法，它返回一個(gè)集合，這個(gè)集合包含了某個(gè)人的好友圈。方法中有一個(gè)循環(huán)，它檢查一個(gè)person對(duì) 象的bestfriend屬性是否為null。如果不為null，則將bestfriend添加到results集合里。如果一個(gè)person對(duì)象確實(shí)有 一個(gè)bestfriend，那么對(duì)這個(gè)person的bestfriend，重復(fù)執(zhí)行上述過程，所以我們就可以一直向bestfriend集合添加 person對(duì)象，直到有一個(gè)person，它沒有bestfriend，或者它的bestfriend已經(jīng)在我們的result集合里了。***這部分有 一點(diǎn)微妙，我們不能向這個(gè)Set集合添加重復(fù)的元素，即person對(duì)象，所以這個(gè)方法并不會(huì)導(dǎo)致***循環(huán)。

真正的問題在于，這段代碼很有可能造成內(nèi)存用盡的異常（out of memory exception）。這個(gè)循環(huán)實(shí)際上是沒有邊界的，所以我們可以不停地往set中添加person對(duì)象，直到內(nèi)存用盡。

順便提一下，如果你想詳細(xì)了解Google Guava,可以看看我們寫的這篇博客： the lesser known yet useful features about it

4、利用兩個(gè)花括號(hào)進(jìn)行初始化

題目大意：這段代碼錯(cuò)誤的地方在哪？

a.沒有錯(cuò)誤

b.可能獲得null值

c.代碼不能編譯

d.打印出不正確的結(jié)果

這個(gè)問題是代碼最少的問題之一，但是足以迷惑絕大部分的開發(fā)者。這道題只有26%的答題者回答正確。

很少有開發(fā)者知道這個(gè)初始化常量集合的簡(jiǎn)便語(yǔ)法，雖然這個(gè)語(yǔ)法會(huì)帶來一些副作用。但事實(shí)上，這個(gè)語(yǔ)法鮮為人知未免不是一件好事。在感嘆之后，你看 到，我們往list里添加了一個(gè)元素，然后打印這個(gè)list。正常情況下，你期望看到打印的結(jié)果是[John]，但是利用兩個(gè)花括號(hào)進(jìn)行初始化是有另一套 初始化過程的。這里，我們用了一個(gè)匿名類來初始化一個(gè)List，當(dāng)要打印NAMES時(shí)，實(shí)際上打印出來的是null，這是因?yàn)槌跏蓟绦蛏形赐瓿?，此時(shí)的 list是空的。

關(guān)于使用兩個(gè)花括號(hào)進(jìn)行容器的初始化，可參考這里（right here）。

5、對(duì)于運(yùn)行時(shí)Map容器的離奇事件

這是另一個(gè)社區(qū)貢獻(xiàn)的問題，貢獻(xiàn)者是來自以色列的Barak Yaish。只有27%的答題者能解答這個(gè)問題。

題目大意：這段代碼的輸出是什么

a.不能編譯

b.類型轉(zhuǎn)換異常

c.[] true

d.[“bar”, “ber”]

好吧，來看看代碼。compute方法通過key在map中查找一個(gè)value。如果這個(gè)value是null，則插入(key, value)，并返回value。因?yàn)殚_始時(shí)，這個(gè)list是空的，“foo”值并不存在，v是null。然后，我們向map中插入一個(gè)“foo”并且 “foo”指向new ArrayList