以下的這些都算是比較高級(jí)的問(wèn)題了。面試中一般也非常少問(wèn)到。由于它們可能會(huì)把面試者拒之門外。只是你能夠自己找個(gè)時(shí)間來(lái)實(shí)踐一下。

System.exit(0)會(huì)跳過(guò)finally塊的運(yùn)行

System.setSecurityManager(new SecurityManager() {@Overridepublic void checkExit(int status) {throw new ThreadDeath();}});try {System.exit(0);} finally {System.out.println("In the finally block");}

System?.?setSecurityManager?(?new?SecurityManager?(?)?{ @?Override public?void?checkExit?(?int?status?)?{ throw?new?ThreadDeath?(?)?; } }?)?; try?{ System?.?exit?(?0?)?; }?finally?{ System?.?out?.?println?(?"In the finally block"?)?; }

這段代碼為什么會(huì)輸出In the finally block？為什么沒(méi)有打印出堆棧跟蹤信息呢？ 2. String str = “Hello”;當(dāng)中str是一個(gè)字符串對(duì)象 跟C++不同的是，Java里的變量要么是基礎(chǔ)類型，要么是引用。變量不可能是對(duì)象。這意味著像這種表達(dá)式：

String str = "Hello";String text = "Bye";str == text; // 比較兩個(gè)引用。而不是內(nèi)容str = text; // 把text的引用賦值給str

String?str?=?"Hello"?; String?text?=?"Bye"?; str?==?text?;?// 比較兩個(gè)引用，而不是內(nèi)容 str?=?text?;?// 把text的引用賦值給str

大多數(shù)情況下事實(shí)上沒(méi)有太大的差別，只是這么寫easy引起困惑。

final StringBuilder sb = new StringBuidler();sb.append("Hello"); // 這個(gè)引用是final類型的，而不是這個(gè)實(shí)例。

method(sb); // 能夠通過(guò)方法來(lái)改動(dòng)這個(gè)實(shí)例。只是這個(gè)變量是無(wú)法改動(dòng)的

final?StringBuilder?sb?=?new?StringBuidler?(?)?; sb?.?append?(?"Hello"?)?;?// 這個(gè)引用是final類型的。而不是這個(gè)實(shí)例。 method?(?sb?)?;?// 能夠通過(guò)方法來(lái)改動(dòng)這個(gè)實(shí)例，只是這個(gè)變量是無(wú)法改動(dòng)的

• Java的內(nèi)存泄露跟C++程序猿理解的一樣 內(nèi)存泄露在維基百科上的定義是”在計(jì)算機(jī)科學(xué)中，假設(shè)程序沒(méi)有正確地管理好內(nèi)存分配 ，就會(huì)出現(xiàn)內(nèi)存泄露。在面向?qū)ο缶幊讨?#xff0c;假設(shè)內(nèi)存中的一個(gè)對(duì)象無(wú)法在代碼中訪問(wèn)不到的話。這就是內(nèi)存泄露。” 只是在Java中，對(duì)象總是可達(dá)的，那些沒(méi)有強(qiáng)引用的對(duì)象會(huì)被清除掉。

  內(nèi)存泄露這個(gè)術(shù)語(yǔ)在Java中意味著：內(nèi)存中存在著不該存在的對(duì)象，通常來(lái)說(shuō)是有些不再使用的資源卻仍存儲(chǔ)在集合中。

• 多線程編程非常難 假設(shè)你沒(méi)有經(jīng)驗(yàn)的話。多線程編程的確非常難。假設(shè)你僅僅是把一堆代碼扔到一堆線程中去運(yùn)行，那樣出了問(wèn)題根本沒(méi)法解決，僅僅能是一團(tuán)糟。 但假設(shè)你能進(jìn)行線程的按需分配。控制線程間的交互。使用一些團(tuán)隊(duì)中的成員也能明確的簡(jiǎn)單的模式，問(wèn)題就變得簡(jiǎn)單多了。當(dāng)然另一個(gè)挑戰(zhàn)就是你得讓團(tuán)隊(duì)中的全部人都遵循你的這個(gè)規(guī)則:-)
• 不用關(guān)心不同操作間性能的不同 近期聽說(shuō)有個(gè)問(wèn)題，它涉及到了整數(shù)的相加，內(nèi)存訪問(wèn)。取模，以及輸出到控制臺(tái)。

  雖然在這些操作里面，每個(gè)都比前面一個(gè)要慢一個(gè)數(shù)量級(jí)，但這哥們就是想優(yōu)化這里面最快的操作，加法，還用了些更昂貴的操作來(lái)替換它。 假設(shè)你真的想要優(yōu)化性能，你最好用一個(gè)便宜的操作來(lái)替換掉那些昂貴的操作，假設(shè)你的瓶頸在硬件這塊，例如說(shuō)要從硬盤里面讀取大量的文件。改動(dòng)軟件的代碼是沒(méi)啥用了，由于問(wèn)題根本 就不在這。

• 隨機(jī)數(shù)都是隨機(jī)的

一組特定的隨機(jī)數(shù)就像是某種模式的數(shù)字。這個(gè)問(wèn)題我在?這篇文章?中已經(jīng)講到過(guò)了。

非常多人都不相信隨機(jī)數(shù)生成器生成的數(shù)字事實(shí)上是不隨機(jī)的。

• 應(yīng)該盡量避免使用浮點(diǎn)數(shù)，由于它們會(huì)產(chǎn)生隨機(jī)錯(cuò)誤

對(duì)于同一個(gè)操作而言。浮點(diǎn)數(shù)每次都會(huì)產(chǎn)生相同的錯(cuò)誤。錯(cuò)誤是可預(yù)測(cè)的，因此也是可控的。假設(shè)你清楚你要做的事情是什么，并且堅(jiān)持使用一些簡(jiǎn)單的規(guī)則，比方說(shuō)對(duì)結(jié)果進(jìn)行舍入操作。那么浮點(diǎn)數(shù)出的錯(cuò)也不會(huì)比BigDecimal要多。除此之外它的可讀性更強(qiáng)，并且效率快了百倍以上（同一時(shí)候產(chǎn)生的垃圾對(duì)象也更少了）。

• 時(shí)區(qū)是永恒不變的

之所以會(huì)有這個(gè)誤解是由于，隨著時(shí)間的變化，時(shí)區(qū)是在改變的。這意味著歐洲/倫敦在新紀(jì)元的時(shí)候是1970/1/1 01:00而不是00:00，為什么？由于倫敦在1968年到1971年這兩年間的時(shí)間內(nèi)使用的是夏令時(shí)。

在過(guò)去的這些年里面，還有不少時(shí)區(qū)也發(fā)生了變化。莫斯科曾經(jīng)是東三區(qū)（GMT+3），如今是東四區(qū)（GMT+4）（從2011年3月27日開始）。

假設(shè)你看下2010年的時(shí)間，你會(huì)發(fā)現(xiàn)它是東三區(qū)而不是東四區(qū)。

還有些事你聽起來(lái)也許會(huì)感覺非常意外：

• 1721年的瑞典的2月有30天。
• 1751年英格蘭的第一天是3月25日，和法國(guó)相比差了11天。

• 美國(guó)採(cǎi)用公歷紀(jì)年后。它往前追溯了上百年，這樣原先記錄的那些日期都能夠用兩種日歷來(lái)進(jìn)行表示（通常為了更精確會(huì)同一時(shí)候提供兩個(gè)日期）。

  比方喬治華盛頓的生日從1731年2月11變成了1732年2月22。

• 當(dāng)你在線程中讀取一個(gè)非volatile變量時(shí)，你終于能讀取它更新的那個(gè)值。

前幾天這個(gè)問(wèn)題在StackOverflow上出現(xiàn)過(guò)兩回了。一般來(lái)說(shuō)，JIT編譯器優(yōu)化代碼的時(shí)候會(huì)將這個(gè)線程沒(méi)有改動(dòng)到的非volatile類型的字段進(jìn)行內(nèi)聯(lián)。

一旦這個(gè)代碼被編譯了（你能夠通過(guò)-XX:+PrintCompilation看到），你在還有一個(gè)線程對(duì)這個(gè)字段進(jìn)行的改動(dòng)它非常可能就永遠(yuǎn)也看不到了。

加上隨機(jī)的同步塊或者打印語(yǔ)句能夠推遲這個(gè)優(yōu)化的運(yùn)行，或者擾亂JIT編譯器。讓它不去運(yùn)行這個(gè)優(yōu)化。

• Java面試題都是正確的

有非常多Java面試題要么是過(guò)時(shí)了（超過(guò)10年沒(méi)有更新了，和如今的Java版本號(hào)已經(jīng)脫節(jié)），要么是誤導(dǎo)大家的，甚至可能是錯(cuò)的。不幸的是這些答案都沒(méi)有檢查過(guò)就被到處傳來(lái)傳去。

我會(huì)參考Stackoverflow上面的答案，由于這里的答案同行審查做的更好些。總的來(lái)說(shuō)，像rose india這種站點(diǎn)就不要上了。上面的答案的質(zhì)量差的離譜。假設(shè)你喜歡刨根究底的話，能夠看看上面一篇文章里有多少拼寫錯(cuò)誤（類名以及專業(yè)術(shù)語(yǔ)）或者錯(cuò)誤的言論。存在這些問(wèn)題的一個(gè)原因在于沒(méi)有一個(gè)有效的反饋機(jī)制來(lái)糾正這些錯(cuò)誤。

文章來(lái)自：?http://it.deepinmind.com/java/2014/05/10/common-java-myths.html

轉(zhuǎn)載于:https://www.cnblogs.com/clnchanpin/p/7008060.html

總結(jié)

以上是生活随笔為你收集整理的关于Java的10个谎言的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。