Java面試題及答案（12）

 

 

抽象類和接口的區別，類能夠繼承多個類嗎，接口能夠繼承多個接口嗎，類能夠實現多個接口嗎？

 

• 抽象類和接口都不能直接實例化，若是要實例化，抽象類變量必須指向實現全部抽象方法的子類對象，接口變量必須指向實現全部接口方法的類對象。 

• 抽象類要被子類繼承，接口要被類實現。　　
  

• 接口只能作方法聲明，抽象類中能夠作方法聲明，也能夠作方法實現 
  

• 接口裏定義的變量只能是公共的靜態的常量，抽象類中的變量是普通變量。 
  

• 抽象類裏的抽象方法必須所有被子類所實現，若是子類不能所有實現父類抽象方法，那麼該子類只能是抽象類。一樣，一個實現接口的時候，如不能所有實現接口方法，那麼該        類也只能爲抽象類。 
  

• 抽象方法只能申明，不能實現。abstract void abc();不能寫成abstract void abc(){}。 
  

• 抽象類裏能夠沒有抽象方法 。
  

• 若是一個類裏有抽象方法，那麼這個類只能是抽象類 。
  

• 抽象方法要被實現，因此不能是靜態的，也不能是私有的。 
  

• 接口可繼承接口，並可多繼承接口，但類只能單根繼承。
  

 

---

 

Tomcat，Apache，Jboss的區別？

 

Tomcat是servlet容器，用於解析jsp，servlet。是一個輕量級的高效的容器；缺點是不支持EJB，只能用於Java應用。

 

Apache是http服務器（web服務器），相似於IIS能夠用來創建虛擬站點，編譯處理靜態頁面。支持SSL技術，支持多個虛擬主機等功能。

 

Jboss是應用服務器，運行EJB的Javaee應用服務器，遵循Javaee規範，可以提供更多平臺的支持和更多集成功能，如數據庫鏈接，JCA等。其對servlet的支持是經過集成其餘servlet容器來實現的。

 

---

 

說出Servlet的生命週期，並說出Servlet和CGI的區別。

 

Servlet被服務器實例化後，容器運行其init方法，請求到達時運行其service方法，service方法自動派遣運行與請求對應的doXXX方法（doGet，doPost）等，當服務器決定將實例銷燬的時候調用其destroy()方法。

 

與CGI的區別在於Servlet處於服務器進程中，它經過多線程方式運行其service方法，一個實例能夠服務於多個請求，而且其實例通常不會銷燬，而CGI對每一個請求都產生新的進程，服務完成後就銷燬，因此效率上低於Servlet。

 

---

 

談談你對MVC的理解

 

MVC是Model—View—Controler的簡稱。即模型—視圖—控制器。MVC是一種設計模式，它強制性的把應用程序的輸入、處理和輸出分開。

 

MVC中的模型、視圖、控制器它們分別擔負着不一樣的任務。

 

視圖: 視圖是用戶看到並與之交互的界面。視圖向用戶顯示相關的數據，並接受用戶的輸入。視圖不進行任何業務邏輯處理。

 

模型: 模型表示業務數據和業務處理，至關於JavaBean。一個模型能爲多個視圖提供數據。這提升了應用程序的重用性。

 

控制器: 當用戶單擊Web頁面中的提交按鈕時，控制器接受請求並調用相應的模型去處理請求，而後根據處理的結果調用相應的視圖來顯示處理的結果。

 

MVC的處理過程：首先控制器接受用戶的請求，調用相應的模型來進行業務處理，並返回數據給控制器。控制器調用相應的視圖來顯示處理的結果。並經過視圖呈現給用戶。

 

---

 

如何避免瀏覽器緩存？

 

• HTTP信息頭中包含Cache-Control:no-cache，pragma:no-cache，或Cache-Control:max-age=0等設置瀏覽器不用緩存請求。 

• 須要根據Cookie，認證信息等決定輸入內容的動態請求是不能被緩存的。 

• 通過HTTPS安全加密的請求不能被緩存。

• HTTP響應頭中不包含Last-Modified/Etag，也不包含Cache-Control/Expires的請求沒法被緩存 。

 

---

 

如何防止緩存雪崩？

 

緣由：

緩存雪崩多是由於數據未加載到緩存中，或者緩存同一時間大面積的失效，從而致使全部請求都去查數據庫，致使數據庫CPU和內存負載太高，甚至宕機。  

 

對應解決：

• 採用加鎖計數，或者使用合理的隊列數量來避免緩存失效時對數據庫形成太大的壓力。這種辦法雖然能緩解數據庫的壓力，可是同時又下降了系統的吞吐量。 

• 分析用戶行爲，儘可能讓失效時間點均勻分佈。避免緩存雪崩的出現。 

• 若是是由於某臺緩存服務器宕機，能夠考慮作主備，好比：redis主備，可是雙緩存涉及到更新事務的問題，update可能讀到髒數據，須要好好解決。

 

---

 

數據庫會死鎖嗎，舉一個死鎖的例子，mysql 怎麼解決死鎖。

 

產生死鎖的緣由主要是：

• 系統資源不足。 

• 進程運行推動的順序不合適。 

• 資源分配不當等。

若是系統資源充足，進程的資源請求都可以獲得知足，死鎖出現的可能性就很低，不然就會因爭奪有限的資源而陷入死鎖。其次，進程運行推動順序與速度不一樣，也可能產生死鎖。

 

產生死鎖的四個必要條件：

• 互斥條件：一個資源每次只能被一個進程使用。 

• 請求與保持條件：一個進程因請求資源而阻塞時，對已得到的資源保持不放。 

• 不剝奪條件：進程已得到的資源，在末使用完以前，不能強行剝奪。 

• 循環等待條件：若干進程之間造成一種頭尾相接的循環等待資源關係。

這四個條件是死鎖的必要條件，只要系統發生死鎖，這些條件必然成立，而只要上述條件之一不知足，就不會發生死鎖。 

 

解決數據庫死鎖的方法：

• 重啓數據庫。 

• 殺掉搶資源的進程。

 

---

 

Dubbo源碼使用了哪些設計模式？

 

工廠模式：

ExtenstionLoader.getExtenstionLoader(Protocol.class).getAdaptiveExtenstion()

 

裝飾器模式+責任鏈：

以provider的調用鏈爲例，具體調用鏈代碼是在protocolFilterWrapper的buildInvokeChain完成的，將註解中含有group=provider的Filter實現。

調用順序：

1. EchoFilter 

2. ClassLoaderFilter

3. GenericFilter

4. ContextFilter

5. ExceptionFilter

6. TimeoutFilter

7. MonitorFilter

8. TraceFilter

裝飾器模式和責任鏈混合使用，Echo是回聲測試請求，ClassLoaderFilter則只是在其主功能上添加了功能。

 

觀察者模式：

provider啓動時須要與註冊中心交互，先註冊本身的服務，再訂閱本身的服務，訂閱時採用了觀察者模式，註冊中心每5s定時檢查是否有服務更新，有更新則向服務提供者發送1個notify消息後便可運行NotifyListener的notity方法，執行監聽器方法。

 

動態代理模式：

擴展JDK的ExtensionLoaderdeAdaptive實現，根據調用階段動態參數決定調用哪一個類，生成代理類的代碼是ExtensionLoader的createAdaptiveExtenstionClassLoader方法。