今天動(dòng)力節(jié)點(diǎn)的Java老師給動(dòng)寶兒拋出了10個(gè)高級(jí)Java面試題,當(dāng)然這些題不一定會(huì)出現(xiàn)在真正的面試當(dāng)中,但是還是適合咱們同學(xué)找個(gè)時(shí)間實(shí)踐一下的,萬一哪天咱們就碰到這樣的面試題了呢?來大家感受下。
1.System.exit(0)會(huì)跳過finally塊的執(zhí)行
System.setSecurityManager(newSecurityManager(){
@Override
publicvoidcheckExit(intstatus){
thrownewThreadDeath();
}
});
try{
System.exit(0);
}finally{
System.out.println("Inthefinallyblock");
}
這段代碼為什么會(huì)輸出Inthefinallyblock?為什么沒有打印出堆棧跟蹤信息呢?
2.Stringstr=“Hello”;其中str是一個(gè)字符串對(duì)象
跟C++不同的是,Java里的變量要么是基礎(chǔ)類型,要么是引用。變量不可能是對(duì)象。這意味著像這樣的表達(dá)式:
Stringstr="Hello";
Stringtext="Bye";
str==text;//比較兩個(gè)引用,而不是內(nèi)容
str=text;//把text的引用賦值給str
大多數(shù)情況下其實(shí)沒有太大的區(qū)別,不過這么寫容易引起困惑。
finalStringBuildersb=newStringBuidler();
sb.append("Hello");//這個(gè)引用是final類型的,而不是這個(gè)實(shí)例。
method(sb);//可以通過方法來修改這個(gè)實(shí)例,不過這個(gè)變量是無法修改的
3.Java的內(nèi)存泄露跟C++程序員理解的一樣
內(nèi)存泄露在維基百科上的定義是”在計(jì)算機(jī)科學(xué)中,如果程序沒有正確地管理好內(nèi)存分配,就會(huì)出現(xiàn)內(nèi)存泄露。在面向?qū)ο缶幊讨校绻麅?nèi)存中的一個(gè)對(duì)象無法在代碼中訪問不到的話,這就是內(nèi)存泄露。”不過在Java中,對(duì)象總是可達(dá)的,那些沒有強(qiáng)引用的對(duì)象會(huì)被清除掉。內(nèi)存泄露這個(gè)術(shù)語在Java中意味著:內(nèi)存中存在著不該存在的對(duì)象,通常來說是有些不再使用的資源卻仍存儲(chǔ)在集合中。
4.多線程編程很難
如果你沒有經(jīng)驗(yàn)的話,多線程編程的確很難。如果你只是把一堆代碼扔到一堆線程中去執(zhí)行,那樣出了問題根本沒法解決,只能是一團(tuán)糟。但如果你能進(jìn)行線程的按需分配,控制線程間的交互,使用一些團(tuán)隊(duì)中的成員也能明白的簡(jiǎn)單的模式,問題就變得簡(jiǎn)單多了。當(dāng)然還有一個(gè)挑戰(zhàn)就是你得讓團(tuán)隊(duì)中的所有人都遵循你的這個(gè)規(guī)則
5.不用關(guān)心不同操作間性能的不同
最近聽說有個(gè)問題,它涉及到了整數(shù)的相加,內(nèi)存訪問,取模,以及輸出到控制臺(tái)。盡管在這些操作里面,每一個(gè)都比前面一個(gè)要慢一個(gè)數(shù)量級(jí),但這哥們就是想優(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)樗鼈儠?huì)產(chǎn)生隨機(jī)錯(cuò)誤
對(duì)于同一個(gè)操作而言,浮點(diǎn)數(shù)每次都會(huì)產(chǎn)生同樣的錯(cuò)誤。錯(cuò)誤是可預(yù)測(cè)的,因此也是可控的。如果你清楚你要做的事情是什么,并且堅(jiān)持使用一些簡(jiǎn)單的規(guī)則,比如說對(duì)結(jié)果進(jìn)行舍入操作,那么浮點(diǎn)數(shù)出的錯(cuò)也不會(huì)比BigDecimal要多,除此之外它的可讀性更強(qiáng),而且效率快了百倍以上(同時(shí)產(chǎn)生的垃圾對(duì)象也更少了)。
8.時(shí)區(qū)是永恒不變的
之所以會(huì)有這個(gè)誤解是因?yàn)椋S著時(shí)間的變化,時(shí)區(qū)是在改變的。這意味著歐洲/倫敦在新紀(jì)元的時(shí)候是1970/1/101: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í)間,你會(huì)發(fā)現(xiàn)它是東三區(qū)而不是東四區(qū)。
還有些事你聽起來或許會(huì)感覺很意外:
?1721年的瑞典的2月有30天。
?1751年英格蘭的第一天是3月25日,和法國相比差了11天。
?美國采用公歷紀(jì)年后,它往前追溯了上百年,這樣原先記錄的那些日期都可以用兩種日歷來進(jìn)行表示(通常為了更精確會(huì)同時(shí)提供兩個(gè)日期)。比如喬治華盛頓的生日從1731年2月11變成了1732年2月22。
9.當(dāng)你在線程中讀取一個(gè)非Volatile變量時(shí),你最終能讀取它更新的那個(gè)值。
前幾天這個(gè)問題在StackOverflow上出現(xiàn)過兩回了。一般來說,JIT編譯器優(yōu)化代碼的時(shí)候會(huì)將這個(gè)線程沒有修改到的非volatile類型的字段進(jìn)行內(nèi)聯(lián)。一旦這個(gè)代碼被編譯了(你可以通過-XX:+PrintCompilation看到),你在另一個(gè)線程對(duì)這個(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)大家的,甚至可能是錯(cuò)的。不幸的是這些答案都沒有檢查過就被到處傳來傳去。