問題一：在多線程環(huán)境中使用HashMap會(huì)有什么問題？在什么情況下使用get()方法會(huì)產(chǎn)生無限循環(huán)？

　　HashMap本身沒有什么問題，有沒有問題取決于你是如何使用它的。比如，你在一個(gè)線程里初始化了一個(gè)HashMap然后在多個(gè)其他線程里對(duì)其進(jìn)行讀取，這肯定沒有任何問題。有個(gè)例子就是使用HashMap來存儲(chǔ)系統(tǒng)配置項(xiàng)。當(dāng)有多于一個(gè)線程對(duì)HashMap進(jìn)行修改操作的時(shí)候才會(huì)真正產(chǎn)生問題，比如增加、刪除、更新鍵值對(duì)的時(shí)候。因?yàn)閜ut()操作可以造成重新分配存儲(chǔ)大小（re-sizeing）的動(dòng)作，因此有可能造成無限循環(huán)的發(fā)生，所以這時(shí)需要使用Hashtable或者ConcurrentHashMap，而后者更優(yōu)。

　　問題二：不重寫B(tài)ean的hashCode()方法是否會(huì)對(duì)性能帶來影響？

　　這個(gè)問題非常好，每個(gè)人可能都會(huì)有自己的體會(huì)。按照我掌握的知識(shí)來說，如果一個(gè)計(jì)算hash的方法寫得不好，直接的影響是，當(dāng)向HashMap中添加元素的時(shí)候會(huì)更頻繁地造成沖突，因此最終增加了耗時(shí)。但是自從Java8開始，這種影響不再像前幾個(gè)版本那樣顯著了，因?yàn)楫?dāng)沖突的發(fā)生超出了一定的限度之后，鏈表類的實(shí)現(xiàn)將會(huì)被替換成二叉樹（binarytree）實(shí)現(xiàn)，這時(shí)你仍可以得到O(logN)的開銷，優(yōu)于鏈表類的O(n)。

　　問題三：對(duì)于一個(gè)不可修改的類，它的每個(gè)對(duì)象是不是都必須聲明成final的？

　　不盡然，因?yàn)槟憧梢酝ㄟ^將成員聲明成非final且private，并且不要在除了構(gòu)造函數(shù)的其他地方來修改它。不要為它們提供setter方法，同時(shí)不會(huì)通過任何函數(shù)泄露出對(duì)此成員的引用。需要記住的是，把對(duì)象聲明成final僅僅保證了它不會(huì)被重新賦上另外一個(gè)值，你仍然可以通過此引用來修改引用對(duì)象的屬性。這一點(diǎn)是關(guān)鍵，面試官通常喜歡聽到你強(qiáng)調(diào)這一點(diǎn)。

　　問題四：你在寫存儲(chǔ)過程或者在Java里調(diào)用存儲(chǔ)過程的時(shí)候如何來處理錯(cuò)誤情況？

　　這是個(gè)很棘手的Java面試題，答案也并不固定。我的答案是，寫存儲(chǔ)過程的時(shí)候一旦有操作失敗，則一定要返回錯(cuò)誤碼。但是在調(diào)用存儲(chǔ)過程的時(shí)候出錯(cuò)的話捕捉SQLException卻是唯一能做的。

　　問題五：Executor.submit()和Executor.execute()這兩個(gè)方法有什么區(qū)別？

　　答案是：前者返回一個(gè)Future對(duì)象，可以通過這個(gè)對(duì)象來獲得工作線程執(zhí)行的結(jié)果。

　　當(dāng)我們考察異常處理的時(shí)候，又會(huì)發(fā)現(xiàn)另外一個(gè)不同。當(dāng)你使用execute提交的任務(wù)拋出異常時(shí)，此異常將會(huì)交由未捕捉異常處理過程來處理（uncaughtexceptionhandler），當(dāng)你沒有顯式指定一個(gè)異常處理器的話，默認(rèn)情況下僅僅會(huì)通過System.err打印出錯(cuò)誤堆棧。

　　當(dāng)你用submit來提交一個(gè)任務(wù)的時(shí)候，這個(gè)任務(wù)一旦拋出異常（無論是否是運(yùn)行時(shí)異常），那這個(gè)異常是任務(wù)返回對(duì)象的一部分。對(duì)這樣一種情形，當(dāng)你調(diào)用Future.get()方法的時(shí)候，這個(gè)方法會(huì)重新拋出這個(gè)異常，并且會(huì)使用ExecutionException進(jìn)行包裝。

　　問題六：什么是單例模式？創(chuàng)建單例對(duì)象的時(shí)候是將整個(gè)方法都標(biāo)記為synchronized好還是僅僅把創(chuàng)建的的語句標(biāo)記為synchronized好？

　　在Java中，單例類是指那些在整個(gè)Java程序中只存在一份實(shí)例的類，例如java.lang.Runtime就是一個(gè)單例類。在Java4版本及以前創(chuàng)建單例會(huì)有些麻煩，但是自從Java5引入了Enum類型之后，事情就變得簡(jiǎn)單了。可以去看看我的關(guān)于如何使用Enum來創(chuàng)建單例類的文章，同時(shí)再看看問題五來看看如何在創(chuàng)建單例類的時(shí)候進(jìn)行雙重檢查。

　　問題七：能否寫一段用Java4或5來遍歷一個(gè)HashMap的代碼？

　　事實(shí)上，用Java可以有四種方式來遍歷任何一個(gè)Map，一種是使用keySet()方法獲取所有的鍵，然后遍歷這些鍵，再依次通過get()方法來獲取對(duì)應(yīng)的值。第二種方法可以使用entrySet()來獲取鍵值對(duì)的集合，然后使用foreach語句來遍歷這個(gè)集合，遍歷的時(shí)候獲得的每個(gè)鍵值對(duì)已經(jīng)包含了鍵和值。這種算是一種更優(yōu)的方式，因?yàn)槊枯啽闅v的時(shí)候同時(shí)獲得了key和value，無需再調(diào)用get()方法，get()方法在那種如果bucket位置有一個(gè)巨大的鏈表的時(shí)候的性能開銷是O(n)。第三種方法是獲取entrySet之后用iterator依次獲取每個(gè)鍵值對(duì)。第四種方法是獲得keyset之后用iterator依次獲取每個(gè)key，然后再根據(jù)key來調(diào)用get方法。

　　問題八：你在什么時(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等集合賴以正常工作的約定。

　　問題九：如果不重寫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)鍵部分（CriticalSection）。這是因?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圖。