面試 | 美團Java 后端實習的面經

大家好，我是小林。

原標題：好卷，大二就在美團實習了

有很多在校的讀者咨詢過我，在校卷什么對求職開發(fā)崗比較有幫助？很多同學都會想去卷一些比賽、證書、績點這些。

其實比賽來說，無疑含金量最高的就是 ACM 比賽了，很多大廠都喜歡拿了 ACM 獎項的同學，ACM 是算法比賽，能拿到比賽名次的，肯定都屬于比較聰明的一類人，成長性會很大。但是 ACM 比賽需要花大量的精力去學算法，而且也不適合每一個人，也是比較看天賦的。

開崗位看重的是你的開發(fā)經驗，適合大多數(shù)人的方式，就是卷實習了，比如從大二/研一早早就開始準備求職方向的內容，然后找實習工作，多積累實習經歷，寫到簡歷上，自然就能證明你是具備了工程開發(fā)的經驗的。

有了實習經歷，秋招的時候，拿到面試的機會也會更大一些，因為大部分企業(yè)都喜歡招進來就能干活的，你具備了實習經歷，就證明你是具備上手快的能力的。

前段時間，正好收到一位訓練營同學的喜事，找到美團大廠實習了，同學是 26 屆，目前是大二，積累個半年大廠實習經歷，等同學明年秋招，妥妥就是大廠 offer 收割機了

那大廠實習的面試難度到底如何？

今天，就來跟大家拆解一波美團Java 后端實習的面經，主要是考察了Java、MySQL、Redis、網(wǎng)絡、操作系統(tǒng)這五大塊知識，可以說是校招必須掌握的五件套知識了。

我只能說，不愧是大廠面試，強度是很大，光是寫面經都快 2 萬字了

考察的知識點，我給大家羅列了一下：

• • Java：

  線程池、線程狀態(tài)、線程同步和鎖、Srping AOP、IoC、動態(tài)代理

• • MySQL：

  索引、事務、性能優(yōu)化

• • Redis:

  線程模式、分布式鎖

• • 計網(wǎng)和操作系統(tǒng)：

  網(wǎng)絡模型、TCP和UDP的區(qū)別、進程通信、擁塞控制

MySQL

講講事務的特性，怎么保證ACID的？

原子性（Atomicity）：一個事務中的所有操作，要么全部完成，要么全部不完成，不會結束在中間某個環(huán)節(jié)，而且事務在執(zhí)行過程中發(fā)生錯誤，會被回滾到事務開始前的狀態(tài)，就像這個事務從來沒有執(zhí)行過一樣，就好比買一件商品，購買成功時，則給商家付了錢，商品到手；購買失敗時，則商品在商家手中，消費者的錢也沒花出去。

一致性（Consistency）：是指事務操作前和操作后，數(shù)據(jù)滿足完整性約束，數(shù)據(jù)庫保持一致性狀態(tài)。比如，用戶 A 和用戶 B 在銀行分別有 800 元和 600 元，總共 1400 元，用戶 A 給用戶 B 轉賬 200 元，分為兩個步驟，從 A 的賬戶扣除 200 元和對 B 的賬戶增加 200 元。一致性就是要求上述步驟操作后，最后的結果是用戶 A 還有 600 元，用戶 B 有 800 元，總共 1400 元，而不會出現(xiàn)用戶 A 扣除了 200 元，但用戶 B 未增加的情況（該情況，用戶 A 和 B 均為 600 元，總共 1200 元）。

隔離性（Isolation）：數(shù)據(jù)庫允許多個并發(fā)事務同時對其數(shù)據(jù)進行讀寫和修改的能力，隔離性可以防止多個事務并發(fā)執(zhí)行時由于交叉執(zhí)行而導致數(shù)據(jù)的不一致，因為多個事務同時使用相同的數(shù)據(jù)時，不會相互干擾，每個事務都有一個完整的數(shù)據(jù)空間，對其他并發(fā)事務是隔離的。也就是說，消費者購買商品這個事務，是不影響其他消費者購買的。

持久性（Durability）：事務處理結束后，對數(shù)據(jù)的修改就是永久的，即便系統(tǒng)故障也不會丟失。

MySQL InnoDB 引擎通過什么技術來保證事務的這四個特性的呢？

持久性是通過 redo log （重做日志）來保證的；原子性是通過 undo log（回滾日志） 來保證的；隔離性是通過 MVCC（多版本并發(fā)控制） 或鎖機制來保證的；一致性則是通過持久性+原子性+隔離性來保證；

事務的隔離級別有哪些？

讀未提交（read uncommitted），指一個事務還沒提交時，它做的變更就能被其他事務看到；

讀提交（read committed），指一個事務提交之后，它做的變更才能被其他事務看到；

可重復讀（repeatable read），指一個事務執(zhí)行過程中看到的數(shù)據(jù)，一直跟這個事務啟動時看到的數(shù)據(jù)是一致的，

MySQL InnoDB 引擎的默認隔離級別；

串行化（serializable）；會對記錄加上讀寫鎖，在多個事務對這條記錄進行讀寫操作時，如果發(fā)生了讀寫沖突的時候，后訪問的事務必須等前一個事務執(zhí)行完成，才能繼續(xù)執(zhí)行；

按隔離水平高低排序如下：

針對不同的隔離級別，并發(fā)事務時可能發(fā)生的現(xiàn)象也會不同。

也就是說：

在「讀未提交」隔離級別下，可能發(fā)生臟讀、不可重復讀和幻讀現(xiàn)象；在「讀提交」隔離級別下，可能發(fā)生不可重復讀和幻讀現(xiàn)象，但是不可能發(fā)生臟讀現(xiàn)象；在「可重復讀」隔離級別下，可能發(fā)生幻讀現(xiàn)象，但是不可能臟讀和不可重復讀現(xiàn)象；在「串行化」隔離級別下，臟讀、不可重復讀和幻讀現(xiàn)象都不可能會發(fā)生。

講講索引的分類是什么？

MySQL可以按照四個角度來分類索引。

• • 按「數(shù)據(jù)結構」分類：

  B+tree索引、Hash索引、Full-text索引

• • 按「物理存儲」分類：

  聚簇索引（主鍵索引）、二級索引（輔助索引）

• • 按「字段特性」分類：

  主鍵索引、唯一索引、普通索引、前綴索引

• • • 按「字段個數(shù)」分類：

    單列索引、聯(lián)合索引

 

接下來，按照這些角度來說說各類索引的特點。

按數(shù)據(jù)結構分類

從數(shù)據(jù)結構的角度來看，MySQL 常見索引有 B+Tree 索引、HASH 索引、Full-Text 索引。每一種存儲引擎支持的索引類型不一定相同，我在表中總結了 MySQL 常見的存儲引擎 InnoDB、MyISAM 和 Memory 分別支持的索引類型。

InnoDB 是在 MySQL 5.5 之后成為默認的 MySQL 存儲引擎，B+Tree 索引類型也是 MySQL 存儲引擎采用最多的索引類型。在創(chuàng)建表時，InnoDB 存儲引擎會根據(jù)不同的場景選擇不同的列作為索引：

如果有主鍵，默認會使用主鍵作為聚簇索引的索引鍵（key）；如果沒有主鍵，就選擇第一個不包含 NULL 值的唯一列作為聚簇索引的索引鍵（key）；在上面兩個都沒有的情況下，InnoDB 將自動生成一個隱式自增 id 列作為聚簇索引的索引鍵（key）；

其它索引都屬于輔助索引（Secondary Index），也被稱為二級索引或非聚簇索引。創(chuàng)建的主鍵索引和二級索引默認使用的是 B+Tree 索引。

按物理存儲分類

從物理存儲的角度來看，索引分為聚簇索引（主鍵索引）、二級索引（輔助索引）。這兩個區(qū)別在前面也提到了：

主鍵索引的 B+Tree 的葉子節(jié)點存放的是實際數(shù)據(jù)，所有完整的用戶記錄都存放在主鍵索引的 B+Tree 的葉子節(jié)點里；二級索引的 B+Tree 的葉子節(jié)點存放的是主鍵值，而不是實際數(shù)據(jù)。

所以，在查詢時使用了二級索引，如果查詢的數(shù)據(jù)能在二級索引里查詢的到，那么就不需要回表，這個過程就是覆蓋索引。如果查詢的數(shù)據(jù)不在二級索引里，就會先檢索二級索引，找到對應的葉子節(jié)點，獲取到主鍵值后，然后再檢索主鍵索引，就能查詢到數(shù)據(jù)了，這個過程就是回表。

按字段特性分類

從字段特性的角度來看，索引分為主鍵索引、唯一索引、普通索引、前綴索引。

主鍵索引

主鍵索引就是建立在主鍵字段上的索引，通常在創(chuàng)建表的時候一起創(chuàng)建，一張表最多只有一個主鍵索引，索引列的值不允許有空值。在創(chuàng)建表時，創(chuàng)建主鍵索引的方式如下：

CREATE?TABLE?table_name??(
??....
??PRIMARY?KEY?(index_column_1)?USING?BTREE
);

唯一索引

唯一索引建立在 UNIQUE 字段上的索引，一張表可以有多個唯一索引，索引列的值必須唯一，但是允許有空值。在創(chuàng)建表時，創(chuàng)建唯一索引的方式如下：

CREATE?TABLE?table_name??(
??....
??UNIQUE?KEY(index_column_1,index_column_2,...)?
);

建表后，如果要創(chuàng)建唯一索引，可以使用這面這條命令：

CREATE?UNIQUE?INDEX?index_name
ON?table_name(index_column_1,index_column_2,...);

普通索引

普通索引就是建立在普通字段上的索引，既不要求字段為主鍵，也不要求字段為 UNIQUE。在創(chuàng)建表時，創(chuàng)建普通索引的方式如下：

CREATE?TABLE?table_name??(
??....
??INDEX(index_column_1,index_column_2,...)?
);

建表后，如果要創(chuàng)建普通索引，可以使用這面這條命令：

CREATE?INDEX?index_name
ON?table_name(index_column_1,index_column_2,...);

前綴索引

前綴索引是指對字符類型字段的前幾個字符建立的索引，而不是在整個字段上建立的索引，前綴索引可以建立在字段類型為 char、 varchar、binary、varbinary 的列上。使用前綴索引的目的是為了減少索引占用的存儲空間，提升查詢效率。在創(chuàng)建表時，創(chuàng)建前綴索引的方式如下：

CREATE?TABLE?table_name(
????column_list,
????INDEX(column_name(length))
);

建表后，如果要創(chuàng)建前綴索引，可以使用這面這條命令：

CREATE?INDEX?index_name
ON table_name(column_name(length));

按字段個數(shù)分類

從字段個數(shù)的角度來看，索引分為單列索引、聯(lián)合索引（復合索引）。

建立在單列上的索引稱為單列索引，比如主鍵索引；建立在多列上的索引稱為聯(lián)合索引；

通過將多個字段組合成一個索引，該索引就被稱為聯(lián)合索引。比如，將商品表中的 product_no 和 name 字段組合成聯(lián)合索引(product_no, name)，創(chuàng)建聯(lián)合索引的方式如下：

CREATE?INDEX?index_product_no_name?ON?product(product_no,?name);

聯(lián)合索引(product_no, name) 的 B+Tree 示意圖如下（圖中葉子節(jié)點之間我畫了單向鏈表，但是實際上是雙向鏈表，原圖我找不到了，修改不了，偷個懶我不重畫了，大家腦補成雙向鏈表就行）。

可以看到，聯(lián)合索引的非葉子節(jié)點用兩個字段的值作為 B+Tree 的 key 值。當在聯(lián)合索引查詢數(shù)據(jù)時，先按 product_no 字段比較，在 product_no 相同的情況下再按 name 字段比較。

也就是說，聯(lián)合索引查詢的 B+Tree 是先按 product_no 進行排序，然后再 product_no 相同的情況再按 name 字段排序。因此，使用聯(lián)合索引時，存在最左匹配原則，也就是按照最左優(yōu)先的方式進行索引的匹配。在使用聯(lián)合索引進行查詢的時候，如果不遵循「最左匹配原則」，聯(lián)合索引會失效，這樣就無法利用到索引快速查詢的特性了。比如，如果創(chuàng)建了一個 (a, b, c) 聯(lián)合索引，如果查詢條件是以下這幾種，就可以匹配上聯(lián)合索引：

where a=1；where a=1 and b=2 and c=3；where a=1 and b=2；

需要注意的是，因為有查詢優(yōu)化器，所以 a 字段在 where 子句的順序并不重要。但是，如果查詢條件是以下這幾種，因為不符合最左匹配原則，所以就無法匹配上聯(lián)合索引，聯(lián)合索引就會失效:

where b=2；where c=3；where b=2 and c=3；

上面這些查詢條件之所以會失效，是因為(a, b, c) 聯(lián)合索引，是先按 a 排序，在 a 相同的情況再按 b 排序，在 b 相同的情況再按 c 排序。所以，b 和 c 是全局無序，局部相對有序的，這樣在沒有遵循最左匹配原則的情況下，是無法利用到索引的。

聯(lián)合索引有一些特殊情況，并不是查詢過程使用了聯(lián)合索引查詢，就代表聯(lián)合索引中的所有字段都用到了聯(lián)合索引進行索引查詢，也就是可能存在部分字段用到聯(lián)合索引的 B+Tree，部分字段沒有用到聯(lián)合索引的 B+Tree 的情況。這種特殊情況就發(fā)生在范圍查詢。聯(lián)合索引的最左匹配原則會一直向右匹配直到遇到「范圍查詢」就會停止匹配。也就是范圍查詢的字段可以用到聯(lián)合索引，但是在范圍查詢字段的后面的字段無法用到聯(lián)合索引。

索引結構，為什么innoDB用B+樹

MySQL 是會將數(shù)據(jù)持久化在硬盤，而存儲功能是由 MySQL 存儲引擎實現(xiàn)的，所以討論 MySQL 使用哪種數(shù)據(jù)結構作為索引，實際上是在討論存儲引使用哪種數(shù)據(jù)結構作為索引，InnoDB 是 MySQL 默認的存儲引擎，它就是采用了 B+ 樹作為索引的數(shù)據(jù)結構。

要設計一個 MySQL 的索引數(shù)據(jù)結構，不僅僅考慮數(shù)據(jù)結構增刪改的時間復雜度，更重要的是要考慮磁盤 I/0 的操作次數(shù)。因為索引和記錄都是存放在硬盤，硬盤是一個非常慢的存儲設備，我們在查詢數(shù)據(jù)的時候，最好能在盡可能少的磁盤 I/0 的操作次數(shù)內完成。

二分查找樹雖然是一個天然的二分結構，能很好的利用二分查找快速定位數(shù)據(jù)，但是它存在一種極端的情況，每當插入的元素都是樹內最大的元素，就會導致二分查找樹退化成一個鏈表，此時查詢復雜度就會從 O(logn)降低為 O(n)。

為了解決二分查找樹退化成鏈表的問題，就出現(xiàn)了自平衡二叉樹，保證了查詢操作的時間復雜度就會一直維持在 O(logn) 。但是它本質上還是一個二叉樹，每個節(jié)點只能有 2 個子節(jié)點，隨著元素的增多，樹的高度會越來越高。

而樹的高度決定于磁盤 I/O 操作的次數(shù)，因為樹是存儲在磁盤中的，訪問每個節(jié)點，都對應一次磁盤 I/O 操作，也就是說樹的高度就等于每次查詢數(shù)據(jù)時磁盤 IO 操作的次數(shù)，所以樹的高度越高，就會影響查詢性能。

B 樹和 B+ 都是通過多叉樹的方式，會將樹的高度變矮，所以這兩個數(shù)據(jù)結構非常適合檢索存于磁盤中的數(shù)據(jù)。

B+Tree vs B Tree：B+Tree 只在葉子節(jié)點存儲數(shù)據(jù)，而 B 樹 的非葉子節(jié)點也要存儲數(shù)據(jù)，所以 B+Tree 的單個節(jié)點的數(shù)據(jù)量更小，在相同的磁盤 I/O 次數(shù)下，就能查詢更多的節(jié)點。另外，B+Tree 葉子節(jié)點采用的是雙鏈表連接，適合 MySQL 中常見的基于范圍的順序查找，而 B 樹無法做到這一點。

B+Tree vs 二叉樹：對于有 N 個葉子節(jié)點的 B+Tree，其搜索復雜度為O(logdN)，其中 d 表示節(jié)點允許的最大子節(jié)點個數(shù)為 d 個。在實際的應用當中， d 值是大于100的，這樣就保證了，即使數(shù)據(jù)達到千萬級別時，B+Tree 的高度依然維持在 3~4 層左右，也就是說一次數(shù)據(jù)查詢操作只需要做 3~4 次的磁盤 I/O 操作就能查詢到目標數(shù)據(jù)。而二叉樹的每個父節(jié)點的兒子節(jié)點個數(shù)只能是 2 個，意味著其搜索復雜度為 O(logN)，這已經比 B+Tree 高出不少，因此二叉樹檢索到目標數(shù)據(jù)所經歷的磁盤 I/O 次數(shù)要更多。

B+Tree vs Hash：Hash 在做等值查詢的時候效率賊快，搜索復雜度為 O(1)。但是 Hash 表不適合做范圍查詢，它更適合做等值的查詢，這也是 B+Tree 索引要比 Hash 表索引有著更廣泛的適用場景的原因

給你張表，發(fā)現(xiàn)查詢速度很慢，你有那些解決方案

分析查詢語句：使用EXPLAIN命令分析SQL執(zhí)行計劃，找出慢查詢的原因，比如是否使用了全表掃描，是否存在索引未被利用的情況等，并根據(jù)相應情況對索引進行適當修改。

創(chuàng)建或優(yōu)化索引：根據(jù)查詢條件創(chuàng)建合適的索引，特別是經常用于WHERE子句的字段、Orderby 排序的字段、Join 連表查詢的字典、 group by的字段，并且如果查詢中經常涉及多個字段，考慮創(chuàng)建聯(lián)合索引，使用聯(lián)合索引要符合最左匹配原則，不然會索引失效

避免索引失效：比如不要用左模糊匹配、函數(shù)計算、表達式計算等等。

查詢優(yōu)化：避免使用SELECT *，只查詢真正需要的列；使用覆蓋索引，即索引包含所有查詢的字段；聯(lián)表查詢最好要以小表驅動大表，并且被驅動表的字段要有索引，當然最好通過冗余字段的設計，避免聯(lián)表查詢。

分頁優(yōu)化：針對 limit n,y 深分頁的查詢優(yōu)化，可以把Limit查詢轉換成某個位置的查詢：select * from tb_sku where id>20000 limit 10，該方案適用于主鍵自增的表，

優(yōu)化數(shù)據(jù)庫表：如果單表的數(shù)據(jù)超過了千萬級別，考慮是否需要將大表拆分為小表，減輕單個表的查詢壓力。也可以將字段多的表分解成多個表，有些字段使用頻率高，有些低，數(shù)據(jù)量大時，會由于使用頻率低的存在而變慢，可以考慮分開。

使用緩存技術：引入緩存層，如Redis，存儲熱點數(shù)據(jù)和頻繁查詢的結果，但是要考慮緩存一致性的問題，對于讀請求會選擇旁路緩存策略，對于寫請求會選擇先更新 db，再刪除緩存的策略。

Redis

Redis單線程為什么這么快？

官方使用基準測試的結果是，單線程的 Redis 吞吐量可以達到 10W/每秒，如下圖所示：

img之所以 Redis 采用單線程（網(wǎng)絡 I/O 和執(zhí)行命令）那么快，有如下幾個原因：

Redis 的大部分操作都在內存中完成，并且采用了高效的數(shù)據(jù)結構，因此 Redis 瓶頸可能是機器的內存或者網(wǎng)絡帶寬，而并非 CPU，既然 CPU 不是瓶頸，那么自然就采用單線程的解決方案了；Redis 采用單線程模型可以避免了多線程之間的競爭，省去了多線程切換帶來的時間和性能上的開銷，而且也不會導致死鎖問題。Redis 采用了I/O 多路復用機制處理大量的客戶端 Socket 請求，IO 多路復用機制是指一個線程處理多個 IO 流，就是我們經常聽到的 select/epoll 機制。簡單來說，在 Redis 只運行單線程的情況下，該機制允許內核中，同時存在多個監(jiān)聽 Socket 和已連接 Socket。內核會一直監(jiān)聽這些 Socket 上的連接請求或數(shù)據(jù)請求。一旦有請求到達，就會交給 Redis 線程處理，這就實現(xiàn)了一個 Redis 線程處理多個 IO 流的效果。

Redis分布式鎖是怎么實現(xiàn)的？

分布式鎖是用于分布式環(huán)境下并發(fā)控制的一種機制，用于控制某個資源在同一時刻只能被一個應用所使用。如下圖所示：

Redis 本身可以被多個客戶端共享訪問，正好就是一個共享存儲系統(tǒng)，可以用來保存分布式鎖，而且 Redis 的讀寫性能高，可以應對高并發(fā)的鎖操作場景。Redis 的 SET 命令有個 NX 參數(shù)可以實現(xiàn)「key不存在才插入」，所以可以用它來實現(xiàn)分布式鎖：

如果 key 不存在，則顯示插入成功，可以用來表示加鎖成功；如果 key 存在，則會顯示插入失敗，可以用來表示加鎖失敗。

基于 Redis 節(jié)點實現(xiàn)分布式鎖時，對于加鎖操作，我們需要滿足三個條件。

加鎖包括了讀取鎖變量、檢查鎖變量值和設置鎖變量值三個操作，但需要以原子操作的方式完成，所以，我們使用 SET 命令帶上 NX 選項來實現(xiàn)加鎖；鎖變量需要設置過期時間，以免客戶端拿到鎖后發(fā)生異常，導致鎖一直無法釋放，所以，我們在 SET 命令執(zhí)行時加上 EX/PX 選項，設置其過期時間；鎖變量的值需要能區(qū)分來自不同客戶端的加鎖操作，以免在釋放鎖時，出現(xiàn)誤釋放操作，所以，我們使用 SET 命令設置鎖變量值時，每個客戶端設置的值是一個唯一值，用于標識客戶端；

滿足這三個條件的分布式命令如下：

SET?lock_key?unique_value?NX?PX?10000

lock_key 就是 key 鍵；unique_value 是客戶端生成的唯一的標識，區(qū)分來自不同客戶端的鎖操作；NX 代表只在 lock_key 不存在時，才對 lock_key 進行設置操作；PX 10000 表示設置 lock_key 的過期時間為 10s，這是為了避免客戶端發(fā)生異常而無法釋放鎖。

而解鎖的過程就是將 lock_key 鍵刪除（del lock_key），但不能亂刪，要保證執(zhí)行操作的客戶端就是加鎖的客戶端。所以，解鎖的時候，我們要先判斷鎖的 unique_value 是否為加鎖客戶端，是的話，才將 lock_key 鍵刪除。可以看到，解鎖是有兩個操作，這時就需要 Lua 腳本來保證解鎖的原子性，因為 Redis 在執(zhí)行 Lua 腳本時，可以以原子性的方式執(zhí)行，保證了鎖釋放操作的原子性。

//?釋放鎖時，先比較?unique_value?是否相等，避免鎖的誤釋放
if?redis.call("get",KEYS[1])?==?ARGV[1]?then
????return?redis.call("del",KEYS[1])
else
????return?0
end

這樣一來，就通過使用 SET 命令和 Lua 腳本在 Redis 單節(jié)點上完成了分布式鎖的加鎖和解鎖。

計網(wǎng)和操作系統(tǒng)

網(wǎng)絡OSI模型和TCP/IP模型分別介紹一下

OSI七層模型

為了使得多種設備能通過網(wǎng)絡相互通信，和為了解決各種不同設備在網(wǎng)絡互聯(lián)中的兼容性問題，國際標準化組織制定了開放式系統(tǒng)互聯(lián)通信參考模型，也就是 OSI 網(wǎng)絡模型，該模型主要有 7 層，分別是應用層、表示層、會話層、傳輸層、網(wǎng)絡層、數(shù)據(jù)鏈路層以及物理層。

每一層負責的職能都不同，如下：

應用層，負責給應用程序提供統(tǒng)一的接口；表示層，負責把數(shù)據(jù)轉換成兼容另一個系統(tǒng)能識別的格式；會話層，負責建立、管理和終止表示層實體之間的通信會話；傳輸層，負責端到端的數(shù)據(jù)傳輸；網(wǎng)絡層，負責數(shù)據(jù)的路由、轉發(fā)、分片；數(shù)據(jù)鏈路層，負責數(shù)據(jù)的封幀和差錯檢測，以及 MAC 尋址；物理層，負責在物理網(wǎng)絡中傳輸數(shù)據(jù)幀；

由于 OSI 模型實在太復雜，提出的也只是概念理論上的分層，并沒有提供具體的實現(xiàn)方案。事實上，我們比較常見，也比較實用的是四層模型，即 TCP/IP 網(wǎng)絡模型，Linux 系統(tǒng)正是按照這套網(wǎng)絡模型來實現(xiàn)網(wǎng)絡協(xié)議棧的。

TCP/IP模型

TCP/IP協(xié)議被組織成四個概念層，其中有三層對應于ISO參考模型中的相應層。ICP/IP協(xié)議族并不包含物理層和數(shù)據(jù)鏈路層，因此它不能獨立完成整個計算機網(wǎng)絡系統(tǒng)的功能，必須與許多其他的協(xié)議協(xié)同工作。TCP/IP 網(wǎng)絡通常是由上到下分成 4 層，分別是應用層，傳輸層，網(wǎng)絡層和網(wǎng)絡接口層。

應用層 支持 HTTP、SMTP 等最終用戶進程傳輸層 處理主機到主機的通信（TCP、UDP）網(wǎng)絡層 尋址和路由數(shù)據(jù)包（IP 協(xié)議）鏈路層 通過網(wǎng)絡的物理電線、電纜或無線信道移動比特

TCP和UDP區(qū)別是什么？

連接：TCP 是面向連接的傳輸層協(xié)議，傳輸數(shù)據(jù)前先要建立連接；UDP 是不需要連接，即刻傳輸數(shù)據(jù)。服務對象：TCP 是一對一的兩點服務，即一條連接只有兩個端點。UDP 支持一對一、一對多、多對多的交互通信可靠性：TCP 是可靠交付數(shù)據(jù)的，數(shù)據(jù)可以無差錯、不丟失、不重復、按序到達。UDP 是盡最大努力交付，不保證可靠交付數(shù)據(jù)。但是我們可以基于 UDP 傳輸協(xié)議實現(xiàn)一個可靠的傳輸協(xié)議，比如 QUIC 協(xié)議擁塞控制、流量控制：TCP 有擁塞控制和流量控制機制，保證數(shù)據(jù)傳輸?shù)陌踩浴DP 則沒有，即使網(wǎng)絡非常擁堵了，也不會影響 UDP 的發(fā)送速率。首部開銷：TCP 首部長度較長，會有一定的開銷，首部在沒有使用「選項」字段時是 20 個字節(jié)，如果使用了「選項」字段則會變長的。UDP 首部只有 8 個字節(jié)，并且是固定不變的，開銷較小。傳輸方式：TCP 是流式傳輸，沒有邊界，但保證順序和可靠。UDP 是一個包一個包的發(fā)送，是有邊界的，但可能會丟包和亂序。

操作系統(tǒng)中進程之間的通信有哪些

Linux 內核提供了不少進程間通信的方式：

管道消息隊列共享內存信號信號量socket

Linux 內核提供了不少進程間通信的方式，其中最簡單的方式就是管道，管道分為「匿名管道」和「命名管道」。

匿名管道顧名思義，它沒有名字標識，匿名管道是特殊文件只存在于內存，沒有存在于文件系統(tǒng)中，shell 命令中的「|」豎線就是匿名管道，通信的數(shù)據(jù)是無格式的流并且大小受限，通信的方式是單向的，數(shù)據(jù)只能在一個方向上流動，如果要雙向通信，需要創(chuàng)建兩個管道，再來匿名管道是只能用于存在父子關系的進程間通信，匿名管道的生命周期隨著進程創(chuàng)建而建立，隨著進程終止而消失。

命名管道突破了匿名管道只能在親緣關系進程間的通信限制，因為使用命名管道的前提，需要在文件系統(tǒng)創(chuàng)建一個類型為 p 的設備文件，那么毫無關系的進程就可以通過這個設備文件進行通信。另外，不管是匿名管道還是命名管道，進程寫入的數(shù)據(jù)都是緩存在內核中，另一個進程讀取數(shù)據(jù)時候自然也是從內核中獲取，同時通信數(shù)據(jù)都遵循先進先出原則，不支持 lseek 之類的文件定位操作。

消息隊列克服了管道通信的數(shù)據(jù)是無格式的字節(jié)流的問題，消息隊列實際上是保存在內核的「消息鏈表」，消息隊列的消息體是可以用戶自定義的數(shù)據(jù)類型，發(fā)送數(shù)據(jù)時，會被分成一個一個獨立的消息體，當然接收數(shù)據(jù)時，也要與發(fā)送方發(fā)送的消息體的數(shù)據(jù)類型保持一致，這樣才能保證讀取的數(shù)據(jù)是正確的。消息隊列通信的速度不是最及時的，畢竟每次數(shù)據(jù)的寫入和讀取都需要經過用戶態(tài)與內核態(tài)之間的拷貝過程。

共享內存可以解決消息隊列通信中用戶態(tài)與內核態(tài)之間數(shù)據(jù)拷貝過程帶來的開銷，它直接分配一個共享空間，每個進程都可以直接訪問，就像訪問進程自己的空間一樣快捷方便，不需要陷入內核態(tài)或者系統(tǒng)調用，大大提高了通信的速度，享有最快的進程間通信方式之名。但是便捷高效的共享內存通信，帶來新的問題，多進程競爭同個共享資源會造成數(shù)據(jù)的錯亂。

那么，就需要信號量來保護共享資源，以確保任何時刻只能有一個進程訪問共享資源，這種方式就是互斥訪問。信號量不僅可以實現(xiàn)訪問的互斥性，還可以實現(xiàn)進程間的同步，信號量其實是一個計數(shù)器，表示的是資源個數(shù)，其值可以通過兩個原子操作來控制，分別是 P 操作和 V 操作。

與信號量名字很相似的叫信號，它倆名字雖然相似，但功能一點兒都不一樣。信號是異步通信機制，信號可以在應用進程和內核之間直接交互，內核也可以利用信號來通知用戶空間的進程發(fā)生了哪些系統(tǒng)事件，信號事件的來源主要有硬件來源（如鍵盤 Cltr+C ）和軟件來源（如 kill 命令），一旦有信號發(fā)生，進程有三種方式響應信號 1. 執(zhí)行默認操作、2. 捕捉信號、3. 忽略信號。有兩個信號是應用進程無法捕捉和忽略的，即 SIGKILL 和 SIGSTOP，這是為了方便我們能在任何時候結束或停止某個進程。

前面說到的通信機制，都是工作于同一臺主機，如果要與不同主機的進程間通信，那么就需要 Socket 通信了。Socket 實際上不僅用于不同的主機進程間通信，還可以用于本地主機進程間通信，可根據(jù)創(chuàng)建 Socket 的類型不同，分為三種常見的通信方式，一個是基于 TCP 協(xié)議的通信方式，一個是基于 UDP 協(xié)議的通信方式，一個是本地進程間通信方式。

TCP的擁塞控制介紹一下？

一般來說，計算機網(wǎng)絡都處在一個共享的環(huán)境。因此也有可能會因為其他主機之間的通信使得網(wǎng)絡擁堵。

在網(wǎng)絡出現(xiàn)擁堵時，如果繼續(xù)發(fā)送大量數(shù)據(jù)包，可能會導致數(shù)據(jù)包時延、丟失等，這時 TCP 就會重傳數(shù)據(jù)，但是一重傳就會導致網(wǎng)絡的負擔更重，于是會導致更大的延遲以及更多的丟包，這個情況就會進入惡性循環(huán)被不斷地放大....

所以，TCP 不能忽略網(wǎng)絡上發(fā)生的事，它被設計成一個無私的協(xié)議，當網(wǎng)絡發(fā)送擁塞時，TCP 會自我犧牲，降低發(fā)送的數(shù)據(jù)量。

于是，就有了擁塞控制，控制的目的就是避免「發(fā)送方」的數(shù)據(jù)填滿整個網(wǎng)絡。

為了在「發(fā)送方」調節(jié)所要發(fā)送數(shù)據(jù)的量，定義了一個叫做「擁塞窗口」的概念。

擁塞窗口 cwnd是發(fā)送方維護的一個的狀態(tài)變量，它會根據(jù)網(wǎng)絡的擁塞程度動態(tài)變化的。發(fā)送窗口 swnd 和接收窗口 rwnd 是約等于的關系，那么由于加入了擁塞窗口的概念后，此時發(fā)送窗口的值是swnd = min(cwnd, rwnd)，也就是擁塞窗口和接收窗口中的最小值。

擁塞窗口 cwnd 變化的規(guī)則：

只要網(wǎng)絡中沒有出現(xiàn)擁塞，cwnd 就會增大；但網(wǎng)絡中出現(xiàn)了擁塞，cwnd 就減少；

那么怎么知道當前網(wǎng)絡是否出現(xiàn)了擁塞呢？其實只要「發(fā)送方」沒有在規(guī)定時間內接收到 ACK 應答報文，也就是發(fā)生了超時重傳，就會認為網(wǎng)絡出現(xiàn)了擁塞。

擁塞控制有哪些控制算法？

擁塞控制主要是四個算法：

慢啟動擁塞避免擁塞發(fā)生快速恢復

慢啟動

TCP 在剛建立連接完成后，首先是有個慢啟動的過程，這個慢啟動的意思就是一點一點的提高發(fā)送數(shù)據(jù)包的數(shù)量，如果一上來就發(fā)大量的數(shù)據(jù)，這不是給網(wǎng)絡添堵嗎？慢啟動的算法記住一個規(guī)則就行：當發(fā)送方每收到一個 ACK，擁塞窗口 cwnd 的大小就會加 1。這里假定擁塞窗口 cwnd 和發(fā)送窗口 swnd 相等，下面舉個栗子：

連接建立完成后，一開始初始化 cwnd = 1，表示可以傳一個 MSS 大小的數(shù)據(jù)。當收到一個 ACK 確認應答后，cwnd 增加 1，于是一次能夠發(fā)送 2 個當收到 2 個的 ACK 確認應答后， cwnd 增加 2，于是就可以比之前多發(fā)2 個，所以這一次能夠發(fā)送 4 個當這 4 個的 ACK 確認到來的時候，每個確認 cwnd 增加 1， 4 個確認 cwnd 增加 4，于是就可以比之前多發(fā) 4 個，所以這一次能夠發(fā)送 8 個。

慢啟動算法的變化過程如下圖：

可以看出慢啟動算法，發(fā)包的個數(shù)是指數(shù)性的增長。那慢啟動漲到什么時候是個頭呢？有一個叫慢啟動門限 ssthresh （slow start threshold）狀態(tài)變量。

當 cwnd < ssthresh 時，使用慢啟動算法。當 cwnd >= ssthresh 時，就會使用「擁塞避免算法」。

擁塞避免算法

前面說道，當擁塞窗口 cwnd 「超過」慢啟動門限 ssthresh 就會進入擁塞避免算法。一般來說 ssthresh 的大小是 65535 字節(jié)。那么進入擁塞避免算法后，它的規(guī)則是：每當收到一個 ACK 時，cwnd 增加 1/cwnd。接上前面的慢啟動的栗子，現(xiàn)假定 ssthresh 為 8：

• • 當 8 個 ACK 應答確認到來時，每個確認增加 1/8，8 個 ACK 確認 cwnd 一共增加 1，于是這一次能夠發(fā)送 9 個 MSS 大小的數(shù)據(jù)，變成了

  線性增長。

擁塞避免算法的變化過程如下圖：

所以，我們可以發(fā)現(xiàn)，擁塞避免算法就是將原本慢啟動算法的指數(shù)增長變成了線性增長，還是增長階段，但是增長速度緩慢了一些。就這么一直增長著后，網(wǎng)絡就會慢慢進入了擁塞的狀況了，于是就會出現(xiàn)丟包現(xiàn)象，這時就需要對丟失的數(shù)據(jù)包進行重傳。當觸發(fā)了重傳機制，也就進入了「擁塞發(fā)生算法」。

擁塞發(fā)生

當網(wǎng)絡出現(xiàn)擁塞，也就是會發(fā)生數(shù)據(jù)包重傳，重傳機制主要有兩種：

超時重傳快速重傳

這兩種使用的擁塞發(fā)送算法是不同的，接下來分別來說說。發(fā)生超時重傳的擁塞發(fā)生算法當發(fā)生了「超時重傳」，則就會使用擁塞發(fā)生算法。這個時候，ssthresh 和 cwnd 的值會發(fā)生變化：

ssthresh 設為 cwnd/2，cwnd 重置為 1 （是恢復為 cwnd 初始化值，我這里假定 cwnd 初始化值 1）

擁塞發(fā)生算法的變化如下圖：

接著，就重新開始慢啟動，慢啟動是會突然減少數(shù)據(jù)流的。這真是一旦「超時重傳」，馬上回到解放前。但是這種方式太激進了，反應也很強烈，會造成網(wǎng)絡卡頓。就好像本來在秋名山高速漂移著，突然來個緊急剎車，輪胎受得了嗎。。。發(fā)生快速重傳的擁塞發(fā)生算法還有更好的方式，前面我們講過「快速重傳算法」。當接收方發(fā)現(xiàn)丟了一個中間包的時候，發(fā)送三次前一個包的 ACK，于是發(fā)送端就會快速地重傳，不必等待超時再重傳。TCP 認為這種情況不嚴重，因為大部分沒丟，只丟了一小部分，則 ssthresh 和 cwnd 變化如下：

cwnd = cwnd/2 ，也就是設置為原來的一半;ssthresh = cwnd;進入快速恢復算法

快速恢復

快速重傳和快速恢復算法一般同時使用，快速恢復算法是認為，你還能收到 3 個重復 ACK 說明網(wǎng)絡也不那么糟糕，所以沒有必要像 RTO 超時那么強烈。正如前面所說，進入快速恢復之前，cwnd 和 ssthresh 已被更新了：

cwnd = cwnd/2 ，也就是設置為原來的一半;ssthresh = cwnd;

然后，進入快速恢復算法如下：

擁塞窗口 cwnd = ssthresh + 3 （ 3 的意思是確認有 3 個數(shù)據(jù)包被收到了）；重傳丟失的數(shù)據(jù)包；如果再收到重復的 ACK，那么 cwnd 增加 1；如果收到新數(shù)據(jù)的 ACK 后，把 cwnd 設置為第一步中的 ssthresh 的值，原因是該 ACK 確認了新的數(shù)據(jù)，說明從 duplicated ACK 時的數(shù)據(jù)都已收到，該恢復過程已經結束，可以回到恢復之前的狀態(tài)了，也即再次進入擁塞避免狀態(tài)；

快速恢復算法的變化過程如下圖：

也就是沒有像「超時重傳」一夜回到解放前，而是還在比較高的值，后續(xù)呈線性增長。

cookie和session有什么區(qū)別？

Cookie和Session都是Web開發(fā)中用于跟蹤用戶狀態(tài)的技術，但它們在存儲位置、數(shù)據(jù)容量、安全性以及生命周期等方面存在顯著差異：

存儲位置：Cookie的數(shù)據(jù)存儲在客戶端（通常是瀏覽器）。當瀏覽器向服務器發(fā)送請求時，會自動附帶Cookie中的數(shù)據(jù)。Session的數(shù)據(jù)存儲在服務器端。服務器為每個用戶分配一個唯一的Session ID，這個ID通常通過Cookie或URL重寫的方式發(fā)送給客戶端，客戶端后續(xù)的請求會帶上這個Session ID，服務器根據(jù)ID查找對應的Session數(shù)據(jù)。

數(shù)據(jù)容量：單個Cookie的大小限制通常在4KB左右，而且大多數(shù)瀏覽器對每個域名的總Cookie數(shù)量也有限制。由于Session存儲在服務器上，理論上不受數(shù)據(jù)大小的限制，主要受限于服務器的內存大小。

安全性：Cookie相對不安全，因為數(shù)據(jù)存儲在客戶端，容易受到XSS（跨站腳本攻擊）的威脅。不過，可以通過設置HttpOnly屬性來防止JavaScript訪問，減少XSS攻擊的風險，但仍然可能受到CSRF（跨站請求偽造）的攻擊。Session通常認為比Cookie更安全，因為敏感數(shù)據(jù)存儲在服務器端。但仍然需要防范Session劫持（通過獲取他人的Session ID）和會話固定攻擊。

生命周期：Cookie可以設置過期時間，過期后自動刪除。也可以設置為會話Cookie，即瀏覽器關閉時自動刪除。Session在默認情況下，當用戶關閉瀏覽器時，Session結束。但服務器也可以設置Session的超時時間，超過這個時間未活動，Session也會失效。

性能：使用Cookie時，因為數(shù)據(jù)隨每個請求發(fā)送到服務器，可能會影響網(wǎng)絡傳輸效率，尤其是在Cookie數(shù)據(jù)較大時。使用Session時，因為數(shù)據(jù)存儲在服務器端，每次請求都需要查詢服務器上的Session數(shù)據(jù)，這可能會增加服務器的負載，特別是在高并發(fā)場景下。

Java

介紹一下線程池的工作原理

線程池原理

線程池是為了減少頻繁的創(chuàng)建線程和銷毀線程帶來的性能損耗，線程池的工作原理如下圖：

線程池分為核心線程池，線程池的最大容量，還有等待任務的隊列，提交一個任務，如果核心線程沒有滿，就創(chuàng)建一個線程，如果滿了，就是會加入等待隊列，如果等待隊列滿了，就會增加線程，如果達到最大線程數(shù)量，如果都達到最大線程數(shù)量，就會按照一些丟棄的策略進行處理。

線程池的參數(shù)有哪些？

線程池的構造函數(shù)有7個參數(shù)：

corePoolSize：線程池核心線程數(shù)量。默認情況下，線程池中線程的數(shù)量如果 <= corePoolSize，那么即使這些線程處于空閑狀態(tài)，那也不會被銷毀。

maximumPoolSize：線程池中最多可容納的線程數(shù)量。當一個新任務交給線程池，如果此時線程池中有空閑的線程，就會直接執(zhí)行，如果沒有空閑的線程且當前線程池的線程數(shù)量小于corePoolSize，就會創(chuàng)建新的線程來執(zhí)行任務，否則就會將該任務加入到阻塞隊列中，如果阻塞隊列滿了，就會創(chuàng)建一個新線程，從阻塞隊列頭部取出一個任務來執(zhí)行，并將新任務加入到阻塞隊列末尾。如果當前線程池中線程的數(shù)量等于maximumPoolSize，就不會創(chuàng)建新線程，就會去執(zhí)行拒絕策略。

keepAliveTime：當線程池中線程的數(shù)量大于corePoolSize，并且某個線程的空閑時間超過了keepAliveTime，那么這個線程就會被銷毀。

unit：就是keepAliveTime時間的單位。

workQueue：工作隊列。當沒有空閑的線程執(zhí)行新任務時，該任務就會被放入工作隊列中，等待執(zhí)行。

threadFactory：線程工廠?？梢杂脕斫o線程取名字等等

handler：拒絕策略。當一個新任務交給線程池，如果此時線程池中有空閑的線程，就會直接執(zhí)行，如果沒有空閑的線程，就會將該任務加入到阻塞隊列中，如果阻塞隊列滿了，就會創(chuàng)建一個新線程，從阻塞隊列頭部取出一個任務來執(zhí)行，并將新任務加入到阻塞隊列末尾。如果當前線程池中線程的數(shù)量等于maximumPoolSize，就不會創(chuàng)建新線程，就會去執(zhí)行拒絕策略

線程池種類有哪些？

FixedThreadPool：它的核心線程數(shù)和最大線程數(shù)是一樣的，所以可以把它看作是固定線程數(shù)的線程池，它的特點是線程池中的線程數(shù)除了初始階段需要從 0 開始增加外，之后的線程數(shù)量就是固定的，就算任務數(shù)超過線程數(shù)，線程池也不會再創(chuàng)建更多的線程來處理任務，而是會把超出線程處理能力的任務放到任務隊列中進行等待。而且就算任務隊列滿了，到了本該繼續(xù)增加線程數(shù)的時候，由于它的最大線程數(shù)和核心線程數(shù)是一樣的，所以也無法再增加新的線程了。

ExecutorService?executor?=?Executors.newFixedThreadPool(5);

CachedThreadPool：可以稱作可緩存線程池，它的特點在于線程數(shù)是幾乎可以無限增加的（實際最大可以達到 Integer.MAX_VALUE，為 2^31-1，這個數(shù)非常大，所以基本不可能達到），而當線程閑置時還可以對線程進行回收。也就是說該線程池的線程數(shù)量不是固定不變的，當然它也有一個用于存儲提交任務的隊列，但這個隊列是 SynchronousQueue，隊列的容量為0，實際不存儲任何任務，它只負責對任務進行中轉和傳遞，所以效率比較高。

ExecutorService?executor?=?Executors.newCachedThreadPool();

SingleThreadExecutor：它會使用唯一的線程去執(zhí)行任務，原理和 FixedThreadPool 是一樣的，只不過這里線程只有一個，如果線程在執(zhí)行任務的過程中發(fā)生異常，線程池也會重新創(chuàng)建一個線程來執(zhí)行后續(xù)的任務。這種線程池由于只有一個線程，所以非常適合用于所有任務都需要按被提交的順序依次執(zhí)行的場景，而前幾種線程池不一定能夠保障任務的執(zhí)行順序等于被提交的順序，因為它們是多線程并行執(zhí)行的。

ExecutorService?executor?=?Executors.newSingleThreadExecutor();

SingleThreadScheduledExecutor：它實際和 ScheduledThreadPool 線程池非常相似，它只是 ScheduledThreadPool 的一個特例，內部只有一個線程。

ExecutorService?executor?=?Executors.newScheduledThreadPool(5);

Java線程的狀態(tài)有哪些？

源自《Java并發(fā)編程藝術》 java.lang.Thread.State枚舉類中定義了六種線程的狀態(tài)，可以調用線程Thread中的getState()方法獲取當前線程的狀態(tài)。

線程狀態(tài)	解釋
NEW	尚未啟動的線程狀態(tài)，即線程創(chuàng)建，還未調用start方法
RUNNABLE	就緒狀態(tài)（調用start，等待調度）+正在運行
BLOCKED	等待監(jiān)視器鎖時，陷入阻塞狀態(tài)
WAITING	等待狀態(tài)的線程正在等待另一線程執(zhí)行特定的操作（如notify）
TIMED_WAITING	具有指定等待時間的等待狀態(tài)
TERMINATED	線程完成執(zhí)行，終止狀態(tài)

blocked和waiting有啥區(qū)別

觸發(fā)條件:線程進入BLOCKED狀態(tài)通常是因為試圖獲取一個對象的鎖（monitor lock），但該鎖已經被另一個線程持有。這通常發(fā)生在嘗試進入synchronized塊或方法時，如果鎖已被占用，則線程將被阻塞直到鎖可用。線程進入WAITING狀態(tài)是因為它正在等待另一個線程執(zhí)行某些操作，例如調用Object.wait()方法、Thread.join()方法或LockSupport.park()方法。在這種狀態(tài)下，線程將不會消耗CPU資源，并且不會參與鎖的競爭。

喚醒機制:當一個線程被阻塞等待鎖時，一旦鎖被釋放，線程將有機會重新嘗試獲取鎖。如果鎖此時未被其他線程獲取，那么線程可以從BLOCKED狀態(tài)變?yōu)镽UNNABLE狀態(tài)。線程在WAITING狀態(tài)中需要被顯式喚醒。例如，如果線程調用了Object.wait()，那么它必須等待另一個線程調用同一對象上的Object.notify()或Object.notifyAll()方法才能被喚醒。

synchronized和reentrantlock及其應用場景

synchronized 工作原理

synchronized是Java提供的原子性內置鎖，這種內置的并且使用者看不到的鎖也被稱為監(jiān)視器鎖，

使用synchronized之后，會在編譯之后在同步的代碼塊前后加上monitorenter和monitorexit字節(jié)碼指令，他依賴操作系統(tǒng)底層互斥鎖實現(xiàn)。他的作用主要就是實現(xiàn)原子性操作和解決共享變量的內存可見性問題。

執(zhí)行monitorenter指令時會嘗試獲取對象鎖，如果對象沒有被鎖定或者已經獲得了鎖，鎖的計數(shù)器+1。此時其他競爭鎖的線程則會進入等待隊列中。執(zhí)行monitorexit指令時則會把計數(shù)器-1，當計數(shù)器值為0時，則鎖釋放，處于等待隊列中的線程再繼續(xù)競爭鎖。

synchronized是排它鎖，當一個線程獲得鎖之后，其他線程必須等待該線程釋放鎖后才能獲得鎖，而且由于Java中的線程和操作系統(tǒng)原生線程是一一對應的，線程被阻塞或者喚醒時時會從用戶態(tài)切換到內核態(tài)，這種轉換非常消耗性能。

從內存語義來說，加鎖的過程會清除工作內存中的共享變量，再從主內存讀取，而釋放鎖的過程則是將工作內存中的共享變量寫回主內存。

實際上大部分時候我認為說到monitorenter就行了，但是為了更清楚的描述，還是再具體一點。

如果再深入到源碼來說，synchronized實際上有兩個隊列waitSet和entryList。

當多個線程進入同步代碼塊時，首先進入entryList有一個線程獲取到monitor鎖后，就賦值給當前線程，并且計數(shù)器+1如果線程調用wait方法，將釋放鎖，當前線程置為null，計數(shù)器-1，同時進入waitSet等待被喚醒，調用notify或者notifyAll之后又會進入entryList競爭鎖如果線程執(zhí)行完畢，同樣釋放鎖，計數(shù)器-1，當前線程置為null

reentrantlock工作原理

ReentrantLock 的底層實現(xiàn)主要依賴于 AbstractQueuedSynchronizer（AQS）這個抽象類。AQS 是一個提供了基本同步機制的框架，其中包括了隊列、狀態(tài)值等。

ReentrantLock 在 AQS 的基礎上通過內部類 Sync 來實現(xiàn)具體的鎖操作。

不同的 Sync 子類實現(xiàn)了公平鎖和非公平鎖的不同邏輯。

可中斷性：ReentrantLock 實現(xiàn)了可中斷性，這意味著線程在等待鎖的過程中，可以被其他線程中斷而提前結束等待。在底層，ReentrantLock 使用了與 LockSupport.park() 和 LockSupport.unpark() 相關的機制來實現(xiàn)可中斷性。

設置超時時間：ReentrantLock 支持在嘗試獲取鎖時設置超時時間，即等待一定時間后如果還未獲得鎖，則放棄鎖的獲取。這是通過內部的 tryAcquireNanos 方法來實現(xiàn)的。

公平鎖和非公平鎖：在直接創(chuàng)建 ReentrantLock 對象時，默認情況下是非公平鎖。公平鎖是按照線程等待的順序來獲取鎖，而非公平鎖則允許多個線程在同一時刻競爭鎖，不考慮它們申請鎖的順序。公平鎖可以通過在創(chuàng)建 ReentrantLock 時傳入 true 來設置，例如：

ReentrantLock?fairLock?=?new?ReentrantLock(true);

多個條件變量

：ReentrantLock 支持多個條件變量，每個條件變量可以與一個 ReentrantLock 關聯(lián)。這使得線程可以更靈活地進行等待和喚醒操作，而不僅僅是基于對象監(jiān)視器的 wait() 和 notify()。多個條件變量的實現(xiàn)依賴于 Condition 接口，例如：

ReentrantLock?lock?=?new?ReentrantLock();
Condition?condition?=?lock.newCondition();
//?使用下面方法進行等待和喚醒
condition.await();
condition.signal();

可重入性：ReentrantLock 支持可重入性，即同一個線程可以多次獲得同一把鎖，而不會造成死鎖。這是通過內部的 holdCount 計數(shù)來實現(xiàn)的。當一個線程多次獲取鎖時，holdCount 遞增，釋放鎖時遞減，只有當 holdCount 為零時，其他線程才有機會獲取鎖。

應用場景的區(qū)別

synchronized：

簡單同步需求：當你需要對代碼塊或方法進行簡單的同步控制時，synchronized是一個很好的選擇。它使用起來簡單，不需要額外的資源管理，因為鎖會在方法退出或代碼塊執(zhí)行完畢后自動釋放。

代碼塊同步：如果你想對特定代碼段進行同步，而不是整個方法，可以使用synchronized代碼塊。這可以讓你更精細地控制同步的范圍，從而減少鎖的持有時間，提高并發(fā)性能。

內置鎖的使用：synchronized關鍵字使用對象的內置鎖（也稱為監(jiān)視器鎖），這在需要使用對象作為鎖對象的情況下很有用，尤其是在對象狀態(tài)與鎖保護的代碼緊密相關時。

ReentrantLock：

高級鎖功能需求：ReentrantLock提供了synchronized所不具備的高級功能，如公平鎖、響應中斷、定時鎖嘗試、以及多個條件變量。當你需要這些功能時，ReentrantLock是更好的選擇。

性能優(yōu)化：在高度競爭的環(huán)境中，ReentrantLock可以提供比synchronized更好的性能，因為它提供了更細粒度的控制，如嘗試鎖定和定時鎖定，可以減少線程阻塞的可能性。

復雜同步結構：當你需要更復雜的同步結構，如需要多個條件變量來協(xié)調線程之間的通信時，ReentrantLock及其配套的Condition對象可以提供更靈活的解決方案。

綜上，synchronized適用于簡單同步需求和不需要額外鎖功能的場景，而ReentrantLock適用于需要更高級鎖功能、性能優(yōu)化或復雜同步邏輯的情況。選擇哪種同步機制取決于具體的應用需求和性能考慮。

線程池一般是怎么用的？

Java 中的 Executors 類定義了一些快捷的工具方法，來幫助我們快速創(chuàng)建線程池?！?a class="article-link" target="_blank" href="/manufacturer/1000210/">阿里巴巴 Java 開發(fā)手冊》中提到，禁止使用這些方法來創(chuàng)建線程池，而應該手動 new ThreadPoolExecutor 來創(chuàng)建線程池。這一條規(guī)則的背后，是大量血淋淋的生產事故，最典型的就是 newFixedThreadPool 和 newCachedThreadPool，可能因為資源耗盡導致 OOM 問題。所以，不建議使用 Executors 提供的兩種快捷的線程池，原因如下：

我們需要根據(jù)自己的場景、并發(fā)情況來評估線程池的幾個核心參數(shù)，包括核心線程數(shù)、最大線程數(shù)、線程回收策略、工作隊列的類型，以及拒絕策略，確保線程池的工作行為符合需求，一般都需要設置有界的工作隊列和可控的線程數(shù)。任何時候，都應該為自定義線程池指定有意義的名稱，以方便排查問題。當出現(xiàn)線程數(shù)量暴增、線程死鎖、線程占用大量 CPU、線程執(zhí)行出現(xiàn)異常等問題時，我們往往會抓取線程棧。此時，有意義的線程名稱，就可以方便我們定位問題。

除了建議手動聲明線程池以外，我還建議用一些監(jiān)控手段來觀察線程池的狀態(tài)。線程池這個組件往往會表現(xiàn)得任勞任怨、默默無聞，除非是出現(xiàn)了拒絕策略，否則壓力再大都不會拋出一個異常。如果我們能提前觀察到線程池隊列的積壓，或者線程數(shù)量的快速膨脹，往往可以提早發(fā)現(xiàn)并解決問題。

Spring IoC和AOP 介紹一下

Spring IoC和AOP 區(qū)別：

IoC：即控制反轉的意思，它是一種創(chuàng)建和獲取對象的技術思想，依賴注入(DI)是實現(xiàn)這種技術的一種方式。傳統(tǒng)開發(fā)過程中，我們需要通過new關鍵字來創(chuàng)建對象。使用IoC思想開發(fā)方式的話，我們不通過new關鍵字創(chuàng)建對象，而是通過IoC容器來幫我們實例化對象。通過IoC的方式，可以大大降低對象之間的耦合度。

AOP：是面向切面編程，能夠將那些與業(yè)務無關，卻為業(yè)務模塊所共同調用的邏輯封裝起來，以減少系統(tǒng)的重復代碼，降低模塊間的耦合度。Spring AOP 就是基于動態(tài)代理的，如果要代理的對象，實現(xiàn)了某個接口，那么 Spring AOP 會使用 JDK Proxy，去創(chuàng)建代理對象，而對于沒有實現(xiàn)接口的對象，就無法使用 JDK Proxy 去進行代理了，這時候 Spring AOP 會使用 Cglib 生成一個被代理對象的子類來作為代理。

在 Spring 框架中，IOC 和 AOP 結合使用，可以更好地實現(xiàn)代碼的模塊化和分層管理。例如：

通過 IOC 容器管理對象的依賴關系，然后通過 AOP 將橫切關注點統(tǒng)一切入到需要的業(yè)務邏輯中。使用 IOC 容器管理 Service 層和 DAO 層的依賴關系，然后通過 AOP 在 Service 層實現(xiàn)事務管理、日志記錄等橫切功能，使得業(yè)務邏輯更加清晰和可維護。

動態(tài)代理是什么？

Java的動態(tài)代理是一種在運行時動態(tài)創(chuàng)建代理對象的機制，主要用于在不修改原始類的情況下對方法調用進行攔截和增強。Java動態(tài)代理主要分為兩種類型：

基于接口的代理

• （JDK動態(tài)代理）：這種類型的代理要求目標對象必須實現(xiàn)至少一個接口。Java動態(tài)代理會創(chuàng)建一個實現(xiàn)了相同接口的代理類，然后在運行時動態(tài)生成該類的實例。這種代理的實現(xiàn)核心是java.lang.reflect.Proxy

• 類和java.lang.reflect.InvocationHandler接口。每一個動態(tài)代理類都必須實現(xiàn)InvocationHandler接口，并且每個代理類的實例都關聯(lián)到一個handler。當通過代理對象調用一個方法時，這個方法的調用會被轉發(fā)為由InvocationHandler接口的invoke()方法來進行調用。

基于類的代理

（CGLIB動態(tài)代理）：CGLIB（Code Generation Library）是一個強大的高性能的代碼生成庫，它可以在運行時動態(tài)生成一個目標類的子類。CGLIB代理不需要目標類實現(xiàn)接口，而是通過繼承的方式創(chuàng)建代理類。因此，如果目標對象沒有實現(xiàn)任何接口，可以使用CGLIB來創(chuàng)建動態(tài)代理。