轉發面試要看 (兩到三年)Java 面試精髓

1.Struts2框架的執行流程 ?

從客戶端發送請求過來,先通過前端控制器（核心過濾器）過濾器中,執行一組攔截器（一組攔截器 就會完成部分功能代碼）執行目標Action,

在Action中返回一個結果視圖,根據Result的配置進行頁面的跳轉.

Struts2和Struts1沒有任何聯繫.Struts2內核是webwork的內核.

2.hibernate框架的理解?

定義:

Hibernate是一個開放源代碼的對象關係映射（ORM）框架，它對JDBC進行了很是輕量級的對象封裝，

使得Java程序員能夠爲所欲爲的使用對象編程思惟來操縱數據庫.能夠經過對象保存到關係型數據庫中,僅提供sava/get方法便可

Hibernate是一個持久層的ORM框架.

3.Spring框架的理解?

Spring是一個開源框架,核心是控制反轉（IOC編程思想）和麪向切面（AOP）。簡單來講，Spring是一個分層的JavaSE/EEfull-stack(一站式) 輕量級開源框架

Spring的AOP的理解:經過預編譯方式和運行期動態代理實現程序功能的統一維護的一種技術,利用AOP能夠對業務邏輯的各個部分進行隔離，從而使得業務邏輯各部分之間的耦合度下降，提升程序的可重用性，同時提升了開發的效率.能夠在不修改源代碼的前提下，對程序進行加強.

例如:在之前配置事務的時候,進行事務的回滾,提交等操做,配置AOP 之後能夠將事務的權限交給Spring框架去管理,自動管理

4.SpringMVC的理解?

springMvc:是一個表現層框架,就是從請求中接收傳入的參數,

將處理後的結果數據返回給頁面展現

基本類型:string,double,float,integer,long.boolean

5.Mybatis的理解?

MyBatis是一個優秀的持久層框架，它對jdbc的操做數據庫的過程進行封裝，使開發者只須要關注 SQL 自己，而不須要花費精力去處理例如註冊驅動、建立connection、建立statement、手動設置參數、結果集檢索等jdbc繁雜的過程代碼。

Mybatis經過xml或註解的方式將要執行的各類statement（statement、preparedStatement、CallableStatement）配置起來，並經過java對象和statement中的sql進行映射生成最終執行的sql語句，最後由mybatis框架執行sql並將結果映射成java對象並返回。

#{}能夠有效防止sql注入

6.Servlet的理解?

* GET和POST區別?

* GET：請求參數會顯示到地址欄.GET方式有大小的限制.GET方式沒有請求體

* POST：請求參數不會顯示到地址欄.在請求體中.POST沒有大小限制.POST方式有請求體.

* 只有表單設置爲method=」post」纔是post請求.其餘的都是get請求

生命週期:客戶端第一次訪問該Servlet的時候纔會建立一個Servlet的對象,那麼Servlet中的init方法就會執行.任何一次從客戶端發送的請求,那麼服務器建立一個新的線程執行Servlet中service方法爲此次請求服務.

service方法的內部根據請求的方式的不一樣調用不一樣doXXX的方法.當Servlet從服務器中移除或者關閉服務器的時候Servlet對象就會被銷燬.destroy的方法就會執行.

7.Struts2與SpringMVC的區別?

1)springmvc的入口是一個servlet即前端控制器，而struts2入口是一個filter過慮器。

2)springmvc是基於方法開發(一個url對應一個方法)，請求參數傳遞到方法的形參，能夠設計爲單例或多例(建議單例)，struts2是基於類開發，傳遞參數是經過類的屬性，只能設計爲多例。

3)Struts採用值棧存儲請求和響應的數據，經過OGNL存取數據， springmvc經過參數解析器是將request請求內容解析，並給方法形參賦值，將數據和視圖封裝成ModelAndView對象，最後又將ModelAndView中的模型數據經過reques域傳輸到頁面。Jsp視圖解析器默認使用jstl。

8.Jsp的核心及核心標籤?

a) Servlet

b) Core XML Database Funcations

9.Redis什麼狀況下使用，redis持久化方案?

a) 處理大數據量的時候

b) Redis的全部數據都是保存在內存中，

Rdb：快照形式，按期把內存中當前時刻的數據保存到磁盤，redis默認支持的持久化方案

aof形式：append only file。把全部對redis數據庫操做的命令，增刪改操做命令，保存到文件中，數據庫恢復是把全部命令執行一遍便可。

10.Hibernate和Mybatis的區別和優劣?

a) Sql優化方面：hibernate的查詢會將表中全部的字段查詢出來，這一點會有性能的消耗

Mybatis的sql是手動編寫的，因此能夠按需求指定查詢的字段，sql會更靈活，可控性更好

b) Hibernate是在JDBC上進行了一次封裝

Mybatis是基於原生的JDBC，運行速度有優點

c) Mybatis mapper xml支持動態sql；Hibernate不支持

d) Hibernate與具體數據庫的關聯只需在xml文件中配置便可，全部hql語句與具體的數據庫無關，移植性好

Mybatis項目全部的sql語句都是依賴所用的數據庫的，因此不一樣數據庫類型的支持很差

11.StringBuffer、StringBuilder的區別?

StringBuffer、StringBuilder是容器，是可變的字符串序列，存放於堆內存。

StringBuffer是JDK1.0版本的，線程是安全的，效率比較低。StringBuilder是JDK1.5出現的，線程不安全，效率高。

12.說一下SOLR?

solr就是一箇中文搜索引擎,作完分詞以後會作熱度排名,核心是中文分詞器,全文搜索支持,索引值指向對應的文檔,至關因而一個字典,默認爲collection的一個域對象,查詢快,效率高.

能夠在Redis裏作分詞以後的緩存,每次搜索一次就次數加一,裏面還有一個投票容錯機制,主機掛掉還有備份機,通常配置都爲奇數態配置.

13.Solr與Lucene的區別?

Lucene是一個開放源代碼的全文檢索引擎工具包，它不是一個完整的全文檢索引擎，Lucene提供了完整的查詢引擎和索引引擎，目的是爲軟件開發人員提供一個簡單易用的工具包，以方便的在目標系統中實現全文檢索的功能，或者以Lucene爲基礎構建全文檢索引擎。

Solr的目標是打造一款企業級的搜索引擎系統，它是一個搜索引擎服務，能夠獨立運行，經過Solr能夠很是快速的構建企業的搜索引擎，經過Solr也能夠高效的完成站內搜索功能。

14.什麼是Redis?

1) Redis的高性能是因爲其將全部數據都存儲在了內存中，爲了使Redis在重啓以後仍能保證數據不丟失，須要將數據從內存中同步到硬盤中，這一過程就是持久化。

Redis支持兩種方式的持久化，一種是RDB方式，一種是AOF方式。能夠單獨使用其中一種或將兩者結合使用。

1.1RDB持久化

RDB方式的持久化是經過快照（snapshotting）完成的，當符合必定條件時Redis會自動將內存中的數據進行快照並持久化到硬盤。

每次進行訪問進行存儲,若是服務器一旦崩潰,會致使數據丟失

RDB是Redis默認採用的持久化方式，在redis.conf配置文件中默認有此下配置：

save 900 1 , save 300 10, save 60 10000

save 開頭的一行就是持久化配置，能夠配置多個條件（每行配置一個條件），每一個條件之間是「或」的關係，「save 900 1」表示15分鐘（900秒鐘）內

至少

1個鍵被更改則進行快照，「save 300 10」表示5分鐘（300秒）內至少10個鍵被更改則進行快照。

在redis.conf中：

配置dir指定

rdb快照文件的位置;配置dbfilenam指定rdb快照文件的名稱

Redis啓動後會讀取RDB快照文件，將數據從硬盤載入到內存。根據數據量大小與結構和服務器性能不一樣，這個時間也不一樣。

一般將記錄一千萬個字符串類型鍵、大小爲1GB的快照文件載入到內存中須要花費20～30秒鐘。

問題總結：

經過RDB方式實現持久化，一旦Redis異常退出，就會丟失最後一次快照之後更改的全部數據。這就須要開發者根據具體的應用場合，經過組合設置自動快照條件的方式來將可能發生的數據損失控制在可以接受的範圍。若是數據很重要以致於沒法承受任何損失，則能夠考慮使用AOF方式進行持久化。

1.2AOF持久化

默認狀況下Redis沒有開啓AOF（append only file）方式的持久化，訪問一段存儲一段,效率高.

能夠經過appendonly參數開啓：appendonly yes開啓AOF持久化後每執行一條會更改Redis中的數據的命令，Redis就會將該命令寫入硬盤中的AOF文件

AOF文件的保存位置和RDB文件的位置相同，都是經過dir參數設置的，默認的文件名是appendonly.aof，能夠經過appendfilename參數修改：appendfilename appendonly.aof

2)主從複製（瞭解）

2.1什麼是主從複製

持久化保證了即便redis服務重啓也會丟失數據，由於redis服務重啓後會將硬盤上持久化的數據恢復到內存中，可是當redis服務器的硬盤損壞了可能會致使數據丟失，若是經過redis的主從複製機制就能夠避免這種單點故障，以下圖：

說明：

n主redis中的數據有兩個副本（replication）即從redis1和從redis2，即便一臺redis服務器宕機其它兩臺redis服務也能夠繼續提供服務。

n主redis中的數據和從redis上的數據保持實時同步，當主redis寫入數據時經過主從複製機制會複製到兩個從redis服務上。

n只有一個主redis，能夠有多個從redis。

n主從複製不會阻塞master，在同步數據時，master 能夠繼續處理client 請求

n一個redis能夠便是主又是從，以下圖：

2.2主從配置

2.2.1主redis配置

無需特殊配置。

2.2.2從redis配置

修改從redis服務器上的redis.conf文件，添加slaveof 主redisip主redis端口

 

上邊的配置說明當前該從redis服務器所對應的主redis是192.168.101.3，端口是6379

2.3主從複製過程

2.3.1完整複製

在redis2.8版本以前主從複製過程以下圖：

複製過程說明：

一、slave 服務啓動，slave 會創建和master 的鏈接，發送sync 命令。

二、master啓動一個後臺進程將數據庫快照保存到RDB文件中

注意：此時若是生成RDB文件過程當中存在寫數據操做會致使RDB文件和當前主redis數據不一致，因此此時master 主進程會開始收集寫命令並緩存起來。

三、master 就發送RDB文件給slave

四、slave 將文件保存到磁盤上，而後加載到內存恢復

五、master把緩存的命令轉發給slave

注意：後續master 收到的寫命令都會經過開始創建的鏈接發送給slave。

當master 和slave 的鏈接斷開時slave 能夠自動從新創建鏈接。若是master 同時收到多個slave 發來的同步鏈接命令，只會啓動一個進程來寫數據庫鏡像，而後發送給全部slave。

完整複製的問題：

在redis2.8以前從redis每次同步都會從主redis中複製所有的數據，若是從redis是新建立的從主redis中複製所有的數據這是沒有問題的，可是，若是當從redis中止運行，再啓動時可能只有少部分數據和主redis不一樣步，此時啓動redis仍然會從主redis複製所有數據，這樣的性能確定沒有隻複製那一小部分不一樣步的數據高。

2.3.2部分複製

部分複製說明：

從機鏈接主機後，會主動發起 PSYNC 命令，從機會提供 master的runid(機器標識，隨機生成的一個串) 和 offset（數據偏移量，若是offset主從不一致則說明數據不一樣步），主機驗證 runid 和 offset 是否有效， runid 至關於主機身份驗證碼，用來驗證從機上一次鏈接的主機，若是runid驗證未經過則，則進行全同步，若是驗證經過則說明曾經同步過，根據offset同步部分數據。

2)redis是一個nosql(not only sql不只僅只有sql)數據庫.翻譯成中文叫作非關係型型數據庫.

關係型數據庫:以二維表形式存儲數據

非關係型數據庫: 以鍵值對形式存儲數據(key, value形式)

Redis是用C語言開發的一個開源的高性能鍵值對（key-value）數據庫。它經過提供多種鍵值數據類型來適應不一樣場景下的存儲需求，

目前爲止Redis支持的鍵值數據類型以下：

字符串類型

散列類型

列表類型

集合類型

有序集合類型。

3)redis的應用場景

緩存（數據查詢、短鏈接、新聞內容、商品內容等等）。（最多使用）

分佈式集羣架構中的session分離。

聊天室的在線好友列表。

任務隊列。（秒殺、搶購、12306等等）

應用排行榜。

網站訪問統計。

數據過時處理（能夠精確到毫秒）

redis是將數據存放到內存中,因爲內容存取速度快因此redis被普遍應用在互聯網項目中,

redis有點:存取速度快,官方稱讀取速度會達到30萬次每秒,寫速度在10萬次每秒最有,具體限制於硬件.

缺點:對持久化支持不夠良好,

因此redis通常不做爲數據的主數據庫存儲,通常配合傳統的關係型數據庫使用.

4) redis應用領域

分佈式緩存

分佈式session

保存博客或者論壇的留言回覆等.

總之是用在數據量大,併發量高的狀況下

15.談下DUBBO?

Dubbo就是資源調度和治理中心的管理工具。

調用關係說明：

0. 服務容器負責啓動，加載，運行服務提供者。

1. 服務提供者在啓動時，向註冊中心註冊本身提供的服務。

2. 服務消費者在啓動時，向註冊中心訂閱本身所需的服務。

3. 註冊中心返回服務提供者地址列表給消費者，若是有變動，註冊中心將基於長鏈接推送變動數據給消費者。

4. 服務消費者，從提供者地址列表中，基於軟負載均衡算法，選一臺提供者進行調用，若是調用失敗，再選另外一臺調用。

5. 服務消費者和提供者，在內存中累計調用次數和調用時間，定時每分鐘發送一次統計數據到監控中心。

16.解決跨域問題?

JSONP-->Script Tags

17.秒殺方案：

一、把商品的數量放到redis中。

二、秒殺時使用decr命令對商品數量減一。若是不是負數說明搶到。

三、一旦返回數值變爲0說明商品已售完。

18.ZOOKeeper?

Zookeeper 做爲一個分佈式的服務框架，主要用來解決分佈式集羣中應用系統的一致性問題，它能提供基於相似於文件系統的目錄節點樹方式的數據存儲，可是 Zookeeper 並非用來專門存儲數據的，它的做用主要是用來維護和監控你存儲的數據的狀態變化。

經過監控這些數據狀態的變化，從而能夠達到基於數據的集羣管理

註冊中心負責服務地址的註冊與查找，至關於目錄服務，服務提供者和消費者只在啓動時與註冊中心交互，註冊中心不轉發請求，壓力小。使用dubbo-2.3.3以上版本，建議使用zookeeper註冊中心。

Zookeeper是Apacahe Hadoop的子項目，是一個樹型的目錄服務，支持變動推送，適合做爲Dubbo服務的註冊中心，工業強度較高，可用於生產環境，並推薦使用

19.ActiveMQ的消息形式

一種是點對點的，即一個生產者和一個消費者一一對應；可進行緩存,只容許單人登陸查看

另外一種是發佈/訂閱模式，即一個生產者產生消息並進行發送後，能夠由多個消費者進行接收。沒法進行緩存,支持多人訪問.

JMS定義了五種不一樣的消息正文格式，以及調用的消息類型，容許你發送並接收以一些不一樣形式的數據，提供現有消息格式的一些級別的兼容性。

StreamMessage -- Java原始值的數據流

MapMessage--一套名稱-值對

TextMessage--一個字符串對象

ObjectMessage--一個序列化的 Java對象

BytesMessage--一個字節的數據流

 

1.訂單系統

1.1.功能分析

一、在購物車頁面點擊「去結算」按鈕跳轉到訂單確認頁面。

a)展現商品列表

b)配送地址列表

c)選擇支付方式

二、展現訂單確認頁面以前，應該確認用戶身份。

a)使用攔截器實現。

b)Cookie中取token

c)取不到token跳轉到登陸頁面

d)取到token，根據token查詢用戶信息。

e)若是沒有用戶信息，登陸過時跳轉到登陸頁面

f)取到用戶信息，放行。

三、提交訂單

a)生成訂單

b)展現訂單提交成功頁面。

訂單系統系統：訂單確認頁面、訂單提交成功頁面。

訂單服務系統

1.1.展現訂單確認頁面

1.1.1.功能分析

一、在購物車頁面點擊「去結算」按鈕跳轉到訂單確認頁面。

二、請求的url：

 

/order/order-cart

三、參數：沒有參數。

四、購物車商品數據從cookie中取出來的。能夠在訂單系統中取到cookie中的購物車數據。

五、配送地址列表，須要用戶登陸。須要根據用戶id查詢收貨地址列表。靜態數據。

六、支付方式。靜態數據。

七、返回值：邏輯視圖String，展現訂單確認頁面。

1.1.2.Dao層、Service層（沒有）

須要根據用戶id查詢收貨地址列表。沒有此功能。

1.1.3.表現層

請求的url：/order/order-cart

參數：無

業務邏輯：

從cookie中取商品列表展現到頁面。

返回值：邏輯視圖。

1.1.用戶身份認證

在展現訂單確認頁面以前，須要對用戶身份進行認證，要求用戶必須登陸。

1.1.1.功能分析

一、使用springmvc的攔截器實現。須要實現一個接口HandlerInterceptor接口。

二、業務邏輯

a)從cookie中取token。

b)沒有token，須要跳轉到登陸頁面。

c)有token。調用sso系統的服務，根據token查詢用戶信息。

d)若是查不到用戶信息。用戶登陸已通過期。須要跳轉到登陸頁面。

e)查詢到用戶信息。放行。

三、在springmvc.xml中配置攔截器。

1.1.2.攔截器實現

1.1.1.功能分析

一、在訂單確認頁面點擊「提交訂單」按鈕生成訂單。

二、請求的url：/order/create

三、參數：提交的是表單的數據。保存的數據：訂單、訂單明細、配送地址。

a)向tb_order中插入記錄。

i.訂單號須要手動生成。

要求訂單號不能重複。

訂單號可讀性號。

可使用redis的incr命令生成訂單號。訂單號須要一個初始值。

ii.Payment：表單數據

iii.payment_type：表單數據

iv.user_id：用戶信息

v.buyer_nick：用戶名

vi.其餘字段null

b)向tb_order_item訂單明細表插入數據。

i.Id：使用incr生成

ii.order_id：生成的訂單號

iii.其餘的都是表單中的數據。

c)tb_order_shipping，訂單配送信息

i.order_id：生成的訂單號

ii.其餘字段都是表單中的數據。

d)使用pojo接收表單的數據。

能夠擴展TbOrder，在子類中添加兩個屬性一個是商品明細列表，一個是配送信息。

把pojo放到taotao-order-interface工程中。

業務邏輯：

一、接收表單的數據

二、生成訂單id

三、向訂單表插入數據。

四、向訂單明細表插入數據

五、向訂單物流表插入數據。

六、返回TaotaoResult。

返回值：TaotaoResult

1.1.1.Dao層

可使用逆向工程。

1.1.2.Service層

參數：OrderInfo

19.單點登陸

單點登陸就是咱們是作了分佈式，tomcat集羣以後會有session複製的問題，影響利羣數量。因此把註冊登陸拿出來單獨作了一個單點登陸系統。作的時候是用的redis，key是用uuid生成的一個token,相似於session id,是用戶的惟一標識，value是用戶的信息。設置了有效期是7天。而後把redis放到了cookie中，實現了cookie的二級跨域。當咱們進行操做時，首先要從cookie裏面取出token若是取不到，就跳到單點登陸系統進行登陸操做若是取到了，再看看token有沒有過時，若是過時了，也是跳到單點登陸系統登陸一下，沒過時就繼續用戶的操做。密碼進行了加密，用Md5