大家好,我是小林。
原標(biāo)題:好卷,大二就在美團(tuán)實(shí)習(xí)了
有很多在校的讀者咨詢過我,在校卷什么對求職開發(fā)崗比較有幫助?很多同學(xué)都會想去卷一些比賽、證書、績點(diǎn)這些。
其實(shí)比賽來說,無疑含金量最高的就是 ACM 比賽了,很多大廠都喜歡拿了 ACM 獎項(xiàng)的同學(xué),ACM 是算法比賽,能拿到比賽名次的,肯定都屬于比較聰明的一類人,成長性會很大。但是 ACM 比賽需要花大量的精力去學(xué)算法,而且也不適合每一個人,也是比較看天賦的。
開崗位看重的是你的開發(fā)經(jīng)驗(yàn),適合大多數(shù)人的方式,就是卷實(shí)習(xí)了,比如從大二/研一早早就開始準(zhǔn)備求職方向的內(nèi)容,然后找實(shí)習(xí)工作,多積累實(shí)習(xí)經(jīng)歷,寫到簡歷上,自然就能證明你是具備了工程開發(fā)的經(jīng)驗(yàn)的。
有了實(shí)習(xí)經(jīng)歷,秋招的時候,拿到面試的機(jī)會也會更大一些,因?yàn)榇蟛糠制髽I(yè)都喜歡招進(jìn)來就能干活的,你具備了實(shí)習(xí)經(jīng)歷,就證明你是具備上手快的能力的。
前段時間,正好收到一位訓(xùn)練營同學(xué)的喜事,找到美團(tuán)大廠實(shí)習(xí)了,同學(xué)是 26 屆,目前是大二,積累個半年大廠實(shí)習(xí)經(jīng)歷,等同學(xué)明年秋招,妥妥就是大廠 offer 收割機(jī)了
那大廠實(shí)習(xí)的面試難度到底如何?
今天,就來跟大家拆解一波美團(tuán)Java 后端實(shí)習(xí)的面經(jīng),主要是考察了Java、MySQL、Redis、網(wǎng)絡(luò)、操作系統(tǒng)這五大塊知識,可以說是校招必須掌握的五件套知識了。
我只能說,不愧是大廠面試,強(qiáng)度是很大,光是寫面經(jīng)都快 2 萬字了
考察的知識點(diǎn),我給大家羅列了一下:
-
-
- Java:
線程池、線程狀態(tài)、線程同步和鎖、Srping AOP、IoC、動態(tài)代理
-
-
-
- MySQL:
索引、事務(wù)、性能優(yōu)化
-
-
-
- Redis:
線程模式、分布式鎖
-
MySQL
講講事務(wù)的特性,怎么保證ACID的?
原子性(Atomicity):一個事務(wù)中的所有操作,要么全部完成,要么全部不完成,不會結(jié)束在中間某個環(huán)節(jié),而且事務(wù)在執(zhí)行過程中發(fā)生錯誤,會被回滾到事務(wù)開始前的狀態(tài),就像這個事務(wù)從來沒有執(zhí)行過一樣,就好比買一件商品,購買成功時,則給商家付了錢,商品到手;購買失敗時,則商品在商家手中,消費(fèi)者的錢也沒花出去。
一致性(Consistency):是指事務(wù)操作前和操作后,數(shù)據(jù)滿足完整性約束,數(shù)據(jù)庫保持一致性狀態(tài)。比如,用戶 A 和用戶 B 在銀行分別有 800 元和 600 元,總共 1400 元,用戶 A 給用戶 B 轉(zhuǎn)賬 200 元,分為兩個步驟,從 A 的賬戶扣除 200 元和對 B 的賬戶增加 200 元。一致性就是要求上述步驟操作后,最后的結(jié)果是用戶 A 還有 600 元,用戶 B 有 800 元,總共 1400 元,而不會出現(xiàn)用戶 A 扣除了 200 元,但用戶 B 未增加的情況(該情況,用戶 A 和 B 均為 600 元,總共 1200 元)。
隔離性(Isolation):數(shù)據(jù)庫允許多個并發(fā)事務(wù)同時對其數(shù)據(jù)進(jìn)行讀寫和修改的能力,隔離性可以防止多個事務(wù)并發(fā)執(zhí)行時由于交叉執(zhí)行而導(dǎo)致數(shù)據(jù)的不一致,因?yàn)槎鄠€事務(wù)同時使用相同的數(shù)據(jù)時,不會相互干擾,每個事務(wù)都有一個完整的數(shù)據(jù)空間,對其他并發(fā)事務(wù)是隔離的。也就是說,消費(fèi)者購買商品這個事務(wù),是不影響其他消費(fèi)者購買的。
持久性(Durability):事務(wù)處理結(jié)束后,對數(shù)據(jù)的修改就是永久的,即便系統(tǒng)故障也不會丟失。
MySQL InnoDB 引擎通過什么技術(shù)來保證事務(wù)的這四個特性的呢?
- 持久性是通過 redo log (重做日志)來保證的;原子性是通過 undo log(回滾日志) 來保證的;隔離性是通過 MVCC(多版本并發(fā)控制) 或鎖機(jī)制來保證的;一致性則是通過持久性+原子性+隔離性來保證;
事務(wù)的隔離級別有哪些?
讀未提交(read uncommitted),指一個事務(wù)還沒提交時,它做的變更就能被其他事務(wù)看到;
讀提交(read committed),指一個事務(wù)提交之后,它做的變更才能被其他事務(wù)看到;
可重復(fù)讀(repeatable read),指一個事務(wù)執(zhí)行過程中看到的數(shù)據(jù),一直跟這個事務(wù)啟動時看到的數(shù)據(jù)是一致的,
MySQL InnoDB 引擎的默認(rèn)隔離級別;
串行化(serializable);會對記錄加上讀寫鎖,在多個事務(wù)對這條記錄進(jìn)行讀寫操作時,如果發(fā)生了讀寫沖突的時候,后訪問的事務(wù)必須等前一個事務(wù)執(zhí)行完成,才能繼續(xù)執(zhí)行;
按隔離水平高低排序如下:
針對不同的隔離級別,并發(fā)事務(wù)時可能發(fā)生的現(xiàn)象也會不同。
也就是說:
- 在「讀未提交」隔離級別下,可能發(fā)生臟讀、不可重復(fù)讀和幻讀現(xiàn)象;在「讀提交」隔離級別下,可能發(fā)生不可重復(fù)讀和幻讀現(xiàn)象,但是不可能發(fā)生臟讀現(xiàn)象;在「可重復(fù)讀」隔離級別下,可能發(fā)生幻讀現(xiàn)象,但是不可能臟讀和不可重復(fù)讀現(xiàn)象;在「串行化」隔離級別下,臟讀、不可重復(fù)讀和幻讀現(xiàn)象都不可能會發(fā)生。
講講索引的分類是什么?
MySQL可以按照四個角度來分類索引。
-
-
- 按「數(shù)據(jù)結(jié)構(gòu)」分類:
B+tree索引、Hash索引、Full-text索引
-
-
-
- 按「物理存儲」分類:
聚簇索引(主鍵索引)、二級索引(輔助索引)
-
-
-
- 按「字段特性」分類:
主鍵索引、唯一索引、普通索引、前綴索引
-
-
-
-
- 按「字段個數(shù)」分類:
單列索引、聯(lián)合索引
-
-
接下來,按照這些角度來說說各類索引的特點(diǎn)。
按數(shù)據(jù)結(jié)構(gòu)分類
從數(shù)據(jù)結(jié)構(gòu)的角度來看,MySQL 常見索引有 B+Tree 索引、HASH 索引、Full-Text 索引。每一種存儲引擎支持的索引類型不一定相同,我在表中總結(jié)了 MySQL 常見的存儲引擎 InnoDB、MyISAM 和 Memory 分別支持的索引類型。
InnoDB 是在 MySQL 5.5 之后成為默認(rèn)的 MySQL 存儲引擎,B+Tree 索引類型也是 MySQL 存儲引擎采用最多的索引類型。在創(chuàng)建表時,InnoDB 存儲引擎會根據(jù)不同的場景選擇不同的列作為索引:
- 如果有主鍵,默認(rèn)會使用主鍵作為聚簇索引的索引鍵(key);如果沒有主鍵,就選擇第一個不包含 NULL 值的唯一列作為聚簇索引的索引鍵(key);在上面兩個都沒有的情況下,InnoDB 將自動生成一個隱式自增 id 列作為聚簇索引的索引鍵(key);
其它索引都屬于輔助索引(Secondary Index),也被稱為二級索引或非聚簇索引。創(chuàng)建的主鍵索引和二級索引默認(rèn)使用的是 B+Tree 索引。
按物理存儲分類
從物理存儲的角度來看,索引分為聚簇索引(主鍵索引)、二級索引(輔助索引)。這兩個區(qū)別在前面也提到了:
- 主鍵索引的 B+Tree 的葉子節(jié)點(diǎn)存放的是實(shí)際數(shù)據(jù),所有完整的用戶記錄都存放在主鍵索引的 B+Tree 的葉子節(jié)點(diǎn)里;二級索引的 B+Tree 的葉子節(jié)點(diǎn)存放的是主鍵值,而不是實(shí)際數(shù)據(jù)。
所以,在查詢時使用了二級索引,如果查詢的數(shù)據(jù)能在二級索引里查詢的到,那么就不需要回表,這個過程就是覆蓋索引。如果查詢的數(shù)據(jù)不在二級索引里,就會先檢索二級索引,找到對應(yīng)的葉子節(jié)點(diǎn),獲取到主鍵值后,然后再檢索主鍵索引,就能查詢到數(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)合索引(復(fù)合索引)。
- 建立在單列上的索引稱為單列索引,比如主鍵索引;建立在多列上的索引稱為聯(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é)點(diǎn)之間我畫了單向鏈表,但是實(shí)際上是雙向鏈表,原圖我找不到了,修改不了,偷個懶我不重畫了,大家腦補(bǔ)成雙向鏈表就行)。
可以看到,聯(lián)合索引的非葉子節(jié)點(diǎn)用兩個字段的值作為 B+Tree 的 key 值。當(dāng)在聯(lián)合索引查詢數(shù)據(jù)時,先按 product_no 字段比較,在 product_no 相同的情況下再按 name 字段比較。
也就是說,聯(lián)合索引查詢的 B+Tree 是先按 product_no 進(jìn)行排序,然后再 product_no 相同的情況再按 name 字段排序。因此,使用聯(lián)合索引時,存在最左匹配原則,也就是按照最左優(yōu)先的方式進(jìn)行索引的匹配。在使用聯(lián)合索引進(jì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àn)橛胁樵儍?yōu)化器,所以 a 字段在 where 子句的順序并不重要。但是,如果查詢條件是以下這幾種,因?yàn)椴环献钭笃ヅ湓瓌t,所以就無法匹配上聯(lián)合索引,聯(lián)合索引就會失效:
- where b=2;where c=3;where b=2 and c=3;
上面這些查詢條件之所以會失效,是因?yàn)?a, b, c) 聯(lián)合索引,是先按 a 排序,在 a 相同的情況再按 b 排序,在 b 相同的情況再按 c 排序。所以,b 和 c 是全局無序,局部相對有序的,這樣在沒有遵循最左匹配原則的情況下,是無法利用到索引的。
聯(lián)合索引有一些特殊情況,并不是查詢過程使用了聯(lián)合索引查詢,就代表聯(lián)合索引中的所有字段都用到了聯(lián)合索引進(jìn)行索引查詢,也就是可能存在部分字段用到聯(lián)合索引的 B+Tree,部分字段沒有用到聯(lián)合索引的 B+Tree 的情況。這種特殊情況就發(fā)生在范圍查詢。聯(lián)合索引的最左匹配原則會一直向右匹配直到遇到「范圍查詢」就會停止匹配。也就是范圍查詢的字段可以用到聯(lián)合索引,但是在范圍查詢字段的后面的字段無法用到聯(lián)合索引。
索引結(jié)構(gòu),為什么innoDB用B+樹
MySQL 是會將數(shù)據(jù)持久化在硬盤,而存儲功能是由 MySQL 存儲引擎實(shí)現(xiàn)的,所以討論 MySQL 使用哪種數(shù)據(jù)結(jié)構(gòu)作為索引,實(shí)際上是在討論存儲引使用哪種數(shù)據(jù)結(jié)構(gòu)作為索引,InnoDB 是 MySQL 默認(rèn)的存儲引擎,它就是采用了 B+ 樹作為索引的數(shù)據(jù)結(jié)構(gòu)。
要設(shè)計(jì)一個 MySQL 的索引數(shù)據(jù)結(jié)構(gòu),不僅僅考慮數(shù)據(jù)結(jié)構(gòu)增刪改的時間復(fù)雜度,更重要的是要考慮磁盤 I/0 的操作次數(shù)。因?yàn)樗饕陀涗浂际谴娣旁谟脖P,硬盤是一個非常慢的存儲設(shè)備,我們在查詢數(shù)據(jù)的時候,最好能在盡可能少的磁盤 I/0 的操作次數(shù)內(nèi)完成。
二分查找樹雖然是一個天然的二分結(jié)構(gòu),能很好的利用二分查找快速定位數(shù)據(jù),但是它存在一種極端的情況,每當(dāng)插入的元素都是樹內(nèi)最大的元素,就會導(dǎo)致二分查找樹退化成一個鏈表,此時查詢復(fù)雜度就會從 O(logn)降低為 O(n)。
為了解決二分查找樹退化成鏈表的問題,就出現(xiàn)了自平衡二叉樹,保證了查詢操作的時間復(fù)雜度就會一直維持在 O(logn) 。但是它本質(zhì)上還是一個二叉樹,每個節(jié)點(diǎn)只能有 2 個子節(jié)點(diǎn),隨著元素的增多,樹的高度會越來越高。
而樹的高度決定于磁盤 I/O 操作的次數(shù),因?yàn)闃涫谴鎯υ诖疟P中的,訪問每個節(jié)點(diǎn),都對應(yīng)一次磁盤 I/O 操作,也就是說樹的高度就等于每次查詢數(shù)據(jù)時磁盤 IO 操作的次數(shù),所以樹的高度越高,就會影響查詢性能。
B 樹和 B+ 都是通過多叉樹的方式,會將樹的高度變矮,所以這兩個數(shù)據(jù)結(jié)構(gòu)非常適合檢索存于磁盤中的數(shù)據(jù)。
B+Tree vs B Tree:B+Tree 只在葉子節(jié)點(diǎn)存儲數(shù)據(jù),而 B 樹 的非葉子節(jié)點(diǎn)也要存儲數(shù)據(jù),所以 B+Tree 的單個節(jié)點(diǎn)的數(shù)據(jù)量更小,在相同的磁盤 I/O 次數(shù)下,就能查詢更多的節(jié)點(diǎn)。另外,B+Tree 葉子節(jié)點(diǎn)采用的是雙鏈表連接,適合 MySQL 中常見的基于范圍的順序查找,而 B 樹無法做到這一點(diǎn)。
B+Tree vs 二叉樹:對于有 N 個葉子節(jié)點(diǎn)的 B+Tree,其搜索復(fù)雜度為O(logdN),其中 d 表示節(jié)點(diǎn)允許的最大子節(jié)點(diǎn)個數(shù)為 d 個。在實(shí)際的應(yīng)用當(dāng)中, d 值是大于100的,這樣就保證了,即使數(shù)據(jù)達(dá)到千萬級別時,B+Tree 的高度依然維持在 3~4 層左右,也就是說一次數(shù)據(jù)查詢操作只需要做 3~4 次的磁盤 I/O 操作就能查詢到目標(biāo)數(shù)據(jù)。而二叉樹的每個父節(jié)點(diǎn)的兒子節(jié)點(diǎn)個數(shù)只能是 2 個,意味著其搜索復(fù)雜度為 O(logN),這已經(jīng)比 B+Tree 高出不少,因此二叉樹檢索到目標(biāo)數(shù)據(jù)所經(jīng)歷的磁盤 I/O 次數(shù)要更多。
B+Tree vs Hash:Hash 在做等值查詢的時候效率賊快,搜索復(fù)雜度為 O(1)。但是 Hash 表不適合做范圍查詢,它更適合做等值的查詢,這也是 B+Tree 索引要比 Hash 表索引有著更廣泛的適用場景的原因
給你張表,發(fā)現(xiàn)查詢速度很慢,你有那些解決方案
分析查詢語句:使用EXPLAIN命令分析SQL執(zhí)行計(jì)劃,找出慢查詢的原因,比如是否使用了全表掃描,是否存在索引未被利用的情況等,并根據(jù)相應(yīng)情況對索引進(jìn)行適當(dāng)修改。
創(chuàng)建或優(yōu)化索引:根據(jù)查詢條件創(chuàng)建合適的索引,特別是經(jīng)常用于WHERE子句的字段、Orderby 排序的字段、Join 連表查詢的字典、 group by的字段,并且如果查詢中經(jīng)常涉及多個字段,考慮創(chuàng)建聯(lián)合索引,使用聯(lián)合索引要符合最左匹配原則,不然會索引失效
避免索引失效:比如不要用左模糊匹配、函數(shù)計(jì)算、表達(dá)式計(jì)算等等。
查詢優(yōu)化:避免使用SELECT *,只查詢真正需要的列;使用覆蓋索引,即索引包含所有查詢的字段;聯(lián)表查詢最好要以小表驅(qū)動大表,并且被驅(qū)動表的字段要有索引,當(dāng)然最好通過冗余字段的設(shè)計(jì),避免聯(lián)表查詢。
分頁優(yōu)化:針對 limit n,y 深分頁的查詢優(yōu)化,可以把Limit查詢轉(zhuǎn)換成某個位置的查詢:select * from tb_sku where id>20000 limit 10,該方案適用于主鍵自增的表,
優(yōu)化數(shù)據(jù)庫表:如果單表的數(shù)據(jù)超過了千萬級別,考慮是否需要將大表拆分為小表,減輕單個表的查詢壓力。也可以將字段多的表分解成多個表,有些字段使用頻率高,有些低,數(shù)據(jù)量大時,會由于使用頻率低的存在而變慢,可以考慮分開。
使用緩存技術(shù):引入緩存層,如Redis,存儲熱點(diǎn)數(shù)據(jù)和頻繁查詢的結(jié)果,但是要考慮緩存一致性的問題,對于讀請求會選擇旁路緩存策略,對于寫請求會選擇先更新 db,再刪除緩存的策略。
Redis
Redis單線程為什么這么快?
官方使用基準(zhǔn)測試的結(jié)果是,單線程的 Redis 吞吐量可以達(dá)到 10W/每秒,如下圖所示:
img之所以 Redis 采用單線程(網(wǎng)絡(luò) I/O 和執(zhí)行命令)那么快,有如下幾個原因:
Redis 的大部分操作都在內(nèi)存中完成,并且采用了高效的數(shù)據(jù)結(jié)構(gòu),因此 Redis 瓶頸可能是機(jī)器的內(nèi)存或者網(wǎng)絡(luò)帶寬,而并非 CPU,既然 CPU 不是瓶頸,那么自然就采用單線程的解決方案了;Redis 采用單線程模型可以避免了多線程之間的競爭,省去了多線程切換帶來的時間和性能上的開銷,而且也不會導(dǎo)致死鎖問題。Redis 采用了I/O 多路復(fù)用機(jī)制處理大量的客戶端 Socket 請求,IO 多路復(fù)用機(jī)制是指一個線程處理多個 IO 流,就是我們經(jīng)常聽到的 select/epoll 機(jī)制。簡單來說,在 Redis 只運(yùn)行單線程的情況下,該機(jī)制允許內(nèi)核中,同時存在多個監(jiān)聽 Socket 和已連接 Socket。內(nèi)核會一直監(jiān)聽這些 Socket 上的連接請求或數(shù)據(jù)請求。一旦有請求到達(dá),就會交給 Redis 線程處理,這就實(shí)現(xiàn)了一個 Redis 線程處理多個 IO 流的效果。
Redis分布式鎖是怎么實(shí)現(xiàn)的?
分布式鎖是用于分布式環(huán)境下并發(fā)控制的一種機(jī)制,用于控制某個資源在同一時刻只能被一個應(yīng)用所使用。如下圖所示:
Redis 本身可以被多個客戶端共享訪問,正好就是一個共享存儲系統(tǒng),可以用來保存分布式鎖,而且 Redis 的讀寫性能高,可以應(yīng)對高并發(fā)的鎖操作場景。Redis 的 SET 命令有個 NX 參數(shù)可以實(shí)現(xiàn)「key不存在才插入」,所以可以用它來實(shí)現(xiàn)分布式鎖:
- 如果 key 不存在,則顯示插入成功,可以用來表示加鎖成功;如果 key 存在,則會顯示插入失敗,可以用來表示加鎖失敗。
基于 Redis 節(jié)點(diǎn)實(shí)現(xiàn)分布式鎖時,對于加鎖操作,我們需要滿足三個條件。
- 加鎖包括了讀取鎖變量、檢查鎖變量值和設(shè)置鎖變量值三個操作,但需要以原子操作的方式完成,所以,我們使用 SET 命令帶上 NX 選項(xiàng)來實(shí)現(xiàn)加鎖;鎖變量需要設(shè)置過期時間,以免客戶端拿到鎖后發(fā)生異常,導(dǎo)致鎖一直無法釋放,所以,我們在 SET 命令執(zhí)行時加上 EX/PX 選項(xiàng),設(shè)置其過期時間;鎖變量的值需要能區(qū)分來自不同客戶端的加鎖操作,以免在釋放鎖時,出現(xiàn)誤釋放操作,所以,我們使用 SET 命令設(shè)置鎖變量值時,每個客戶端設(shè)置的值是一個唯一值,用于標(biāo)識客戶端;
滿足這三個條件的分布式命令如下:
SET?lock_key?unique_value?NX?PX?10000
- lock_key 就是 key 鍵;unique_value 是客戶端生成的唯一的標(biāo)識,區(qū)分來自不同客戶端的鎖操作;NX 代表只在 lock_key 不存在時,才對 lock_key 進(jìn)行設(shè)置操作;PX 10000 表示設(shè)置 lock_key 的過期時間為 10s,這是為了避免客戶端發(fā)生異常而無法釋放鎖。
而解鎖的過程就是將 lock_key 鍵刪除(del lock_key),但不能亂刪,要保證執(zhí)行操作的客戶端就是加鎖的客戶端。所以,解鎖的時候,我們要先判斷鎖的 unique_value 是否為加鎖客戶端,是的話,才將 lock_key 鍵刪除??梢钥吹?,解鎖是有兩個操作,這時就需要 Lua 腳本來保證解鎖的原子性,因?yàn)?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é)點(diǎn)上完成了分布式鎖的加鎖和解鎖。
計(jì)網(wǎng)和操作系統(tǒng)
網(wǎng)絡(luò)OSI模型和TCP/IP模型分別介紹一下
OSI七層模型
為了使得多種設(shè)備能通過網(wǎng)絡(luò)相互通信,和為了解決各種不同設(shè)備在網(wǎng)絡(luò)互聯(lián)中的兼容性問題,國際標(biāo)準(zhǔn)化組織制定了開放式系統(tǒng)互聯(lián)通信參考模型,也就是 OSI 網(wǎng)絡(luò)模型,該模型主要有 7 層,分別是應(yīng)用層、表示層、會話層、傳輸層、網(wǎng)絡(luò)層、數(shù)據(jù)鏈路層以及物理層。
每一層負(fù)責(zé)的職能都不同,如下:
- 應(yīng)用層,負(fù)責(zé)給應(yīng)用程序提供統(tǒng)一的接口;表示層,負(fù)責(zé)把數(shù)據(jù)轉(zhuǎn)換成兼容另一個系統(tǒng)能識別的格式;會話層,負(fù)責(zé)建立、管理和終止表示層實(shí)體之間的通信會話;傳輸層,負(fù)責(zé)端到端的數(shù)據(jù)傳輸;網(wǎng)絡(luò)層,負(fù)責(zé)數(shù)據(jù)的路由、轉(zhuǎn)發(fā)、分片;數(shù)據(jù)鏈路層,負(fù)責(zé)數(shù)據(jù)的封幀和差錯檢測,以及 MAC 尋址;物理層,負(fù)責(zé)在物理網(wǎng)絡(luò)中傳輸數(shù)據(jù)幀;
由于 OSI 模型實(shí)在太復(fù)雜,提出的也只是概念理論上的分層,并沒有提供具體的實(shí)現(xiàn)方案。事實(shí)上,我們比較常見,也比較實(shí)用的是四層模型,即 TCP/IP 網(wǎng)絡(luò)模型,Linux 系統(tǒng)正是按照這套網(wǎng)絡(luò)模型來實(shí)現(xiàn)網(wǎng)絡(luò)協(xié)議棧的。
TCP/IP模型
TCP/IP協(xié)議被組織成四個概念層,其中有三層對應(yīng)于ISO參考模型中的相應(yīng)層。ICP/IP協(xié)議族并不包含物理層和數(shù)據(jù)鏈路層,因此它不能獨(dú)立完成整個計(jì)算機(jī)網(wǎng)絡(luò)系統(tǒng)的功能,必須與許多其他的協(xié)議協(xié)同工作。TCP/IP 網(wǎng)絡(luò)通常是由上到下分成 4 層,分別是應(yīng)用層,傳輸層,網(wǎng)絡(luò)層和網(wǎng)絡(luò)接口層。
- 應(yīng)用層 支持 HTTP、SMTP 等最終用戶進(jìn)程傳輸層 處理主機(jī)到主機(jī)的通信(TCP、UDP)網(wǎng)絡(luò)層 尋址和路由數(shù)據(jù)包(IP 協(xié)議)鏈路層 通過網(wǎng)絡(luò)的物理電線、電纜或無線信道移動比特
TCP和UDP區(qū)別是什么?
- 連接:TCP 是面向連接的傳輸層協(xié)議,傳輸數(shù)據(jù)前先要建立連接;UDP 是不需要連接,即刻傳輸數(shù)據(jù)。服務(wù)對象:TCP 是一對一的兩點(diǎn)服務(wù),即一條連接只有兩個端點(diǎn)。UDP 支持一對一、一對多、多對多的交互通信可靠性:TCP 是可靠交付數(shù)據(jù)的,數(shù)據(jù)可以無差錯、不丟失、不重復(fù)、按序到達(dá)。UDP 是盡最大努力交付,不保證可靠交付數(shù)據(jù)。但是我們可以基于 UDP 傳輸協(xié)議實(shí)現(xiàn)一個可靠的傳輸協(xié)議,比如 QUIC 協(xié)議擁塞控制、流量控制:TCP 有擁塞控制和流量控制機(jī)制,保證數(shù)據(jù)傳輸?shù)陌踩浴DP 則沒有,即使網(wǎng)絡(luò)非常擁堵了,也不會影響 UDP 的發(fā)送速率。首部開銷:TCP 首部長度較長,會有一定的開銷,首部在沒有使用「選項(xiàng)」字段時是 20 個字節(jié),如果使用了「選項(xiàng)」字段則會變長的。UDP 首部只有 8 個字節(jié),并且是固定不變的,開銷較小。傳輸方式:TCP 是流式傳輸,沒有邊界,但保證順序和可靠。UDP 是一個包一個包的發(fā)送,是有邊界的,但可能會丟包和亂序。
操作系統(tǒng)中進(jìn)程之間的通信有哪些
Linux 內(nèi)核提供了不少進(jìn)程間通信的方式:
- 管道消息隊(duì)列共享內(nèi)存信號信號量socket
Linux 內(nèi)核提供了不少進(jìn)程間通信的方式,其中最簡單的方式就是管道,管道分為「匿名管道」和「命名管道」。
匿名管道顧名思義,它沒有名字標(biāo)識,匿名管道是特殊文件只存在于內(nèi)存,沒有存在于文件系統(tǒng)中,shell 命令中的「|」豎線就是匿名管道,通信的數(shù)據(jù)是無格式的流并且大小受限,通信的方式是單向的,數(shù)據(jù)只能在一個方向上流動,如果要雙向通信,需要創(chuàng)建兩個管道,再來匿名管道是只能用于存在父子關(guān)系的進(jìn)程間通信,匿名管道的生命周期隨著進(jìn)程創(chuàng)建而建立,隨著進(jìn)程終止而消失。
命名管道突破了匿名管道只能在親緣關(guān)系進(jìn)程間的通信限制,因?yàn)槭褂妹艿赖那疤?,需要在文件系統(tǒng)創(chuàng)建一個類型為 p 的設(shè)備文件,那么毫無關(guān)系的進(jìn)程就可以通過這個設(shè)備文件進(jìn)行通信。另外,不管是匿名管道還是命名管道,進(jìn)程寫入的數(shù)據(jù)都是緩存在內(nèi)核中,另一個進(jìn)程讀取數(shù)據(jù)時候自然也是從內(nèi)核中獲取,同時通信數(shù)據(jù)都遵循先進(jìn)先出原則,不支持 lseek 之類的文件定位操作。
消息隊(duì)列克服了管道通信的數(shù)據(jù)是無格式的字節(jié)流的問題,消息隊(duì)列實(shí)際上是保存在內(nèi)核的「消息鏈表」,消息隊(duì)列的消息體是可以用戶自定義的數(shù)據(jù)類型,發(fā)送數(shù)據(jù)時,會被分成一個一個獨(dú)立的消息體,當(dāng)然接收數(shù)據(jù)時,也要與發(fā)送方發(fā)送的消息體的數(shù)據(jù)類型保持一致,這樣才能保證讀取的數(shù)據(jù)是正確的。消息隊(duì)列通信的速度不是最及時的,畢竟每次數(shù)據(jù)的寫入和讀取都需要經(jīng)過用戶態(tài)與內(nèi)核態(tài)之間的拷貝過程。
共享內(nèi)存可以解決消息隊(duì)列通信中用戶態(tài)與內(nèi)核態(tài)之間數(shù)據(jù)拷貝過程帶來的開銷,它直接分配一個共享空間,每個進(jìn)程都可以直接訪問,就像訪問進(jìn)程自己的空間一樣快捷方便,不需要陷入內(nèi)核態(tài)或者系統(tǒng)調(diào)用,大大提高了通信的速度,享有最快的進(jìn)程間通信方式之名。但是便捷高效的共享內(nèi)存通信,帶來新的問題,多進(jìn)程競爭同個共享資源會造成數(shù)據(jù)的錯亂。
那么,就需要信號量來保護(hù)共享資源,以確保任何時刻只能有一個進(jìn)程訪問共享資源,這種方式就是互斥訪問。信號量不僅可以實(shí)現(xiàn)訪問的互斥性,還可以實(shí)現(xiàn)進(jìn)程間的同步,信號量其實(shí)是一個計(jì)數(shù)器,表示的是資源個數(shù),其值可以通過兩個原子操作來控制,分別是 P 操作和 V 操作。
與信號量名字很相似的叫信號,它倆名字雖然相似,但功能一點(diǎn)兒都不一樣。信號是異步通信機(jī)制,信號可以在應(yīng)用進(jìn)程和內(nèi)核之間直接交互,內(nèi)核也可以利用信號來通知用戶空間的進(jìn)程發(fā)生了哪些系統(tǒng)事件,信號事件的來源主要有硬件來源(如鍵盤 Cltr+C )和軟件來源(如 kill 命令),一旦有信號發(fā)生,進(jìn)程有三種方式響應(yīng)信號 1. 執(zhí)行默認(rèn)操作、2. 捕捉信號、3. 忽略信號。有兩個信號是應(yīng)用進(jìn)程無法捕捉和忽略的,即 SIGKILL 和 SIGSTOP,這是為了方便我們能在任何時候結(jié)束或停止某個進(jìn)程。
前面說到的通信機(jī)制,都是工作于同一臺主機(jī),如果要與不同主機(jī)的進(jìn)程間通信,那么就需要 Socket 通信了。Socket 實(shí)際上不僅用于不同的主機(jī)進(jìn)程間通信,還可以用于本地主機(jī)進(jìn)程間通信,可根據(jù)創(chuàng)建 Socket 的類型不同,分為三種常見的通信方式,一個是基于 TCP 協(xié)議的通信方式,一個是基于 UDP 協(xié)議的通信方式,一個是本地進(jìn)程間通信方式。
TCP的擁塞控制介紹一下?
一般來說,計(jì)算機(jī)網(wǎng)絡(luò)都處在一個共享的環(huán)境。因此也有可能會因?yàn)槠渌鳈C(jī)之間的通信使得網(wǎng)絡(luò)擁堵。
在網(wǎng)絡(luò)出現(xiàn)擁堵時,如果繼續(xù)發(fā)送大量數(shù)據(jù)包,可能會導(dǎo)致數(shù)據(jù)包時延、丟失等,這時 TCP 就會重傳數(shù)據(jù),但是一重傳就會導(dǎo)致網(wǎng)絡(luò)的負(fù)擔(dān)更重,于是會導(dǎo)致更大的延遲以及更多的丟包,這個情況就會進(jìn)入惡性循環(huán)被不斷地放大....
所以,TCP 不能忽略網(wǎng)絡(luò)上發(fā)生的事,它被設(shè)計(jì)成一個無私的協(xié)議,當(dāng)網(wǎng)絡(luò)發(fā)送擁塞時,TCP 會自我犧牲,降低發(fā)送的數(shù)據(jù)量。
于是,就有了擁塞控制,控制的目的就是避免「發(fā)送方」的數(shù)據(jù)填滿整個網(wǎng)絡(luò)。
為了在「發(fā)送方」調(diào)節(jié)所要發(fā)送數(shù)據(jù)的量,定義了一個叫做「擁塞窗口」的概念。
擁塞窗口 cwnd是發(fā)送方維護(hù)的一個的狀態(tài)變量,它會根據(jù)網(wǎng)絡(luò)的擁塞程度動態(tài)變化的。發(fā)送窗口 swnd 和接收窗口 rwnd 是約等于的關(guān)系,那么由于加入了擁塞窗口的概念后,此時發(fā)送窗口的值是swnd = min(cwnd, rwnd),也就是擁塞窗口和接收窗口中的最小值。
擁塞窗口 cwnd 變化的規(guī)則:
- 只要網(wǎng)絡(luò)中沒有出現(xiàn)擁塞,cwnd 就會增大;但網(wǎng)絡(luò)中出現(xiàn)了擁塞,cwnd 就減少;
那么怎么知道當(dāng)前網(wǎng)絡(luò)是否出現(xiàn)了擁塞呢?其實(shí)只要「發(fā)送方」沒有在規(guī)定時間內(nèi)接收到 ACK 應(yīng)答報文,也就是發(fā)生了超時重傳,就會認(rèn)為網(wǎng)絡(luò)出現(xiàn)了擁塞。
擁塞控制有哪些控制算法?
擁塞控制主要是四個算法:
- 慢啟動擁塞避免擁塞發(fā)生快速恢復(fù)
慢啟動
TCP 在剛建立連接完成后,首先是有個慢啟動的過程,這個慢啟動的意思就是一點(diǎn)一點(diǎn)的提高發(fā)送數(shù)據(jù)包的數(shù)量,如果一上來就發(fā)大量的數(shù)據(jù),這不是給網(wǎng)絡(luò)添堵嗎?慢啟動的算法記住一個規(guī)則就行:當(dāng)發(fā)送方每收到一個 ACK,擁塞窗口 cwnd 的大小就會加 1。這里假定擁塞窗口 cwnd 和發(fā)送窗口 swnd 相等,下面舉個栗子:
- 連接建立完成后,一開始初始化 cwnd = 1,表示可以傳一個 MSS 大小的數(shù)據(jù)。當(dāng)收到一個 ACK 確認(rèn)應(yīng)答后,cwnd 增加 1,于是一次能夠發(fā)送 2 個當(dāng)收到 2 個的 ACK 確認(rèn)應(yīng)答后, cwnd 增加 2,于是就可以比之前多發(fā)2 個,所以這一次能夠發(fā)送 4 個當(dāng)這 4 個的 ACK 確認(rèn)到來的時候,每個確認(rèn) cwnd 增加 1, 4 個確認(rèn) cwnd 增加 4,于是就可以比之前多發(fā) 4 個,所以這一次能夠發(fā)送 8 個。
慢啟動算法的變化過程如下圖:
可以看出慢啟動算法,發(fā)包的個數(shù)是指數(shù)性的增長。那慢啟動漲到什么時候是個頭呢?有一個叫慢啟動門限 ssthresh (slow start threshold)狀態(tài)變量。
- 當(dāng) cwnd < ssthresh 時,使用慢啟動算法。當(dāng) cwnd >= ssthresh 時,就會使用「擁塞避免算法」。
擁塞避免算法
前面說道,當(dāng)擁塞窗口 cwnd 「超過」慢啟動門限 ssthresh 就會進(jìn)入擁塞避免算法。一般來說 ssthresh 的大小是 65535 字節(jié)。那么進(jìn)入擁塞避免算法后,它的規(guī)則是:每當(dāng)收到一個 ACK 時,cwnd 增加 1/cwnd。接上前面的慢啟動的栗子,現(xiàn)假定 ssthresh 為 8:
-
-
- 當(dāng) 8 個 ACK 應(yīng)答確認(rèn)到來時,每個確認(rèn)增加 1/8,8 個 ACK 確認(rèn) cwnd 一共增加 1,于是這一次能夠發(fā)送 9 個 MSS 大小的數(shù)據(jù),變成了
線性增長。
-
擁塞避免算法的變化過程如下圖:
所以,我們可以發(fā)現(xiàn),擁塞避免算法就是將原本慢啟動算法的指數(shù)增長變成了線性增長,還是增長階段,但是增長速度緩慢了一些。就這么一直增長著后,網(wǎng)絡(luò)就會慢慢進(jìn)入了擁塞的狀況了,于是就會出現(xiàn)丟包現(xiàn)象,這時就需要對丟失的數(shù)據(jù)包進(jìn)行重傳。當(dāng)觸發(fā)了重傳機(jī)制,也就進(jìn)入了「擁塞發(fā)生算法」。
擁塞發(fā)生
當(dāng)網(wǎng)絡(luò)出現(xiàn)擁塞,也就是會發(fā)生數(shù)據(jù)包重傳,重傳機(jī)制主要有兩種:
- 超時重傳快速重傳
這兩種使用的擁塞發(fā)送算法是不同的,接下來分別來說說。發(fā)生超時重傳的擁塞發(fā)生算法當(dāng)發(fā)生了「超時重傳」,則就會使用擁塞發(fā)生算法。這個時候,ssthresh 和 cwnd 的值會發(fā)生變化:
- ssthresh 設(shè)為 cwnd/2,cwnd 重置為 1 (是恢復(fù)為 cwnd 初始化值,我這里假定 cwnd 初始化值 1)
擁塞發(fā)生算法的變化如下圖:
接著,就重新開始慢啟動,慢啟動是會突然減少數(shù)據(jù)流的。這真是一旦「超時重傳」,馬上回到解放前。但是這種方式太激進(jìn)了,反應(yīng)也很強(qiáng)烈,會造成網(wǎng)絡(luò)卡頓。就好像本來在秋名山高速漂移著,突然來個緊急剎車,輪胎受得了嗎。。。發(fā)生快速重傳的擁塞發(fā)生算法還有更好的方式,前面我們講過「快速重傳算法」。當(dāng)接收方發(fā)現(xiàn)丟了一個中間包的時候,發(fā)送三次前一個包的 ACK,于是發(fā)送端就會快速地重傳,不必等待超時再重傳。TCP 認(rèn)為這種情況不嚴(yán)重,因?yàn)榇蟛糠譀]丟,只丟了一小部分,則 ssthresh 和 cwnd 變化如下:
- cwnd = cwnd/2 ,也就是設(shè)置為原來的一半;ssthresh = cwnd;進(jìn)入快速恢復(fù)算法
快速恢復(fù)
快速重傳和快速恢復(fù)算法一般同時使用,快速恢復(fù)算法是認(rèn)為,你還能收到 3 個重復(fù) ACK 說明網(wǎng)絡(luò)也不那么糟糕,所以沒有必要像 RTO 超時那么強(qiáng)烈。正如前面所說,進(jìn)入快速恢復(fù)之前,cwnd 和 ssthresh 已被更新了:
- cwnd = cwnd/2 ,也就是設(shè)置為原來的一半;ssthresh = cwnd;
然后,進(jìn)入快速恢復(fù)算法如下:
- 擁塞窗口 cwnd = ssthresh + 3 ( 3 的意思是確認(rèn)有 3 個數(shù)據(jù)包被收到了);重傳丟失的數(shù)據(jù)包;如果再收到重復(fù)的 ACK,那么 cwnd 增加 1;如果收到新數(shù)據(jù)的 ACK 后,把 cwnd 設(shè)置為第一步中的 ssthresh 的值,原因是該 ACK 確認(rèn)了新的數(shù)據(jù),說明從 duplicated ACK 時的數(shù)據(jù)都已收到,該恢復(fù)過程已經(jīng)結(jié)束,可以回到恢復(fù)之前的狀態(tài)了,也即再次進(jìn)入擁塞避免狀態(tài);
快速恢復(fù)算法的變化過程如下圖:
也就是沒有像「超時重傳」一夜回到解放前,而是還在比較高的值,后續(xù)呈線性增長。
cookie和session有什么區(qū)別?
Cookie和Session都是Web開發(fā)中用于跟蹤用戶狀態(tài)的技術(shù),但它們在存儲位置、數(shù)據(jù)容量、安全性以及生命周期等方面存在顯著差異:
存儲位置:Cookie的數(shù)據(jù)存儲在客戶端(通常是瀏覽器)。當(dāng)瀏覽器向服務(wù)器發(fā)送請求時,會自動附帶Cookie中的數(shù)據(jù)。Session的數(shù)據(jù)存儲在服務(wù)器端。服務(wù)器為每個用戶分配一個唯一的Session ID,這個ID通常通過Cookie或URL重寫的方式發(fā)送給客戶端,客戶端后續(xù)的請求會帶上這個Session ID,服務(wù)器根據(jù)ID查找對應(yīng)的Session數(shù)據(jù)。
數(shù)據(jù)容量:單個Cookie的大小限制通常在4KB左右,而且大多數(shù)瀏覽器對每個域名的總Cookie數(shù)量也有限制。由于Session存儲在服務(wù)器上,理論上不受數(shù)據(jù)大小的限制,主要受限于服務(wù)器的內(nèi)存大小。
安全性:Cookie相對不安全,因?yàn)閿?shù)據(jù)存儲在客戶端,容易受到XSS(跨站腳本攻擊)的威脅。不過,可以通過設(shè)置HttpOnly屬性來防止JavaScript訪問,減少XSS攻擊的風(fēng)險,但仍然可能受到CSRF(跨站請求偽造)的攻擊。Session通常認(rèn)為比Cookie更安全,因?yàn)槊舾袛?shù)據(jù)存儲在服務(wù)器端。但仍然需要防范Session劫持(通過獲取他人的Session ID)和會話固定攻擊。
生命周期:Cookie可以設(shè)置過期時間,過期后自動刪除。也可以設(shè)置為會話Cookie,即瀏覽器關(guān)閉時自動刪除。Session在默認(rèn)情況下,當(dāng)用戶關(guān)閉瀏覽器時,Session結(jié)束。但服務(wù)器也可以設(shè)置Session的超時時間,超過這個時間未活動,Session也會失效。
性能:使用Cookie時,因?yàn)閿?shù)據(jù)隨每個請求發(fā)送到服務(wù)器,可能會影響網(wǎng)絡(luò)傳輸效率,尤其是在Cookie數(shù)據(jù)較大時。使用Session時,因?yàn)閿?shù)據(jù)存儲在服務(wù)器端,每次請求都需要查詢服務(wù)器上的Session數(shù)據(jù),這可能會增加服務(wù)器的負(fù)載,特別是在高并發(fā)場景下。
Java
介紹一下線程池的工作原理
線程池原理
線程池是為了減少頻繁的創(chuàng)建線程和銷毀線程帶來的性能損耗,線程池的工作原理如下圖:
線程池分為核心線程池,線程池的最大容量,還有等待任務(wù)的隊(duì)列,提交一個任務(wù),如果核心線程沒有滿,就創(chuàng)建一個線程,如果滿了,就是會加入等待隊(duì)列,如果等待隊(duì)列滿了,就會增加線程,如果達(dá)到最大線程數(shù)量,如果都達(dá)到最大線程數(shù)量,就會按照一些丟棄的策略進(jìn)行處理。
線程池的參數(shù)有哪些?
線程池的構(gòu)造函數(shù)有7個參數(shù):
corePoolSize:線程池核心線程數(shù)量。默認(rèn)情況下,線程池中線程的數(shù)量如果 <= corePoolSize,那么即使這些線程處于空閑狀態(tài),那也不會被銷毀。
maximumPoolSize:線程池中最多可容納的線程數(shù)量。當(dāng)一個新任務(wù)交給線程池,如果此時線程池中有空閑的線程,就會直接執(zhí)行,如果沒有空閑的線程且當(dāng)前線程池的線程數(shù)量小于corePoolSize,就會創(chuàng)建新的線程來執(zhí)行任務(wù),否則就會將該任務(wù)加入到阻塞隊(duì)列中,如果阻塞隊(duì)列滿了,就會創(chuàng)建一個新線程,從阻塞隊(duì)列頭部取出一個任務(wù)來執(zhí)行,并將新任務(wù)加入到阻塞隊(duì)列末尾。如果當(dāng)前線程池中線程的數(shù)量等于maximumPoolSize,就不會創(chuàng)建新線程,就會去執(zhí)行拒絕策略。
keepAliveTime:當(dāng)線程池中線程的數(shù)量大于corePoolSize,并且某個線程的空閑時間超過了keepAliveTime,那么這個線程就會被銷毀。
unit:就是keepAliveTime時間的單位。
workQueue:工作隊(duì)列。當(dāng)沒有空閑的線程執(zhí)行新任務(wù)時,該任務(wù)就會被放入工作隊(duì)列中,等待執(zhí)行。
threadFactory:線程工廠??梢杂脕斫o線程取名字等等
handler:拒絕策略。當(dāng)一個新任務(wù)交給線程池,如果此時線程池中有空閑的線程,就會直接執(zhí)行,如果沒有空閑的線程,就會將該任務(wù)加入到阻塞隊(duì)列中,如果阻塞隊(duì)列滿了,就會創(chuàng)建一個新線程,從阻塞隊(duì)列頭部取出一個任務(wù)來執(zhí)行,并將新任務(wù)加入到阻塞隊(duì)列末尾。如果當(dāng)前線程池中線程的數(shù)量等于maximumPoolSize,就不會創(chuàng)建新線程,就會去執(zhí)行拒絕策略
線程池種類有哪些?
- FixedThreadPool:它的核心線程數(shù)和最大線程數(shù)是一樣的,所以可以把它看作是固定線程數(shù)的線程池,它的特點(diǎn)是線程池中的線程數(shù)除了初始階段需要從 0 開始增加外,之后的線程數(shù)量就是固定的,就算任務(wù)數(shù)超過線程數(shù),線程池也不會再創(chuàng)建更多的線程來處理任務(wù),而是會把超出線程處理能力的任務(wù)放到任務(wù)隊(duì)列中進(jìn)行等待。而且就算任務(wù)隊(duì)列滿了,到了本該繼續(xù)增加線程數(shù)的時候,由于它的最大線程數(shù)和核心線程數(shù)是一樣的,所以也無法再增加新的線程了。
ExecutorService?executor?=?Executors.newFixedThreadPool(5);
- CachedThreadPool:可以稱作可緩存線程池,它的特點(diǎn)在于線程數(shù)是幾乎可以無限增加的(實(shí)際最大可以達(dá)到 Integer.MAX_VALUE,為 2^31-1,這個數(shù)非常大,所以基本不可能達(dá)到),而當(dāng)線程閑置時還可以對線程進(jìn)行回收。也就是說該線程池的線程數(shù)量不是固定不變的,當(dāng)然它也有一個用于存儲提交任務(wù)的隊(duì)列,但這個隊(duì)列是 SynchronousQueue,隊(duì)列的容量為0,實(shí)際不存儲任何任務(wù),它只負(fù)責(zé)對任務(wù)進(jìn)行中轉(zhuǎn)和傳遞,所以效率比較高。
ExecutorService?executor?=?Executors.newCachedThreadPool();
- SingleThreadExecutor:它會使用唯一的線程去執(zhí)行任務(wù),原理和 FixedThreadPool 是一樣的,只不過這里線程只有一個,如果線程在執(zhí)行任務(wù)的過程中發(fā)生異常,線程池也會重新創(chuàng)建一個線程來執(zhí)行后續(xù)的任務(wù)。這種線程池由于只有一個線程,所以非常適合用于所有任務(wù)都需要按被提交的順序依次執(zhí)行的場景,而前幾種線程池不一定能夠保障任務(wù)的執(zhí)行順序等于被提交的順序,因?yàn)樗鼈兪嵌嗑€程并行執(zhí)行的。
ExecutorService?executor?=?Executors.newSingleThreadExecutor();
- SingleThreadScheduledExecutor:它實(shí)際和 ScheduledThreadPool 線程池非常相似,它只是 ScheduledThreadPool 的一個特例,內(nèi)部只有一個線程。
ExecutorService?executor?=?Executors.newScheduledThreadPool(5);
Java線程的狀態(tài)有哪些?
源自《Java并發(fā)編程藝術(shù)》 java.lang.Thread.State枚舉類中定義了六種線程的狀態(tài),可以調(diào)用線程Thread中的getState()方法獲取當(dāng)前線程的狀態(tài)。
線程狀態(tài) | 解釋 |
---|---|
NEW | 尚未啟動的線程狀態(tài),即線程創(chuàng)建,還未調(diào)用start方法 |
RUNNABLE | 就緒狀態(tài)(調(diào)用start,等待調(diào)度)+正在運(yùn)行 |
BLOCKED | 等待監(jiān)視器鎖時,陷入阻塞狀態(tài) |
WAITING | 等待狀態(tài)的線程正在等待另一線程執(zhí)行特定的操作(如notify) |
TIMED_WAITING | 具有指定等待時間的等待狀態(tài) |
TERMINATED | 線程完成執(zhí)行,終止?fàn)顟B(tài) |
blocked和waiting有啥區(qū)別
觸發(fā)條件:線程進(jìn)入BLOCKED狀態(tài)通常是因?yàn)樵噲D獲取一個對象的鎖(monitor lock),但該鎖已經(jīng)被另一個線程持有。這通常發(fā)生在嘗試進(jìn)入synchronized塊或方法時,如果鎖已被占用,則線程將被阻塞直到鎖可用。線程進(jìn)入WAITING狀態(tài)是因?yàn)樗诘却硪粋€線程執(zhí)行某些操作,例如調(diào)用Object.wait()方法、Thread.join()方法或LockSupport.park()方法。在這種狀態(tài)下,線程將不會消耗CPU資源,并且不會參與鎖的競爭。
喚醒機(jī)制:當(dāng)一個線程被阻塞等待鎖時,一旦鎖被釋放,線程將有機(jī)會重新嘗試獲取鎖。如果鎖此時未被其他線程獲取,那么線程可以從BLOCKED狀態(tài)變?yōu)镽UNNABLE狀態(tài)。線程在WAITING狀態(tài)中需要被顯式喚醒。例如,如果線程調(diào)用了Object.wait(),那么它必須等待另一個線程調(diào)用同一對象上的Object.notify()或Object.notifyAll()方法才能被喚醒。
synchronized和reentrantlock及其應(yīng)用場景
synchronized 工作原理
synchronized是Java提供的原子性內(nèi)置鎖,這種內(nèi)置的并且使用者看不到的鎖也被稱為監(jiān)視器鎖,
使用synchronized之后,會在編譯之后在同步的代碼塊前后加上monitorenter和monitorexit字節(jié)碼指令,他依賴操作系統(tǒng)底層互斥鎖實(shí)現(xiàn)。他的作用主要就是實(shí)現(xiàn)原子性操作和解決共享變量的內(nèi)存可見性問題。
執(zhí)行monitorenter指令時會嘗試獲取對象鎖,如果對象沒有被鎖定或者已經(jīng)獲得了鎖,鎖的計(jì)數(shù)器+1。此時其他競爭鎖的線程則會進(jìn)入等待隊(duì)列中。執(zhí)行monitorexit指令時則會把計(jì)數(shù)器-1,當(dāng)計(jì)數(shù)器值為0時,則鎖釋放,處于等待隊(duì)列中的線程再繼續(xù)競爭鎖。
synchronized是排它鎖,當(dāng)一個線程獲得鎖之后,其他線程必須等待該線程釋放鎖后才能獲得鎖,而且由于Java中的線程和操作系統(tǒng)原生線程是一一對應(yīng)的,線程被阻塞或者喚醒時時會從用戶態(tài)切換到內(nèi)核態(tài),這種轉(zhuǎn)換非常消耗性能。
從內(nèi)存語義來說,加鎖的過程會清除工作內(nèi)存中的共享變量,再從主內(nèi)存讀取,而釋放鎖的過程則是將工作內(nèi)存中的共享變量寫回主內(nèi)存。
實(shí)際上大部分時候我認(rèn)為說到monitorenter就行了,但是為了更清楚的描述,還是再具體一點(diǎn)。
如果再深入到源碼來說,synchronized實(shí)際上有兩個隊(duì)列waitSet和entryList。
- 當(dāng)多個線程進(jìn)入同步代碼塊時,首先進(jìn)入entryList有一個線程獲取到monitor鎖后,就賦值給當(dāng)前線程,并且計(jì)數(shù)器+1如果線程調(diào)用wait方法,將釋放鎖,當(dāng)前線程置為null,計(jì)數(shù)器-1,同時進(jìn)入waitSet等待被喚醒,調(diào)用notify或者notifyAll之后又會進(jìn)入entryList競爭鎖如果線程執(zhí)行完畢,同樣釋放鎖,計(jì)數(shù)器-1,當(dāng)前線程置為null
reentrantlock工作原理
ReentrantLock 的底層實(shí)現(xiàn)主要依賴于 AbstractQueuedSynchronizer(AQS)這個抽象類。AQS 是一個提供了基本同步機(jī)制的框架,其中包括了隊(duì)列、狀態(tài)值等。
ReentrantLock 在 AQS 的基礎(chǔ)上通過內(nèi)部類 Sync 來實(shí)現(xiàn)具體的鎖操作。
不同的 Sync 子類實(shí)現(xiàn)了公平鎖和非公平鎖的不同邏輯。
可中斷性:ReentrantLock 實(shí)現(xiàn)了可中斷性,這意味著線程在等待鎖的過程中,可以被其他線程中斷而提前結(jié)束等待。在底層,ReentrantLock 使用了與 LockSupport.park() 和 LockSupport.unpark() 相關(guān)的機(jī)制來實(shí)現(xiàn)可中斷性。
設(shè)置超時時間:ReentrantLock 支持在嘗試獲取鎖時設(shè)置超時時間,即等待一定時間后如果還未獲得鎖,則放棄鎖的獲取。這是通過內(nèi)部的 tryAcquireNanos 方法來實(shí)現(xiàn)的。
公平鎖和非公平鎖:在直接創(chuàng)建 ReentrantLock 對象時,默認(rèn)情況下是非公平鎖。公平鎖是按照線程等待的順序來獲取鎖,而非公平鎖則允許多個線程在同一時刻競爭鎖,不考慮它們申請鎖的順序。公平鎖可以通過在創(chuàng)建 ReentrantLock 時傳入 true 來設(shè)置,例如:
ReentrantLock?fairLock?=?new?ReentrantLock(true);
多個條件變量
- :ReentrantLock 支持多個條件變量,每個條件變量可以與一個 ReentrantLock 關(guān)聯(lián)。這使得線程可以更靈活地進(jìn)行等待和喚醒操作,而不僅僅是基于對象監(jiān)視器的 wait() 和 notify()。多個條件變量的實(shí)現(xiàn)依賴于 Condition 接口,例如:
ReentrantLock?lock?=?new?ReentrantLock();
Condition?condition?=?lock.newCondition();
//?使用下面方法進(jìn)行等待和喚醒
condition.await();
condition.signal();
可重入性:ReentrantLock 支持可重入性,即同一個線程可以多次獲得同一把鎖,而不會造成死鎖。這是通過內(nèi)部的 holdCount 計(jì)數(shù)來實(shí)現(xiàn)的。當(dāng)一個線程多次獲取鎖時,holdCount 遞增,釋放鎖時遞減,只有當(dāng) holdCount 為零時,其他線程才有機(jī)會獲取鎖。
應(yīng)用場景的區(qū)別
synchronized:
簡單同步需求:當(dāng)你需要對代碼塊或方法進(jìn)行簡單的同步控制時,synchronized是一個很好的選擇。它使用起來簡單,不需要額外的資源管理,因?yàn)殒i會在方法退出或代碼塊執(zhí)行完畢后自動釋放。
代碼塊同步:如果你想對特定代碼段進(jìn)行同步,而不是整個方法,可以使用synchronized
代碼塊。這可以讓你更精細(xì)地控制同步的范圍,從而減少鎖的持有時間,提高并發(fā)性能。
內(nèi)置鎖的使用:synchronized
關(guān)鍵字使用對象的內(nèi)置鎖(也稱為監(jiān)視器鎖),這在需要使用對象作為鎖對象的情況下很有用,尤其是在對象狀態(tài)與鎖保護(hù)的代碼緊密相關(guān)時。
ReentrantLock:
高級鎖功能需求:ReentrantLock
提供了synchronized所不具備的高級功能,如公平鎖、響應(yīng)中斷、定時鎖嘗試、以及多個條件變量。當(dāng)你需要這些功能時,ReentrantLock
是更好的選擇。
性能優(yōu)化:在高度競爭的環(huán)境中,ReentrantLock
可以提供比synchronized
更好的性能,因?yàn)樗峁┝烁?xì)粒度的控制,如嘗試鎖定和定時鎖定,可以減少線程阻塞的可能性。
復(fù)雜同步結(jié)構(gòu):當(dāng)你需要更復(fù)雜的同步結(jié)構(gòu),如需要多個條件變量來協(xié)調(diào)線程之間的通信時,ReentrantLock
及其配套的Condition
對象可以提供更靈活的解決方案。
綜上,synchronized
適用于簡單同步需求和不需要額外鎖功能的場景,而ReentrantLock
適用于需要更高級鎖功能、性能優(yōu)化或復(fù)雜同步邏輯的情況。選擇哪種同步機(jī)制取決于具體的應(yīng)用需求和性能考慮。
線程池一般是怎么用的?
Java 中的 Executors 類定義了一些快捷的工具方法,來幫助我們快速創(chuàng)建線程池?!?a class="article-link" target="_blank" href="/manufacturer/1000210/">阿里巴巴 Java 開發(fā)手冊》中提到,禁止使用這些方法來創(chuàng)建線程池,而應(yīng)該手動 new ThreadPoolExecutor 來創(chuàng)建線程池。這一條規(guī)則的背后,是大量血淋淋的生產(chǎn)事故,最典型的就是 newFixedThreadPool 和 newCachedThreadPool,可能因?yàn)橘Y源耗盡導(dǎo)致 OOM 問題。所以,不建議使用 Executors 提供的兩種快捷的線程池,原因如下:
- 我們需要根據(jù)自己的場景、并發(fā)情況來評估線程池的幾個核心參數(shù),包括核心線程數(shù)、最大線程數(shù)、線程回收策略、工作隊(duì)列的類型,以及拒絕策略,確保線程池的工作行為符合需求,一般都需要設(shè)置有界的工作隊(duì)列和可控的線程數(shù)。任何時候,都應(yīng)該為自定義線程池指定有意義的名稱,以方便排查問題。當(dāng)出現(xiàn)線程數(shù)量暴增、線程死鎖、線程占用大量 CPU、線程執(zhí)行出現(xiàn)異常等問題時,我們往往會抓取線程棧。此時,有意義的線程名稱,就可以方便我們定位問題。
除了建議手動聲明線程池以外,我還建議用一些監(jiān)控手段來觀察線程池的狀態(tài)。線程池這個組件往往會表現(xiàn)得任勞任怨、默默無聞,除非是出現(xiàn)了拒絕策略,否則壓力再大都不會拋出一個異常。如果我們能提前觀察到線程池隊(duì)列的積壓,或者線程數(shù)量的快速膨脹,往往可以提早發(fā)現(xiàn)并解決問題。
Spring IoC和AOP 介紹一下
Spring IoC和AOP 區(qū)別:
IoC:即控制反轉(zhuǎn)的意思,它是一種創(chuàng)建和獲取對象的技術(shù)思想,依賴注入(DI)是實(shí)現(xiàn)這種技術(shù)的一種方式。傳統(tǒng)開發(fā)過程中,我們需要通過new關(guān)鍵字來創(chuàng)建對象。使用IoC思想開發(fā)方式的話,我們不通過new關(guān)鍵字創(chuàng)建對象,而是通過IoC容器來幫我們實(shí)例化對象。通過IoC的方式,可以大大降低對象之間的耦合度。
AOP:是面向切面編程,能夠?qū)⒛切┡c業(yè)務(wù)無關(guān),卻為業(yè)務(wù)模塊所共同調(diào)用的邏輯封裝起來,以減少系統(tǒng)的重復(fù)代碼,降低模塊間的耦合度。Spring AOP 就是基于動態(tài)代理的,如果要代理的對象,實(shí)現(xiàn)了某個接口,那么 Spring AOP 會使用 JDK Proxy,去創(chuàng)建代理對象,而對于沒有實(shí)現(xiàn)接口的對象,就無法使用 JDK Proxy 去進(jìn)行代理了,這時候 Spring AOP 會使用 Cglib 生成一個被代理對象的子類來作為代理。
在 Spring 框架中,IOC 和 AOP 結(jié)合使用,可以更好地實(shí)現(xiàn)代碼的模塊化和分層管理。例如:
- 通過 IOC 容器管理對象的依賴關(guān)系,然后通過 AOP 將橫切關(guān)注點(diǎn)統(tǒng)一切入到需要的業(yè)務(wù)邏輯中。使用 IOC 容器管理 Service 層和 DAO 層的依賴關(guān)系,然后通過 AOP 在 Service 層實(shí)現(xiàn)事務(wù)管理、日志記錄等橫切功能,使得業(yè)務(wù)邏輯更加清晰和可維護(hù)。
動態(tài)代理是什么?
Java的動態(tài)代理是一種在運(yùn)行時動態(tài)創(chuàng)建代理對象的機(jī)制,主要用于在不修改原始類的情況下對方法調(diào)用進(jìn)行攔截和增強(qiáng)。Java動態(tài)代理主要分為兩種類型:
基于接口的代理
-
- (JDK動態(tài)代理):這種類型的代理要求目標(biāo)對象必須實(shí)現(xiàn)至少一個接口。Java動態(tài)代理會創(chuàng)建一個實(shí)現(xiàn)了相同接口的代理類,然后在運(yùn)行時動態(tài)生成該類的實(shí)例。這種代理的實(shí)現(xiàn)核心是java.lang.reflect.Proxy
- 類和java.lang.reflect.InvocationHandler接口。每一個動態(tài)代理類都必須實(shí)現(xiàn)InvocationHandler接口,并且每個代理類的實(shí)例都關(guān)聯(lián)到一個handler。當(dāng)通過代理對象調(diào)用一個方法時,這個方法的調(diào)用會被轉(zhuǎn)發(fā)為由InvocationHandler接口的invoke()方法來進(jìn)行調(diào)用。
基于類的代理
- (CGLIB動態(tài)代理):CGLIB(Code Generation Library)是一個強(qiáng)大的高性能的代碼生成庫,它可以在運(yùn)行時動態(tài)生成一個目標(biāo)類的子類。CGLIB代理不需要目標(biāo)類實(shí)現(xiàn)接口,而是通過繼承的方式創(chuàng)建代理類。因此,如果目標(biāo)對象沒有實(shí)現(xiàn)任何接口,可以使用CGLIB來創(chuàng)建動態(tài)代理。