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觸發條件的文章

51:
---------------------
作者:Cs_hnu_scw
來源:CSDN
原文:https://blog.csdn.net/Cs_hnu_scw/article/details/79426142
版權聲明:本文為博主原創文章,轉載請附上博文鏈接!


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM