科大訊飛一面

sycronized和locked的區(qū)別？

Synchronized編碼更簡(jiǎn)單，鎖機(jī)制由JVM維護(hù)，在競(jìng)爭(zhēng)不激烈的情況下性能更好。Lock功能更強(qiáng)大更靈活，競(jìng)爭(zhēng)激烈時(shí)性能較好。

區(qū)別如下：

• 來(lái)源：lock是一個(gè)接口，而synchronized是java的一個(gè)關(guān)鍵字，synchronized是內(nèi)置的語(yǔ)言實(shí)現(xiàn)；
• 異常是否釋放鎖：synchronized在發(fā)生異常時(shí)候會(huì)自動(dòng)釋放占有的鎖，因此不會(huì)出現(xiàn)死鎖；而lock發(fā)生異常時(shí)候，不會(huì)主動(dòng)釋放占有的鎖，必須手動(dòng)unlock來(lái)釋放鎖，可能引起死鎖的發(fā)生。（所以最好將同步代碼塊用try catch包起來(lái)，finally中寫入unlock，避免死鎖的發(fā)生。）
• 是否響應(yīng)中斷l(xiāng)ock等待鎖過(guò)程中可以用interrupt來(lái)中斷等待，而synchronized只能等待鎖的釋放，不能響應(yīng)中斷；
• 是否知道獲取鎖：Lock可以通過(guò)trylock來(lái)知道有沒(méi)有獲取鎖，而synchronized不能；
• Lock可以提高多個(gè)線程進(jìn)行讀操作的效率。（可以通過(guò)readwritelock實(shí)現(xiàn)讀寫分離）
• 在性能上來(lái)說(shuō)，如果競(jìng)爭(zhēng)資源不激烈，兩者的性能是差不多的，而當(dāng)競(jìng)爭(zhēng)資源非常激烈時(shí)（即有大量線程同時(shí)競(jìng)爭(zhēng)），此時(shí)Lock的性能要遠(yuǎn)遠(yuǎn)優(yōu)于synchronized。

hashmap put的流程

圖片

HashMap HashMap的put()方法用于向HashMap中添加鍵值對(duì)，當(dāng)調(diào)用HashMap的put()方法時(shí)，會(huì)按照以下詳細(xì)流程執(zhí)行（JDK8 1.8版本）：

第一步：根據(jù)要添加的鍵的哈希碼計(jì)算在數(shù)組中的位置（索引）。

第二步：檢查該位置是否為空（即沒(méi)有鍵值對(duì)存在）

• 如果為空，則直接在該位置創(chuàng)建一個(gè)新的Entry對(duì)象來(lái)存儲(chǔ)鍵值對(duì)。將要添加的鍵值對(duì)作為該Entry的鍵和值，并保存在數(shù)組的對(duì)應(yīng)位置。將HashMap的修改次數(shù)（modCount）加1，以便在進(jìn)行迭代時(shí)發(fā)現(xiàn)并發(fā)修改。

第三步：如果該位置已經(jīng)存在其他鍵值對(duì)，檢查該位置的第一個(gè)鍵值對(duì)的哈希碼和鍵是否與要添加的鍵值對(duì)相同？

• 如果相同，則表示找到了相同的鍵，直接將新的值替換舊的值，完成更新操作。

第四步：如果第一個(gè)鍵值對(duì)的哈希碼和鍵不相同，則需要遍歷鏈表或紅黑樹來(lái)查找是否有相同的鍵：

如果鍵值對(duì)集合是鏈表結(jié)構(gòu)，從鏈表的頭部開(kāi)始逐個(gè)比較鍵的哈希碼和equals()方法，直到找到相同的鍵或達(dá)到鏈表末尾。

• 如果找到了相同的鍵，則使用新的值取代舊的值，即更新鍵對(duì)應(yīng)的值。
• 如果沒(méi)有找到相同的鍵，則將新的鍵值對(duì)添加到鏈表的頭部。

如果鍵值對(duì)集合是紅黑樹結(jié)構(gòu)，在紅黑樹中使用哈希碼和equals()方法進(jìn)行查找。根據(jù)鍵的哈希碼，定位到紅黑樹中的某個(gè)節(jié)點(diǎn)，然后逐個(gè)比較鍵，直到找到相同的鍵或達(dá)到紅黑樹末尾。

• 如果找到了相同的鍵，則使用新的值取代舊的值，即更新鍵對(duì)應(yīng)的值。
• 如果沒(méi)有找到相同的鍵，則將新的鍵值對(duì)添加到紅黑樹中。

第五步：檢查鏈表長(zhǎng)度是否達(dá)到閾值（默認(rèn)為8）：

• 如果鏈表長(zhǎng)度超過(guò)閾值，且HashMap的數(shù)組長(zhǎng)度大于等于64，則會(huì)將鏈表轉(zhuǎn)換為紅黑樹，以提高查詢效率。

第六步：檢查負(fù)載因子是否超過(guò)閾值（默認(rèn)為0.75）：

• 如果鍵值對(duì)的數(shù)量（size）與數(shù)組的長(zhǎng)度的比值大于閾值，則需要進(jìn)行擴(kuò)容操作。

第七步：擴(kuò)容操作：

• 創(chuàng)建一個(gè)新的兩倍大小的數(shù)組。
• 將舊數(shù)組中的鍵值對(duì)重新計(jì)算哈希碼并分配到新數(shù)組中的位置。
• 更新HashMap的數(shù)組引用和閾值參數(shù)。

第八步：完成添加操作。

此外，HashMap是非線程安全的，如果在多線程環(huán)境下使用，需要采取額外的同步措施或使用線程安全的ConcurrentHashMap。

avl樹和紅黑樹的區(qū)別？

• 平衡二叉樹追求的是一種 “完全平衡” 狀態(tài)：任何結(jié)點(diǎn)的左右子樹的高度差不會(huì)超過(guò) 1，優(yōu)勢(shì)是樹的結(jié)點(diǎn)是很平均分配的。這個(gè)要求實(shí)在是太嚴(yán)了，導(dǎo)致每次進(jìn)行插入/刪除節(jié)點(diǎn)的時(shí)候，幾乎都會(huì)破壞平衡樹的第二個(gè)規(guī)則，進(jìn)而我們都需要通過(guò)左旋和右旋來(lái)進(jìn)行調(diào)整，使之再次成為一顆符合要求的平衡樹。
• 紅黑樹不追求這種完全平衡狀態(tài)，而是追求一種 “弱平衡” 狀態(tài)：整個(gè)樹最長(zhǎng)路徑不會(huì)超過(guò)最短路徑的 2 倍。優(yōu)勢(shì)是雖然犧牲了一部分查找的性能效率，但是能夠換取一部分維持樹平衡狀態(tài)的成本。與平衡樹不同的是，紅黑樹在插入、刪除等操作，不會(huì)像平衡樹那樣，頻繁著破壞紅黑樹的規(guī)則，所以不需要頻繁著調(diào)整，這也是我們?yōu)槭裁创蠖鄶?shù)情況下使用紅黑樹的原因。

紅黑樹插入的時(shí)間復(fù)雜度是多少？

紅黑樹平衡，插入、刪除、查找操作的時(shí)間復(fù)雜度都是O(logn)。

如何給數(shù)據(jù)庫(kù)中數(shù)據(jù)加行級(jí)鎖？

InnoDB 引擎是支持行級(jí)鎖的，而 MyISAM 引擎并不支持行級(jí)鎖。

普通的 select 語(yǔ)句是不會(huì)對(duì)記錄加鎖的，因?yàn)樗鼘儆诳煺兆x。如果要在查詢時(shí)對(duì)記錄加行鎖，可以使用下面這兩個(gè)方式，這種查詢會(huì)加鎖的語(yǔ)句稱為鎖定讀。

//對(duì)讀取的記錄加共享鎖
select ... lock in share mode;

//對(duì)讀取的記錄加獨(dú)占鎖
select ... for update;

上面這兩條語(yǔ)句必須在一個(gè)事務(wù)中，因?yàn)楫?dāng)事務(wù)提交了，鎖就會(huì)被釋放，所以在使用這兩條語(yǔ)句的時(shí)候，要加上 begin、start transaction 或者 set autocommit = 0。

共享鎖（S鎖）滿足讀讀共享，讀寫互斥。獨(dú)占鎖（X鎖）滿足寫寫互斥、讀寫互斥。

圖片

行級(jí)鎖的類型主要有三類：

• Record Lock，記錄鎖，也就是僅僅把一條記錄鎖上；
• Gap Lock，間隙鎖，鎖定一個(gè)范圍，但是不包含記錄本身；
• Next-Key Lock：Record Lock + Gap Lock 的組合，鎖定一個(gè)范圍，并且鎖定記錄本身。

Record Lock

Record Lock 稱為記錄鎖，鎖住的是一條記錄。而且記錄鎖是有 S 鎖和 X 鎖之分的：

• 當(dāng)一個(gè)事務(wù)對(duì)一條記錄加了 S 型記錄鎖后，其他事務(wù)也可以繼續(xù)對(duì)該記錄加 S 型記錄鎖（S 型與 S 鎖兼容），但是不可以對(duì)該記錄加 X 型記錄鎖（S 型與 X 鎖不兼容）;
• 當(dāng)一個(gè)事務(wù)對(duì)一條記錄加了 X 型記錄鎖后，其他事務(wù)既不可以對(duì)該記錄加 S 型記錄鎖（S 型與 X 鎖不兼容），也不可以對(duì)該記錄加 X 型記錄鎖（X 型與 X 鎖不兼容）。

舉個(gè)例子，當(dāng)一個(gè)事務(wù)執(zhí)行了下面這條語(yǔ)句：

mysql > begin;
mysql > select * from t_test where id = 1 for update;

就是對(duì) t_test 表中主鍵 id 為 1 的這條記錄加上 X 型的記錄鎖，這樣其他事務(wù)就無(wú)法對(duì)這條記錄進(jìn)行修改了。

圖片

當(dāng)事務(wù)執(zhí)行 commit 后，事務(wù)過(guò)程中生成的鎖都會(huì)被釋放。

Gap Lock

Gap Lock 稱為間隙鎖，只存在于可重復(fù)讀隔離級(jí)別，目的是為了解決可重復(fù)讀隔離級(jí)別下幻讀的現(xiàn)象。

假設(shè)，表中有一個(gè)范圍 id 為（3，5）間隙鎖，那么其他事務(wù)就無(wú)法插入 id = 4 這條記錄了，這樣就有效的防止幻讀現(xiàn)象的發(fā)生。

圖片

間隙鎖雖然存在 X 型間隙鎖和 S 型間隙鎖，但是并沒(méi)有什么區(qū)別，間隙鎖之間是兼容的，即兩個(gè)事務(wù)可以同時(shí)持有包含共同間隙范圍的間隙鎖，并不存在互斥關(guān)系，因?yàn)殚g隙鎖的目的是防止插入幻影記錄而提出的。

Next-Key Lock

Next-Key Lock 稱為臨鍵鎖，是 Record Lock + Gap Lock 的組合，鎖定一個(gè)范圍，并且鎖定記錄本身。

假設(shè)，表中有一個(gè)范圍 id 為（3，5] 的 next-key lock，那么其他事務(wù)即不能插入 id = 4 記錄，也不能修改 id = 5 這條記錄。

圖片

所以，next-key lock 即能保護(hù)該記錄，又能阻止其他事務(wù)將新紀(jì)錄插入到被保護(hù)記錄前面的間隙中。

next-key lock 是包含間隙鎖+記錄鎖的，如果一個(gè)事務(wù)獲取了 X 型的 next-key lock，那么另外一個(gè)事務(wù)在獲取相同范圍的 X 型的 next-key lock 時(shí)，是會(huì)被阻塞的。

比如，一個(gè)事務(wù)持有了范圍為 (1, 10] 的 X 型的 next-key lock，那么另外一個(gè)事務(wù)在獲取相同范圍的 X 型的 next-key lock 時(shí)，就會(huì)被阻塞。

雖然相同范圍的間隙鎖是多個(gè)事務(wù)相互兼容的，但對(duì)于記錄鎖，我們是要考慮 X 型與 S 型關(guān)系，X 型的記錄鎖與 X 型的記錄鎖是沖突的。

如果和redis無(wú)法連接，如何排查原因？

• 網(wǎng)絡(luò)閃斷：先排查網(wǎng)絡(luò)問(wèn)題，比如檢查網(wǎng)絡(luò)連接是否正常。確保網(wǎng)絡(luò)連接穩(wěn)定，沒(méi)有斷開(kāi)或中斷。檢查網(wǎng)絡(luò)帶寬是否耗盡。如果網(wǎng)絡(luò)帶寬達(dá)到極限，可能會(huì)導(dǎo)致閃斷。你可以聯(lián)系網(wǎng)絡(luò)管理員或提供商以解決帶寬問(wèn)題。
• Redis連接拒絕：確認(rèn)maxclients設(shè)置。在Redis配置文件(redis.conf)中，找到maxclients設(shè)置項(xiàng)，確保其值足夠大以容納你的并發(fā)連接數(shù)。你可以通過(guò)修改配置文件來(lái)增加maxclients的值。
• 連接溢出：進(jìn)程可打開(kāi)的最大文件數(shù)控制(ulimit -n)是限制系統(tǒng)中同時(shí)存在的文件描述符數(shù)量的設(shè)置。對(duì)于Redis來(lái)說(shuō)，高并發(fā)情況下需要處理大量的連接，因此需要增大該值。

如果redis內(nèi)存不足，你認(rèn)為是什么原因

• 沒(méi)有開(kāi)啟內(nèi)存淘汰策略，導(dǎo)致 Redis 無(wú)法運(yùn)用內(nèi)存淘汰策略來(lái)淘汰不常用的內(nèi)存數(shù)據(jù)。
• 在 Redis 長(zhǎng)時(shí)間運(yùn)行的情況下，由于頻繁的插入和刪除操作，可能會(huì)導(dǎo)致內(nèi)存碎片，導(dǎo)致可用內(nèi)存減少。
• 單 Redis 節(jié)點(diǎn)的內(nèi)存無(wú)法扛住激增的用戶數(shù)據(jù)，這時(shí)候需要考慮構(gòu)建 Redis 集群來(lái)應(yīng)對(duì)內(nèi)存不足的問(wèn)題。

為什么 redis購(gòu)物車用hash不用 string

使用 Hash 類型來(lái)實(shí)現(xiàn)購(gòu)物車有幾個(gè)明顯的優(yōu)勢(shì)，相比使用 String 類型：

• 結(jié)構(gòu)化數(shù)據(jù)：Hash 類型允許將購(gòu)物車中的每個(gè)商品表示為一個(gè)字段-值對(duì)（field-value pair），其中字段可以是商品的 ID，值可以是商品的數(shù)量或其他屬性。這種結(jié)構(gòu)化可以使得數(shù)據(jù)更加清晰和易于管理
• 節(jié)省內(nèi)存：在 Redis 中，Hash 類型對(duì)于存儲(chǔ)小數(shù)量的字段-值對(duì)（例如購(gòu)物車中的商品）通常會(huì)使用更高效的內(nèi)存編碼方式。當(dāng) Hash 中的成員少于一定數(shù)量時(shí)，Redis 會(huì)使用壓縮算法來(lái)減少內(nèi)存消耗。
• 操作靈活性：使用 Hash 類型，你可以對(duì)購(gòu)物車進(jìn)行更復(fù)雜的操作，比如只更新某個(gè)商品的數(shù)量，而不需要將整個(gè)購(gòu)物車類型的數(shù)據(jù)取出和再存儲(chǔ)。對(duì)于多個(gè)購(gòu)物車的操作，Hash 可以顯著提高效率。
• 方便查詢與修改：使用 Hash 類型的購(gòu)物車，可以更方便地查詢和修改特定商品的信息，例如獲取某個(gè)商品的數(shù)量，非常簡(jiǎn)單，只需要進(jìn)行一次 HGET 操作。

講一下Nginx的負(fù)載均衡策略

Nginx支持的負(fù)載均衡算法包括：

• 輪詢：按照順序依次將請(qǐng)求分配給后端服務(wù)器。這種算法最簡(jiǎn)單，但是也無(wú)法處理某個(gè)節(jié)點(diǎn)變慢或者客戶端操作有連續(xù)性的情況。
• IP哈希：根據(jù)客戶端IP地址的哈希值來(lái)確定分配請(qǐng)求的后端服務(wù)器。適用于需要保持同一客戶端的請(qǐng)求始終發(fā)送到同一臺(tái)后端服務(wù)器的場(chǎng)景，如會(huì)話保持。
• URL哈希：按訪問(wèn)的URL的哈希結(jié)果來(lái)分配請(qǐng)求，使每個(gè)URL定向到一臺(tái)后端服務(wù)器，可以進(jìn)一步提高后端緩存服務(wù)器的效率。
• 最短響應(yīng)時(shí)間：按照后端服務(wù)器的響應(yīng)時(shí)間來(lái)分配請(qǐng)求，響應(yīng)時(shí)間短的優(yōu)先分配。適用于后端服務(wù)器性能不均的場(chǎng)景，能夠?qū)⒄?qǐng)求發(fā)送到響應(yīng)時(shí)間快的服務(wù)器，實(shí)現(xiàn)負(fù)載均衡。
• 加權(quán)輪詢：按照權(quán)重分配請(qǐng)求給后端服務(wù)器，權(quán)重越高的服務(wù)器獲得更多的請(qǐng)求。適用于后端服務(wù)器性能不同的場(chǎng)景，可以根據(jù)服務(wù)器權(quán)重分配請(qǐng)求，提高高性能服務(wù)器的利用率。

linux 命令怎么看 cpu 占用率？

可以通過(guò) top 命令來(lái)查看系統(tǒng)的 cpu 占用率和各個(gè)進(jìn)程的 cpu 占用率。

圖片

死鎖的時(shí)候cpu利用率是高還是低？為什么？

這個(gè)關(guān)鍵是看用了什么鎖：

• 如果是用了自旋鎖，拿不到鎖的時(shí)候，忙等待，反復(fù)探測(cè)鎖狀態(tài)，直到拿到鎖，進(jìn)入臨界區(qū)，這種情況會(huì)消耗CPU，如果發(fā)生死鎖的話，cpu 利用率就會(huì)比較高。
• 如果是互斥鎖，拿不到鎖就讓線程休眠的，這時(shí)候就相當(dāng)于放棄了 cpu，不會(huì)消耗 cpu，如果發(fā)生死鎖的話，cpu 利用率就不會(huì)升高的。

linux 命令怎么看進(jìn)程占用的端口？

可以通過(guò) lsof 或者 netstate 命令查看，比如查看 80 端口。

lsof ：

[root@xiaolin ~]# lsof -i :80
COMMAND     PID  USER   FD   TYPE   DEVICE SIZE/OFF NODE NAME
nginx       929  root    6u  IPv4    15249      0t0  TCP *:http (LISTEN)
nginx       929  root    7u  IPv6    15250      0t0  TCP *:http (LISTEN)
nginx       934 nginx    6u  IPv4    15249      0t0  TCP *:http (LISTEN)
nginx       934 nginx    7u  IPv6    15250      0t0  TCP *:http (LISTEN)
AliYunDun 16507  root   10u  IPv4 40212783      0t0  TCP xiaolin:41830->100.100.30.26:http (ESTABLISHED)

netstate：

[root@xiaolin ~]# netstat -napt | grep 80
tcp        0      0 0.0.0.0:80       0.0.0.0:*       LISTEN      929/nginx: master p