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

　　HashMap本身沒有什么問題，有沒有問題取決于你是如何使用它的。比如，你在一個線程里初始化了一個HashMap然后在多個其他線程里對其進行讀取，這肯定沒有任何問題。有個例子就是使用HashMap來存儲系統配置項。當有多于一個線程對HashMap進行修改操作的時候才會真正產生問題，比如增加、刪除、更新鍵值對的時候。因為put()操作可以造成重新分配存儲大小（re-sizeing）的動作，因此有可能造成無限循環的發生，所以這時需要使用Hashtable或者ConcurrentHashMap，而后者更優。

　　問題二：不重寫Bean的hashCode()方法是否會對性能帶來影響？

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

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

　　不盡然，因為你可以通過將成員聲明成非final且private，并且不要在除了構造函數的其他地方來修改它。不要為它們提供setter方法，同時不會通過任何函數泄露出對此成員的引用。需要記住的是，把對象聲明成final僅僅保證了它不會被重新賦上另外一個值，你仍然可以通過此引用來修改引用對象的屬性。這一點是關鍵，面試官通常喜歡聽到你強調這一點。

　　問題四：你在寫存儲過程或者在Java里調用存儲過程的時候如何來處理錯誤情況？

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

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

　　答案是：前者返回一個Future對象，可以通過這個對象來獲得工作線程執行的結果。

　　當我們考察異常處理的時候，又會發現另外一個不同。當你使用execute提交的任務拋出異常時，此異常將會交由未捕捉異常處理過程來處理（uncaughtexceptionhandler），當你沒有顯式指定一個異常處理器的話，默認情況下僅僅會通過System.err打印出錯誤堆棧。

　　當你用submit來提交一個任務的時候，這個任務一旦拋出異常（無論是否是運行時異常），那這個異常是任務返回對象的一部分。對這樣一種情形，當你調用Future.get()方法的時候，這個方法會重新拋出這個異常，并且會使用ExecutionException進行包裝。

　　問題六：什么是單例模式？創建單例對象的時候是將整個方法都標記為synchronized好還是僅僅把創建的的語句標記為synchronized好？

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

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

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

　　問題八：你在什么時候會重寫hashCode()和equals()方法？

　　當你需要根據業務邏輯來進行相等性判斷、而不是根據對象相等性來判斷的時候你就需要重寫這兩個函數了。例如，兩個Employee對象相等的依據是它們擁有相同的emp_id，盡管它們有可能是兩個不同的Object對象，并且分別在不同的地方被創建。同時，如果你準備把它們當作HashMap中的key來使用的話，你也必須重寫這兩個方法。現在，作為Java中equals-hashcode的一個約定，當你重寫equals的時候必須也重寫hashcode，否則你會打破諸如Set,Map等集合賴以正常工作的約定。

　　問題九：如果不重寫hashCode方法會有什么問題？

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

　　問題十：我們要同步整個getInstance()方法，還是只同步getInstance()方法中的關鍵部分？

　　答案是：僅僅同步關鍵部分（CriticalSection）。這是因為，如果我們同步整個方法的話，每次有線程調用getInstance()方法的時候都會等待其他線程調用完成才行，即使在此方法中并沒有執行對象的創建操作。換句話說，我們只需要同步那些創建對象的代碼，而創建對象的代碼只會執行一次。一旦對象創建完成之后，根本沒有必要再對方法進行同步保護了。事實上，從性能上來說，對方法進行同步保護這種編碼方法非常要命，因為它會使性能降低10到20倍。下面是單例模式的UML圖。