來自交通銀行Java面試題目總結(jié)

更新時(shí)間：2020-01-16 16:19:18 來源：動(dòng)力節(jié)點(diǎn) 瀏覽4821次

　　你在什么時(shí)候會(huì)重寫hashCode()和equals()方法?

　　當(dāng)你需要根據(jù)業(yè)務(wù)邏輯來進(jìn)行相等性判斷、而不是根據(jù)對(duì)象相等性來判斷的時(shí)候你就需要重寫這兩個(gè)函數(shù)了。例如，兩個(gè)Employee對(duì)象相等的依據(jù)是它們擁有相同的emp_id，盡管它們有可能是兩個(gè)不同的Object對(duì)象，并且分別在不同的地方被創(chuàng)建。同時(shí)，如果你準(zhǔn)備把它們當(dāng)作HashMap中的key來使用的話，你也必須重寫這兩個(gè)方法。現(xiàn)在，作為Java中equals-hashcode的一個(gè)約定，當(dāng)你重寫equals的時(shí)候必須也重寫hashcode，否則你會(huì)打破諸如Set, Map等集合賴以正常工作的約定。你可以看看我的另外一篇博文來理解這兩個(gè)方法之間的微妙區(qū)別與聯(lián)系。

　　如果不重寫hashCode方法會(huì)有什么問題?

　　如果不重寫equals方法的話，equals和hashCode之間的約定就會(huì)被打破：當(dāng)通過equals方法返回相等的兩個(gè)對(duì)象，他們的hashCode也必須一樣。如果不重寫hashCode方法的話，即使是使用equals方法返回值為true的兩個(gè)對(duì)象，當(dāng)它們插入同一個(gè)map的時(shí)候，因?yàn)閔ashCode返回不同所以仍然會(huì)被插入到兩個(gè)不同的位置。這樣就打破了HashMap的本來目的，因?yàn)镸ap本身不允許存進(jìn)去兩個(gè)key相同的值。當(dāng)使用put方法插入一個(gè)的時(shí)候，HashMap會(huì)先計(jì)算對(duì)象的hashcode，然后根據(jù)它來找到存儲(chǔ)位置(bucket)，然后遍歷此存儲(chǔ)位置上所有的Map.Entry對(duì)象來查看是否與待插入對(duì)象相同。如果沒有提供hashCode的話，這些就都做不到了。

　　我們要同步整個(gè)getInstance()方法，還是只同步getInstance()方法中的關(guān)鍵部分?

　　答案是：僅僅同步關(guān)鍵部分(Critical Section)。這是因?yàn)椋绻覀兺秸麄€(gè)方法的話，每次有線程調(diào)用getInstance()方法的時(shí)候都會(huì)等待其他線程調(diào)用完成才行，即使在此方法中并沒有執(zhí)行對(duì)象的創(chuàng)建操作。換句話說，我們只需要同步那些創(chuàng)建對(duì)象的代碼，而創(chuàng)建對(duì)象的代碼只會(huì)執(zhí)行一次。一旦對(duì)象創(chuàng)建完成之后，根本沒有必要再對(duì)方法進(jìn)行同步保護(hù)了。事實(shí)上，從性能上來說，對(duì)方法進(jìn)行同步保護(hù)這種編碼方法非常要命，因?yàn)樗鼤?huì)使性能降低10到20倍。下面是單例模式的UML圖。

來自交通銀行Java面試題目總結(jié)

　　再補(bǔ)充一下，創(chuàng)建線程安全的單例對(duì)象有多種方法，你也可以順便提一下。

　　HashMap，在調(diào)用get()方法的時(shí)候equals()和hashCode()方法都起了什么樣的作用?

　　這個(gè)問題算是對(duì)問題十二的補(bǔ)充，應(yīng)聘者應(yīng)該知道的是，一旦你提到了hashCode()方法，人們很可能要問HashMap是如何使用這個(gè)函數(shù)的。當(dāng)你向HashMap插入一個(gè)key的時(shí)候，首先，這個(gè)對(duì)象的hashCode()方法會(huì)被調(diào)用，調(diào)用結(jié)果用來計(jì)算將要存儲(chǔ)的位置(bucket)。

　　因?yàn)槟硞€(gè)位置上可能以鏈表的方式已經(jīng)包含了多個(gè)Map.Entry對(duì)象，所以HashMap會(huì)使用equals()方法來將此對(duì)象與所有這些Map.Entry所包含的key進(jìn)行對(duì)比，以確定此key對(duì)象是否已經(jīng)存在。

　　在Java中如何避免死鎖?

　　你可以通過打破互相等待的局面來避免死鎖。為了達(dá)到這一點(diǎn)，你需要在代碼中合理地安排獲取和釋放鎖的順序。如果獲得鎖的順序是固定的，并且獲得的順序和釋放的順序剛好相反的話，就不會(huì)產(chǎn)生出現(xiàn)死鎖的條件了。

　　創(chuàng)建字符串對(duì)象的時(shí)候，使用字面值和使用new String()構(gòu)造器這兩種方式有什么不同?

　　當(dāng)我們使用new String構(gòu)造器來創(chuàng)建字符串的時(shí)候，字符串的值會(huì)在堆中創(chuàng)建，而不會(huì)加入JVM的字符串池中。相反，使用字面值創(chuàng)建的String對(duì)象會(huì)被放入堆的PermGen段中。例如：

　　String str=new String(“Test”);

　　這句代碼創(chuàng)建的對(duì)象str不會(huì)放入字符串池中，我們需要顯式調(diào)用String.intern()方法來將它放入字符串池中。僅僅當(dāng)你使用字面值創(chuàng)建字符串時(shí)，Java才會(huì)自動(dòng)將它放入字符串池中，比如：String s=”Test”。順便提一下，這里有個(gè)容易被忽視的地方，當(dāng)我們將參數(shù)“Test”傳入構(gòu)造器的時(shí)候，這個(gè)參數(shù)是個(gè)字面值，因此它也會(huì)在字符串池中保存另外一份。想了解更多關(guān)于字面值字符串和字符串對(duì)象之間的差別，請(qǐng)看這篇文章。

　　下圖很好地解釋了這種差異。

來自交通銀行Java面試題目總結(jié)

　　什么是不可修改對(duì)象(Immutable Object)?你能否寫一個(gè)例子?

　　不可修改對(duì)象是那些一旦被創(chuàng)建就不能修改的對(duì)象。對(duì)這種對(duì)象的任何改動(dòng)的后果都是會(huì)創(chuàng)建一個(gè)新的對(duì)象，而不是在原對(duì)象本身做修改。例如Java中的String類就是不可修改的。大多數(shù)這樣的類通常都是final類型的，因?yàn)檫@樣可以避免自己被繼承繼而被覆蓋方法，在覆蓋的方法里，不可修改的特性就難以得到保證了。你通常也可以通過將類的成員設(shè)置成private但是非final的來獲得同樣的效果。

　　另外，你同樣要保證你的類不要通過任何方法暴露成員，特別是那些可修改類型的成員。同樣地，當(dāng)你的方法接收客戶類傳入的可修改對(duì)象的話，你應(yīng)該使用一個(gè)復(fù)制的對(duì)象來防止客戶代碼來修改這個(gè)剛傳入的可修改類。比如，傳入java.util.Date對(duì)象的話，你應(yīng)該自己使用clone()方法來獲得一個(gè)副本。

　　當(dāng)你通過類函數(shù)返回一個(gè)可修改對(duì)象的時(shí)候，你也要采取類似的防護(hù)措施，返回一個(gè)類成功的副本，防止客戶代碼通過此引用修改了成員對(duì)象的屬性。千萬不要直接把你的可修改成員直接返回給客戶代碼。

來自交通銀行Java面試題目總結(jié)