下面的這些都算是比較高級的問題了，面試中一般也很少問到，因?yàn)樗鼈兛赡軙衙嬖囌呔苤T外。不過你可以自己找個(gè)時(shí)間來實(shí)踐一下。 

1. System.exit(0)會跳過finally塊的執(zhí)行

 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");
 } 

這段代碼為什么會輸出In the finally block？為什么沒有打印出堆棧跟蹤信息呢？ 

2. String str = “Hello”;其中str是一個(gè)字符串對象

 跟C++不同的是，Java里的變量要么是基礎(chǔ)類型，要么是引用。變量不可能是對象。這意味著像這樣的表達(dá)式：

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

大多數(shù)情況下其實(shí)沒有太大的區(qū)別，不過這么寫容易引起困惑。

 final StringBuilder sb = new StringBuidler();
 sb.append("Hello"); // 這個(gè)引用是final類型的，而不是這個(gè)實(shí)例。
 method(sb); // 可以通過方法來修改這個(gè)實(shí)例，不過這個(gè)變量是無法修改的 

3.Java的內(nèi)存泄露跟C++程序員理解的一樣 

內(nèi)存泄露在維基百科上的定義是”在計(jì)算機(jī)科學(xué)中，如果程序沒有正確地管理好內(nèi)存分配 ，就會出現(xiàn)內(nèi)存泄露。在面向?qū)ο缶幊讨校绻麅?nèi)存中的一個(gè)對象無法在代碼中訪問不到的話，這就是內(nèi)存泄露。” 不過在Java中，對象總是可達(dá)的，那些沒有強(qiáng)引用的對象會被清除掉。內(nèi)存泄露這個(gè)術(shù)語在Java中意味著：內(nèi)存中存在著不該存在的對象，通常來說是有些不再使用的資源卻仍存儲在集合中。 

4.多線程編程很難 

如果你沒有經(jīng)驗(yàn)的話，多線程編程的確很難。如果你只是把一堆代碼扔到一堆線程中去執(zhí)行，那樣出了問題根本沒法解決，只能是一團(tuán)糟。 但如果你能進(jìn)行線程的按需分配，控制線程間的交互，使用一些團(tuán)隊(duì)中的成員也能明白的簡單的模式，問題就變得簡單多了。當(dāng)然還有一個(gè)挑戰(zhàn)就是你得讓團(tuán)隊(duì)中的所有人都遵循你的這個(gè)規(guī)則 

5.不用關(guān)心不同操作間性能的不同 

最近聽說有個(gè)問題，它涉及到了整數(shù)的相加，內(nèi)存訪問，取模，以及輸出到控制臺。盡管在這些操作里面，每一個(gè)都比前面一個(gè)要慢一個(gè)數(shù)量級，但這哥們就是想優(yōu)化這里面最快的操作，加法，還用了些更昂貴的操作來替換它。 如果你真的想要優(yōu)化性能，你最好用一個(gè)廉價(jià)的操作來替換掉那些昂貴的操作，如果你的瓶頸在硬件這塊，比方說要從硬盤里面讀取大量的文件，修改軟件的代碼是沒啥用了，因?yàn)閱栴}根本 就不在這。 

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

一組特定的隨機(jī)數(shù)就像是某種模式的數(shù)字。這個(gè)問題我在這篇文章中已經(jīng)講到過了。很多人都不相信隨機(jī)數(shù)生成器生成的數(shù)字其實(shí)是不隨機(jī)的。 

7.應(yīng)該盡量避免使用浮點(diǎn)數(shù)，因?yàn)樗鼈儠a(chǎn)生隨機(jī)錯誤 

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

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

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

在過去的這些年里面，還有不少時(shí)區(qū)也發(fā)生了變化。莫斯科以前是東三區(qū)（GMT+3），現(xiàn)在是東四區(qū)（GMT+4）（從2011年3月27日開始）。如果你看下2010年的時(shí)間，你會發(fā)現(xiàn)它是東三區(qū)而不是東四區(qū)。 

還有些事你聽起來或許會感覺很意外：
 1721年的瑞典的2月有30天。
 1751年英格蘭的第一天是3月25日，和法國相比差了11天。

美國采用公歷紀(jì)年后，它往前追溯了上百年，這樣原先記錄的那些日期都可以用兩種日歷來進(jìn)行表示（通常為了更精確會同時(shí)提供兩個(gè)日期）。比如喬治華盛頓的生日從1731年2月11變成了1732年2月22。 

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

前幾天這個(gè)問題在StackOverflow上出現(xiàn)過兩回了。一般來說，JIT編譯器優(yōu)化代碼的時(shí)候會將這個(gè)線程沒有修改到的非volatile類型的字段進(jìn)行內(nèi)聯(lián)。一旦這個(gè)代碼被編譯了（你可以通過-XX:+PrintCompilation看到），你在另一個(gè)線程對這個(gè)字段進(jìn)行的修改它很可能就永遠(yuǎn)也看不到了。加上隨機(jī)的同步塊或者打印語句可以推遲這個(gè)優(yōu)化的執(zhí)行，或者擾亂JIT編譯器，讓它不去執(zhí)行這個(gè)優(yōu)化。 

10.Java面試題都是正確的 

有很多Java面試題要么是過時(shí)了（超過10年沒有更新了，和現(xiàn)在的Java版本已經(jīng)脫節(jié)），要么是誤導(dǎo)大家的，甚至可能是錯的。不幸的是這些答案都沒有檢查過就被到處傳來傳去。 

我會參考Stackoverflow上面的答案，因?yàn)檫@里的答案同行審查做的更好些?？偟膩碚f，像rose india這樣的網(wǎng)站就不要上了，上面的答案的質(zhì)量差的離譜。如果你喜歡刨根究底的話，可以看看上面一篇文章里有多少拼寫錯誤（類名以及專業(yè)術(shù)語）或者錯誤的言論。存在這些問題的一個(gè)原因在于沒有一個(gè)有效的反饋機(jī)制來糾正這些錯誤。 

為大家推薦一些Java面試題：

最有價(jià)值的50道java面試題 適用于準(zhǔn)入職Java程序員

10個(gè)經(jīng)典的Java main方法面試題

探討Java中最常見的十道面試題(超經(jīng)典)

適用于Java程序員的10道XML面試題 新鮮出爐

以上就是本文的全部內(nèi)容，希望對大家的學(xué)習(xí)有所幫助，也希望大家多多支持腳本之家。

最新評論