1.非技術(shù)問題

A华畏、 整理一個項(xiàng)目中遇到的哪些棘手的問題谨敛，這些問題帶來了什么問題媳荒，當(dāng)時想了哪些解決方案抗悍，最終為何選擇了這個方案，這個方案的結(jié)果是什么钳枕，后續(xù)應(yīng)該如何在系統(tǒng)設(shè)計時提前考慮這些問題缴渊；

B、 當(dāng)XXX官問你有什么想問的問題時鱼炒。要注意不要問xinchou相關(guān)信息衔沼。主要問團(tuán)隊情況、過來做什么事情，可能會遇到的挑戰(zhàn)

C指蚁、 開放性問題注意的點(diǎn)菩佑，開放性問題沒有標(biāo)準(zhǔn)答案，核心就是不要把話說太死凝化，以自己的了解說個大概即可稍坯。多方面考慮開放性問題。

D搓劫、 XXX注意不要過于表現(xiàn)自己瞧哟，根據(jù)XXX官的問題，回答核心問題即可枪向，有時隱藏部分實(shí)力勤揩，也是極好。

E秘蛔、 XXX注意雄可，當(dāng)一個問題，你覺得沒有準(zhǔn)備好的時候缠犀，可以重復(fù)XXX官的問題数苫，放慢語速。然后在這段時間去思考這個問題辨液。

F虐急、 回答問題要有條理性、邏輯性滔迈。要回答一個問題時止吁，先在腦袋里想一想，然后再組織一下燎悍，最后再說出來敬惦。這樣會更具有結(jié)構(gòu)化的東西出來。

2. 常見技術(shù)

一些實(shí)現(xiàn)原理性的東西谈山。

1俄删、java如何垃圾回收

2、java如何判斷內(nèi)存為垃圾

3奏路、java out of memory有哪幾種情況出現(xiàn)

4畴椰、分布式系統(tǒng)雪崩產(chǎn)生原因，如何防止雪崩

5鸽粉、tcp擁塞算法

6斜脂、微服務(wù)和soa的區(qū)別，微服務(wù)的技術(shù)難點(diǎn)

7触机、談?wù)剅edis的使用帚戳，redis的數(shù)據(jù)主從同步

Redis集群高可用玷或，主從同步，哨兵

--------------------------------------

ConcurrentHashMap 1.7和1.8的區(qū)別

1片任、整體結(jié)構(gòu)

1.7：Segment + HashEntry + Unsafe

1.8: 移除Segment庐椒，使鎖的粒度更小，Synchronized + CAS + Node + Unsafe

2蚂踊、put（）

1.7：先定位Segment约谈，再定位桶，put全程加鎖犁钟，沒有獲取鎖的線程提前找桶的位置棱诱，并最多自旋64次獲取鎖，超過則掛起涝动。

1.8：由于移除了Segment迈勋，類似HashMap，可以直接定位到桶醋粟，拿到first節(jié)點(diǎn)后進(jìn)行判斷靡菇，1、為空則CAS插入米愿；2厦凤、為-1則說明在擴(kuò)容，則跟著一起擴(kuò)容育苟；3较鼓、else則加鎖put（類似1.7）

3、get（）

基本類似违柏，由于value聲明為volatile博烂，保證了修改的可見性，因此不需要加鎖漱竖。

4禽篱、resize（）

1.7：跟HashMap步驟一樣，只不過是搬到單線程中執(zhí)行馍惹，避免了HashMap在1.7中擴(kuò)容時死循環(huán)的問題躺率，保證線程安全。

1.8：支持并發(fā)擴(kuò)容讼积，HashMap擴(kuò)容在1.8中由頭插改為尾插（為了避免死循環(huán)問題）肥照，ConcurrentHashmap也是，遷移也是從尾部開始勤众，擴(kuò)容前在桶的頭部放置一個hash值為-1的節(jié)點(diǎn)，這樣別的線程訪問時就能判斷是否該桶已經(jīng)被其他線程處理過了鲤脏。

5们颜、size（）

1.7：很經(jīng)典的思路：計算兩次吕朵，如果不變則返回計算結(jié)果，若不一致窥突，則鎖住所有的Segment求和努溃。

1.8：用baseCount來存儲當(dāng)前的節(jié)點(diǎn)個數(shù)，這就設(shè)計到baseCount并發(fā)環(huán)境下修改的問題（說實(shí)話我沒看懂-_-!）

----

（1）JDK1.7用的是頭插法阻问，而JDK1.8及之后使用的都是尾插法梧税，那么他們?yōu)槭裁匆@樣做呢？因?yàn)镴DK1.7是用單鏈表進(jìn)行的縱向延伸称近，當(dāng)采用頭插法時會容易出現(xiàn)逆序且環(huán)形鏈表死循環(huán)問題第队。但是在JDK1.8之后是因?yàn)榧尤肓思t黑樹使用尾插法，能夠避免出現(xiàn)逆序且鏈表死循環(huán)的問題刨秆。

（2）擴(kuò)容后數(shù)據(jù)存儲位置的計算方式也不一樣：1. 在JDK1.7的時候是直接用hash值和需要擴(kuò)容的二進(jìn)制數(shù)進(jìn)行&（這里就是為什么擴(kuò)容的時候?yàn)樯兑欢ū仨毷?的多少次冪的原因所在凳谦，因?yàn)槿绻挥?的n次冪的情況時最后一位二進(jìn)制數(shù)才一定是1，這樣能最大程度減少hash碰撞）（hash值 & length-1）

2衡未、而在JDK1.8的時候直接用了JDK1.7的時候計算的規(guī)律尸执，也就是擴(kuò)容前的原始位置+擴(kuò)容的大小值=JDK1.8的計算方式，而不再是JDK1.7的那種異或的方法缓醋。但是這種方式就相當(dāng)于只需要判斷Hash值的新增參與運(yùn)算的位是0還是1就直接迅速計算出了擴(kuò)容后的儲存方式如失。

（3）JDK1.7的時候使用的是數(shù)組+ 單鏈表的數(shù)據(jù)結(jié)構(gòu)。但是在JDK1.8及之后時送粱，使用的是數(shù)組+鏈表+紅黑樹的數(shù)據(jù)結(jié)構(gòu)（當(dāng)鏈表的深度達(dá)到8的時候岖常，也就是默認(rèn)閾值，就會自動擴(kuò)容把鏈表轉(zhuǎn)成紅黑樹的數(shù)據(jù)結(jié)構(gòu)來把時間復(fù)雜度從O（n）變成O（logN）提高了效率）

----------------------------

redis據(jù)你所知是單線程的葫督，為什么redis還可以快竭鞍？

開發(fā)語言

現(xiàn)在我們都用高級語言來編程，比如 Java橄镜、python 等偎快。也許你會覺得 C 語言很古老，但是它真的很有用洽胶，畢竟 unix 系統(tǒng)就是用 C 實(shí)現(xiàn)的晒夹，所以 C 語言是非常貼近操作系統(tǒng)的語言。Redis 就是用 C 語言開發(fā)的姊氓，所以執(zhí)行會比較快丐怯。

純內(nèi)存訪問

Redis 將所有數(shù)據(jù)放在內(nèi)存中，非數(shù)據(jù)同步正常工作時翔横，是不需要從磁盤讀取數(shù)據(jù)的

單線程

第一读跷，單線程簡化算法的實(shí)現(xiàn)，并發(fā)的數(shù)據(jù)結(jié)構(gòu)實(shí)現(xiàn)不但困難而且測試也麻煩禾唁。

第二效览，單線程避免了線程切換以及加鎖釋放鎖帶來的消耗无切，對于服務(wù)端開發(fā)來說，鎖和線程切換通常是性能殺手丐枉。

非阻塞多路 I/O 復(fù)用機(jī)制

I/O 多路復(fù)用實(shí)際上是指多個連接的管理可以在同一進(jìn)程哆键。多路是指網(wǎng)絡(luò)連接，復(fù)用只是同一個線程瘦锹。在網(wǎng)絡(luò)服務(wù)中籍嘹，I/O 多路復(fù)用起的作用是一次性把多個連接的事件通知業(yè)務(wù)代碼處理，處理的方式由業(yè)務(wù)代碼來決定弯院，該方法就會返回可讀 / 寫的 FD 個數(shù)辱士。

Redis 使用 epoll 作為 I/O 多路復(fù)用技術(shù)的實(shí)現(xiàn)，再加上 Redis 自身的事件處理模型將 epoll 的 read抽兆、write识补、close 等都轉(zhuǎn)換成事件，不在網(wǎng)絡(luò) I/O 上浪費(fèi)過多的時間辫红，從而實(shí)現(xiàn)對多個 FD 讀寫的監(jiān)控凭涂，提高性能。

為什么用skiplist? 不用平衡樹：

1. 內(nèi)存贴妻，內(nèi)存占用skiplist 較為靈活一些切油。每個節(jié)點(diǎn)平均1.3.平衡樹是2

2. 范圍查找，平衡樹范圍查找名惩，找到范圍小值后澎胡，還需要中序遍歷，查到大值節(jié)點(diǎn)娩鹉。skiplist直接底層level往后查詢就可以了攻谁。

3. 新增刪除，平衡樹會導(dǎo)致子數(shù)的調(diào)整弯予，而skiplist只需要修改相鄰節(jié)點(diǎn)的指針戚宦。

4. 從算法實(shí)現(xiàn)難度上來比較，skiplist比平衡樹要簡單得多

set命令要用 setkey value px milliseconds nx锈嫩；保證原子性

value要具有唯一性受楼，釋放鎖時要驗(yàn)證value值，不能誤解鎖呼寸；

解鎖要使用lua腳本艳汽，也是為了保證原子性

Redis官方也指出該方法有安全隱患就是在主從復(fù)制模式下會導(dǎo)致兩個線程可能會同時持有一個鎖，如果業(yè)務(wù)允許如此对雪，則推薦使用這種方案河狐，畢竟實(shí)現(xiàn)簡單，易維護(hù)。

如果對鎖的要求非常高的場景甚牲，Redis官方建議使用RedLock算法义郑。

高并發(fā)場景下的問題

以下問題不是說在并發(fā)不高的場景下不容易出現(xiàn)蝶柿，只是在高并發(fā)場景下出現(xiàn)的概率更高些而已丈钙。

性能問題。 性能問題來自于兩個方面交汤。

獲取鎖的時間上雏赦。如果redlock運(yùn)用在高并發(fā)的場景下，存在N個master節(jié)點(diǎn)芙扎，一個一個去請求星岗，耗時會比較長，從而影響性能戒洼。這個好解決俏橘。通過上面描述不難發(fā)現(xiàn)，從多個節(jié)點(diǎn)獲取鎖的操作并不是一個同步操作圈浇，可以是異步操作寥掐，這樣可以多個節(jié)點(diǎn)同時獲取。即使是并行處理的磷蜀，還是得預(yù)估好獲取鎖的時間召耘，保證鎖的TTL > 獲取鎖的時間+任務(wù)處理時間。

被加鎖的資源太大褐隆。加鎖的方案本身就是會為了正確性而犧牲并發(fā)的污它，犧牲和資源大小成正比。這個時候可以考慮對資源做拆分庶弃，拆分的方式有兩種：

從業(yè)務(wù)上將鎖住的資源拆分成多段衫贬，每段分開加鎖。比如歇攻，我要對一個商戶做若干個操作固惯，操作前要鎖住這個商戶，這時我可以將若干個操作拆成多個獨(dú)立的步驟分開加鎖掉伏，提高并發(fā)缝呕。

用分桶的思想，將一個資源拆分成多個桶斧散，一個加鎖失敗立即嘗試下一個供常。比如批量任務(wù)處理的場景，要處理200w個商戶的任務(wù)鸡捐，為了提高處理速度栈暇，用多個線程，每個線程取100個商戶處理箍镜，就得給這100個商戶加鎖源祈，如果不加處理煎源，很難保證同一時刻兩個線程加鎖的商戶沒有重疊，這時可以按一個維度香缺，比如某個標(biāo)簽手销，對商戶進(jìn)行分桶，然后一個任務(wù)處理一個分桶图张，處理完這個分桶再處理下一個分桶锋拖，減少競爭。

重試的問題祸轮。 無論是簡單實(shí)現(xiàn)還是redlock實(shí)現(xiàn)兽埃，都會有重試的邏輯。如果直接按上面的算法實(shí)現(xiàn)适袜，是會存在多個client幾乎在同一時刻獲取同一個鎖柄错，然后每個client都鎖住了部分節(jié)點(diǎn)，但是沒有一個client獲取大多數(shù)節(jié)點(diǎn)的情況苦酱。解決的方案也很常見售貌，在重試的時候讓多個節(jié)點(diǎn)錯開，錯開的方式就是在重試時間中加一個隨機(jī)時間躏啰。這樣并不能根治這個問題趁矾，但是可以有效緩解問題，親試有效给僵。

節(jié)點(diǎn)宕機(jī)

對于單master節(jié)點(diǎn)且沒有做持久化的場景毫捣，宕機(jī)就掛了，這個就必須在實(shí)現(xiàn)上支持重復(fù)操作帝际，自己做好冪等蔓同。

對于多master的場景，比如redlock蹲诀，我們來看這樣一個場景：

假設(shè)有5個redis的節(jié)點(diǎn)：A斑粱、B、C脯爪、D则北、E，沒有做持久化痕慢。

client1從A尚揣、B、C 3個節(jié)點(diǎn)獲取鎖成功掖举，那么client1獲取鎖成功快骗。

節(jié)點(diǎn)C掛了。

client2從C、D方篮、E獲取鎖成功名秀，client2也獲取鎖成功，那么在同一時刻client1和client2同時獲取鎖藕溅，redlock被玩壞了匕得。

怎么解決呢？最容易想到的方案是打開持久化蜈垮。持久化可以做到持久化每一條redis命令耗跛，但這對性能影響會很大裕照，一般不會采用攒发，如果不采用這種方式，在節(jié)點(diǎn)掛的時候肯定會損失小部分的數(shù)據(jù)晋南，可能我們的鎖就在其中惠猿。

另一個方案是延遲啟動。就是一個節(jié)點(diǎn)掛了修復(fù)后负间，不立即加入偶妖，而是等待一段時間再加入，等待時間要大于宕機(jī)那一刻所有鎖的最大TTL政溃。

但這個方案依然不能解決問題趾访，如果在上述步驟3中B和C都掛了呢，那么只剩A董虱、D扼鞋、E三個節(jié)點(diǎn)，從D和E獲取鎖成功就可以了愤诱，還是會出問題云头。那么只能增加master節(jié)點(diǎn)的總量，緩解這個問題了淫半。增加master節(jié)點(diǎn)會提高穩(wěn)定性溃槐，但是也增加了成本，需要在兩者之間權(quán)衡科吭。

任務(wù)執(zhí)行時間超過鎖的TTL

之前產(chǎn)線上出現(xiàn)過因?yàn)榫W(wǎng)絡(luò)延遲導(dǎo)致任務(wù)的執(zhí)行時間遠(yuǎn)超預(yù)期昏滴，鎖過期，被多個線程執(zhí)行的情況对人。

這個問題是所有分布式鎖都要面臨的問題谣殊，包括基于zookeeper和DB實(shí)現(xiàn)的分布式鎖，這是鎖過期了和client不知道鎖過期了之間的矛盾规伐。

在加鎖的時候蟹倾，我們一般都會給一個鎖的TTL，這是為了防止加鎖后client宕機(jī)，鎖無法被釋放的問題鲜棠。但是所有這種姿勢的用法都會面臨同一個問題肌厨，就是沒發(fā)保證client的執(zhí)行時間一定小于鎖的TTL。雖然大多數(shù)程序員都會樂觀的認(rèn)為這種情況不可能發(fā)生豁陆，我也曾經(jīng)這么認(rèn)為柑爸，直到被現(xiàn)實(shí)一次又一次的打臉。

事件驅(qū)動盒音，所謂的reactor模式

redis問題總結(jié)：

1表鳍；FD泄露：

當(dāng)系統(tǒng)剩余內(nèi)存不足以fork子進(jìn)程時，AOF重寫子進(jìn)程啟動失敗祥诽，Redis不斷嘗試啟動AOF重寫子進(jìn)程譬圣，終于在數(shù)小時后將允許的fd數(shù)耗盡，此時錯誤log為“Error opening /setting AOF rewrite IPC pipes: Numerical result out of range”雄坪。

解決方案：

1厘熟、設(shè)置linux系統(tǒng)的vm.overcommit_memory = 1（其意義可查閱man手冊，本文不再展開）维哈，盡量減少子進(jìn)程fork失敗的情況绳姨；

2、設(shè)置Redis的maxmemory限制阔挠，當(dāng)內(nèi)存使用達(dá)到一定比例時不再接受新的數(shù)據(jù)飘庄；

3、使用主從備份购撼，或bgsave持久化（RDB方式無此問題）跪削，關(guān)閉AOF持久化，等下一版本發(fā)布份招。

4切揭、升級3.2.9 版本。

2.動碼攻擊：當(dāng)時IP統(tǒng)計锁摔、手機(jī)統(tǒng)計 都在一個redis集群廓旬。后面對于頻次統(tǒng)計遷移到一個統(tǒng)計集群。不存明細(xì)

3.很多key沒有設(shè)置過期時間谐腰，通過scan命令去ttl

4.hash tag問題孕豹，誤用了{(lán)g}前綴，導(dǎo)致該節(jié)點(diǎn)數(shù)據(jù)集中十气、讀寫集中

不要存儲大key（NONE）

減少存儲的字段（DONE）

通過映射励背，縮短字段（DONE）

? ? userMobileNo? ? ? ? ?? u

? ? deviceId? ? ? ? ? ? ? ? ?? d

? ? tag_first_withdraw ?? A001

業(yè)務(wù)上精簡數(shù)據(jù)（FAIL）

? ? 只存儲7天的數(shù)據(jù)

分段hash（TODO）

————————————————

8、Java GC機(jī)制砸西？GC Roots有哪些叶眉？址儒。

9、對方法區(qū)和永久區(qū)的理解以及它們之間的關(guān)系衅疙？

建議讀一下<深入理解java虛擬機(jī)>這本書.這里面是這樣闡述方法區(qū)的:用于存儲已經(jīng)被JVM加載的類信息,常量,靜態(tài)變量等.雖然JVM規(guī)范把方法區(qū)描述為堆的一個邏輯部分,

但是他卻有另外的一個別名叫做Non-Heap(非堆),目的是個JVM的方法區(qū)分開來.很多人吧方法區(qū)稱為永久代,但是兩者其實(shí)并不等價.永久代只是來實(shí)現(xiàn)方法區(qū)而已,

這樣HotSpot可以像管理java的堆內(nèi)存一樣管理這部分的內(nèi)存,能夠省去專門為方法區(qū)編寫內(nèi)存代碼管理的工作.我覺得讀完這段話,應(yīng)該能明白方法區(qū)和永久代的關(guān)系.

我認(rèn)為方法區(qū)使用的是JVM的堆內(nèi)存,但是JVM團(tuán)隊想?yún)^(qū)分開來,所以有重新起名叫做方法區(qū),那么方法區(qū)和永久代到底是很么關(guān)系,上面的一段話其實(shí)已經(jīng)說明了,

方法區(qū)和永久代本質(zhì)上不是等號的,永久代只是為了實(shí)現(xiàn)方法區(qū),使得JVM可以通過像管理堆內(nèi)存一樣去實(shí)現(xiàn)管理方法區(qū)的GC機(jī)制.

元空間在取代永久代之后莲趣，唯一的不同之處在于，元空間所占用的內(nèi)存為本地內(nèi)存饱溢，不在是JVM申請的內(nèi)存补疑，所以只要機(jī)器還有內(nèi)存尸红，元空間就可以一直申請使用漂问。

10萍启、Spring怎樣解決循環(huán)依賴的問題？

11肋杖、分布式緩存有哪些技術(shù)框架

12溉仑、如何解決線上問題，步驟和解決辦法（運(yùn)維知識）

13兽愤、除開gdb以外彼念，有哪些服務(wù)端調(diào)試手段

14、hash索引的實(shí)現(xiàn)原理

總結(jié)一下 AVL 樹的優(yōu)點(diǎn)：

不錯的查找性能（O（logn））浅萧，不存在極端的低效查找的情況。

可以實(shí)現(xiàn)范圍查找哲思、數(shù)據(jù)排序洼畅。

看起來 AVL 樹作為數(shù)據(jù)查找的數(shù)據(jù)結(jié)構(gòu)確實(shí)很不錯，但是 AVL 樹并不適合做 Mysql 數(shù)據(jù)庫的索引數(shù)據(jù)結(jié)構(gòu)棚赔，因?yàn)榭紤]一下這個問題：

數(shù)據(jù)庫查詢數(shù)據(jù)的瓶頸在于磁盤 IO帝簇，如果使用的是 AVL 樹，我們每一個樹節(jié)點(diǎn)只存儲了一個數(shù)據(jù)靠益，我們一次磁盤 IO 只能取出來一個節(jié)點(diǎn)上的數(shù)據(jù)加載到內(nèi)存里丧肴，那比如查詢 id=7 這個數(shù)據(jù)我們就要進(jìn)行磁盤 IO 三次，

這是多么消耗時間的胧后。所以我們設(shè)計數(shù)據(jù)庫索引時需要首先考慮怎么盡可能減少磁盤 IO 的次數(shù)芋浮。

磁盤 IO 有個有個特點(diǎn)，就是從磁盤讀取 1B 數(shù)據(jù)和 1KB 數(shù)據(jù)所消耗的時間是基本一樣的壳快，我們就可以根據(jù)這個思路纸巷，我們可以在一個樹節(jié)點(diǎn)上盡可能多地存儲數(shù)據(jù)，一次磁盤 IO 就多加載點(diǎn)數(shù)據(jù)到內(nèi)存眶痰，這就是 B 樹瘤旨，B+樹的的設(shè)計原理了

B 樹和 B+樹有什么不同呢？

第一竖伯，B 樹一個節(jié)點(diǎn)里存的是數(shù)據(jù)存哲，而 B+樹存儲的是索引（地址）因宇，所以 B 樹里一個節(jié)點(diǎn)存不了很多個數(shù)據(jù)，但是 B+樹一個節(jié)點(diǎn)能存很多索引祟偷，B+樹葉子節(jié)點(diǎn)存所有的數(shù)據(jù)羽嫡。

第二，B+樹的葉子節(jié)點(diǎn)是數(shù)據(jù)階段用了一個鏈表串聯(lián)起來肩袍，便于范圍查找杭棵。

通過 B 樹和 B+樹的對比我們看出，B+樹節(jié)點(diǎn)存儲的是索引氛赐，在單個節(jié)點(diǎn)存儲容量有限的情況下魂爪，單節(jié)點(diǎn)也能存儲大量索引，使得整個 B+樹高度降低艰管，減少了磁盤 IO滓侍。

其次，B+樹的葉子節(jié)點(diǎn)是真正數(shù)據(jù)存儲的地方牲芋，葉子節(jié)點(diǎn)用了鏈表連接起來撩笆，這個鏈表本身就是有序的，在數(shù)據(jù)范圍查找時缸浦，更具備效率夕冲。

因此 Mysql 的索引用的就是 B+樹，B+樹在查找效率裂逐、范圍查找中都有著非常不錯的性能歹鱼。

InnoDB一棵B+樹可以存放多少行數(shù)據(jù)？

磁盤扇區(qū)（512字節(jié)）卜高、文件系統(tǒng)（4kb）弥姻、InnoDB存儲引擎（16kb）都有各自的最小存儲單元。

----------------------------------------------------------------------------------

15掺涛、mysql的innoddb和MyIsam兩種引擎的區(qū)別（沒答上來）

1. InnoDB 支持事務(wù)庭敦，MyISAM 不支持事務(wù)。這是 MySQL 將默認(rèn)存儲引擎從 MyISAM 變成 InnoDB 的重要原因之一薪缆；

2. InnoDB 支持外鍵秧廉，而 MyISAM 不支持。對一個包含外鍵的 InnoDB 表轉(zhuǎn)為 MYISAM 會失敯恰定血；

3. InnoDB 是聚集索引，MyISAM 是非聚集索引诞外。聚簇索引的文件存放在主鍵索引的葉子節(jié)點(diǎn)上澜沟，

因此 InnoDB 必須要有主鍵，通過主鍵索引效率很高峡谊。但是輔助索引需要兩次查詢茫虽，先查詢到主鍵刊苍，然后再通過主鍵查詢到數(shù)據(jù)。

因此濒析，主鍵不應(yīng)該過大正什，因?yàn)橹麈I太大，其他索引也都會很大号杏。而 MyISAM 是非聚集索引婴氮，數(shù)據(jù)文件是分離的，索引保存的是數(shù)據(jù)文件的指針盾致。主鍵索引和輔助索引是獨(dú)立的主经。

4. InnoDB 不保存表的具體行數(shù)，執(zhí)行 select count(*) from table 時需要全表掃描庭惜。而MyISAM 用一個變量保存了整個表的行數(shù)罩驻，執(zhí)行上述語句時只需要讀出該變量即可，速度很快护赊；? ?

5. InnoDB 最小的鎖粒度是行鎖惠遏，MyISAM 最小的鎖粒度是表鎖。一個更新語句會鎖住整張表骏啰，導(dǎo)致其他查詢和更新都會被阻塞节吮，因此并發(fā)訪問受限。這也是 MySQL 將默認(rèn)存儲引擎從 MyISAM 變成 InnoDB 的重要原因之一

16器一、mysql數(shù)據(jù)庫索引的實(shí)現(xiàn)原理

17课锌、一臺機(jī)器只有1G物理內(nèi)存，是否程序可以獲取到2G祈秕，為什么。

18雏胃、描述请毛，操作系統(tǒng)虛擬內(nèi)存是如何實(shí)現(xiàn)的

用戶進(jìn)程向操作系統(tǒng)發(fā)出內(nèi)存申請請求

系統(tǒng)會檢查進(jìn)程的虛擬地址空間是否被用完，如果有剩余瞭亮，給進(jìn)程分配虛擬地址

系統(tǒng)為這塊虛擬地址創(chuàng)建的內(nèi)存映射（Memory Mapping）方仿，并將它放進(jìn)該進(jìn)程的頁表（Page Table）

系統(tǒng)返回虛擬地址給用戶進(jìn)程，用戶進(jìn)程開始訪問該虛擬地址

CPU 根據(jù)虛擬地址在此進(jìn)程的頁表（Page Table）中找到了相應(yīng)的內(nèi)存映射（Memory Mapping）统翩，但是這個內(nèi)存映射（Memory Mapping）沒有和物理內(nèi)存關(guān)聯(lián)仙蚜，于是產(chǎn)生缺頁中斷

操作系統(tǒng)收到缺頁中斷后，分配真正的物理內(nèi)存并將它關(guān)聯(lián)到頁表相應(yīng)的內(nèi)存映射（Memory Mapping）厂汗。中斷處理完成后 CPU 就可以訪問內(nèi)存了

當(dāng)然缺頁中斷不是每次都會發(fā)生委粉，只有系統(tǒng)覺得有必要延遲分配內(nèi)存的時候才用的著，也即很多時候在上面的第 3 步系統(tǒng)會分配真正的物理內(nèi)存并和內(nèi)存映射（Memory Mapping）進(jìn)行關(guān)聯(lián)娶桦。

19贾节、vector擴(kuò)容的原理

20汁汗、什么環(huán)節(jié)會發(fā)送RST包

21、垃圾回收栗涂、redis知牌、異常錯誤捕獲、消息隊列斤程、kafka日志框架

22角寸、秒殺系統(tǒng)怎么設(shè)計，性能優(yōu)化（網(wǎng)站反應(yīng)很慢 怎么優(yōu)化）

23忿墅、怎么保證分布式數(shù)據(jù)的一致性 項(xiàng)目經(jīng)驗(yàn)

24扁藕、redis數(shù)據(jù)結(jié)構(gòu) 持久化方式 和高峰期如何避免雪崩、主從同步球匕。

run-to-complete 模型纹磺、epoll 網(wǎng)絡(luò)模型

25、唯一索引和key索引亮曹。HTTP協(xié)議相關(guān)橄杨。如何實(shí)現(xiàn)一個hash數(shù)據(jù)結(jié)構(gòu)。

26照卦、io模型

27式矫、tcp粘包問題

28、web漏洞

29役耕、http2.0有那些特性

30采转、io復(fù)用select，poll瞬痘，epoll區(qū)別

31故慈、es，zk框全，etcd察绷，kafka了解？

總的來說Kafka快的原因：

1津辩、partition順序讀寫拆撼，充分利用磁盤特性，這是基礎(chǔ)喘沿；

2闸度、Producer生產(chǎn)的數(shù)據(jù)持久化到broker，采用mmap文件映射蚜印，實(shí)現(xiàn)順序的快速寫入莺禁；

3、Customer從broker讀取數(shù)據(jù)晒哄，采用sendfile睁宰，將磁盤文件讀到OS內(nèi)核緩沖區(qū)后肪获，直接轉(zhuǎn)到socket buffer進(jìn)行網(wǎng)絡(luò)發(fā)送。

mmap 和 sendfile總結(jié)

1柒傻、都是Linux內(nèi)核提供孝赫、實(shí)現(xiàn)零拷貝的API；

2红符、sendfile 是將讀到內(nèi)核空間的數(shù)據(jù)青柄，轉(zhuǎn)到socket buffer，進(jìn)行網(wǎng)絡(luò)發(fā)送预侯；

3致开、mmap將磁盤文件映射到內(nèi)存，支持讀和寫萎馅，對內(nèi)存的操作會反映在磁盤文件上双戳。

RocketMQ 在消費(fèi)消息時，使用了 mmap糜芳。kafka 使用了 sendFile飒货。

32、分布式鎖怎么做峭竣？

33塘辅、負(fù)載均衡怎樣做

34、tcp皆撩，項(xiàng)目扣墩，解決過的難點(diǎn)問題，思路過程

35扛吞、同步異步

36呻惕、進(jìn)程線程

37、Redis 和 數(shù)據(jù)庫

38滥比、分布式架構(gòu)拿nginx來講的

39蟆融、進(jìn)程間通信

40、zookeeper守呜，kafka的知識，日志處理的架構(gòu)山憨，分布式系統(tǒng)的基本要素啥的查乒。?

41、Threadlocal

42郁竟、web server如何實(shí)現(xiàn)大文件的上傳下載

43玛迄、用sed替換某一行的某個詞? sed -i '1s/xxx/ddd' file

44、kill命令的作用棚亩，不同選項(xiàng)下有什么區(qū)別

45蓖议、10秒頻控虏杰，在10秒發(fā)起10萬請求，在第11秒發(fā)起10萬請求勒虾，這樣我就在2秒內(nèi)發(fā)起了20萬請求纺阔，你如何解決？降低時間窗口期修然，10秒的窗口期換成2秒笛钝。

46、ads如何做分庫訪問db的愕宋。

47玻靡、走主鍵 一次io

48、走聯(lián)合索引 兩次io

49中贝、不走索引 多次io

50囤捻、如果讓你自己來實(shí)現(xiàn)分庫分表你怎么做？

51邻寿、在32gb的內(nèi)存里對1tb數(shù)據(jù)排序

52蝎土、hadoop和hive是做什么的，hive的udf是什么老厌，一張大表和一張小表join瘟则，該如何做效率更高？

53枝秤、Cassandra的是如何存儲的醋拧？為什么不用mysql？二者的區(qū)別淀弹。

54丹壕、elastic search如何存儲，如何查詢薇溃，其中做了什么優(yōu)化菌赖？什么是倒排索引？

55沐序、數(shù)據(jù)庫琉用，mysql和Postgre的事務(wù)是如何實(shí)現(xiàn)的。

56策幼、Postgre和mysql數(shù)據(jù)庫的區(qū)別是什么邑时。

57、32位的系統(tǒng)特姐，最多可以new出多大的內(nèi)存晶丘？

58、32位的系統(tǒng)，最多可以創(chuàng)建多少的線程浅浮？

59沫浆、什么進(jìn)程kill -9殺不掉（處于D狀態(tài)的進(jìn)程殺不掉）。

60滚秩、跨國的專線（高時延专执，大帶寬）的TCP通訊如何優(yōu)化？

61叔遂、設(shè)置一個合理的發(fā)送和接收緩沖區(qū)（帶寬時延乘積）

62他炊、調(diào)大初始擁塞控制窗口大小

63、挑戰(zhàn)一致性hash擴(kuò)容過程已艰，配額服務(wù)擴(kuò)容如何做到平滑痊末，對業(yè)務(wù)不影響，或者業(yè)務(wù)不感知哩掺。

64凿叠、進(jìn)程間通訊有哪些機(jī)制？那種速度最快嚼吞？為什么盒件？

65、cap定理舱禽、base理論炒刁、Redis集群

66、微服務(wù)和soa的區(qū)別

67誊稚、ThreadLocal用來干啥的翔始，底層實(shí)現(xiàn)原理

3. 常見數(shù)據(jù)結(jié)構(gòu)算法題

1、N個人中至少兩個人同一天生日的概率

2里伯、整數(shù)數(shù)組中找出前邊的數(shù)都比自己小城瞎，后邊的數(shù)都比自己大的數(shù)

3、字符串串去空格

4疾瓮、手寫鏈表反轉(zhuǎn)函數(shù)脖镀，要求是不用其他輔助的存儲

5、二叉樹的遍歷

6狼电、計算二叉樹高度

7蜒灰、字符串轉(zhuǎn)整形?

8、寫一個lru算法

9肩碟、手寫算法 ：多文件內(nèi)容排序卷员，求根號算法

10、排序 時間復(fù)雜度

11腾务、紅黑樹、二叉樹削饵、冒泡排序岩瘦、快速排序

12未巫、給定一個有序的旋轉(zhuǎn)數(shù)組，查找某個元素是否在數(shù)組內(nèi)启昧，eg： ［4 5 6 1 2 3］target=5

13叙凡、 給定一個物品在各個時間點(diǎn)的價格，求進(jìn)行一次買賣之后最大獲利密末。

變形為：求多次買賣的最大獲利

14握爷、 設(shè)計一個最優(yōu)時空復(fù)雜度的位循環(huán)隊列

15、實(shí)現(xiàn)一個LRU

16严里、系統(tǒng)為某進(jìn)程分配了4個頁框新啼，該進(jìn)程已訪問的頁號序列為2,0,2,9,3,4,2,8,2,4,8,4,5。若進(jìn)程要訪問的下一頁的頁號為7刹碾，依據(jù)LRU算法燥撞，應(yīng)淘汰頁的頁號是幾號？

17迷帜、手寫深拷貝實(shí)現(xiàn)代碼

18物舒、哈夫曼編碼

19、有序數(shù)組戏锹，相同的元素最多保留2個冠胯，O(1)的算法

20、手寫代碼锦针，求鏈表倒數(shù)第k個元素

21.手寫代碼荠察，求數(shù)組中出現(xiàn)次數(shù)超過一般的數(shù)

22. 有一個隨機(jī)數(shù)生成器，能以p概率生成0伞插，1-p概率生成1割粮。利用這個生成器等概率生成0-6。

23. 在32gb的內(nèi)存里對1tb數(shù)據(jù)排序

24. 簡單動態(tài)規(guī)劃媚污，爬樓梯問題

25舀瓢、最長公共子序列

26、二維數(shù)組耗美，回字型輸出

27京髓、一個數(shù)組，和sum商架，求出數(shù)組中所有可能的任意元素（一個元素只能用一次）的和等于sum的組合堰怨。

28、柱狀圖求最大矩形面積

29蛇摸、大整數(shù)字串相乘

30备图、N*N地圖隨機(jī)放X個雷，打印地圖，每格顯示周邊雷的個數(shù)

有沒有一種一定能保證線程安全的代碼寫法揽涮？（偷偷告訴你抠藕，真的有！）

多個線程如何保持A1B2C3等順序交替輸出蒋困？

synchronized volatile的CPU原語是如何實(shí)現(xiàn)的盾似？

無鎖、偏向鎖雪标、輕量級鎖零院、重量級鎖有什么差別？

如何正確的啟動和停止一個線程村刨？

線程和纖程的區(qū)別的是什么告抄？為什么纖程比較輕量級？

ThreadLocal有沒有內(nèi)存泄漏的問題烹困？為什么玄妈？

下列三種業(yè)務(wù)，應(yīng)該如何使用線程池：

高并發(fā)髓梅、任務(wù)執(zhí)行時間短

并發(fā)不高拟蜻、任務(wù)執(zhí)行時間長

并發(fā)高、業(yè)務(wù)執(zhí)行時間長

<p>+2枯饿，來看看這些問題吧</p>

<p>01 支付寶一面</p>

<p>介紹一下自己酝锅。</p>

<p>項(xiàng)目參與的核心設(shè)計有哪些</p>

<p>ArrayList和LinkedList底層</p>

<p>HashMap及線程安全的ConcurrentHashMap，以及各自優(yōu)劣勢</p>

<p>Java如何實(shí)現(xiàn)線程安全</p>

<p>Synchronized和Lock哪個更好奢方？</p>

<p>HashMap中的get()方法是如何實(shí)現(xiàn)的搔扁？</p>

<p>HashMap可以用在哪些場景？</p>

<p>JVM蟋字，垃圾回收機(jī)制稿蹲，內(nèi)存劃分等</p>

<p>SQL優(yōu)化，常用的索引鹊奖？</p>

<p>還有什么問題需要問的苛聘。</p>

<p><strong>02 支付寶二面</strong></p>

<p>沒有自我介紹，直接問做過哪些Java開發(fā)相關(guān)的項(xiàng)目忠聚。</p>

<p>對哪些技術(shù)比較熟悉设哗？</p>

<p>多線程狀態(tài)圖，狀態(tài)如何流轉(zhuǎn)两蟀？</p>

<p>死鎖网梢，死鎖原因</p>

<p>頁鎖、樂觀鎖赂毯、悲觀鎖战虏？</p>

<p>樂觀鎖如何保證線程安全拣宰？</p>

<p>用過線程池嗎，對應(yīng)的好處活烙，如何用徐裸？</p>

<p>兩個10G的文件，里面是一些url啸盏，內(nèi)存只有1G，如何將這兩個文件合并骑祟，找到相同的url回懦？</p>

<p>1000個多并發(fā)線程，10臺機(jī)器次企，每臺機(jī)器4核的怯晕，設(shè)計線程池大小。</p>

<p>代碼題：兩個有序數(shù)組缸棵，數(shù)組中存在重復(fù)數(shù)字舟茶，合并成一個有序數(shù)組，去除重復(fù)數(shù)字堵第。</p>

<p>說一下自己的優(yōu)點(diǎn)吧凉。</p>

<p>03&nbsp;<strong>支付寶三面</strong></p>

<p>jvm性能調(diào)優(yōu)都做了什么</p>

<p>數(shù)據(jù)庫性能調(diào)優(yōu)如何做</p>

<p>分布式系統(tǒng)原理：CAP，最終一致性踏志，冪等操作等</p>

<p>高并發(fā)情況下阀捅，我們系統(tǒng)是如何支撐大量的請求的</p>

<p>集群如何同步會話狀態(tài)</p>

<p>常用NOSQL，有做過比較?</p>

<p>什么情況會出現(xiàn)雪崩针余，以及如何應(yīng)對饲鄙？</p>

<p>負(fù)載均衡的原理</p>

<p>數(shù)據(jù)庫事務(wù)屬性</p>

<p>與同事溝通的時候，如果遇到?jīng)_突了如何解決圆雁？</p>

<p>工作中覺得哪方面欠缺忍级？</p>

<p>有問題要問么？</p>

<p>期望薪水伪朽？</p>

<p>其實(shí)結(jié)合面試題轴咱，大家不難看出，題目基本涵蓋的方面就那一些驱负，最主要的嗦玖，&nbsp;<strong>多線程與高并發(fā)，jvm跃脊、設(shè)計模式宇挫、redis，zookeeper酪术，數(shù)據(jù)庫</strong>&nbsp;這6個模塊器瘪，再接下來就是一些具體項(xiàng)目的應(yīng)用

1.二叉搜索樹和平衡二叉樹有什么關(guān)系翠储，強(qiáng)平衡二叉樹（AVL樹）和弱平衡二叉樹（紅黑樹）有什么區(qū)別

二叉搜索樹：也稱二叉查找樹，或二叉排序樹橡疼。定義也比較簡單援所，要么是一顆空樹，要么就是具有如下性質(zhì)的二叉樹：

（1）若任意節(jié)點(diǎn)的左子樹不空欣除，則左子樹上所有結(jié)點(diǎn)的值均小于它的根結(jié)點(diǎn)的值住拭；（

2）若任意節(jié)點(diǎn)的右子樹不空，則右子樹上所有結(jié)點(diǎn)的值均大于它的根結(jié)點(diǎn)的值历帚；

（3）任意節(jié)點(diǎn)的左滔岳、右子樹也分別為二叉查找樹；

（4）沒有鍵值相等的節(jié)點(diǎn)挽牢。平衡二叉樹：在二叉搜索樹的基礎(chǔ)上多了兩個重要的特點(diǎn)

（1）左右兩子樹的高度差的絕對值不能超過1谱煤；

（2）左右兩子樹也是一顆平衡二叉樹。

紅黑書：紅黑樹是在普通二叉樹上禽拔，對每個節(jié)點(diǎn)添加一個顏色屬性形成的刘离，需要同時滿足一下五條性質(zhì)

（1）節(jié)點(diǎn)是紅色或者是黑色；

（2）根節(jié)點(diǎn)是黑色睹栖；

（3）每個葉節(jié)點(diǎn)（NIL或空節(jié)點(diǎn)）是黑色硫惕；

（4）每個紅色節(jié)點(diǎn)的兩個子節(jié)點(diǎn)都是黑色的（也就是說不存在兩個連續(xù)的紅色節(jié)點(diǎn)）；

（5）從任一節(jié)點(diǎn)到其沒個葉節(jié)點(diǎn)的所有路徑都包含相同數(shù)目的黑色節(jié)點(diǎn)磨淌。

區(qū)別：AVL樹需要保持平衡疲憋，但它的旋轉(zhuǎn)太耗時，而紅黑樹就是一個沒有AVL樹那樣平衡梁只，因此插入缚柳、刪除效率會高于AVL樹，而AVL樹的查找效率顯然高于紅黑樹搪锣。

B樹和B+樹的區(qū)別秋忙，為什么MySQL要使用B+樹B樹：

（1）關(guān)鍵字集合分布在整顆樹中；（2）任何一個關(guān)鍵字出現(xiàn)且只出現(xiàn)在一個結(jié)點(diǎn)中构舟；（3）搜索有可能在非葉子結(jié)點(diǎn)結(jié)束灰追；（4）其搜索性能等價于在關(guān)鍵字全集內(nèi)做一次二分查找；

B+樹：

（1）有n棵子樹的非葉子結(jié)點(diǎn)中含有n個關(guān)鍵字（b樹是n-1個）狗超，這些關(guān)鍵字不保存數(shù)據(jù)弹澎，只用來索引，所有數(shù)據(jù)都保存在葉子節(jié)點(diǎn)（b樹是每個關(guān)鍵字都保存數(shù)據(jù)）努咐；

（2）所有的葉子結(jié)點(diǎn)中包含了全部關(guān)鍵字的信息苦蒿，及指向含這些關(guān)鍵字記錄的指針，且葉子結(jié)點(diǎn)本身依關(guān)鍵字的大小自小而大順序鏈接渗稍；

（3）所有的非葉子結(jié)點(diǎn)可以看成是索引部分佩迟，結(jié)點(diǎn)中僅含其子樹中的最大（或最型爬摹）

關(guān)鍵字；（4）通常在b+樹上有兩個頭指針报强，一個指向根結(jié)點(diǎn)灸姊，一個指向關(guān)鍵字最小的葉子結(jié)點(diǎn)；

（5）同一個數(shù)字會在不同節(jié)點(diǎn)中重復(fù)出現(xiàn)秉溉，根節(jié)點(diǎn)的最大元素就是b+樹的最大元素力惯。B+樹相比于B樹的查詢優(yōu)勢：

（1）B+樹的中間節(jié)點(diǎn)不保存數(shù)據(jù)，所以磁盤頁能容納更多節(jié)點(diǎn)元素召嘶，更“矮胖”夯膀；

（2）B+樹查詢必須查找到葉子節(jié)點(diǎn)，B樹只要匹配到即可不用管元素位置苍蔬，因此B+樹查找更穩(wěn)定（并不慢）；

（3）對于范圍查找來說蝴蜓，B+樹只需遍歷葉子節(jié)點(diǎn)鏈表即可碟绑，B樹卻需要重復(fù)地中序遍歷參考文章：

如何解決Hash沖突通過引入單向鏈表來解決Hash沖突。當(dāng)出現(xiàn)Hash沖突時茎匠，比較新老key值是否相等格仲，如果相等，新值覆蓋舊值诵冒。如果不相等凯肋，新值會存入新的Node結(jié)點(diǎn)，

指向老節(jié)點(diǎn)汽馋，形成鏈?zhǔn)浇Y(jié)構(gòu)侮东，即鏈表。當(dāng)Hash沖突發(fā)生頻繁的時候豹芯，會導(dǎo)致鏈表長度過長悄雅，以致檢索效率低，所以JDK1.8之后引入了紅黑樹铁蹈，

當(dāng)鏈表長度大于8時宽闲，鏈表會轉(zhuǎn)換成紅黑書，以此提高查詢性能握牧。

epoll和poll的區(qū)別容诬，

及其應(yīng)用場景select和epoll都是I/O多路復(fù)用的方式，但是select是通過不斷輪詢監(jiān)聽socket實(shí)現(xiàn)沿腰，e

poll是當(dāng)socket有變化時通過回掉的方式主動告知用戶進(jìn)程實(shí)現(xiàn)參考文章:https://www.cnblogs.com/hsmwlyl/p/10652503.html5.

簡述線程池原理览徒，F(xiàn)ixedThreadPool用的阻塞隊列是什么？Java線程池的實(shí)現(xiàn)原理其實(shí)就是一個線程集合workerSet和一個阻塞隊列workQueue矫俺。

當(dāng)用戶向線程池提交一個任務(wù)(也就是線程)時吱殉，線程池會先將任務(wù)放入workQueue中掸冤。workerSet中的線程會不斷的從workQueue中獲取線程然后執(zhí)行。

當(dāng)workQueue中沒有任務(wù)的時候友雳，worker就會阻塞稿湿，直到隊列中有任務(wù)了就取出來繼續(xù)執(zhí)行。FixedThreadPool使用的是“無界隊列”LinkedBlockingQueue

sychronized和ReentrantLock的區(qū)別（1）ReentrantLock顯示獲得押赊、釋放鎖饺藤，synchronized隱式獲得釋放鎖（2）ReentrantLock可響應(yīng)中斷、可輪回流礁，synchronized是不可以響應(yīng)中斷的涕俗，為處理鎖的不可用性提供了更高的靈活性

（3）ReentrantLock是API級別的，synchronized是JVM級別的（4）ReentrantLock可以實(shí)現(xiàn)公平鎖（5）ReentrantLock通過Condition可以綁定多個條件

sychronized的自旋鎖神帅、偏向鎖倡缠、輕量級鎖、重量級鎖缰儿，分別介紹和聯(lián)系自旋鎖：

果持有鎖的線程能在很短時間內(nèi)釋放鎖資源乳丰，那么那些等待競爭鎖的線程就不需要做內(nèi)核態(tài)和用戶態(tài)之間的切換進(jìn)入阻塞掛起狀態(tài)，它們只需要等一等（自旋）霎桅，

等持有鎖的線程釋放鎖后即可立即獲取鎖栖疑，這樣就避免用戶線程和內(nèi)核的切換的消耗。偏向鎖：顧名思義滔驶，它會偏向于第一個訪問鎖的線程遇革，如果在運(yùn)行過程中，

同步鎖只有一個線程訪問揭糕，不存在多線程爭用的情況萝快，則線程是不需要觸發(fā)同步的，減少加鎖／解鎖的一些CAS操作（比如等待隊列的一些CAS操作）插佛，

這種情況下杠巡，就會給線程加一個偏向鎖。如果在運(yùn)行過程中雇寇，遇到了其他線程搶占鎖氢拥，則持有偏向鎖的線程會被掛起，JVM會消除它身上的偏向鎖锨侯，將鎖恢復(fù)到標(biāo)準(zhǔn)的輕量級鎖嫩海。

輕量級鎖：輕量級鎖是由偏向所升級來的，偏向鎖運(yùn)行在一個線程進(jìn)入同步塊的情況下囚痴，當(dāng)?shù)诙€線程加入鎖爭用的時候叁怪，偏向鎖就會升級為輕量級鎖；重量級鎖：我們知道深滚，

我們要進(jìn)入一個同步奕谭、線程安全的方法時涣觉，是需要先獲得這個方法的鎖的，退出這個方法時血柳，則會釋放鎖官册。如果獲取不到這個鎖的話，意味著有別的線程在執(zhí)行這個方法难捌，

這時我們就會馬上進(jìn)入阻塞的狀態(tài)膝宁，等待那個持有鎖的線程釋放鎖，然后再把我們從阻塞的狀態(tài)喚醒根吁，我們再去獲取這個方法的鎖员淫。這種獲取不到鎖就馬上進(jìn)入阻塞狀態(tài)的鎖，

我們稱之為重量級鎖击敌。

HTTP有哪些問題介返，加密算法有哪些，針對不同加密方式可能產(chǎn)生的問題沃斤，及其HTTPS是如何保證安全傳輸?shù)腍TTP的不足：

通信使用明文映皆，內(nèi)容可能會被竊聽；不驗(yàn)證通信方的身份轰枝，因此有可能遭遇偽裝；無法證明報文的完整性组去，有可能已遭篡改鞍陨；

常用加密算法：MD5算法、DES算法从隆、AES算法诚撵、RSA算法

螞蟻Java二面

1.設(shè)計模式有哪些大類，及熟悉其中哪些設(shè)計模式創(chuàng)建型模式键闺、結(jié)構(gòu)型模式寿烟、行為型模式

volatile關(guān)鍵字，他是如何保證可見性辛燥，有序性volatile可以保證線程可見性且提供了一定的有序性筛武，

但是無法保證原子性。在JVM底層volatile是采用“內(nèi)存屏障”來實(shí)現(xiàn)的挎塌。觀察加入volatile關(guān)鍵字和沒有加入volatile關(guān)鍵字時所生成的匯編代碼發(fā)現(xiàn)徘六，

加入volatile關(guān)鍵字時，會多出一個lock前綴指令榴都，lock前綴指令實(shí)際上相當(dāng)于一個內(nèi)存屏障（也成內(nèi)存柵欄）待锈，

內(nèi)存屏障會提供3個功能：I.它確保指令重排序時不會把其后面的指令排到內(nèi)存屏障之前的位置，

也不會把前面的指令排到內(nèi)存屏障的后面嘴高；即在執(zhí)行到內(nèi)存屏障這句指令時竿音，在它前面的操作已經(jīng)全部完成和屎；

II.它會強(qiáng)制將對緩存的修改操作立即寫入主存；

III.如果是寫操作春瞬，它會導(dǎo)致其他CPU中對應(yīng)的緩存行無效柴信。

Java的內(nèi)存結(jié)構(gòu)，堆分為哪幾部分快鱼，

默認(rèn)年齡多大進(jìn)入老年代Java的內(nèi)存結(jié)構(gòu)：程序計數(shù)器颠印、虛擬機(jī)棧、本地方法棧抹竹、堆线罕、方法區(qū)。Java虛擬機(jī)根據(jù)對象存活的周期不同窃判，把堆內(nèi)存劃分為幾塊钞楼，一般分為新生代、老年代和永久代袄琳。

默認(rèn)的設(shè)置下询件，當(dāng)對象的年齡達(dá)到15歲的時候，也就是躲過15次Gc的時候唆樊，他就會轉(zhuǎn)移到老年代中去躲過15次GC之后進(jìn)入老年代宛琅。

4.ConcurrentHashMap如何保證線程安全，jdk1.8有什么變化JDK1.7：使用了分段鎖機(jī)制實(shí)現(xiàn)ConcurrentHashMap逗旁，ConcurrentHashMap在對象中保

存了一個Segment數(shù)組嘿辟，即將整個Hash表劃分為多個分段；而每個Segment元素片效，即每個分段則類似于一個Hashtable红伦；這樣，在執(zhí)行put操作時首先根據(jù)hash算法定位到元素屬于哪個Segment淀衣，然后對該Segment加鎖即可昙读。

因此，ConcurrentHashMap在多線程并發(fā)編程中可是實(shí)現(xiàn)多線程put操作膨桥，不過其最大并發(fā)度受Segment的個數(shù)限制蛮浑。JDK1.8：底層采用數(shù)組+鏈表+紅黑樹的方式實(shí)現(xiàn)，

而加鎖則采用CAS和synchronized

為什么ConcurrentHashMap底層為什么要紅黑樹因?yàn)榘l(fā)生hash沖突的時候只嚣，會在鏈表上新增節(jié)點(diǎn)陵吸，但是鏈表過長的話會影響檢索效率，引入紅黑書可以提高插入和查詢的效率介牙。

6.如何做的MySQL優(yōu)化MySQL的優(yōu)化有多種方式壮虫，我們可以從以下幾個方面入手：存儲引擎的選擇、字段類型的選擇、索引的選擇囚似、分區(qū)分表剩拢、主從復(fù)制、讀寫分離饶唤、SQL優(yōu)化徐伐。

講一下oom以及遇到這種情況怎么處理的，是否使用過日志分析工具OOM募狂，全稱“OutOfMemory”办素，翻譯成中文就是“內(nèi)存用完了”，

當(dāng)JVM因?yàn)闆]有足夠的內(nèi)存來為對象分配空間并且垃圾回收器也已經(jīng)沒有空間可回收時祸穷，就會拋出這個error性穿。

處理過程：首先通過內(nèi)存映射分析工具如EclipseMemoryAnalyzer堆dump出的異常堆轉(zhuǎn)儲進(jìn)行快照解析確認(rèn)內(nèi)存中的對象是否是必要的，

也就是先分清楚是內(nèi)存泄漏MemoryLeak還是MemoryOverflow如果是內(nèi)存泄漏可通過工具進(jìn)一步查看泄露的對象到GCRoots的引用鏈雷滚，

就能找到泄露對象是怎么通過路徑與GCRoots相關(guān)聯(lián)導(dǎo)致垃圾收集器無法回收他們?nèi)绻淮嬖谛孤毒蜋z查堆參數(shù)-Xmx與-Xms與機(jī)器物理內(nèi)存對比是否還可以

調(diào)大從代碼上檢測是否是某些對象的生命周期過長持有狀態(tài)時間過長嘗試減少代碼運(yùn)行期間的內(nèi)存消耗

螞蟻Java三面

1.項(xiàng)目介紹

2.你們怎么保證Redis緩存和數(shù)據(jù)庫的數(shù)據(jù)一致性需曾？可以通過雙刪延時策略來保證他們的一致性。

3.Redis緩存雪崩祈远？擊穿呆万？穿透？緩存雪崩：緩存同一時間大面積的失效车份，所以谋减，后面的請求都會落到數(shù)據(jù)庫上，

造成數(shù)據(jù)庫短時間內(nèi)承受大量請求而崩掉扫沼。緩存擊穿：key對應(yīng)的數(shù)據(jù)存在逃顶，但在redis中過期，此時若有大量并發(fā)請求過來充甚，這些請求發(fā)現(xiàn)緩存過期一般都會從后端DB加載數(shù)據(jù)并回設(shè)到緩存，

這個時候大并發(fā)的請求可能會瞬間把后端DB壓垮霸褒。緩存穿透：key對應(yīng)的數(shù)據(jù)在數(shù)據(jù)源并不存在伴找，每次針對此key的請求從緩存獲取不到，請求都會到數(shù)據(jù)源废菱，從而可能壓垮數(shù)據(jù)源技矮。

比如用一個不存在的用戶id獲取用戶信息，不論緩存還是數(shù)據(jù)庫都沒有殊轴，若黑客利用此漏洞進(jìn)行攻擊可能壓垮數(shù)據(jù)庫衰倦。

4.你熟悉哪些消息中間件,有做過性能比較?RocketMQ、RabbitMQ旁理、ActiveMQ樊零、Kafka