問題一：在多執行緒環境中使用HashMap會有什麼問題？在什麼情況下使用get()方法會產生無限迴圈？

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

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

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

問題三：對於一個不可修改的類，它的每個物件是不是都必須宣告成final的？

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

問題四：String的substring()方法內部是如何實現的？

又一個Java面試的好問題，你應該答出“substring方法通過原字串建立了一個新的物件”，否則你的回答肯定是不能令人滿意的。這個問題也經常被拿來測試應聘者對於substring()可能帶來的記憶體洩漏風險是否有所瞭解。直到Java 1.7版本之前，substring會儲存一份原字串的字元陣列的引用，這意味著，如果你從1GB大小的字串裡截取了5個字元，而這5個字元也會阻止那1GB記憶體被回收，因為這個引用是強引用。

到了Java 1.7，這個問題被解決了，原字串的字元陣列已經不再被引用，但是這個改變也使得substring()建立字串的操作更加耗時，以前的開銷是O(1)，現在最壞情況是O(n)。

問題五：能否寫一個單例模式，並且保證例項的唯一性？

這算是Java一個比較核心的問題了，面試官期望你能知道在寫單例模式時應該對例項的初始化與否進行雙重檢查。記住對例項的宣告使用Volatile關鍵字，以保證單例模式是執行緒安全的。下面是一段示例，展示瞭如何用一種執行緒安全的方式實現了單例模式：

public class Singleton {

    private static volatile Singleton _instance;

    /**

     * Double checked locking code on Singleton

     * @return Singelton instance

     */

    public static Singleton getInstance() {

        if (_instance == null) {

            synchronized (Singleton.class) {

                if (_instance == null) {

                    _instance = new Singleton();

                }

            }

        }

        return _instance;

    }

}

問題六：你在寫儲存過程或者在Java裡呼叫儲存過程的時候如何來處理錯誤情況？

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

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

此問題來自另外一篇文章，《15個最流行的java多執行緒面試問題》，現在對熟練掌握併發技能的開發者的需求越來越大，因此這個問題也越來越引起大家的重視。答案是：前者返回一個Future物件，可以通過這個物件來獲得工作執行緒執行的結果。

當我們考察異常處理的時候，又會發現另外一個不同。當你使用execute提交的任務丟擲異常時，此異常將會交由未捕捉異常處理過程來處理（uncaught exception handler），當你沒有顯式指定一個異常處理器的話，預設情況下僅僅會通過System.err打印出錯誤堆疊。當你用submit來提交一個任務的時候，這個任務一旦丟擲異常（無論是否是執行時異常），那這個異常是任務返回物件的一部分。對這樣一種情形，當你呼叫Future.get()方法的時候，這個方法會重新丟擲這個異常，並且會使用ExecutionException進行包裝。

問題八：工廠模式和抽象工廠模式有何不同？

抽象工廠模式提供了多一級的抽象。不同的工廠類都繼承了同一個抽象工廠方法，但是卻根據工廠的類別建立不同的物件。例如，AutomobileFactory, UserFactory, RoleFactory都繼承了AbstractFactory，但是每個工廠類建立自己對應型別的物件。下面是工廠模式和抽象工廠模式對應的UML圖。

問題九：什麼是單例模式？建立單例物件的時候是將整個方法都標記為

synchronized好還是僅僅把建立的的語句標記為synchronized好？

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

問題十：能否寫一段用Java 4或5來遍歷一個HashMap的程式碼？

事實上，用Java可以有四種方式來遍歷任何一個Map，一種是使用keySet()方法獲取所有的鍵，然後遍歷這些鍵，再依次通過get()方法來獲取對應的值。第二種方法可以使用entrySet()來獲取鍵值對的集合，然後使用for each語句來遍歷這個集合，遍歷的時候獲得的每個鍵值對已經包含了鍵和值。這種算是一種更優的方式，因為每輪遍歷的時候同時獲得了key和value，無需再呼叫get()方法，get()方法在那種如果bucket位置有一個巨大的連結串列的時候的效能開銷是O(n)。第三種方法是獲取entrySet之後用iterator依次獲取每個鍵值對。第四種方法是獲得key set之後用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()方法中的關鍵部分？

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

再補充一下，建立執行緒安全的單例物件有多種方法，你也可以順便提一下。

問題十四：HashMap，在呼叫get()方法的時候equals()和hashCode()方法都起了什麼樣的作用？

這個問題算是對問題十二的補充，應聘者應該知道的是，一旦你提到了hashCode()方法，人們很可能要問HashMap是如何使用這個函式的。當你向HashMap插入一個key的時候，首先，這個物件的hashCode()方法會被呼叫，呼叫結果用來計算將要儲存的位置(bucket)。

因為某個位置上可能以連結串列的方式已經包含了多個Map.Entry物件，所以HashMap會使用equals()方法來將此物件與所有這些Map.Entry所包含的key進行對比，以確定此key物件是否已經存在。

問題十五：在Java中如何避免死鎖？

你可以通過打破互相等待的局面來避免死鎖。為了達到這一點，你需要在程式碼中合理地安排獲取和釋放鎖的順序。如果獲得鎖的順序是固定的，並且獲得的順序和釋放的順序剛好相反的話，就不會產生出現死鎖的條件了。

問題十六：建立字串物件的時候，使用字面值和使用new String()構造器這兩種方式有什麼不同？

當我們使用new String構造器來建立字串的時候，字串的值會在堆中建立，而不會加入JVM的字串池中。相反，使用字面值建立的String物件會被放入堆的PermGen段中。例如：

String str=new String(“Test”);

這句程式碼建立的物件str不會放入字串池中，我們需要顯式呼叫String.intern()方法來將它放入字串池中。僅僅當你使用字面值建立字串時，Java才會自動將它放入字串池中，比如：String s=”Test”。順便提一下，這裡有個容易被忽視的地方，當我們將引數“Test”傳入構造器的時候，這個引數是個字面值，因此它也會在字串池中儲存另外一份。想了解更多關於字面值字串和字串物件之間的差別，請看這篇文章。

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

問題十七：什麼是不可修改物件(Immutable Object)？你能否寫一個例子？

不可修改物件是那些一旦被建立就不能修改的物件。對這種物件的任何改動的後果都是會建立一個新的物件，而不是在原物件本身做修改。例如Java中的String類就是不可修改的。大多數這樣的類通常都是final型別的，因為這樣可以避免自己被繼承繼而被覆蓋方法，在覆蓋的方法裡，不可修改的特性就難以得到保證了。你通常也可以通過將類的成員設定成private但是非final的來獲得同樣的效果。

另外，你同樣要保證你的類不要通過任何方法暴露成員，特別是那些可修改型別的成員。同樣地，當你的方法接收客戶類傳入的可修改物件的話，你應該使用一個複製的物件來防止客戶程式碼來修改這個剛傳入的可修改類。比如，傳入java.util.Date物件的話，你應該自己使用clone()方法來獲得一個副本。

當你通過類函式返回一個可修改物件的時候，你也要採取類似的防護措施，返回一個類成功的副本，防止客戶程式碼通過此引用修改了成員物件的屬性。千萬不要直接把你的可修改成員直接返回給客戶程式碼。

問題十八：如何在不使用任何分析工具的情況下用最簡單的方式計算某個方法的執行所花費的時間？

在執行此方法之前和之後獲取一個系統時間，取這兩個時間的差值，即可得到此方法所花費的時間。

需要注意的是，如果執行此方法花費的時間非常短，那麼得到的時間值有可能是0ms。這時你可以在一個計算量比較大的方法上試一下效果。

long start=System.currentTimeMillis();

method();

long end=System.currentTimeMillis();

System.out.println("Time taken for execution is "+(end-start));

問題十九：當你要把某個類作為HashMap的key使用的話，你需要重寫這個類的哪兩個方法？

為了使類可以在HashMap或Hashtable中作為key使用，必須要實現這個類自己的equals()和hashCode()方法。具體請參考問題十四。

問題二十：你如何阻止客戶程式碼直接初始化你的類的構造方法？例如，你有一個名為Cache的介面和兩個具體的實現類MemoryCache和DiskCache，你如何保證這兩個類禁止客戶程式碼用new關鍵字來獲取它們的例項？

我把這最後一個問題留給你做練習吧，你可以在我給出答案之前好好思索一下。我確信你能夠找到正確的方法的，因為這是將類的實現掌控在自己手中的一個重要的方法，同時也能為以後的維護提供巨大的好處。