網(wǎng)絡(luò)編程

1. ISO模型與協(xié)議
2. http1.0：需要使用keep-alive參數(shù)來(lái)告知服務(wù)器端要建立一個(gè)長(zhǎng)連接
3. http1.1：默認(rèn)長(zhǎng)連接。支持只發(fā)送header信息，可以用作權(quán)限請(qǐng)求。支持Host域。
4. http2.0：多路復(fù)用的技術(shù)，做到同一個(gè)連接并發(fā)處理多個(gè)請(qǐng)求。HTTP2.0使用HPACK算法對(duì)header的數(shù)據(jù)進(jìn)行壓縮。支持HTTP2.0的web server請(qǐng)求數(shù)據(jù)的時(shí)候，服務(wù)器會(huì)順便把一些客戶端需要的資源一起推送到客戶端，免得客戶端再次創(chuàng)建連接發(fā)送請(qǐng)求到服務(wù)器端獲取。這種方式非常合適加載靜態(tài)資源。
5. 會(huì)話層:負(fù)責(zé)管理主機(jī)之間的會(huì)話進(jìn)程，負(fù)責(zé)建立、管理、終止進(jìn)程之間的會(huì)話。
6. 傳輸層:將上層數(shù)據(jù)分段并提供端到端的、可靠的或不可靠的傳輸，還要處理端到端的差錯(cuò)控制和流量控制問(wèn)題。協(xié)議TCP、UDP、SPX
7. 網(wǎng)絡(luò)層:對(duì)子網(wǎng)間的數(shù)據(jù)包進(jìn)行路由選擇。此外，網(wǎng)絡(luò)層還可以實(shí)現(xiàn)擁塞控制、網(wǎng)際互連等功能。協(xié)議IP、IPX、RIP、OSPF
8. 數(shù)據(jù)鏈路層:在不可靠的物理介質(zhì)上提供可靠的傳輸。該層的作用包括：物理地址尋址、數(shù)據(jù)的成幀、流量控制、數(shù)據(jù)的檢錯(cuò)、重發(fā)等。協(xié)議SDLC、HDLC、PPP、STP、幀中繼
9. TCP\IP模型與協(xié)議
10. 應(yīng)用層：?jiǎn)挝皇菙?shù)據(jù)段，協(xié)議有FTP、TELNET、HTTP、SMTP、SNMP、TFTP、NTP、DNS
11. 運(yùn)輸層：?jiǎn)挝皇菙?shù)據(jù)包，協(xié)議有TCP、UDP
12. 網(wǎng)絡(luò)層：?jiǎn)挝皇菙?shù)據(jù)幀，協(xié)議有IP
13. 網(wǎng)絡(luò)接口層：?jiǎn)挝皇潜忍?，ARP、RARP
14. 三次握手與四次揮手
15. BIO NIO AIO
16. BIO：同步阻塞IO，每個(gè)請(qǐng)求都要一個(gè)線程來(lái)處理。
17. NIO：同步非阻塞IO，一個(gè)線程可以處理多個(gè)請(qǐng)求，適用于短連接、小數(shù)據(jù)。
18. AIO：異步非阻塞IO，一個(gè)線程處理多個(gè)請(qǐng)求，使用回調(diào)函數(shù)實(shí)現(xiàn)，適用于長(zhǎng)連接、大數(shù)據(jù)。
19. DDOS攻擊原理與防御方式
20. HTTP Get Flood：發(fā)送大量會(huì)產(chǎn)生sql查詢的連接，使得數(shù)據(jù)庫(kù)負(fù)載很高。
21. CSRF跨站請(qǐng)求偽造原理攻擊者盜用了你的身份，以你的名義發(fā)送惡意請(qǐng)求。
22. CSRF攻擊是源于WEB的隱式身份驗(yàn)證機(jī)制！WEB的身份驗(yàn)證機(jī)制雖然可以保證一個(gè)請(qǐng)求是來(lái)自于某個(gè)用戶的瀏覽器，但卻無(wú)法保證該請(qǐng)求是用戶批準(zhǔn)發(fā)送的！
23. 防御方式：1.驗(yàn)證碼；2. 后臺(tái)生成token，讓前端請(qǐng)求攜帶。3.使用對(duì)稱加密，后端隨機(jī)給前端一個(gè)密鑰，前端進(jìn)行加密，后端解密。
24. 會(huì)話劫持通過(guò)暴力破解、 預(yù)測(cè)、竊?。ㄍㄟ^(guò)XSS攻擊）等方式獲取到用戶session
25. XSS攻擊XSS攻擊是Web攻擊中最常見(jiàn)的攻擊方法之一，它是通過(guò)對(duì)網(wǎng)頁(yè)注入可執(zhí)行代碼且成功地被瀏覽器執(zhí)行，達(dá)到攻擊的目的，形成了一次有效XSS攻擊，一旦攻擊成功，它可以獲取用戶的聯(lián)系人列表，然后向聯(lián)系人發(fā)送虛假詐騙信息，可以刪除用戶的日志等等，有時(shí)候還和其他攻擊方式同時(shí)實(shí)施比如SQL注入攻擊服務(wù)器和數(shù)據(jù)庫(kù)、Click劫持、相對(duì)鏈接劫持等實(shí)施釣魚(yú)，它帶來(lái)的危害是巨大的，是web安全的頭號(hào)大敵。
26. XSS反射型攻擊，惡意代碼并沒(méi)有保存在目標(biāo)網(wǎng)站，通過(guò)引誘用戶點(diǎn)擊一個(gè)鏈接到目標(biāo)網(wǎng)站的惡意鏈接來(lái)實(shí)施攻擊的。
27. XSS存儲(chǔ)型攻擊，惡意代碼被保存到目標(biāo)網(wǎng)站的服務(wù)器中，這種攻擊具有較強(qiáng)的穩(wěn)定性和持久性，比較常見(jiàn)場(chǎng)景是在博客，論壇等社交網(wǎng)站上，但OA系統(tǒng)，和CRM系統(tǒng)上也能看到它身影，比如：某CRM系統(tǒng)的客戶投訴功能上存在XSS存儲(chǔ)型漏洞，黑客提交了惡意攻擊代碼，當(dāng)系統(tǒng)管理員查看投訴信息時(shí)惡意代碼執(zhí)行，竊取了客戶的資料，然而管理員毫不知情，這就是典型的XSS存儲(chǔ)型攻擊。

• 解決方法
• 在表單提交或者url參數(shù)傳遞前，對(duì)需要的參數(shù)進(jìn)行過(guò)濾
• 過(guò)濾用戶輸入。檢查用戶輸入的內(nèi)容中是否有非法內(nèi)容。如<>（尖括號(hào)）、”（引號(hào)）、 ‘（單引號(hào)）、%（百分比符號(hào)）、;（分號(hào)）、()（括號(hào)）、&（& 符號(hào)）、+（加號(hào)）等

28.RPC與HTTP服務(wù)的區(qū)別

數(shù)據(jù)庫(kù)原理

1. MYISAM與innodb搜索引擎原理MyISAM引擎使用B+Tree作為索引結(jié)構(gòu)，葉節(jié)點(diǎn)的data域存放的是數(shù)據(jù)記錄的地址。其采用索引文件與數(shù)據(jù)文件，索引文件只存放索引，葉子節(jié)點(diǎn)存放數(shù)據(jù)的物理地址。數(shù)據(jù)文件存放數(shù)據(jù)。其索引方式是非聚集的。
2. InnoDB也使用B+Tree作為索引結(jié)構(gòu)。但是它的主索引與數(shù)據(jù)都放在一個(gè)文件中。這種索引叫做聚集索引，因?yàn)镮nnoDB的數(shù)據(jù)文件本身要按主鍵聚集，所以InnoDB要求表必須有主鍵（MyISAM可以沒(méi)有），如果沒(méi)有顯式指定，則MySQL系統(tǒng)會(huì)自動(dòng)選擇一個(gè)可以唯一標(biāo)識(shí)數(shù)據(jù)記錄的列作為主鍵，如果不存在這種列，則MySQL自動(dòng)為InnoDB表生成一個(gè)隱含字段作為主鍵，這個(gè)字段長(zhǎng)度為6個(gè)字節(jié)，類型為長(zhǎng)整形。

• 區(qū)別一：InnoDB的主索引與數(shù)據(jù)都放在一個(gè)文件中。而MYISAM是分開(kāi)存放的。
• 區(qū)別二：InnoDB的輔助索引data域存儲(chǔ)相應(yīng)記錄主鍵的值而不是地址。
• 區(qū)別三：InnoDB的主鍵索引是聚集索引，而MYISAM不是聚集索引。

3.索引，聚簇索引和二級(jí)索引的加鎖區(qū)別

• 聚集（clustered）索引，也叫聚簇索引。數(shù)據(jù)行的物理順序與列值（一般是主鍵的那一列）的邏輯順序相同，一個(gè)表中只能擁有一個(gè)聚集索引。
• 非聚集（unclustered）索引。該索引中索引的邏輯順序與磁盤(pán)上行的物理存儲(chǔ)順序不同，一個(gè)表中可以擁有多個(gè)非聚集索引。會(huì)發(fā)生二次查詢。
• 稠密索引:稠密索引文件中的索引塊保持鍵的順序與文件中的排序順序一致。
• 稀疏索引:稀疏索引沒(méi)有為每個(gè)數(shù)據(jù)都創(chuàng)建一個(gè)索引,它比稠密索引節(jié)省了更多的存儲(chǔ)空間，但查找給定值的記錄需更多的時(shí)間。只有當(dāng)數(shù)據(jù)文件是按照某個(gè)查找鍵排序時(shí)，在該查找鍵上建立的稀疏索引才能被使用，而稠密索引則可以應(yīng)用在任何的查找鍵。
• 聯(lián)合索引:將一張表中多個(gè)列組成聯(lián)合索引(col1,col2,col3)，其生效方式滿足最左前綴原則。
• 覆蓋索引:對(duì)于二級(jí)索引而言，在innodb中一般是需要先根據(jù)二級(jí)索引查詢到主鍵，然后在根據(jù)一級(jí)索引查詢到數(shù)據(jù)。但是如果select的列都在索引中，就避免進(jìn)行一級(jí)查詢。

4.主鍵選擇

• 在使用InnoDB存儲(chǔ)引擎時(shí)，如果沒(méi)有特別的需要，請(qǐng)永遠(yuǎn)使用一個(gè)與業(yè)務(wù)無(wú)關(guān)的自增字段作為主鍵。
• where 1 = 1:能夠方便我們拼sql，但是使用了之后就無(wú)法使用索引優(yōu)化策略，因此會(huì)進(jìn)行全表掃描，影響效率。

5.分表分庫(kù)

• 水平拆分：依據(jù)表中的數(shù)據(jù)的邏輯關(guān)系，將同一個(gè)表中的數(shù)據(jù)依照某種條件拆分到多臺(tái)數(shù)據(jù)庫(kù)（主機(jī)）上面。按照1個(gè)或多個(gè)字段以及相應(yīng)的規(guī)則，將一張表重的數(shù)據(jù)分到多張表中去。比如按照id%5的規(guī)則，將一張大表拆分成5張小表。適合具有超大表的系統(tǒng)。
• 垂直拆分：依照不同的表（或者Schema）來(lái)切分到不同的數(shù)據(jù)庫(kù)（主機(jī)）之上。一般按照模塊來(lái)分庫(kù)。適合各業(yè)務(wù)之間耦合度非常低的系統(tǒng)。

6.隔離級(jí)別

• read uncommit:讀不加鎖，寫(xiě)加共享鎖。會(huì)產(chǎn)生臟讀、幻讀。
• read commit：讀加共享鎖，寫(xiě)加排它鎖，但不加間隙鎖。間隙鎖的主要作用是防止不可重復(fù)讀，但會(huì)加大鎖的范圍。
• repeatable read(innodb默認(rèn)):讀加共享鎖，寫(xiě)加間隙排它鎖。注意，Innodb對(duì)這個(gè)級(jí)別進(jìn)行了特殊處理，使得這個(gè)級(jí)別能夠避免幻讀，但不是所有引擎都能夠防止幻讀！(網(wǎng)易面試官問(wèn))
• serialization：會(huì)給整張表加鎖，強(qiáng)一致，但是效率低。

7.innodb中的鎖

• MVCC(multi-Version Concurrency Control)：讀不加鎖，讀寫(xiě)不沖突。適合寫(xiě)少讀多的場(chǎng)景。讀操作分為：快照讀（返回記錄的可見(jiàn)版本，不加鎖）、當(dāng)前讀（記錄的最新版本，加鎖，保證其它記錄不修改）。
• LBCC(Lock-Based Concurrency Control)：
• join原理Simple Nested-Loop Join：效率最低，按照join的次序，在join的屬性上一個(gè)個(gè)掃描，并合并結(jié)果。
• Index Nested-Loop Join：效率最高，join的屬性上面有索引，根據(jù)索引來(lái)匹配。
• Block Nested-Loop Join：用于沒(méi)有索引的列。它會(huì)采用join buffer，將外表的值緩存到j(luò)oin buffer中，然后與內(nèi)表進(jìn)行批量比較，這樣可以降低對(duì)外表的訪問(wèn)頻率

8.galera

• 多主架構(gòu)：真正的多點(diǎn)讀寫(xiě)的集群，在任何時(shí)候讀寫(xiě)數(shù)據(jù)，都是最新的。
• 同步復(fù)制，各節(jié)點(diǎn)間無(wú)延遲且節(jié)點(diǎn)宕機(jī)不會(huì)導(dǎo)致數(shù)據(jù)丟失。
• 緊密耦合，所有節(jié)點(diǎn)均保持相同狀態(tài)，節(jié)點(diǎn)間無(wú)不同數(shù)據(jù)。
• 無(wú)需主從切換操作。
• 無(wú)需進(jìn)行讀寫(xiě)分離。
• 并發(fā)復(fù)制：從節(jié)點(diǎn)在APPLY數(shù)據(jù)時(shí)，支持并行執(zhí)行，有更好的性能表現(xiàn)。
• 故障切換：在出現(xiàn)數(shù)據(jù)庫(kù)故障時(shí)，因?yàn)橹С侄帱c(diǎn)寫(xiě)入，切的非常容易。
• 熱插拔：在服務(wù)期間，如果數(shù)據(jù)庫(kù)掛了，只要監(jiān)控程序發(fā)現(xiàn)的夠快，不可服務(wù)時(shí)間就會(huì)非常少。在節(jié)點(diǎn)故障期間，節(jié)點(diǎn)本身對(duì)集群的影響非常小。
• 自動(dòng)節(jié)點(diǎn)克?。涸谛略龉?jié)點(diǎn)，或者停機(jī)維護(hù)時(shí)，增量數(shù)據(jù)或者基礎(chǔ)數(shù)據(jù)不需要人工手動(dòng)備份提供，Galera Cluster會(huì)自動(dòng)拉取在線節(jié)點(diǎn)數(shù)據(jù)，最終集群會(huì)變?yōu)橐恢隆?/li>
• 對(duì)應(yīng)用透明：集群的維護(hù)，對(duì)應(yīng)用程序是透明的，幾乎感覺(jué)不到。

9.LSM Tree，主要應(yīng)用于nessDB、leveldb、hbase

• 核心思想的核心就是放棄部分讀能力，換取寫(xiě)入的最大化能力。它假設(shè)假定內(nèi)存足夠大，因此不需要每次有數(shù)據(jù)更新就必須將數(shù)據(jù)寫(xiě)入到磁盤(pán)中，而可以先將最新的數(shù)據(jù)駐留在內(nèi)存中，等到積累到最后多之后，再使用

  歸并排序

  的方式將內(nèi)存內(nèi)的數(shù)據(jù)合并追加到磁盤(pán)隊(duì)尾。（使用歸并排序是要因?yàn)閹判驑?shù)都是有序樹(shù)）
• LSM具有批量特性，存儲(chǔ)延遲。B樹(shù)在insert的時(shí)候可能會(huì)造成分裂，可能會(huì)造成隨機(jī)讀寫(xiě)。而LSM將多次單頁(yè)隨機(jī)寫(xiě)，變成一次多頁(yè)隨機(jī)寫(xiě),復(fù)用了磁盤(pán)尋道時(shí)間，極大提升效率。
• LSM Tree放棄磁盤(pán)讀性能來(lái)?yè)Q取寫(xiě)的順序性。
• 一般會(huì)使用Bloom Filter來(lái)優(yōu)化LSM。當(dāng)將內(nèi)存中的數(shù)據(jù)與磁盤(pán)數(shù)據(jù)合并的時(shí)候，先要判斷數(shù)據(jù)是否有重復(fù)，如果不用Bloom Filter就需要在磁盤(pán)上一層層地找，而使用了之后就會(huì)降低搜索代價(jià)。

多線程

1. synchronized、CAS
2. Collections
3. 支持高并發(fā)的數(shù)據(jù)結(jié)構(gòu)，如ConcurrentHashMap
4. 基于AQS實(shí)現(xiàn)的鎖、信號(hào)量、計(jì)數(shù)器原理
5. Runnable與Callable的區(qū)別
6. 線程池
7. 作用

• 減少在創(chuàng)建和銷毀線程上所花的時(shí)間以及系統(tǒng)資源的開(kāi)銷 。
• 當(dāng)前任務(wù)與主線程隔離，能實(shí)現(xiàn)和主線程的異步執(zhí)行，特別是很多可以分開(kāi)重復(fù)執(zhí)行的任務(wù)。

8.阻塞隊(duì)列

9.threadlocal

Spring框架

1. IOC/DI
2. Core、Beans、Context、Expression Language
3. JDBC、ORM、OXM、JMS、Transaction
4. AOP
5. Web
6. Test
7. @Autowired原理
8. 工廠模式
9. 反射
10. 自動(dòng)配置@ConfigurationProperties(prefix = 'hello')：讀取以hello為開(kāi)頭的配置，屬性類使用
11. @Configuration：指名當(dāng)前類為配置類
12. @EnableConfigurationProperties(Properties)：指名配置屬性類
13. @ConditionalOnClass(Condition.class)：條件類，只有Condition.class存在，當(dāng)前配置類才生效
14. Spring Boot在spring.factories配置了很多全限定名的配置類。

Redis

核心原理

1. 常用數(shù)據(jù)類型String:二進(jìn)制安全，可以存任何數(shù)據(jù)，比如序列化的圖片。最大長(zhǎng)度位512M.
2. Hash:是KV對(duì)集合，本質(zhì)是String類型的KV映射，適合存儲(chǔ)對(duì)象。
3. List:簡(jiǎn)單字符串鏈表，可以在left、right兩邊插入，本質(zhì)是雙向鏈表。緩沖區(qū)也是用這個(gè)實(shí)現(xiàn)。
4. Set:String類型的無(wú)序集合,內(nèi)部實(shí)現(xiàn)是一個(gè) value永遠(yuǎn)為null的HashMap，實(shí)際就是通過(guò)計(jì)算hash的方式來(lái)快速排重的，這也是set能提供判斷一個(gè)成員是否在集合內(nèi)的原因。
5. zset:有序集合，每個(gè)元素會(huì)關(guān)聯(lián)一個(gè)double類型的score，然后根據(jù)score進(jìn)行排序。注意：元素不能重復(fù)，但是score是可以重復(fù)的。使用HashMap和跳躍表(SkipList)來(lái)保證數(shù)據(jù)的存儲(chǔ)和有序，HashMap里放的是成員到score的映射，而跳躍表里存放的是所有的成員，排序依據(jù)是HashMap里存的score.

• pub/sub:在Redis中，你可以設(shè)定對(duì)某一個(gè)key值進(jìn)行消息發(fā)布及消息訂閱，當(dāng)一個(gè)key值上進(jìn)行了消息發(fā)布后，所有訂閱它的客戶端都會(huì)收到相應(yīng)的消息。

持久化

1. RDB：一種是手動(dòng)執(zhí)行持久化命令來(lái)持久化快照；另一種是在配置文件中配置策略，來(lái)自動(dòng)持久化。持久化命令有save、bgsave兩種，bgsave會(huì)調(diào)用fork命令，產(chǎn)生子進(jìn)程來(lái)進(jìn)行持久化，而父進(jìn)程繼續(xù)處理數(shù)據(jù)，但是持久化的快照是fork那一刻的快照，因此這種策略可能會(huì)丟失一部分?jǐn)?shù)據(jù)。特點(diǎn)：每次都記錄所有數(shù)據(jù)，恢復(fù)快，子進(jìn)程不影響父進(jìn)程性能。
2. AOF：append only file，將每條操作命令都記錄到appendonly.aof文件中，但是不會(huì)立馬寫(xiě)入硬盤(pán)，我們可以配置always（每有一個(gè)命令，都同步）、everysec（每秒同步一次）、no（沒(méi)30秒同步一次）。往往everysec就夠了。aof數(shù)據(jù)損失要比RDB小。特點(diǎn)：有序記錄所有操作，數(shù)據(jù)丟失更少，會(huì)對(duì)操作做壓縮優(yōu)化，bgrewriteaof也會(huì)fork子進(jìn)程，不影響父進(jìn)程性能

事務(wù)

1. Transactions:不是嚴(yán)格的ACID的事務(wù)，但是這個(gè)Transactions還是提供了基本的命令打包執(zhí)行的功能（在服務(wù)器不出問(wèn)題的情況下，可以保證一連串的命令是順序在一起執(zhí)行的，中間有會(huì)有其它客戶端命令插進(jìn)來(lái)執(zhí)行）。
2. Redis還提供了一個(gè)Watch功能，你可以對(duì)一個(gè)key進(jìn)行Watch，然后再執(zhí)行Transactions，在這過(guò)程中，如果這個(gè)Watched的值進(jìn)行了修改，那么這個(gè)Transactions會(huì)發(fā)現(xiàn)并拒絕執(zhí)行。

KafKA

1. topic
2. broker
3. partition
4. consumer
5. producer
6. stream
7. 存儲(chǔ)機(jī)制
8. 網(wǎng)絡(luò)模型
9. 注意：partition之間是無(wú)序的
10. 消息隊(duì)列的生產(chǎn)者消費(fèi)者中消費(fèi)者沒(méi)有收到消息怎么辦，消息有順序比如1.2.3但是收到的卻是1.3.2怎么辦？消息發(fā)過(guò)來(lái)的過(guò)程中損壞或者出錯(cuò)怎么辦

Spring security

1. 攔截器棧
2. @PreAuthorize
3. @PostAuthorize
4. 支持Expression Language

jvm原理

內(nèi)存模型、垃圾收集器、CMS與G1是重點(diǎn)

垃圾收集算法

• 標(biāo)記-清除(CMS)容易產(chǎn)生碎片，當(dāng)碎片太多會(huì)提前觸發(fā)Full GC
• 復(fù)制(年輕代基本用這個(gè)算法)會(huì)浪費(fèi)一半的可能感覺(jué)
• 標(biāo)記-整理(serial Old、Parallel Old)
• Serial：采用單線程stop-the-world的方式進(jìn)行收集。當(dāng)內(nèi)存不足時(shí)，串行GC設(shè)置停頓標(biāo)識(shí)，待所有線程都進(jìn)入安全點(diǎn)(Safepoint)時(shí)，應(yīng)用線程暫停，串行GC開(kāi)始工作，采用單線程方式回收空間并整理內(nèi)存。串行收集器特別適合堆內(nèi)存不高、單核甚至雙核CPU的場(chǎng)合。
• ParNew
• Parallel Scavenge

CMS：

• 初始標(biāo)記(stop of world)
• 并行標(biāo)記、預(yù)清理
• 重新標(biāo)記(stop of world)
• 并行清理

G1

將堆分成很多region，可以同時(shí)堆年輕代與老年代進(jìn)行收集

• 初始標(biāo)記（stop of world）:初始標(biāo)記(Initial Mark)負(fù)責(zé)標(biāo)記所有能被直接可達(dá)的根對(duì)象(原生棧對(duì)象、全局對(duì)象、JNI對(duì)象)
• 并行標(biāo)記:
• 重新標(biāo)記（stop of world）:
• 清理（stop of world）:
• 重置

gc觸發(fā)條件

1. 從年輕代分區(qū)拷貝存活對(duì)象時(shí)，無(wú)法找到可用的空閑分區(qū)，會(huì)觸發(fā)Minor GC
2. 從老年代分區(qū)轉(zhuǎn)移存活對(duì)象時(shí)，無(wú)法找到可用的空閑分區(qū)，會(huì)觸發(fā)Major GC
3. 分配巨型對(duì)象時(shí)在老年代無(wú)法找到足夠的連續(xù)分區(qū)，會(huì)觸發(fā)Major GC
4. 可達(dá)性分析：通過(guò)檢查一塊內(nèi)存空間能否被root達(dá)到，來(lái)判斷是否對(duì)其進(jìn)行回收。

jdk不同版本新增的部分特性

jvm調(diào)優(yōu)

• VisualVM:JDK自帶JVM可視化工具，能過(guò)對(duì)內(nèi)存、gc、cpu、thread、class、變量等等信息進(jìn)行可視化。

設(shè)計(jì)模式

1. 單例雙重檢查
2. 觀察者模式
3. 裝飾者模式:jdk中輸入輸出流用到了該模式
4. 適配器模式:jdk中Reader、writer用到了該模式
5. 代理模式
6. 靜態(tài)代理
7. JDK動(dòng)態(tài)代理
8. Cglib到動(dòng)態(tài)代理
9. 生產(chǎn)者消費(fèi)者模式
10. 工廠模式

項(xiàng)目管理與運(yùn)維工具

1. git+Jenkins
2. maven
3. K8Spod：Pod是所有業(yè)務(wù)類型的基礎(chǔ)，所有的容器均在Pod中運(yùn)行,它是一個(gè)或多個(gè)容器的組合。每一個(gè)Pod都會(huì)被指派一個(gè)唯一的Ip地址，在Pod中的每一個(gè)容器共享網(wǎng)絡(luò)命名空間，包括Ip地址和網(wǎng)絡(luò)端口。Pod能夠被指定共享存儲(chǔ)卷的集合，在Pod中所有的容器能夠訪問(wèn)共享存儲(chǔ)卷，允許這些容器共享數(shù)據(jù)。
4. kubelet：kubelet負(fù)責(zé)管理pods和它們上面的容器，images鏡像、volumes、etc。
5. ingress，用于負(fù)載均衡
6. docker
7. docker與虛擬機(jī)的區(qū)別

數(shù)據(jù)結(jié)構(gòu)

1. 平衡二叉樹(shù)AVL
2. 高度log(n)
3. 插入時(shí)間復(fù)雜度log(n)
4. 紅黑樹(shù)
5. 插入時(shí)間復(fù)雜度log(n)
6. 查找時(shí)間復(fù)雜度log(n)
7. 在查找是，紅黑樹(shù)雖然復(fù)雜度也是log(n),但是從效率上比要略低于AVL。但是其優(yōu)勢(shì)在于插入元素的時(shí)候，不會(huì)像AVL那樣頻繁地旋轉(zhuǎn)。
8. B+Tree：只有葉子節(jié)點(diǎn)存值，非葉子節(jié)點(diǎn)只存key和child，因此同樣大小的物理頁(yè)上能存放更多的節(jié)點(diǎn)。每一層的節(jié)點(diǎn)數(shù)量越多，意味著層次越少，也就意味著IO次數(shù)越少，因此非常適合數(shù)據(jù)庫(kù)以及文件系統(tǒng)。
9. 大根堆：采用數(shù)組存儲(chǔ)樹(shù)，是一個(gè)完全樹(shù)。先插入到數(shù)組最后的位置上，然后采用上浮的思想，將該元素與比它小的父元素調(diào)換，直到parent>target，浮到root;然后將root與未排序的最后一個(gè)元素交換位置；重復(fù)以上步驟，直到所有元素都有序。插入如查找的復(fù)雜度都是log(n)。
10. 優(yōu)先隊(duì)列PriorityQueue，Java中使用小根堆實(shí)現(xiàn)，非線程安全。
11. 優(yōu)先阻塞隊(duì)列PriorityBlockQueue，線程安全。

算法

1. 快排
2. 時(shí)間復(fù)雜度O(nlog(n))
3. 空間復(fù)雜度O(log(n))
4. 堆排序
5. 時(shí)間復(fù)雜度O(nlog(n))
6. 空間復(fù)雜度O(1)
7. 歸并排序
8. 時(shí)間復(fù)雜度O(nlog(n))
9. 空間復(fù)雜度O(n)
10. 跳表時(shí)間復(fù)雜度O(log(n))
11. 空間復(fù)雜度O(2n)
12. 高度O(log(n))

分布式

cap理論

1. 可用性
2. 一致性
3. 分區(qū)容忍性：對(duì)網(wǎng)絡(luò)斷開(kāi)的容忍度，有點(diǎn)像魯棒性
4. 拜占庭將軍問(wèn)題

Raft 算法

• 有l(wèi)eader、follower、candidate

同步流程

1. 由客戶端提交數(shù)據(jù)到Leader節(jié)點(diǎn)。
2. 由Leader節(jié)點(diǎn)把數(shù)據(jù)復(fù)制到集群內(nèi)所有的Follower節(jié)點(diǎn)。如果一次復(fù)制失敗，會(huì)不斷進(jìn)行重試。
3. Follower節(jié)點(diǎn)們接收到復(fù)制的數(shù)據(jù)，會(huì)反饋給Leader節(jié)點(diǎn)。
4. 如果Leader節(jié)點(diǎn)接收到超過(guò)半數(shù)的Follower反饋，表明復(fù)制成功。于是提交自己的數(shù)據(jù)，并通知客戶端數(shù)據(jù)提交成功。
5. 由Leader節(jié)點(diǎn)通知集群內(nèi)所有的Follower節(jié)點(diǎn)提交數(shù)據(jù)，從而完成數(shù)據(jù)同步流程。

zookeeper

1. Zab（Zookeeper Atomic Broadcast）協(xié)議,有兩種模式：

• 它們分別是：恢復(fù)模式（選主）和廣播模式（同步）。
• 有兩種算法：1. basic paxos；2. fast paxos（默認(rèn)）

1. 文件系統(tǒng)：zookeeper的通知機(jī)制、分布式鎖、隊(duì)列管理、配置管理都是基于文件系統(tǒng)的。
2. 分布式鎖：有了zookeeper的一致性文件系統(tǒng)，鎖的問(wèn)題變得容易。鎖服務(wù)可以分為兩類，一個(gè)是保持獨(dú)占，另一個(gè)是控制時(shí)序。
3. 獨(dú)占鎖：將zookeeper上的一個(gè)znode看作是一把鎖，通過(guò)createznode的方式來(lái)實(shí)現(xiàn)。所有客戶端都去創(chuàng)建 /distribute_lock 節(jié)點(diǎn)，最終成功創(chuàng)建的那個(gè)客戶端也即擁有了這把鎖。用完刪除掉自己創(chuàng)建的distribute_lock 節(jié)點(diǎn)就釋放出鎖。
4. 控制時(shí)序鎖：/distribute_lock 已經(jīng)預(yù)先存在，所有客戶端在它下面創(chuàng)建臨時(shí)順序編號(hào)目錄節(jié)點(diǎn)，和選master一樣，編號(hào)最小的獲得鎖，用完刪除。
5. 隊(duì)列管理，分為同步隊(duì)列、非同步隊(duì)列
6. 數(shù)據(jù)復(fù)制的好處

• 容錯(cuò)：一個(gè)節(jié)點(diǎn)出錯(cuò)，不致于讓整個(gè)系統(tǒng)停止工作，別的節(jié)點(diǎn)可以接管它的工作；
• 提高系統(tǒng)的擴(kuò)展能力 ：把負(fù)載分布到多個(gè)節(jié)點(diǎn)上，或者增加節(jié)點(diǎn)來(lái)提高系統(tǒng)的負(fù)載能力；
• 提高性能：讓客戶端本地訪問(wèn)就近的節(jié)點(diǎn)，提高用戶訪問(wèn)速度。

5.一致性hash算法原理

微服務(wù)

Spring cloud

• 網(wǎng)關(guān)：zuul
• 分布式\版本化配置 config
• 服務(wù)注冊(cè)和發(fā)現(xiàn)：Eureka，配置時(shí)需要注意多久刷新列表一次，多久監(jiān)測(cè)心跳等。
• service-to-service 調(diào)用
• 負(fù)載均衡：Ribbon；在生成RestTemplate的bean時(shí)，通過(guò)@LoadBalanced注解可以使得RestTemplate的調(diào)用
• 斷路器：Hystrix
• 監(jiān)控：spring admin。在啟動(dòng)類上加@EnableAdminServer注解。

java web

1. servlet工作原理
2. tomcat工作原理,好文，強(qiáng)推
3. container

linux

1. 系統(tǒng)結(jié)構(gòu)，講得很好，強(qiáng)推
2. 硬鏈接與軟連接
3. 硬鏈接：數(shù)據(jù)節(jié)點(diǎn)通過(guò)引用計(jì)數(shù)的方式來(lái)對(duì)指向它的硬鏈接計(jì)數(shù)，當(dāng)計(jì)數(shù)為0就刪除。
4. 軟連接：我們可以把它看成是快捷方式，它只是記錄了某個(gè)文件的硬鏈接的路徑，如果我們把源文件刪除，再重新創(chuàng)建一個(gè)相同名字的文件，那么軟連接指向的就是新創(chuàng)建的文件。
5. 虛擬文件系統(tǒng)(VFS)：文件系統(tǒng)是有很多實(shí)現(xiàn)的，比如ext2、ext3、FAT等等，而VFS則是存在于應(yīng)用程序與文件系統(tǒng)中間，它封裝了open、close、read、write等等操作文件系統(tǒng)的接口，為應(yīng)用程序屏蔽掉不同文件系統(tǒng)之間的差異。
6. VFS數(shù)據(jù)結(jié)構(gòu)

其它

• bitmap，大文件交集
• Elasticsearch索引原理
• 從內(nèi)存到屏幕經(jīng)歷了啥
• 高并發(fā)場(chǎng)景的限流，你怎么來(lái)確定限流限多少，模擬場(chǎng)景和實(shí)際場(chǎng)景有區(qū)別怎么解決，

百度面試

• 說(shuō)一下redis與kafka，redis持久化策略
• git中rebase與merge區(qū)別
• docker底層原理，依賴操作系統(tǒng)的什么
• ls -l | grep xxx的執(zhí)行過(guò)程，盡可能的細(xì)，是多進(jìn)程還是單進(jìn)程？
• 兩個(gè)有序數(shù)組求中位數(shù)
• 算法 3Sum、中序遍歷非遞歸實(shí)現(xiàn)、循環(huán)打印矩陣
• final、finally、finanize
• jvm內(nèi)存模型
• 垃圾回收器
• Spring特點(diǎn)介紹下
• Synchronize與ReentrantLock的區(qū)別、使用場(chǎng)景
• CAS使用場(chǎng)景
• 聊了下git+jekins+K8S+docker實(shí)現(xiàn)自動(dòng)化部署
• innodb原理，使用場(chǎng)景，與MYISAM在場(chǎng)景上的區(qū)別
• weakReference、softReference等
• Hbase的原理，LSM Tree
• Linux中，哪種進(jìn)程可以使用管道

美團(tuán)

• 權(quán)限模型
• 介紹下線程池，阻塞隊(duì)列的用法，無(wú)界隊(duì)列真的無(wú)界嗎？
• 說(shuō)一下redis
• kafka存儲(chǔ)模型與網(wǎng)絡(luò)模型
• zookeeper與redis實(shí)現(xiàn)分布式鎖
• 樂(lè)觀鎖與悲觀鎖
• 算法：有n個(gè)人，給你ai與aj的身高關(guān)系，如ai比aj高，進(jìn)行身高排序，如果條件不滿足，則輸出“不滿足”
• Spring boot的特性

以上是總結(jié)出的最全技術(shù)面試題目，以下是最新總結(jié)出的BAT面試java必考題目和答案。