一面：
1.? ? Java中的多態(tài)
面向?qū)ο缶幊逃腥筇匦裕悍庋b、繼承罪针、多態(tài)
多態(tài)：指允許不同類的對象對同一消息做出響應(yīng)悬蔽。即同一消息可以根據(jù)發(fā)送對象的不同而采用多種不同的行為方式载迄。（發(fā)送消息就是函數(shù)調(diào)用）
2.? 為什么要同時重寫hashcode和equals
1）棒仍、如果兩個對象相同（即用equals比較返回true）悲靴，那么它們的hashCode值一定要相同；
2）莫其、如果兩個對象的hashCode相同癞尚，它們并不一定相同(即用equals比較返回false)
由于為了提高程序的效率才實現(xiàn)了hashcode方法，先進(jìn)行hashcode的比較乱陡，如果不同浇揩，那沒就不必在進(jìn)行equals的比較了，這樣就大大減少了equals比較的次數(shù)憨颠，這對比需要比較的數(shù)量很大的效率提高是很明顯的
3.? Hashmap的原理
HashMap由數(shù)組+鏈表組成的胳徽，數(shù)組是HashMap的主體，鏈表則是主要為了解決哈希沖突而存在的，如果定位到的數(shù)組位置不含鏈表（當(dāng)前entry的next指向null）,那么對于查找膜廊，添加等操作很快，僅需一次尋址即可淫茵；如果定位到的數(shù)組包含鏈表爪瓜，對于添加操作，其時間復(fù)雜度為O(n)匙瘪，首先遍歷鏈表铆铆，存在即覆蓋，否則新增丹喻；對于查找操作來講薄货，仍需遍歷鏈表，然后通過key對象的equals方法逐一比對查找碍论。所以谅猾，性能考慮，HashMap中的鏈表出現(xiàn)越少鳍悠，性能才會越好税娜。
4.? ? Hashmap如何變線程安全，每種方式的優(yōu)缺點
通過以下三種方法來實現(xiàn)：
1）.替換成Hashtable藏研，Hashtable通過對整個表上鎖實現(xiàn)線程安全敬矩，因此效率比較低
2）.使用Collections類的synchronizedMap方法包裝一下。方法如下：
public static Map synchronizedMap(Map m) ?返回由指定映射支持的同步（線程安全的）映射
3）.使用ConcurrentHashMap蠢挡，它使用分段鎖來保證線程安全
通過前兩種方式獲得的線程安全的HashMap在讀寫數(shù)據(jù)的時候會對整個容器上鎖弧岳，而ConcurrentHashMap并不需要對整個容器上鎖，它只需要鎖住要修改的部分就行了
5.? ? 垃圾回收機制
Java 虛擬機內(nèi)存模型分為：
? ? ? 一部分是線程共享的业踏，其中禽炬，線程共享的數(shù)據(jù)區(qū)包括方法區(qū)和堆，Java 堆的唯一目的就是存放對象實例勤家，幾乎所有的對象實例（和數(shù)組）都在這里分配內(nèi)存瞎抛。方法區(qū)與Java堆一樣，也是線程共享的并且不需要連續(xù)的內(nèi)存却紧，其用于存儲已被虛擬機加載的?類信息桐臊、常量、靜態(tài)變量晓殊、即時編譯器編譯后的代碼等數(shù)據(jù)断凶。
? ? ? 一部分則是線程私有的。線程私有的數(shù)據(jù)區(qū)包括虛擬機棧巫俺、本地方法棧和程序計數(shù)器认烁。
6.? ? Jvm的參數(shù)你知道的說一下
7.? ? 設(shè)計模式了解的說一下啊
8.? ? 手寫java多線程
9.? ? 手寫java的soeket編程，服務(wù)端和客戶端
二面：
1.? ? 服務(wù)器如何負(fù)載均衡，有哪些算法却嗡，哪個比較好舶沛，一致性哈希原理，怎么避免DDOS攻擊請求打到少數(shù)機器窗价。
2.? TCP連接中的三次握手和四次揮手如庭，四次揮手的最后一個ack的作用是什么，為什么要time wait撼港，為什么是2msl坪它。
三次握手
第一次握手：主機A發(fā)送位碼為syn＝1,隨機產(chǎn)生seq number=10001的數(shù)據(jù)包到服務(wù)器，主機B由SYN=1知道帝牡，A要求建立聯(lián)機往毡，此時狀態(tài)為SYN_SENT；?
第二次握手：主機B收到請求后要確認(rèn)聯(lián)機信息靶溜，向A發(fā)送ack number=(主機A的seq+1),syn=1,ack=1,隨機產(chǎn)生seq=20001的包开瞭，此時狀態(tài)由LISTEN變?yōu)镾YN_RECV；?
第三次握手：主機A收到后檢查ack number是否正確罩息，即第一次發(fā)送的seq number+1,以及位碼ack是否為1惩阶，若正確，主機A會再發(fā)送ack number=(主機B的seq+1),ack=1扣汪，主機B收到后確認(rèn)seq值與ack=1則連接建立成功断楷，雙方狀態(tài)ESTABLISHED。
完成三次握手崭别，主機A與主機B開始傳送數(shù)據(jù)
為什么要time wait冬筒，為什么是2msl：而且握手的4個報文也都發(fā)送完畢，按理可以直接回到CLOSED 狀態(tài)(就好比從SYN_SENT 狀態(tài)到ESTABLISH 狀態(tài)那樣)茅主，但是我們必須假想網(wǎng)絡(luò)是不可靠的舞痰，你無法保證你(客戶端)最后發(fā)送的ACK報文一定會被對方收到，就是說對方處于LAST_ACK 狀態(tài)下的SOCKET可能會因為超時未收到ACK報文诀姚，而重發(fā)FIN報文响牛，所以這個TIME_WAIT 狀態(tài)的作用就是用來重發(fā)可能丟失的ACK報文。
3.? 數(shù)據(jù)庫的備份和恢復(fù)怎么實現(xiàn)的赫段，主從復(fù)制怎么做的呀打，什么時候會出現(xiàn)數(shù)據(jù)不一致，如何解決糯笙。
數(shù)據(jù)不一致：1.網(wǎng)絡(luò)的延遲贬丛；2.主從兩臺機器的負(fù)載不一致；3.max_allowed_packet設(shè)置不一致给涕；4.key自增鍵開始的鍵值跟自增步長設(shè)置不一致引起的主從不一致豺憔；5.mysql異常宕機情況下额获，如果未設(shè)置sync_binlog=1或者innodb_flush_log_at_trx_commit=1很有可能出現(xiàn)binlog或者relaylog文件出現(xiàn)損壞，導(dǎo)致主從不一致恭应；6.mysql本身的bug引起的主從不同步抄邀；7.版本不一致，特別是高版本是主昼榛，低版本為從的情況下境肾，主數(shù)據(jù)庫上面支持的功能，從數(shù)據(jù)庫上面不支持該功能褒纲。
解決辦法：方法一：忽略錯誤后，繼續(xù)同步?該方法適用于主從庫數(shù)據(jù)相差不大钥飞，或者要求數(shù)據(jù)可以不完全統(tǒng)一的情況莺掠，數(shù)據(jù)要求不嚴(yán)格的情況?方式二：重新做主從，完全同步?該方法適用于主從庫數(shù)據(jù)相差較大读宙，或者要求數(shù)據(jù)完全統(tǒng)一的情況彻秆；1.先進(jìn)入主庫，進(jìn)行鎖表结闸，防止數(shù)據(jù)寫入?mysql> flush tables with read lock;?2.進(jìn)行數(shù)據(jù)備份?
4.? Linux查看cpu占用率高的進(jìn)程
top 命令：查看進(jìn)程級別的cpu使用情況唇兑。vmstat 命令：查看系統(tǒng)級別的cpu使用情況
9.? ? 設(shè)計模式講一下熟悉的
10. 會不會濫用設(shè)計模式
11. 多線程條件變量為什么要在while體里
12. 你遇到什么挫折，怎么應(yīng)對和處理
三面：
1.? ? Redis的特點
redis是一個基于內(nèi)存的高性能key-value數(shù)據(jù)庫桦锄，支持string(字符串)? 扎附，list(列表)，hash(散列)结耀，sets (集合)留夜，sorted set(有序集合)；
redis支持集群图甜，分布式碍粥，支持主從的模式；
原則：
Master會將數(shù)據(jù)同步到slave黑毅，而slave不會將數(shù)據(jù)同步到master嚼摩。Slave啟動時會連接master來同步數(shù)據(jù)。
典型的讀寫分離模型矿瘦。利用master來插入數(shù)據(jù)枕面，slave提供檢索服務(wù)。有效減少單個機器的并發(fā)訪問數(shù)量缚去。
讀寫分離模型：
通過增加Slave DB的數(shù)量膊畴，讀的性能可以線性增長，為了避免Master DB的單點故障病游，集群一般都會采用兩臺Master DB 做雙機熱備唇跨，所以整個集群的讀和寫的可用性都非常高稠通。
缺陷：
不管是Master還是Slave，每個節(jié)點都必須保存完整的數(shù)據(jù)买猖，如果在數(shù)據(jù)量很大的情況下改橘，集群的擴展能力是受限于單個節(jié)點的存儲能力，而且對于Write-intensive類型的應(yīng)用玉控，讀寫分離架構(gòu)并不適合飞主。
為了解決讀寫分離模型的缺陷，可以將數(shù)分片模型應(yīng)用進(jìn)來高诺÷凳叮可以將每個節(jié)點看成都是master，然后通過業(yè)務(wù)實現(xiàn)數(shù)據(jù)分片虱而。結(jié)合兩種模型筏餐，可以將每個master設(shè)計成由一個master和多個slave組成的模型。
redis優(yōu)點
a.單線程牡拇，利用redis隊列技術(shù)并將訪問變?yōu)榇性L問魁瞪，消除了傳統(tǒng)數(shù)據(jù)庫串行控制的開銷
b.redis具有快速和持久化的特征，速度快惠呼，因為數(shù)據(jù)存在內(nèi)存中导俘。
c.分布式 讀寫分離模式
d.支持豐富數(shù)據(jù)類型
e.支持事務(wù)，操作都是原子性剔蹋，所謂原子性就是對數(shù)據(jù)的更改要么全部執(zhí)行旅薄，要不全部不執(zhí)行。
f.可用于緩存泣崩，消息赋秀，按key設(shè)置過期時間，過期后自動刪除
回收策略
從最近最少使用的數(shù)據(jù)淘汰律想，挑選將要過期的數(shù)據(jù)淘汰猎莲。
redis和memcache相比，有哪些優(yōu)勢技即？
a.memcache所有的值均是簡單的字符串著洼，redis支持更為豐富的數(shù)據(jù)類型
b.redis速度比memcached快很多
c.redis支持持久化
redis與memcache區(qū)別
a.存儲方式 memcache存在內(nèi)存中，redis存在硬盤中而叼，保證數(shù)據(jù)持久化
b.數(shù)據(jù)類型 memcache對數(shù)據(jù)類型支持相對簡單身笤，redis有復(fù)雜的數(shù)據(jù)類型
c.使用底層模型不同:底層實現(xiàn)方式以及客戶端之間通信的應(yīng)用協(xié)議不一樣
d.redis最大可以達(dá)到1G而memcache只有1MB
2.? Redis的持久化怎么做，aof和rdb葵陵，有什么區(qū)別液荸，有什么優(yōu)缺點。
redis提供了不同級別的持久化方式脱篙，一種是RDB娇钱，一種AOF伤柄。可以同時開啟兩種持久化方式, 在這種情況下, 當(dāng)redis重啟的時候會優(yōu)先載入AOF文件來恢復(fù)原始的數(shù)據(jù),因為在通常情況下AOF文件保存的數(shù)據(jù)集要比RDB文件保存的數(shù)據(jù)集要完整.
RDB：在指定的時間間隔能對數(shù)據(jù)進(jìn)行快照存儲(隔一段時間,把內(nèi)存里的數(shù)據(jù)轉(zhuǎn)存在硬盤里的文件)
優(yōu)點：
1）RDB是一個非常緊湊的文件,它保存了某個時間點得數(shù)據(jù)集,非常適用于數(shù)據(jù)集的備份,比如您可以在每個小時報保存一下過去24小時內(nèi)的數(shù)據(jù),同時每天保存過去30天的數(shù)據(jù),這樣即使出了問題您也可以根據(jù)需求恢復(fù)到不同版本的數(shù)據(jù)集.
2）與AOF相比,在恢復(fù)大的數(shù)據(jù)集的時候文搂，RDB方式會更快一些.
缺點：
如果您希望在redis意外停止工作（例如電源中斷）的情況下丟失的數(shù)據(jù)最少的話适刀，那么RDB不適合您.雖然您可以配置不同的save時間點(例如每隔5分鐘并且對數(shù)據(jù)集有100個寫的操作),是Redis要完整的保存整個數(shù)據(jù)集是一個比較繁重的工作,您通常會每隔5分鐘或者更久做一次完整的保存,萬一在Redis意外宕機,您可能會丟失幾分鐘的數(shù)據(jù).
AOF：每次對服務(wù)器寫的操作,當(dāng)服務(wù)器重啟的時候會重新執(zhí)行這些命令來恢復(fù)原始的數(shù)據(jù),AOF命令以redis協(xié)議追加保存每次寫的操作到文件末尾.Redis還能對AOF文件進(jìn)行后臺重寫,使得AOF文件的體積不至于過大.
優(yōu)點：
使用AOF 會讓您的Redis更加耐久: 您可以使用不同的fsync策略：無fsync,每秒fsync,每次寫的時候fsync.使用默認(rèn)的每秒fsync策略,Redis的性能依然很好(fsync是由后臺線程進(jìn)行處理的,主線程會盡力處理客戶端請求),一旦出現(xiàn)故障，您最多丟失1秒的數(shù)據(jù).
缺點：
對于相同的數(shù)據(jù)集來說煤蹭，AOF 文件的體積通常要大于RDB 文件的體積笔喉。
根據(jù)所使用的 fsync 策略，AOF 的速度可能會慢于?RDB 硝皂。 在一般情況下常挚， 每秒 fsync 的性能依然非常高， 而關(guān)閉 fsync 可以讓 AOF 的速度和 RDB 一樣快稽物， 即使在高負(fù)荷之下也是如此奄毡。 不過在處理巨大的寫入載入時，RDB 可以提供更有保證的最大延遲時間（latency）姨裸。
3.? Redis使用哨兵部署會有什么問題秧倾，我說需要擴容的話還是得集群部署怨酝。
4.? 說一下JVM內(nèi)存模型把傀缩，有哪些區(qū)，分別干什么的
5.? 說一下gc算法农猬，分代回收說下
6.? MySQL的引擎講一下赡艰，有什么區(qū)別，使用場景呢
在MySQL數(shù)據(jù)庫中斤葱，常用的引擎主要就是2個：Innodb和MyIASM慷垮。
Innodb引擎，1）Innodb引擎提供了對數(shù)據(jù)庫ACID事務(wù)的支持揍堕。并且還提供了行級鎖和外鍵的約束料身。它的設(shè)計的目標(biāo)就是處理大數(shù)據(jù)容量的數(shù)據(jù)庫系統(tǒng)。2）大容量的數(shù)據(jù)集時趨向于選擇Innodb衩茸。因為它支持事務(wù)處理和故障的恢復(fù)芹血。Innodb可以利用數(shù)據(jù)日志來進(jìn)行數(shù)據(jù)的恢復(fù)。主鍵的查詢在Innodb也是比較快的楞慈。3）Innodb引擎的索引的數(shù)據(jù)結(jié)構(gòu)也是B+樹幔烛，只不過數(shù)據(jù)結(jié)構(gòu)中存儲的都是實際的數(shù)據(jù)，這種索引有被稱為聚集索引囊蓝。4）Select count(*) from table指令的時候饿悬，需要進(jìn)行掃描全表
MyIASM引擎，1）它是MySql的默認(rèn)引擎聚霜，但不提供事務(wù)的支持狡恬，也不支持行級鎖和外鍵珠叔。因此當(dāng)執(zhí)行Insert插入和Update更新語句時，即執(zhí)行寫操作的時候需要鎖定這個表傲宜。所以會導(dǎo)致效率會降低运杭。2）大批量的插入語句時（這里是INSERT語句）在MyIASM引擎中執(zhí)行的比較的快，但是UPDATE語句在Innodb下執(zhí)行的會比較的快函卒，尤其是在并發(fā)量大的時候辆憔。3）MyIASM引擎，B+樹的數(shù)據(jù)結(jié)構(gòu)中存儲的內(nèi)容實際上是實際數(shù)據(jù)的地址值报嵌。也就是說它的索引和實際數(shù)據(jù)是分開的虱咧，只不過使用索引指向了實際數(shù)據(jù)。這種索引的模式被稱為非聚集索引锚国。4）Select count(*) from table語句時腕巡，可以直接的讀取已經(jīng)保存的值而不需要進(jìn)行掃描全表
分布式事務(wù)了解么
