Java模擬面試總結(jié)
下面是針對(duì)一系列模擬面試后的情況進(jìn)行面試題的總結(jié)和梳理，希望對(duì)大家有所幫助：
1、SpringBoot的啟動(dòng)類(lèi)？
@SpringBootApplication{@SpringBootConfiguration（標(biāo)識(shí)配置類(lèi)）、@EnableAutoConfiguration(自動(dòng)配置基于@import)、@ComponentScan (掃描路徑設(shè)置)}
啟動(dòng)流程：
第一部分進(jìn)行SpringApplication的初始化模塊，配置一些基本的環(huán)境變量、資源、構(gòu)造器、監(jiān)聽(tīng)器，第二部分實(shí)現(xiàn)了應(yīng)用具體的啟動(dòng)方案，包括啟動(dòng)流程的監(jiān)聽(tīng)模塊、加載配置環(huán)境模塊、及核心的創(chuàng)建上下文環(huán)境模塊，第三部分是自動(dòng)化配置模塊，該模塊作為springboot自動(dòng)配置核心
SpringTestApplication類(lèi)執(zhí)行main方法，main方法調(diào)用SpringApplication的run方法。
run方法干了兩件事：
創(chuàng)建SpringApplication對(duì)象
利用創(chuàng)建好的SpringApplication對(duì)象調(diào)用run方法
2、數(shù)據(jù)庫(kù)的底層結(jié)構(gòu)是？是如何實(shí)現(xiàn)存儲(chǔ)的？
B+樹(shù)；
3、Mybatis是如何防止Sql注入的？
#{}是經(jīng)過(guò)預(yù)編譯的，是安全的；${}是未經(jīng)過(guò)預(yù)編譯的，僅僅是取變量的值，是非安全的，存在SQL注入
4、HashMap的容量長(zhǎng)度？ 擴(kuò)充機(jī)制？ 容量必須是2的冪
默認(rèn)值 16；當(dāng)我們不斷的向HashMap中添加元素時(shí)，它會(huì)判斷HashMap當(dāng)前的容量值(當(dāng)前元素的個(gè)數(shù))是否超過(guò)了它的臨界值（在沒(méi)有指定其初始化大小時(shí)，默認(rèn)16*0.75=12），如果添加的元素個(gè)數(shù)超過(guò)了臨界值，它就會(huì)開(kāi)始進(jìn)行擴(kuò)容。
5、多線程的實(shí)現(xiàn)方式
繼承Thread類(lèi)創(chuàng)建線程、實(shí)現(xiàn)Runnable接口創(chuàng)建線程、實(shí)現(xiàn)Callable接口通過(guò)FutureTask包裝器來(lái)創(chuàng)建Thread線程
6、Redis Sentinel（哨兵機(jī)制）是怎么工作的？重點(diǎn)描述一下故障轉(zhuǎn)移的過(guò)程？
1）每個(gè)Sentinel以每秒鐘一次的頻率向它所知的Master，Slave以及其他 Sentinel 實(shí)例發(fā)送一個(gè) PING 命令。
2)如果一個(gè)實(shí)例（instance）距離最后一次有效回復(fù) PING 命令的時(shí)間超過(guò) down-after-milliseconds 選項(xiàng)所指定的值， 則這個(gè)實(shí)例會(huì)被當(dāng)前 Sentinel 標(biāo)記為主觀下線。
3)如果一個(gè)Master被標(biāo)記為主觀下線，則正在監(jiān)視這個(gè)Master的所有 Sentinel 要以每秒一次的頻率確認(rèn)Master的確進(jìn)入了主觀下線狀態(tài)。
4)當(dāng)有足夠數(shù)量的 Sentinel（大于等于配置文件指定的值）在指定的時(shí)間范圍內(nèi)確認(rèn)Master的確進(jìn)入了主觀下線狀態(tài)， 則Master會(huì)被標(biāo)記為客觀下線 。
5)當(dāng)Master被 Sentinel 標(biāo)記為客觀下線時(shí)，Sentinel 向下線的 Master 的所有 Slave 發(fā)送 INFO 命令的頻率會(huì)從 10 秒一次改為每秒一次 （在一般情況下， 每個(gè) Sentinel 會(huì)以每 10 秒一次的頻率向它已知的所有Master，Slave發(fā)送 INFO 命令 ）。
6)若沒(méi)有足夠數(shù)量的 Sentinel 同意 Master 已經(jīng)下線， Master 的客觀下線狀態(tài)就會(huì)變成主觀下線。若 Master 重新向 Sentinel 的 PING 命令返回有效回復(fù)， Master 的主觀下線狀態(tài)就會(huì)被移除。
7）sentinel節(jié)點(diǎn)會(huì)與其他sentinel節(jié)點(diǎn)進(jìn)行“溝通”，投票選舉一個(gè)sentinel節(jié)點(diǎn)進(jìn)行故障處理，在從節(jié)點(diǎn)中選取一個(gè)主節(jié)點(diǎn)，其他從節(jié)點(diǎn)掛載到新的主節(jié)點(diǎn)上自動(dòng)復(fù)制新主節(jié)點(diǎn)的數(shù)據(jù)。
7、Redis的持久化機(jī)制？
AOF和RDB;
AOF：記錄每次寫(xiě)請(qǐng)求的命令，以追加的方式在文件尾部追加，直接在尾部追加，效率比較高。 對(duì)于操作系統(tǒng)來(lái)說(shuō)，不是每次寫(xiě)都直接寫(xiě)到磁盤(pán)，操作系統(tǒng)自己會(huì)有一層cache，redis寫(xiě)磁盤(pán)的數(shù)據(jù)會(huì)先緩存在os cache里，redis每隔1秒調(diào)用一次操作系統(tǒng)的fsync操作，強(qiáng)制將os cache中的數(shù)據(jù)刷入AOF文件中。
當(dāng)redis重啟的時(shí)候，就把AOF中記錄的命令重新執(zhí)行一遍就可以了，但是如果文件很大的話，執(zhí)行會(huì)耗費(fèi)較多的時(shí)間，對(duì)于數(shù)據(jù)恢復(fù)來(lái)說(shuō)耗時(shí)會(huì)多一點(diǎn)。
RDB：是快照文件，每隔一定時(shí)間將redis內(nèi)存中的數(shù)據(jù)生成一份完整的RDB快照文件，當(dāng)redis重啟的時(shí)候直接加載數(shù)據(jù)即可，同樣的數(shù)據(jù)比AOF恢復(fù)的要快。
RDB的優(yōu)點(diǎn)：第一點(diǎn)就是他會(huì)生成多個(gè)數(shù)據(jù)文件，每個(gè)數(shù)據(jù)文件都代表了某一時(shí)刻redis中的數(shù)據(jù)，非常適合做冷備。 第二點(diǎn)，RDB持久化機(jī)制對(duì)redis對(duì)外提供的讀寫(xiě)服務(wù)影響非常小，可以讓redis保持高性能，因?yàn)閞edis主進(jìn)程只需要fork一個(gè)子進(jìn)程，讓子進(jìn)程執(zhí)行磁盤(pán)IO操作來(lái)進(jìn)行RDB持久化即可。 第三點(diǎn)，相對(duì)于AOF持久化機(jī)制來(lái)說(shuō)，直接基于RDB數(shù)據(jù)文件來(lái)重啟和恢復(fù)redis進(jìn)程，更加快速。
AOF，存放的指令日志，做數(shù)據(jù)恢復(fù)的時(shí)候，其實(shí)是要回放和執(zhí)行所有的指令日志，來(lái)恢復(fù)出來(lái)內(nèi)存中的所有數(shù)據(jù)的。
RDB，就是一份數(shù)據(jù)文件，恢復(fù)的時(shí)候，直接加載到內(nèi)存中即可。
RBD的缺點(diǎn)：
1）故障時(shí)可能數(shù)據(jù)丟失的比AOF要多。 一般來(lái)說(shuō)，RDB數(shù)據(jù)快照文件，都是每隔5分鐘或者更長(zhǎng)時(shí)間生成一次，這個(gè)時(shí)候一旦redis進(jìn)程宕機(jī)，那么會(huì)丟失最近5分鐘的數(shù)據(jù)。
這個(gè)問(wèn)題，也是rdb最大的缺點(diǎn)，就是不適合做第一優(yōu)先的恢復(fù)方案，如果你依賴RDB做第一優(yōu)先恢復(fù)方案，會(huì)導(dǎo)致數(shù)據(jù)丟失的比較多
2）RDB每次在fork子進(jìn)程來(lái)執(zhí)行RDB快照數(shù)據(jù)文件生成的時(shí)候，如果數(shù)據(jù)文件特別大，可能會(huì)導(dǎo)致對(duì)客戶端提供的服務(wù)暫停數(shù)毫秒，或者甚至數(shù)秒。
所以一般不要讓RDB的間隔太長(zhǎng)，否則每次生成的RDB文件太大了，對(duì)redis本身的性能可能會(huì)有影響的。
AOF的優(yōu)點(diǎn)：
1）AOF可以更好的保護(hù)數(shù)據(jù)不丟失 一般AOF會(huì)每隔1秒，通過(guò)一個(gè)后臺(tái)線程執(zhí)行一次fsync操作，最多丟失1秒鐘的數(shù)據(jù)。
每隔1秒，就執(zhí)行一次fsync操作，保證os cache中的數(shù)據(jù)寫(xiě)入磁盤(pán)中。 redis進(jìn)程掛了，最多丟掉1秒鐘的數(shù)據(jù).
2）AOF持久化性能高 AOF日志文件以Append-only模式寫(xiě)入，所以沒(méi)有任何磁盤(pán)尋址的開(kāi)銷(xiāo)，寫(xiě)入性能非常高，而且文件不容易破損，即使文件尾部破損，也很容易修復(fù)。
3）AOF日志文件即使過(guò)大的時(shí)候，出現(xiàn)后臺(tái)重寫(xiě)操作，也不會(huì)影響客戶端的讀寫(xiě)。 因?yàn)樵趓ewrite log的時(shí)候，會(huì)對(duì)其中的指令進(jìn)行壓縮，創(chuàng)建出一份需要恢復(fù)數(shù)據(jù)的最小日志出來(lái)。在創(chuàng)建新日志文件的時(shí)候，老的日志文件還是照常寫(xiě)入。當(dāng)新的merge后的日志文件ready的時(shí)候，再交換新老日志文件即可。
4）AOF日志文件的命令通過(guò)非?？勺x的方式進(jìn)行記錄，這個(gè)特性非常適合做災(zāi)難性的誤刪除的緊急恢復(fù)。
比如某人不小心用flushall命令清空了所有數(shù)據(jù)，只要這個(gè)時(shí)候后臺(tái)rewrite還沒(méi)有發(fā)生，那么就可以立即拷貝AOF文件，將最后一條flushall命令給刪了，然后再將該AOF文件放回去，就可以通過(guò)恢復(fù)機(jī)制，自動(dòng)恢復(fù)所有數(shù)據(jù)。
AOF的缺點(diǎn)：
（1）對(duì)于同一份數(shù)據(jù)來(lái)說(shuō)，AOF日志文件通常比RDB數(shù)據(jù)快照文件更大
（2）AOF開(kāi)啟后，支持的寫(xiě)QPS會(huì)比RDB支持的寫(xiě)QPS低，因?yàn)锳OF一般會(huì)配置成每秒fsync一次日志文件，當(dāng)然，每秒一次fsync，性能也還是很高的。
如果你要保證一條數(shù)據(jù)都不丟，也是可以的，AOF的fsync設(shè)置成沒(méi)寫(xiě)入一條數(shù)據(jù)，fsync一次，但是那樣導(dǎo)致redis的QPS大幅度下降。
（3）以前AOF發(fā)生過(guò)bug，就是通過(guò)AOF記錄的日志，進(jìn)行數(shù)據(jù)恢復(fù)的時(shí)候，沒(méi)有恢復(fù)一模一樣的數(shù)據(jù)出來(lái)。
所以說(shuō)，類(lèi)似AOF這種較為復(fù)雜的基于命令日志/merge/回放的方式，比基于RDB每次持久化一份完整的數(shù)據(jù)快照文件的方式，更加脆弱一些，容易有bug。不過(guò)AOF就是為了避免rewrite過(guò)程導(dǎo)致的bug，因此每次rewrite并不是基于舊的指令日志進(jìn)行merge的，而是基于當(dāng)時(shí)內(nèi)存中的數(shù)據(jù)進(jìn)行指令的重新構(gòu)建，這樣健壯性會(huì)好很多。
（4）唯一的比較大的缺點(diǎn)，其實(shí)就是做數(shù)據(jù)恢復(fù)的時(shí)候，會(huì)比較慢，做冷備不太合適。
你剛才提到冷備，那你具體說(shuō)說(shuō)為啥AOF不適合RDB適合？
其實(shí)兩個(gè)都可以做，只不過(guò)RDB更適合。
RDB可以做冷備，是因?yàn)樗鼤?huì)生成多個(gè)文件，每個(gè)文件都代表了某一個(gè)時(shí)刻的完整的數(shù)據(jù)快照，我們可以將這種完整的數(shù)據(jù)文件發(fā)送到一些遠(yuǎn)程的安全存儲(chǔ)上去，比如可以是阿里云的ODPS分布式存儲(chǔ)上，以預(yù)定好的備份策略來(lái)定期備份redis中的數(shù)據(jù)。
AOF也可以做冷備，只不過(guò)它只有一個(gè)文件，但是我們可以去自己寫(xiě)程序，每隔一定時(shí)間，去copy一份這個(gè)文件出來(lái)。
RDB做冷備，優(yōu)勢(shì)在于由redis去控制固定時(shí)長(zhǎng)生成快照文件的事情，比較方便，而 AOF，還需要我們自己寫(xiě)一些腳本去做這個(gè)事情，各種定時(shí)，比較麻煩。
RDB數(shù)據(jù)做冷備，在最壞的情況下，提供數(shù)據(jù)恢復(fù)的時(shí)候，速度比AOF快。
8、Spring MVC的主要組件？
（1）前端控制器 DispatcherServlet（不需要程序員開(kāi)發(fā)）
作用：接收請(qǐng)求、響應(yīng)結(jié)果，相當(dāng)于轉(zhuǎn)發(fā)器，有了DispatcherServlet 就減少了其它組件之間的耦合度。
（2）處理器映射器HandlerMApping（不需要程序員開(kāi)發(fā)）
作用：根據(jù)請(qǐng)求的URL來(lái)查找Handler
（3）處理器適配器HandlerAdapter
注意：在編寫(xiě)Handler的時(shí)候要按照HandlerAdapter要求的規(guī)則去編寫(xiě)，這樣適配器HandlerAdapter才可以正確的去執(zhí)行Handler。
（4）處理器Handler（需要程序員開(kāi)發(fā)）
（5）視圖解析器 ViewResolver（不需要程序員開(kāi)發(fā)）
作用：進(jìn)行視圖的解析，根據(jù)視圖邏輯名解析成真正的視圖（view）
（6）視圖View（需要程序員開(kāi)發(fā)jsp）
View是一個(gè)接口， 它的實(shí)現(xiàn)類(lèi)支持不同的視圖類(lèi)型（jsp，freemarker，pdf等等）
9、23種設(shè)計(jì)模式
三大類(lèi) ：創(chuàng)建型模式、結(jié)構(gòu)型模式、行為型模式；
創(chuàng)建型模式：共5種：工廠方法模式、抽象工廠模式、單例模式、建造者模式、原型模式
結(jié)構(gòu)型模式：共七種：適配器模式、裝飾器模式、代理模式、外觀模式、橋接模式、組合模式、享元模式。
行為型模式：共十一種：策略模式、模板方法模式、觀察者模式、迭代子模式、責(zé)任鏈模式、命令模式、備忘錄模式、狀態(tài)模式、訪問(wèn)者模式、中介者模式、解釋器模式。
10、Spring MVC的工作流程
（1）用戶發(fā)送請(qǐng)求至前端控制器DispatcherServlet； （2） DispatcherServlet收到請(qǐng)求后，調(diào)用HandlerMApping處理器映射器，請(qǐng)求獲取Handle； （3）處理器映射器根據(jù)請(qǐng)求url找到具體的處理器，生成處理器對(duì)象及處理器攔截器(如果有則生成)一并返回給DispatcherServlet； （4）DispatcherServlet 調(diào)用 HandlerAdapter處理器適配器； （5）HandlerAdapter 經(jīng)過(guò)適配調(diào)用 具體處理器(Handler，也叫后端控制器)； （6）Handler執(zhí)行完成返回ModelAndView； （7）HandlerAdapter將Handler執(zhí)行結(jié)果ModelAndView返回給DispatcherServlet； （8）DispatcherServlet將ModelAndView傳給ViewResolver視圖解析器進(jìn)行解析； （9）ViewResolver解析后返回具體View； （10）DispatcherServlet對(duì)View進(jìn)行渲染視圖（即將模型數(shù)據(jù)填充至視圖中） （11）DispatcherServlet響應(yīng)用戶
11、MySQL優(yōu)化
主要從4個(gè)方面
設(shè)計(jì)：存儲(chǔ)引擎，字段類(lèi)型，范式與逆范式
功能：索引，緩存，分庫(kù)分表。
架構(gòu)：主從復(fù)制，讀寫(xiě)分離，負(fù)載均衡。
合理SQL：測(cè)試，經(jīng)驗(yàn)
12、SpringBoot整合
創(chuàng)建工程環(huán)境。
配置數(shù)據(jù)庫(kù)連接信息。這里使用yml方式。spring: datasource: username: root url: …
編寫(xiě)實(shí)體類(lèi)。
編寫(xiě)MApper接口類(lèi)
13、Redis如何使用？
啟動(dòng)redis 、配置redis的數(shù)據(jù)庫(kù)連接、編寫(xiě)redis操作工具類(lèi)、測(cè)試
14、Redis是什么？應(yīng)用場(chǎng)景？如何實(shí)現(xiàn)同步？
非關(guān)系型數(shù)據(jù)庫(kù)，C編寫(xiě)的， key,value鍵值對(duì)數(shù)據(jù)庫(kù) 數(shù)據(jù)存儲(chǔ)在內(nèi)存中 讀寫(xiě)快。
優(yōu)點(diǎn)：讀寫(xiě)快，支持?jǐn)?shù)據(jù)持久化，數(shù)據(jù)結(jié)構(gòu)豐富，
缺點(diǎn)：容易受到物理內(nèi)存的限制，不能作為海量數(shù)據(jù)的高性能讀寫(xiě) ，不具備容錯(cuò)和恢復(fù)功能。
適應(yīng)場(chǎng)景在較小的數(shù)據(jù)量的高性能操作和運(yùn)算上。
15、ES如何保證數(shù)據(jù)不丟失
16、SpringBean的生命周期
實(shí)例化 Instantiation、屬性賦值 Populate、初始化 Initialization、銷(xiāo)毀 Destruction
17、Mybatis的一級(jí)二級(jí)緩存
一級(jí)緩存默認(rèn)開(kāi)啟，查詢時(shí)先從緩存中查詢，緩存中沒(méi)有對(duì)應(yīng)數(shù)據(jù)時(shí)再進(jìn)行數(shù)據(jù)庫(kù)查詢。
二級(jí)緩存即查詢緩存，他的作用于是mApper和namespace，二級(jí)緩存可以跨SqlSession
18、SpringBoot注解？
@RestController表示該方法的返回結(jié)果直接寫(xiě)入HTTP response body中 @RequestMApping 注解 處理請(qǐng)求地址映射
@EnableAutoConfiguration 注解允許 Spring Boot 自動(dòng)配置注解
@Configuration用于定義配置類(lèi)
@SpringBootApplication用在 Spring Boot的主類(lèi)上，標(biāo)識(shí)這是一個(gè) Spring Boot 應(yīng)用，用來(lái)開(kāi)啟 Spring Boot 的各項(xiàng)能力。 @ComponentScan 組件掃描。讓spring Boot掃描到Configuration類(lèi)并把它加入到程序上下文。
@ResponseBody
@Component
@AutoWired
@RequestParam用在方法的參數(shù)前面：
@PathVariable 路徑變量。參數(shù)與大括號(hào)里的名字一樣要相同 @ResponseBody表示該方法的返回結(jié)果直接寫(xiě)入HTTP response body 中
@Repository 用于標(biāo)注數(shù)據(jù)訪問(wèn)組件，即DAO組件
19、 Spring事務(wù)有哪些？
ACID 原子性、一致性、隔離性、持久性
20、 這些事務(wù)的特性有哪些？
原子性（要么全部成功要么全部失敗，不會(huì)結(jié)束在中間某個(gè)環(huán)節(jié)）
一致性（執(zhí)行前和執(zhí)行后數(shù)據(jù)庫(kù)保持在一致性狀態(tài)）
隔離性（數(shù)據(jù)所處的狀態(tài)要么是更改之前的狀態(tài)要么是更改之后的狀態(tài) 不會(huì)看到中間的狀態(tài)數(shù)據(jù)）
持久性（只要事務(wù)成功結(jié)束，那么數(shù)據(jù)庫(kù)的數(shù)據(jù)就會(huì)永久保存下來(lái)，即使數(shù)據(jù)庫(kù)崩潰 重新啟動(dòng)后數(shù)據(jù)庫(kù)還能恢復(fù)到事務(wù)成功結(jié)束的狀態(tài)）
21、數(shù)據(jù)庫(kù)的事務(wù)隔離？怎么實(shí)現(xiàn)的
不考慮事務(wù)的隔離性會(huì)出現(xiàn)幾種：臟讀（在一個(gè)事務(wù)里讀取到領(lǐng)另一個(gè)未提交事務(wù)的數(shù)據(jù)）、不可重復(fù)讀（在一個(gè)事務(wù)范圍內(nèi)多次查詢返回的數(shù)據(jù)不同的數(shù)據(jù)， 發(fā)生在修改）、幻讀（ 前后兩次讀取的數(shù)據(jù)在第二次查詢的時(shí)候能查到都第一次看不到的行數(shù)據(jù)，發(fā)生在插入和刪除 ）
事務(wù)的ACID是通過(guò)InnoDB的日志和鎖來(lái)保證的，事務(wù)的隔離性通
過(guò)數(shù)據(jù)鎖的機(jī)制實(shí)現(xiàn)的
22、RESTful是一種設(shè)計(jì)風(fēng)格而不是規(guī)范，比如接口的命名不以動(dòng)詞命名（如findById deleteById等），不同的請(qǐng)求方式代表了相應(yīng)的動(dòng)作 比如 /user接口 crud操作只需要更換不同的請(qǐng)求方式即可 一個(gè)接口即可搞定 而不需要定義多個(gè)接口
23、MySQL常用的存儲(chǔ)引擎：
InnoDB、MyISAM、MEMORY、ARCHIVE
MyISAM索引與InnoDB索引的區(qū)別？
InnoDB索引是聚簇索引，MyISAM索引是非聚簇索引。
InnoDB的主鍵索引的葉子節(jié)點(diǎn)存儲(chǔ)著行數(shù)據(jù)，因此主鍵索引非常高效。
MyISAM索引的葉子節(jié)點(diǎn)存儲(chǔ)的是行數(shù)據(jù)地址，需要再尋址一次才能得到數(shù)據(jù)。
InnoDB非主鍵索引的葉子節(jié)點(diǎn)存儲(chǔ)的是主鍵和其他帶索引的列數(shù)據(jù)，因此查詢時(shí)做到覆蓋索引會(huì)非常高效。
23.1、InnoDB引擎的4大特性
插入緩沖（insert buffer)、二次寫(xiě)(double write)、自適應(yīng)哈希索引(ahi)、預(yù)讀(read ahead)
23.2、引擎的選擇？
如果要提供提交、回滾、崩潰恢復(fù)能力的事物安全（ACID兼容）能力，并要求實(shí)現(xiàn)并發(fā)控制，InnoDB是一個(gè)好的選擇。
如果數(shù)據(jù)表主要用來(lái)插入和查詢記錄，則MyISAM引擎能提供較高的處理效率。
如果只是臨時(shí)存放數(shù)據(jù)，數(shù)據(jù)量不大，并且不需要較高的數(shù)據(jù)安全性，可以選擇將數(shù)據(jù)保存在內(nèi)存中的Memory引擎，MySQL中使用該引擎作為臨時(shí)表，存放查詢的中間結(jié)果。
如果只有INSERT和SELECT操作，可以選擇Archive，Archive支持高并發(fā)的插入操作，但是本身不是事務(wù)安全的。Archive非常適合存儲(chǔ)歸檔數(shù)據(jù)，如記錄日志信息可以使 Archive。
24、@ResquestBody 和@ResponseBody的區(qū)別？
@ResponseBody注解表示該方法的返回的結(jié)果直接寫(xiě)入 HTTP 響應(yīng)正文中，一般在異步獲取數(shù)據(jù)時(shí)使用。通常是在使用 @RequestMApping 后，返回值通常解析為跳轉(zhuǎn)路徑，加上 @Responsebody 后返回結(jié)果不會(huì)被解析為跳轉(zhuǎn)路徑，而是直接寫(xiě)入HTTP 響應(yīng)正文中。
@RequestBody是作用在形參列表上，用于將前臺(tái)發(fā)送過(guò)來(lái)固定格式的數(shù)據(jù)（xml 格式或者 json等）封裝為對(duì)應(yīng)的 JavaBean 對(duì)象，封裝時(shí)使用到的一個(gè)對(duì)象是系統(tǒng)默認(rèn)配置的 HttpMessageConverter進(jìn)行解析，然后封裝到形參上。
在GET請(qǐng)求中，不能使用@RequestBody。在POST請(qǐng)求，可以使用@RequestBody和@RequestParam，但是如果使用@RequestBody，對(duì)于參數(shù)轉(zhuǎn)化的配置必須統(tǒng)一。
25、為什么使用數(shù)據(jù)庫(kù)？三大范式了解嗎?
1.存取的速度快，數(shù)據(jù)永久保存
2．第一范式：每個(gè)列都不可以再拆分。
第二范式：在第一范式的基礎(chǔ)上，非主鍵列完全依賴于主鍵，而不能是依賴于主鍵的一部分。
第三范式：在第二范式的基礎(chǔ)上，非主鍵列只依賴于主鍵，不依賴于其他非主鍵。
25.1、數(shù)據(jù)庫(kù)中為什么要用索引？這么多優(yōu)點(diǎn)怎么不在每一個(gè)表中的列都使用索引呢 ？
1、可以大大加快數(shù)據(jù)的檢索速度,使用索引，提高系統(tǒng)的性能。
2、時(shí)間上：在每一列上使用索引耗費(fèi)時(shí)間，在使用時(shí)會(huì)降低執(zhí)行效率，
空間上：會(huì)占用物理空間
25.2、你在開(kāi)發(fā)的時(shí)候用到索引了嗎 應(yīng)用場(chǎng)景是？
數(shù)據(jù)量的時(shí)候查詢字段較多的時(shí)候
當(dāng)數(shù)據(jù)多且字段值有相同的值得時(shí)候用普通索引，當(dāng)字段多且字段值沒(méi)有重復(fù)的時(shí)候用唯一索引，當(dāng)有多個(gè)字段名都經(jīng)常被查詢的話用復(fù)合索引。
26、rabbitmq 的使用場(chǎng)景有哪些？(你公司生產(chǎn)環(huán)境用的那個(gè)消息中間件)
好處：異步處理、流量削峰、消息通訊、應(yīng)用解耦;
缺點(diǎn):可用性降低、復(fù)雜度提高、一致性問(wèn)題
Rabbit ：支持高并發(fā)高吞吐、支持集群化、功能較為完善
使用場(chǎng)景：順序消費(fèi)、服務(wù)間異步通信、定時(shí)任務(wù)、請(qǐng)求削峰
27、zookeeper的部署模式？ 應(yīng)用場(chǎng)景？
三種 ：?jiǎn)螜C(jī)部署，集群部署，偽集群部署。
數(shù)據(jù)發(fā)布/訂閱、負(fù)載均衡、命名服務(wù)、分布式協(xié)調(diào)/通知、集群管理、Master 選舉、分布式鎖、分布式隊(duì)列
28、log4j有什么用？
在開(kāi)發(fā)階段寫(xiě)下的這些判斷僅為了調(diào)試的語(yǔ)句，在開(kāi)發(fā)完成時(shí)需要查找并移除。部署運(yùn)行后，尤其是在一些企業(yè)應(yīng)用系統(tǒng)中，還經(jīng)常需要進(jìn)一步調(diào)試，這時(shí)就遇到了更大的麻煩。所以，我們需要一套完備的、靈活的、可配置的日志工具log4J就是優(yōu)秀的選擇。
28.1、Log4j主要由哪三部分組成？每部分的主要作用是什么？
Log4j 由 logger、Appender 和 layout 三個(gè)組件組成?？梢酝ㄟ^(guò)同名的 Java 類(lèi)訪問(wèn) Log4j 的這三個(gè)組件。
Logger 在執(zhí)行應(yīng)用程序時(shí)，接收日志語(yǔ)句生成的日志請(qǐng)求。它是一種重要的日志處理組件， 可以通過(guò) log4j API 的 logger 類(lèi)對(duì)其進(jìn)行訪問(wèn)。它的方法有：debug、info、warn、error、fatal 和 log。這些方法用于記錄消息。 Appender - 管理日志語(yǔ)句的輸出結(jié)果。執(zhí)行日志語(yǔ)句時(shí)，Logger 對(duì)象將接收來(lái)自日志語(yǔ)句的記錄請(qǐng)求。此請(qǐng)求是通過(guò) logger 發(fā)送至 Appender 的。然后，Appender 將輸出結(jié)果寫(xiě)入到用戶選擇的目的地。對(duì)于不同的日志目的地，提供不同的 Appender 類(lèi)型。這些 Appender 包括：用于文件的 file Appender、用于數(shù)據(jù)庫(kù)的 JDBC Appender 和用于 SMTP 服務(wù)器的 SMTP Appender。 Layout - 用于指定 Appender 將日志語(yǔ)句寫(xiě)入日志目的地所采用的格式。Appender 可以用來(lái)格式化輸出結(jié)果的各種布局包括：簡(jiǎn)單布局、模式布局和 HTML 布局。
29、線程池的作用？
線程池作用就是限制系統(tǒng)中執(zhí)行線程的數(shù)量。
1、提高效率 創(chuàng)建好一定數(shù)量的線程放在池中，等需要使用的時(shí)候就從池中拿一個(gè)，這要比需要的時(shí)候創(chuàng)建一個(gè)線程對(duì)象要快的多。
2、方便管理 可以編寫(xiě)線程池管理代碼對(duì)池中的線程同一進(jìn)行管理
3、降低資源消耗
29.1、線程池都有哪幾種工作隊(duì)列
1、ArrayBlockingQueue
是一個(gè)基于數(shù)組結(jié)構(gòu)的有界阻塞隊(duì)列，此隊(duì)列按 FIFO（先進(jìn)先出）原則對(duì)元素進(jìn)行排序。
2、LinkedBlockingQueue
一個(gè)基于鏈表結(jié)構(gòu)的阻塞隊(duì)列，此隊(duì)列按FIFO （先進(jìn)先出） 排序元素，吞吐量通常要高于ArrayBlockingQueue。靜態(tài)工廠方法Executors.newFixedThreadPool()使用了這個(gè)隊(duì)列
3、SynchronousQueue
一個(gè)不存儲(chǔ)元素的阻塞隊(duì)列。每個(gè)插入操作必須等到另一個(gè)線程調(diào)用移除操作，否則插入操作一直處于阻塞狀態(tài)，吞吐量通常要高于LinkedBlockingQueue，靜態(tài)工廠方法Executors.newCachedThreadPool使用了這個(gè)隊(duì)列。
4、PriorityBlockingQueue
一個(gè)具有優(yōu)先級(jí)的無(wú)限阻塞隊(duì)列。
30、Nginx？
Nginx是一個(gè)輕量級(jí)/高性能的反向代理Web服務(wù)器，他實(shí)現(xiàn)非常高效的反向代理、負(fù)載平衡
30.1、為什么要用Nginx？
跨平臺(tái)、配置簡(jiǎn)單、方向代理、高并發(fā)連接：處理2-3萬(wàn)并發(fā)連接數(shù)，官方監(jiān)測(cè)能支持5萬(wàn)并發(fā)，內(nèi)存消耗?。洪_(kāi)啟10個(gè)nginx才占150M內(nèi)存 ，nginx處理靜態(tài)文件好，耗費(fèi)內(nèi)存少，
而且Nginx內(nèi)置的健康檢查功能：如果有一個(gè)服務(wù)器宕機(jī)，會(huì)做一個(gè)健康檢查，再發(fā)送的請(qǐng)求就不會(huì)發(fā)送到宕機(jī)的服務(wù)器了。重新將請(qǐng)求提交到其他的節(jié)點(diǎn)上。
使用Nginx的話還能：
節(jié)省寬帶：支持GZIP壓縮，可以添加瀏覽器本地緩存
穩(wěn)定性高：宕機(jī)的概率非常小
接收用戶請(qǐng)求是異步的
30.2、Nginx的優(yōu)缺點(diǎn)？
優(yōu)點(diǎn)：
占內(nèi)存小，可實(shí)現(xiàn)高并發(fā)連接，處理響應(yīng)快
可實(shí)現(xiàn)http服務(wù)器、虛擬主機(jī)、方向代理、負(fù)載均衡
Nginx配置簡(jiǎn)單
可以不暴露正式的服務(wù)器IP地址
缺點(diǎn)： 動(dòng)態(tài)處理差：nginx處理靜態(tài)文件好,耗費(fèi)內(nèi)存少，但是處理動(dòng)態(tài)頁(yè)面則很雞肋，現(xiàn)在一般前端用nginx作為反向代理抗住壓力，
30.3、Nginx應(yīng)用場(chǎng)景？
http服務(wù)器。Nginx是一個(gè)http服務(wù)可以獨(dú)立提供http服務(wù)?？梢宰鼍W(wǎng)頁(yè)靜態(tài)服務(wù)器。
虛擬主機(jī)?？梢詫?shí)現(xiàn)在一臺(tái)服務(wù)器虛擬出多個(gè)網(wǎng)站，例如個(gè)人網(wǎng)站使用的虛擬機(jī)。
反向代理，負(fù)載均衡。當(dāng)網(wǎng)站的訪問(wèn)量達(dá)到一定程度后，單臺(tái)服務(wù)器不能滿足用戶的請(qǐng)求時(shí)，需要用多臺(tái)服務(wù)器集群可以使用nginx做反向代理。并且多臺(tái)服務(wù)器可以平均分擔(dān)負(fù)載，不會(huì)應(yīng)為某臺(tái)服務(wù)器負(fù)載高宕機(jī)而某臺(tái)服務(wù)器閑置的情況。
nginz 中也可以配置安全管理、比如可以使用Nginx搭建API接口網(wǎng)關(guān),對(duì)每個(gè)接口服務(wù)進(jìn)行攔截。
30.4、Nginx 是如何實(shí)現(xiàn)高并發(fā)的?
異步，非阻塞，使用了epoll 和大量的底層代碼優(yōu)化。
如果一個(gè)server采用一個(gè)進(jìn)程負(fù)責(zé)一個(gè)request的方式，那么進(jìn)程數(shù)就是并發(fā)數(shù)。正常情況下，會(huì)有很多進(jìn)程一直在等待中。
而nginx采用一個(gè)master進(jìn)程，多個(gè)woker進(jìn)程的模式。
master進(jìn)程主要負(fù)責(zé)收集、分發(fā)請(qǐng)求。每當(dāng)一個(gè)請(qǐng)求過(guò)來(lái)時(shí)，master就拉起一個(gè)worker進(jìn)程負(fù)責(zé)處理這個(gè)請(qǐng)求。
同時(shí)master進(jìn)程也負(fù)責(zé)監(jiān)控woker的狀態(tài)，保證高可靠性
woker進(jìn)程一般設(shè)置為跟cpu核心數(shù)一致。nginx的woker進(jìn)程在同一時(shí)間可以處理的請(qǐng)求數(shù)只受內(nèi)存限制，可以處理多個(gè)請(qǐng)求。
Nginx 的異步非阻塞工作方式正把當(dāng)中的等待時(shí)間利用起來(lái)了。在需要等待的時(shí)候，這些進(jìn)程就空閑出來(lái)待命了，因此表現(xiàn)為少數(shù)幾個(gè)進(jìn)程就解決了大量的并發(fā)問(wèn)題。
31、多線程 線程安全 高并發(fā)？
32、Dubbo？
33、Redis優(yōu)化？
33.1、Redis的隊(duì)列如何異步使用？
Redis 的 list 結(jié)構(gòu)可以作為隊(duì)列使用，rpush 生產(chǎn)消息，lpop 消費(fèi)消息，lpop 沒(méi)有取到消息時(shí)，可以讓線程休眠一會(huì)再獲取消息
blpop 指令，在隊(duì)列沒(méi)有消息時(shí)，會(huì)阻塞線程直到消息被生產(chǎn)，獲取消息
