Web後端 JAVAWeb面試考查知識點

面試知識點：
1：簡單講一下Java的跨平臺原理
答：因爲非跨平臺的狀況下，對於不一樣的操做系統，那麼就須要開發幾套不一樣程序代碼。爲了解決這個問題，java經過不一樣系統，不一樣版本，不一樣位數的JVM來屏蔽不一樣的系統指令集差別而對外提供統一的接口（JavaAPI），因此這樣對於咱們普通的開發者來講，只須要開發符合Java規範的程序便可。若是程序須要部署到不一樣的操做系統，那麼咱們只須要按照對應版本的虛擬機便可。

2：java開發環境的步驟
答：須要的內容：對應操做系統的JDK  ， 對應版本位數的IDE（開發工具，好比Eclipse或者IDEA），若是是開發Web項目，那麼還須要服務器，好比Tomcat，jetty。

步驟：

（1）下載JDK，而且配置好Java_Home這個環境變量，由於對於開發工具和Tomcat都須要依賴這個配置變量。

（2）下載IDE，正常解壓便可。

（3）下載Tomcat ，正常解壓便可，而且將這個集成到開發工具中，便於項目進行發佈。 三者的版本要符合規範

3：Java中Int數據佔幾個字節
答：四個字節，32位

4：面向對象的特徵有哪些？
答：繼承，封裝，多態，抽象（而後對每一個概念進行描述和講解一個實例）

5：拆箱和裝箱
答：裝箱：就是基本數據類型轉換成對應的包裝類型。

好比：int  x  = 5 ; -----Integer y = x ; （這是自動裝箱）

實際上進行的是：Integer y = Integer.valueOf(x); （這是手動裝箱）

拆箱：就是包裝類型轉換成對應的基本數據類型。

好比：Integer a = 5;     --------  int b = a ; （這發生了自動拆箱）

實際進行的是：int b = a.intValue() ; （手動拆箱）

6：有了基本數據類型，爲何還須要包裝類型
答：Java是面向對象的語言，而基本數據類型沒有面向對象的特性，並且包裝類型存在緩存，這樣可以更加好的利用資源。（好比，Integer的緩存內容就是-128--------127）

7：equals和==的區別
答：「==」判斷兩個對象是否值相等。這裏要注意：當爲基本類型的時候，就是比較值，若是是引用類型，那麼就是比較首地址。

Equals：判斷兩個對象的內容是否同樣，這個通常是用於引用對象的比較的使用。

8：實現一個拷貝文件的工具類，使用字符流仍是字節流
答：使用字節流，由於咱們拷貝的文件中，可能有圖片，圖像，若是使用字符流就沒法進行拷貝，因此爲了工具類的實用性，採用字節流更好。

9：簡單說一下forward和redirect的區別
答：相同點：都是對請求進行處理

不一樣點：（1）forward是發生在服務器端，效率更好，而redirect是發生在了客戶端

（2）forward是請求轉發，只是一次請求，而redirect是至關於了兩次請求

（3）Forward不會改變客戶端的URL顯示，而redirect會改變客戶端的URL的顯示

10：servlet的生命週期
答：加載servlet的class---》實例化Servlet-----》初始化servlet（調用init方法）------》調用服務service方法（處理doget和dopost方法）-----》servlet容器關閉時調用銷燬方法（destory方法）

11：session和cookie的區別
答：共同點：session和cookie都是會話跟蹤技術，cookie經過在客戶端記錄信息肯定用戶信息，而session經過在服務器端進行記錄肯定用戶信息，可是session依賴於cookie，其中sessionID（session的惟一標識須要存放在客戶端）；

不一樣點：（1）cookie存放在客戶端的瀏覽器上，而session存放在服務器中

（2）cookier不是很安全，別人能夠分析本地的cookie並進行cookie欺騙，因此考慮安全應該使用session

（3）Session會在一段時間內保存在服務器上，當訪問增多時，會比較佔用你服務器的性能，考慮到減輕服務器性能，應該使用cookie

（4）單個cookie保存的數據不能超過4K，不少瀏覽器都限制一個站點最多存放20個cookie

（5）重要信息通常放在session，而相似購物車就應該使用cookie，可是cookier是能夠被禁用的，因此應該利用cookie與數據庫兩種方式。

12：struts2的執行流程
答：（1）瀏覽器發送請求，到達服務器

（2）通過一系列的過濾器後，到達核心過濾器（StrusPrepareAndExcuteFilter）

（3）StrusPrepareAndExcuteFilter經過ActionManager判斷當前的請求是否須要某個Action處理，若是不須要，就繼續執行，若是須要，就會把請求轉爲ActionProxy處理。

（4）ActionProxy經過configurationManager詢問框架的配置（Strus.xml）找到須要調用的aciton類

（5）建立一個ActionInvation實例，來調用Action的對應方法，在調用前會執行一些攔截器

（6）經過調用Action的方法的結果找到對應的結果集name

（7）而後再經過相關的攔截器

（8）經過結果集的name找到對應的結果集來對瀏覽器進行響應

13：struts2的攔截器？通常用於什麼場景？
答：攔截器概念：是動態攔截Action調用的對象，它提供了一種機制可使開發者在進行Action方法執行先後進行所定義的處理。

（1）struts2中的不少功能都是經過攔截器進行完成的，好比文件上傳，參數綁定，字符編碼。

（2）若是業務須要，咱們能夠自定義攔截器，便於在action執行先後，進行所須要的業務處理。

使用場景：

（1）用戶登錄判斷：判斷是否已經登錄，若是沒有登錄，則跳轉到登錄頁面，不然進行放行處理。

（2）權限判斷：若是用戶沒有對應的權限，那麼則沒法進行訪問，不然正常執行。

（3）操做日誌：。。。。。。。。。。

14：Springmvc的執行流程
答：（1）用戶向服務器發送請求，被前端控制器DispacherServlet捕獲。

（2）DispacherServlet對請求URL進行解析，獲得請求資源標示符（URI），而後根據URI調用HanderMapping得到該Handlder配置的全部相關的對象（包括handler對象以及Handler對象對應的攔截器），最後以HandlerExecutionChain對象的形式進行返回（查找handler）

（3）DispacherServlet根據得到的Handler，選擇一個合適的HandlerAdapter，提取Request中的模型數據，填充Handler入參，開始執行Handler（controller），Handler執行完成後，向DispacherServlet返回一個ModelAndView對象（執行handler）。

（4）DispacherServlet根據返回的ModelAndView，選擇對應的ViewResovler（必須是已經註冊到Spring容器中的ViewResovler）。（簡稱爲選擇ViewResovler）

（5）經過ViewResovler結合Model和View，來渲染視圖，DispacherServlet再將渲染的結果返回給客戶端。

15：struts2和springmvc的區別
答：（1）核心控制器不一樣。Struts2是filter過濾器，而springmvc是servlet。

（2）控制器實例不一樣。Springmvc相比strus2要快一些。（理論上）Struts2是基於對象，因此它是多實例的，而springmvc是基於方法的，因此它是單例的，可是應該避免全局變量的修改，這樣會致使線程安全問題。

（3）管理方式不一樣。大部分企業都使用Spring，而Springmvc是spring的一個模塊，因此集成更加簡單容易，並且提升了全註解的開發形式。而strus2須要採用XML的形式進行配置來進行管理（雖然也能夠採用註解，可是公司通常都不會使用）。

（4）參數傳遞不一樣。Struts2是經過值棧（ValueStack）進行傳遞和接受，而Springmvc是經過方法的參數來接受，這樣Springmvc更加高效。

（5）學習程度不一樣。Struts2存在不少技術點，好比攔截器，值棧，以及OGML表達式，學習成本高，而Springmvc比較簡單，上手快。

（6）Interrcpter的實現機制不一樣。Strus2有本身的攔截器的機制，而Springmvc是經過AOP的形式，這樣致使strus2的配置文件比springmvc更加龐大。

（7）對於Ajax請求不一樣。Springmvc能夠根據註解@responseBody 來對ajax請求執行返回json格式數據，而strus2須要根據插件進行封裝返回數據。

16：說一下spring的兩大核心技術
答：Spring的概念：Spring是一個J2EE應用程序框架，是輕量級Ioc和AOP的容器框架（相對於重量級的EJB來講），主要是針對JavaBean的生命週期進行管理的輕量級容器，能夠單獨使用，也能夠和MVC框架和數據庫mybatis和hibernate框架進行使用。

（1）IOC或者DI

  原來的處理模式：若是某個service須要使用某個Dao，那麼就須要手動建立dao對象。

  使用spring後：直接經過spring進行依賴注入便可

核心原理：就是配置文件+反射（工廠模式）+容器（map）

（2）AOP

  核心原理：使用動態代理的方式在執行先後或出現異常後進行相關邏輯處理。

 使用場景：事務處理，日誌，權限。。。。。。。

17：spring的事務隔離級別
答：（1）默認--0（2）讀未提交 ---1   （3）讀已提交-----2    （4）重複讀----4   （5）串行化-----8
（1）、 ISOLATION_DEFAULT： 這是一個PlatfromTransactionManager默認的隔離級別，使用數據庫默認的事務隔離級別.另外四個與JDBC的隔離級別相對應
（2）、 ISOLATION_READ_UNCOMMITTED： 這是事務最低的隔離級別，它充許令外一個事務能夠看到這個事務未提交的數據。這種隔離級別會產生髒讀，不可重複讀和幻像讀。
（3）、 ISOLATION_READ_COMMITTED： 保證一個事務修改的數據提交後才能被另一個事務讀取。另一個事務不能讀取該事務未提交的數據
（4）、 ISOLATION_REPEATABLE_READ： 這種事務隔離級別能夠防止髒讀，不可重複讀。可是可能出現幻像讀。它除了保證一個事務不能讀取另外一個事務未提交的數據外，還保證了避免下面的狀況產生(不可重複讀)。
（5）、 ISOLATION_SERIALIZABLE 這是花費最高代價可是最可靠的事務隔離級別。事務被處理爲順序執行。除了防止髒讀，不可重複讀外，還避免了幻像讀。
18：Spring的事務傳播特性
答：多個事務存在是怎麼處理的策略。

（1）PROPAGATION_REQUIRED：若是存在一個事務，就支持當前事務，若是不存在事務，則開啓事務。

（2）PROPAGATION_SUPPORT：若是存在一個事務，支持當前事務，若是不存在事務，則使用非事務進行執行。

（3）PROPAGATION_MANDTORY：若是已經存在一個事務，支持當前事務，若是沒有一個活動的事務，則拋出異常。

（4）PROPAGATION_REQUIRED_NEW：老是開啓一個新的事務，若是一個事務已經存在，則將這個事務進行掛起。

（5）PROPAGATION_NO_SUPPORT：老是非事務地執行，並掛起任何存在的事務。

（6）PROPAGATION_NEVER：老是非事務執行，若是存在一個活動事務，則拋出異常。

（7）PROPAGATION_NESTED：若是一個活動的事務存在，則運行在一個嵌套的事務中，若是沒有活動事務，則按TransactionDefiniton.PROPAGATION_REQUIRED屬性執行。

18：什麼是ORM框架？
答：ORM（對象關係映射）模式是一種爲了解決面向對象與關係數據庫存在的互不匹配的現象的技術，能夠簡單的方案是採起硬編碼方式（JDBC操做和SQL方式），爲每一種可能的數據庫訪問操做提供單獨的方法，這種方法存在不少的缺陷，因此使用ORM框架來進行解決。表明的有：Hibernate和Mybatis

核心原則：（1）簡單：以最基本的形式鏈接數據（2）傳達性：數據庫結構性任何人都能理解的語言文檔化（3）精確性：基於數據模型建立正確標準化的結構

19：Mybatis和Hibernate的相同點和不一樣點？
參考本篇文章    參考文章二

20：Hibernate的對象狀態
答：三種，

（1）瞬時狀態：經過new建立對象後，對象並無馬上持久化，它並未與數據庫中的數據有任何關聯，此時Java對象的狀態爲瞬時狀態。
　　Session對於瞬時狀態的Java對象是一無所知的，當對象再也不被其餘對象引用時，它的全部數據也就丟失了，對象將會被Java虛擬機按照垃圾回收機制處理。

（2）持久化狀態：當對象與Session關聯，被Session管理時，它就處於持久狀態。處於持久狀態的對象擁有數據庫標識（數據庫中的主鍵值）。
　　那麼，對象是何時與Session發生關聯的呢？有兩種方法：
　　　　第一種，經過Sesison的查詢接口，或者get()方法，或者load()方法從數據庫中加載對象的時候，加載的對象是與數據庫表中的一條記錄關聯的，此時對象與加載它的Session發生關聯；
　　　　第二種，瞬時狀態的對象，經過Session的save()方法或SaveOrUpdate()方法時，Java對象也與Session發生關聯。
　　對於處於持久狀態的對象，Session會持續跟蹤和管理它們，若是對象的內部狀態發生了任何變動，Hibernate會選擇合適的時機（如事務提交時）將變動固化到數據庫中。

（3）遊離狀態：處於持久狀態的對象，脫離與其關聯的nSession的管理後，對象就處於遊離狀態。
　　處於遊離狀態的對象，Session沒法保證對象所包含的數據與數據庫中的記錄一直，由於Hibernate已經沒法感知對該對象的任何操做。
　　Session提供了兩個方法（update()、merge()），將處於遊離狀態的對象，與一個新的Session發生關聯。
　　此時，對象的狀態就從遊離狀態從新轉換爲持久狀態。

之間的轉換關係：

 

21：Hibernate的緩存
答：(1)爲何須要緩存

目的：提升數據的訪問速度，把磁盤或者數據庫的數據放入到內存，提升系統性能。

（2）Hibernate緩存的類型

類型：一級緩存和二級緩存。

一級緩存：是session級別緩存，是內置的沒法卸載的，是事務級別的緩存（session對象的生命週期一般對應一個數據庫事務或者一個應用程序），持久化類型的那個實例都具備惟一的OID。

二級緩存：是sessionFactory的緩存。因爲sessionFactory的生命週期和整個應用程序的整個過程對應，因此二級緩存是進程範圍或者集羣範圍的緩存，會出現併發問題，所以須要採起適當的訪問策略，該策略爲被緩存數據提供了事務隔離級別。二級緩存是可選的，默認狀況是不開啓的。

（3）什麼數據適合放入到緩存

1：不多被修改的數據   2：常常被查詢的數據  3：不會被併發訪問的數據  4：常量數據  5：不是很重要的數據，偶爾會被併發的數據。

（4）Hibernate緩存的缺陷

缺陷：Hibernate的二級緩存沒法解決分佈式緩存問題，因此須要經過memcache丶redis等中央緩存來代替二級緩存。

22：簡單講解一下WebService使用的場景？
答：概念：WebService是SOA（面向服務編程）的架構，它是不依賴於語言，不依賴於平臺，能夠實現不一樣的語言間的相互調用，經過Internet進行基於Http協議的網絡應用間的交互。

webservice就是遠程調用技術,也叫XML Web Service WebService是一種能夠接收從Internet或者Intranet上的其它系統中傳遞過來的請求，輕量級的獨立的通信技術。是:經過SOAP在Web上提供的軟件服務，使用WSDL文件進行說明，並經過UDDI進行註冊

主要的技術點：（1）SOAP：是web service的結拜呢通訊協議，定義SOAP消息的XML格式；-----就是所使用的協議

（2）WSDL：是一種XML文檔，它定義SOAP消息以及這些消息是怎樣交換的，主要就是定義使用服務的規範（由於不一樣的web service所自定義的參數和格式都不必定相同，而客戶端若是要使用的話，那麼就必需要明白對應的規範格式是如何的格式）；----就是至關於提供一份詳細的使用說明書；

（3）UDDI：能夠被比喻成電話本，電話本里記錄的是電話信息，而UUDI記錄的是Web Service信息。能夠不把Web Service註冊到UDDI，但若是要讓全球的人知道本身的Web Service，最好仍是註冊到UDDI；----就是至關於爲了方便更多的人進行查詢和使用；

   UDDI目錄說明文件也是一個XML文檔，其主要是包含三個部分：白頁：說明提供Web Service的公司信息，好比名稱，地址等；黃頁：說明UDDI目錄的分類，好比金融，服務等；綠頁：說明接口由Web Service提供的詳細信息；

場景：（1）異構系統（不一樣語言）的整合

（2）不一樣客戶端的整合瀏覽器，安卓，微信，PC端訪問

（3）好比手機上的天氣預報，就是經過webservice調用接口

（4）好比單點登陸：一個服務是全部系統的登陸。

23：簡單介紹一下Activiti？
答：Activiti是一個開源的工做流引擎，它實現了BPMN 2.0規範，能夠發佈設計好的流程定義，並經過api進行流程調度。
Activiti 做爲一個聽從 Apache 許可的工做流和業務流程管理開源平臺，其核心是基於 Java 的超快速、超穩定的 BPMN2.0 流程引擎，強調流程服務的可嵌入性和可擴展性，同時更增強調面向業務人員。
  Activiti 流程引擎重點關注在系統開發的易用性和輕量性上。每一項 BPM 業務功能 Activiti 流程引擎都以服務的形式提供給開發人員。經過使用這些服務，開發人員可以構建出功能豐富、輕便且高效的 BPM 應用程序。

 它易於與Spring整合，主要使用在OA（辦公自動化）上，把線下流程放到線上，把現實生活中一些流程固定在流程中。它能夠運用到OA的流程管理中，好比請假流程，報銷流程。

24：有沒有作過數據庫優化方面的事情？
答：（1）查找，定位慢查詢，並優化

優化方案：

（2）建立索引：建立合適的索引，咱們就能夠先在索引中查詢，查詢到以後直接到對應的記錄。

（3）分表：當一張表的數據比較多或者一張表的某些字段的值比較多而且不多使用時，就採用水平分表和垂直分表優化。

（4）讀寫分離：當一臺服務器不能知足需求時，採用讀寫分離的方式進行集羣。

（5）緩存：使用redis來進行緩存

（6）語句優化：好比少使用子查詢而用join操做，少使用or多用IN，避免函數操做字段，避免模糊匹配，少用Order by排序，

25：如何定位慢查詢和查找慢查詢？
答：（1）開啓慢查詢功能

在mysql的my.ini文件，添加下面的內容：

slow_query_log= 1   //------>開啓慢查詢，默認是不開啓，即設置爲0的；
long_query_time= 1  //------>設置查詢時間不能超過1秒（默認單位是秒）

slow_query_log_file=c:/slow.log  //----->設置慢查詢記錄的文件的位置，這樣就會把執行超過1秒的sql語句進行記錄

（2）對於慢查詢的語句，那麼就經過上面的一個問題的答案便可。

26：設計數據庫所要遵循的範式？
答：1NF,2NF,3NF和適度的反3NF（便可以適當的增長冗餘字段）

27：數據庫如何選擇合適的存儲引擎？
答：存儲引擎的類別：分爲三類

（1）Innodb：對事務要求高，通常對於重要的數據的存儲，建議使用該引擎。好比訂單表，帳號表等。。。

（2）Myisam：對事務要求不高，同時是以查詢和添加爲主的，建議使用該引擎，好比BBS系統中的發帖數和回帖數。

（3）Memory：數據變化頻繁，不須要入庫，同時又頻繁的查詢和修改，建議使用該引擎，速度相對較快。

Myisam與Innodb的區別：

（1）事務安全：MyiSAM不支持事務，Innodb支持事務；

（2）鎖機制：前者支持表鎖，然後者支持行鎖；

（3）外鍵：前者不支持外鍵，然後者支持；

（4）查詢和添加速度：前者快，後者慢；

（5）全文索引：前者支持，後者不支持；

28：數據庫如何進行索引的選擇？
答：索引的類型：四種

（1）普通索引：容許有重複的值；

（2）惟一索引：不容許有重複的值；

（3）主鍵索引：特殊的惟一索引，是隨着主鍵的建立而建立，也就是把某個列設爲主鍵的時候，數據庫就會給該列建立索引，惟一且不能爲null值；

（4）全文索引：用來對錶中的文本域（text，varchar）進行索引；只在MyISAM引擎中支持，Innodb不支持；

29：數據庫索引使用的技巧？
答：（1）創建索引的缺點：佔用磁盤空間，而且會對dml（插入，刪除，修改，）操做速度產生影響，變慢；

（2）創建索引列的原則：不是頻繁進行修改；該字段不是頻繁的幾個（好比sex列不適合）；確定在where條件中進行使用；

（3） 不能使用索引的狀況：

a：使用查詢語句LIKE 「%XXXX」，以%開頭是不能使用索引的，而若是是LIKE "XXX%"的就會使用索引；

b：使用or查詢，若是or兩端中，有一個字段是沒有索引的，那麼就不會使用索引；

c：對於聯合索引，沒有符合「最左原則」；

d：對於索引列上面進行了數學運算；

e：對於索引列上面進行了函數運算；

f：若是列類型是字符串，那必定要在條件中將數據使用引號進行使用，不然不使用索引；

g：若是mysql估計使用全表掃描要比使用索引快，則不會使用索引；

（4）不推薦創建索引狀況：

a：數據的惟一性差；好比性別列，由於數據就只有兩種狀況，那麼建議的二叉樹級別少，可能是平級，這樣無異於進行全表掃描；

b：頻繁更新的字段不要創建索引；好比logincount登陸次數，頻繁變化致使索引也頻繁變化，增大數據庫工做量，下降效率。

c) 字段不在where語句出現時不要添加索引,若是where後含IS NULL /IS NOT NULL/ like ‘%輸入符%’等條件，不建議使用索引
只有在where語句出現，mysql纔會去使用索引
d） where 子句裏對索引列使用不等於（<>），使用索引效果通常

30：數據庫優化之分表？
答：（1）水平分表（按行數據進行分表）：mysql數據通常達到百萬級別，查詢效率會很低，容易形成表鎖，甚至堆積不少鏈接，直接掛掉，水平分表可以很大程序減小這些壓力。

水平分表的策略：

a：按時間分表：這種分表方式有必定的侷限性，當數據有較強的實效性，如微博發送記錄，微信消息。。。這種數據不多有用戶會查詢幾個月前的數據，就能夠按月進行分表；

b：按區間範圍分表：通常在有嚴格的自增id需求上，經過一個原始目標的ID或者名稱經過必定的hash算法計算出數據存儲的代表，而後再訪問相應的表；

c：hash分表：（用得最多的），

（2）垂直分表（按列分表）：若是一張表中某個字段值很是多（長文本，二進制等），並且只有在不多的狀況下被查詢，這個時候就能夠把多個字段單獨放到一張表，經過外鍵關聯起來；好比考試詳情，通常只關注分數，不關注詳情；

31：數據庫的優化之讀寫分離？
答：當一臺數據庫沒法知足過多的併發數據庫訪問的時候，就能夠採起數據庫的讀寫分離；

兩個核心問題：

a：主從同步：數據庫最終會把數據持久化到磁盤，若是集羣必須確保每一個數據庫服務器的數據是一致的，因此對能改變數據庫數據的操做都在主數據庫去操做，而其餘的數據庫從主數據庫上同步數據

b：讀寫分離：使用負載均衡來實現寫的操做都在主數據庫，而讀的操做都在從服務器。

32：數據庫優化之緩存？
答：在持久層(DAO)和數據庫(DB)直接添加一個緩存層，若是用戶訪問的數據已經被緩存起來時，在用戶訪問時直接從緩存中獲取，不用訪問數據庫，而緩存是內存級別的，訪問速度快。

做用：減小數據庫服務器壓力，減小訪問時間。

java中經常使用的緩存有：hibernate二級緩存（不能解決分佈式緩存）；redis緩存；memcache緩存；

33：數據庫語句優化小技巧？
答：（1）DDL優化：

a：經過禁用索引倆提供導入數據性能，這個操做主要針對有數據的表

b：關閉惟一校驗

   set unique_checks=0 關閉   set unique_checks=1  開啓

c：修改事務提交方式

    set autocommit = 0 關閉    set autocommit = 1 開啓批量導入

（2）DML優化：

a：屢次提交變爲一次提交

insert into test values（1，2）；

insert into test values（3，4）；

變爲：insert into test values（1，2），（3,4）；

（3）DQL優化：

Order by優化----------多用索引排序

能夠參考以下的這篇文章：數據庫優化策略

34：redis對象保存方式？
答：（1）Json字符串：須要把對象轉換爲json字符串，當作字符串處理，直接使用set get來設置

優勢：設置和獲取比較簡單

缺點：沒有提供專門的方法，須要把對象轉換爲json

（2）字節：須要作序列號，就是把對象序列化爲字節保存

若是可是JSON轉對象會消耗資源的狀況，這個問題就須要考量幾個地方：

a：就是使用JSON轉換的lib是否存在性能問題

b：就是數據的數據量級別，若是是存儲百萬級的大數據對象，建議採用存儲序列化對象方式，若是是少許的數據級對象，或者是數據對象字段很少，仍是建議採用JSON轉String方式。畢竟redis對存儲字符類型這部分優化很是好。

35：redis的數據淘汰策略
答：緣由：由於redis的內存是有限的，不能無限制的存放緩存內容，因此對於數據要進行相應的策略處理。

策略方式（六種）：

volatile-lru：從已設置過時時間的數據集（server.db[i].expires）中挑選最近最少使用的數據淘汰
volatile-ttl：從已設置過時時間的數據集（server.db[i].expires）中挑選將要過時的數據淘汰
volatile-random：從已設置過時時間的數據集（server.db[i].expires）中任意選擇數據淘汰
allkeys-lru：從數據集（server.db[i].dict）中挑選最近最少使用的數據淘汰
allkeys-random：從數據集（server.db[i].dict）中任意選擇數據淘汰
no-enviction（驅逐）：禁止驅逐數據
36：區別B樹，B-，B+,B*，平衡二叉樹，紅黑樹？
答：

       B樹：二叉樹，每一個結點只存儲一個關鍵字，等於則命中，小於走左結點，大於

走右結點；

       B-樹：多路搜索樹，每一個結點存儲M/2到M個關鍵字，非葉子結點存儲指向關鍵

字範圍的子結點；

       全部關鍵字在整顆樹中出現，且只出現一次，非葉子結點能夠命中；

       B+樹：在B-樹基礎上，爲葉子結點增長鏈表指針，全部關鍵字都在葉子結點

中出現，非葉子結點做爲葉子結點的索引；B+樹老是到葉子結點才命中；

       B*樹：在B+樹基礎上，爲非葉子結點也增長鏈表指針，將結點的最低利用率

從1/2提升到2/3；

關於B，B-,B+,B*樹的總結文章

關於紅黑樹的總結文章

B樹只可以進行隨機檢索，而B+樹支持隨機檢索和順序檢索。

37：Java鎖的類型
答：（1）公平鎖/非公平鎖

（2）可重入鎖

（3）獨享鎖/共享鎖

（4）互斥鎖/讀寫鎖

（5）樂觀鎖/悲觀鎖------這個hibernate中用到不少

（6）分段鎖------這個就是concurrentHashMap底層相對HashMap線程安全的地方的實現原理

（7）自旋鎖-------這個就是原子類（好比AstomicInteger類）的底層CAS的實現

（8）偏向鎖/輕量級鎖/重量級鎖

參考本篇文章：Java中各類不一樣鎖的類型

38：Java併發編程中的countDownLatch，CyliBarry（柵欄），semaphor（信號量），Exchanger（線程數據交換）這四個對象，另外還有對Runable和Callabel兩個接口瞭解和區別及其Future和FutureTask瞭解，和線程池Excutor對象中的excute（）和submit（）方法的區別。
答：這幾個對象都是在java併發包中的，針對不一樣的併發問題進行的解決辦法，因此要對上面的進行了解

其中的兩個接口也是須要進行掌握的，還有就是線程池的那兩個方法都是有不一樣的區別。

39：數據庫主從配置
答：（1）如何進行配置的話就很少說

（2）在使用主從配置的實踐項目中，有幾種方法進行主從數據庫的使用：

方法一：採用中間件來進行主從數據庫的切換選擇，好比使用阿里開源的mycat，和360開源的atalas，都是在主數據庫中進行配置好，就行了，經過這樣的方式進行的話，比較方便。

方法二：就是經過在spring配置中，首先配置好主從數據庫的配置xml內容，而後經過AOP機制來進行判斷註解的形式，來採起主從數據庫的選擇。這種方法是經過代碼來進行完成的。能夠參考下面的這篇文章。Spring如何採起主從數據庫的實施

40：Java中的動態代理
答：（1）靜態代理（2）JDK動態代理（3）cglib動態代理

41：Maven常見的依賴範圍(scope)有哪些？
答：（1）compile:編譯依賴，默認的依賴方式，在編譯（編譯項目和編譯測試用例），運行測試用例，運行（項目實際運行）三個階段都有效，典型地有spring-core等jar。
（2）test:測試依賴，只在編譯測試用例和運行測試用例有效，典型地有JUnit。
（3）provided:對於編譯和測試有效，不會打包進發布包中，典型的例子爲servlet-api,通常的web工程運行時都使用容器的servlet-api。
（4）runtime:只在運行測試用例和實際運行時有效，典型地是jdbc驅動jar包。
（5）system: 不從maven倉庫獲取該jar,而是經過systemPath指定該jar的路徑。
（6）import: 用於一個dependencyManagement對另外一個dependencyManagement的繼承。

42：Maven中dependencyManagement和dependency的區別。
dependencies：

就算在子項目中不寫該依賴項，那麼子項目仍然會從父項目中繼承該依賴項（所有繼承）

dependencyManagement：

只是聲明依賴，並不實現引入，所以子項目須要顯示聲明須要用的依賴。若是不在子項目中聲明依賴，是不會從父項目中繼承下來的；只有在子項目中寫了該依賴項，而且沒有指定具體版本，纔會從父項目中繼承該項，而且version和scope都讀取自父pom;另外若是子項目中指定了版本號，那麼會使用子項目中指定的jar版本

43：Maven配置多倉庫的方法
答：（1）能夠配置多個mirror鏡像，可是這樣很差，若是在某環境不可用時，maven下載jar速度變得很慢；

（2）能夠增長repository標籤，經過在裏面加入url指定倉庫地址便可，這樣就不會影響原來的倉庫結構；

（3）配置本地倉庫----》經過localRepostitory標籤和中央倉庫-----》經過mirror標籤，通常國內都是使用阿里的鏡像，訪問快，結合的方式；

44：Maven項目進行分模塊開發的做用
答：非模塊化的缺點：

（1）首先build整個項目的時間愈來愈長，儘管你一直在web層工做，但你不得不build整個項目

（2）模塊化體現不出來，若是咱們只負責維護某個模塊，由於咱們全部的模塊都在一個war包中，那麼咱們能夠隨意修改其餘模塊（權限的控制），致使版本管理混亂，衝突。同時由於模塊太多，太大，很差維護。
不少人都在同時修改這個war包，將致使工做沒法順利進行。
（3）pom.xml原本是能夠繼承、複用的，可是若是咱們新建一個項目，只能依賴於這個war包，那麼會把這個war包的相關的前臺的東西依賴過來，致使項目管理混亂。

（4）項目管理複雜，由於文件包含過多，不利於項目不一樣成員之間的分塊開發；

模塊化的優勢：

(1)方便重用，好比以前開發了一個學生線，那麼當咱們再開發一條teacher線的時候，咱們只須要引用兩條線之間共有的模塊，這些包都是複用的，稱爲咱們平臺複用的基礎類庫，供全部的項目使用。這是模塊化最重要的一個目的。
(2)靈活性。好比咱們這些公共的jar包，當不須要的時候，能夠直接deploy到nexus，其餘人從這個nexus私服下載就能夠了，代碼的可維護性、可擴展性好，而且保證了項目獨立性與完整性。
(3)開發效率提升。經過不一樣的模塊進行分開開發，各個模塊小組能夠併發開發，相似「高內聚，低耦合」的模式，而不須要進行基礎模塊開發，提供了工做效率。

45：wait和notify的內容和實現生產者消費者模型
答：參考這篇文章   生產者消費者

還有就是wait方法爲何要放在while語句中進行循環判斷，而不是用if來進行條件判斷的緣由，很重要，能夠參考這篇文章

爲何wait方法須要放在while語句後面的詳解

46：JVM的內存結構
答：（1）棧（2）堆）（3）方法區（4）本地棧（5）程序計算器

堆區分爲：新生代（複製方法清理）和老年代（標記--整理方法）；新生代又分爲Eden和Surior區（這裏面又分爲From space和To space），其二者內存空間的比例是8:1；

47：Minor GC 觸發 和Full GC的觸發條件
答：Mirror GC 觸發條件：

（1）當Eden區滿的時候，就會觸發Mirror GC

Full GC 觸發條件：

（1）當調用System.gc（）的方法

（2）當老年代的內容不足

（3）當方法區的內容不足

（4）當從Eden區的對象進入到老年代的內存大於老年代剩餘的大小

（5）當從Eden區和From space 區的對象複製到To Space 空間的時候，而To space空間的大小不夠存放，則會轉存到老年代，而此時老年代的內存大小不足，這時候也會觸發Full GC

（6）dump內存的時候：好比，經過jmap工具dump內存的時候，先進行full gc 再開始dump

48：JVM中的GC（垃圾回收）的機制
答：

（1）如何判斷一個對象是否可以被清除
方法一：引用計數法（實現簡單，可是沒法解決循環引用的問題）

      在java中是經過引用來和對象進行關聯的，也就是說若是要操做對象，必須經過引用來進行。那麼很顯然一個簡單的辦法就是經過引用計數來判斷一個對象是否能夠被回收。不失通常性，若是一個對象沒有任何引用與之關聯，則說明該對象基本不太可能在其餘地方被使用到，那麼這個對象就成爲可被回收的對象了。

方法二：可達性分析：

     在Java中採起了 可達性分析法。該方法的基本思想是經過一系列的「GC Roots」對象做爲起點進行搜索，若是在「GC Roots」和一個對象之間沒有可達路徑，則稱該對象是不可達的，不過要注意的是被斷定爲不可達的對象不必定就會成爲可回收對象。被斷定爲不可達的對象要成爲可回收對象必須至少經歷兩次標記過程，若是在這兩次標記過程當中仍然沒有逃脫成爲可回收對象的可能性，則基本上就真的成爲可回收對象了。

備註----兩次標記的過程詳細：
對於用可達性分析法搜索不到的對象，GC並不必定會回收該對象。要徹底回收一個對象，至少須要通過兩次標記的過程。

第一次標記：對於一個沒有其餘引用的對象，篩選該對象是否有必要執行finalize()方法，若是沒有執行必要，則意味可直接回收。（篩選依據：是否複寫或執行過finalize()方法；由於finalize方法只能被執行一次）。
第二次標記：若是被篩選斷定位有必要執行，則會放入FQueue隊列，並自動建立一個低優先級的finalize線程來執行釋放操做。若是在一個對象釋放前被其餘對象引用，則該對象會被移除FQueue隊列。
（2）要準確理解Java的垃圾回收機制，就要從：「何時」，「對什麼東西」，「作了什麼」三個方面來具體分析。
第一：「何時」即就是GC觸發的條件。GC觸發的條件有兩種。（1）程序調用System.gc時能夠觸發；（2）系統自身來決定GC觸發的時機。
系統判斷GC觸發的依據：根據Eden區和From Space區的內存大小來決定。當內存大小不足時，則會啓動GC線程並中止應用線程。
第二：「對什麼東西」籠統的認爲是Java對象並無錯。可是準確來說，GC操做的對象分爲：經過可達性分析法沒法搜索到的對象和能夠搜索到的對象。對於搜索不到的方法進行標記。
第三：「作了什麼」最淺顯的理解爲釋放對象。可是從GC的底層機制能夠看出，對於能夠搜索到的對象進行復制操做，對於搜索不到的對象，調用finalize()方法進行釋放。
具體過程：當GC線程啓動時，會經過可達性分析法把Eden區和From Space區的存活對象複製到To Space區，而後把Eden Space和From Space區的對象釋放掉。當GC輪訓掃描To Space區必定次數後，把依然存活的對象複製到老年代，而後釋放To Space區的對象。

49：JVM中GC的清理方法
答：（1）標記--清除：優勢：簡單   缺點：容易生成不少的內存碎片

（2）複製：這是堆中的新生代中使用的方法；   優勢：減小了內容碎片，而且很是高效      缺點：使得內存的空間大小被分紅多個塊，每次使用的內存大小減小

（3）標記--整理：這是堆中的老年代中使用的方法；

（4）分代收集：也就是把堆分爲新生代和老年代，而後再使用上面的三種方法中的不一樣方法，這種方法也是目前用得最多的方法；

50：JVM中的GC收集器
答：（1）對於新生代：

1：Serial收集器
2：ParNew收集器
3：Parallel Scavenge收集器
（2）對於老年代：
1：Serial Old收集器
2：Parallel Old收集器

3：CMS收集器         4：G1收集器

關於JVM中的垃圾收集器的介紹

關於JVM介紹很是好的文章（1）

關於JVM中的GC觸發條件的文章