2020最新B站面試經歷,含答案!

1 操做系統相關mysql

自旋鎖和通常鎖的區別是什麼?爲何要使用自旋鎖?
當一個線程在獲取鎖的時候,若是這個鎖已經被其餘線程獲取,那麼這個線程不會破門而入,而是循環等待,可是嗷嗷待哺,須要不斷地嗷嗷叫判斷鎖是否被成功獲取,直到獲取到鎖纔會退出循環。程序員

自旋鎖一般會出現哪些問題?
若是某個線程拿着鎖死不放手,其餘線程無法拿到這把鎖,只好等待獲取鎖的線程進入循環等待的狀態,等待不是睡覺,仍是會消耗CPU,等待久了就會致使CPU的使用率過高。面試

那麼自旋鎖和其餘鎖到底有啥不一樣?
從線程狀態來看,自旋鎖的狀態是運行-運行-運行。而非自旋鎖的狀態是運行---阻塞---運行,因此自旋鎖會更高效。redis

無論是什麼鎖,都是爲了實現保護共享資源而提出的一種鎖機制,都是爲了對某項資源的互斥使用。對於互斥鎖而言,若是資源已經被佔用,那麼資源的申請者只會進入睡眠的狀態。而自旋鎖不會引發調用者睡眠,而是一直循環在那裏查看該自旋鎖的保持着是否已經釋放了鎖。sql

那麼在Java中如何去實現一個自旋鎖
public class SpinLock {
private AtomicReference cas = new AtomicReference ();
public void lock() {
Thread current = Thread.currentThread();
// 利用CAS
while (!cas.compareAndSet(null, current)) {
// DO
}
}
public void unlock() {
Thread current = Thread.currentThread();
cas.compareAndSet(current, null);
}
}
上段代碼中,方法lock利用的CAS,當線程A獲取鎖的時候,成功獲取不會進入while循環。若是此時線程A沒有釋放鎖,當線程B來獲取鎖的時候,因爲不知足CAS,就會進入whilei循環,不斷判斷是否知足CAS,直到線程A調用unlock釋放。
數據庫

自旋鎖有哪些優勢?
由於運行在用戶態,沒有上下文的線程狀態切換,線程一直處於active,減小了沒必要要的上下文切換,從而執行速度較快
由於非自旋鎖在沒有獲取鎖的狀況下會進入阻塞狀態,從而進入內核態,此時就須要線程的上下文切換,由於阻塞後進入內核調度狀態,會致使用戶態和內核態之間的切換,影響鎖的性能。
瞭解哪些I/O模型?select是阻塞IO嗎?
首先將IO模型給安排一遍,而後把本身很熟悉的IO模型詳細說一波並介紹出應用場景,這個裝的X就算比較完美,具體的很是詳細的在下一篇文章,這裏簡要說一波。這一部分在上一篇詳細闡述過
阻塞IO後端

咱們知道在調用某個函數的時候無非就是兩種狀況,要麼立刻返回,而後根據返回值進行接下來的業務處理。當在使用阻塞IO的時候,應用程序會被無情的掛起,等待內核完成操做,由於此時的內核可能將CPU時間切換到了其餘須要的進程中,在咱們的應用程序看來感受被卡主(阻塞)了。
設計模式

非阻塞IO數組

當使用非阻塞函數的時候,和阻塞IO類比,內核會當即返回,返回後得到足夠的CPU時間繼續作其餘的事情。
緩存

IO複用模型

當使用fgets等待標準輸入的時候,若是此時套接字有數據但不能讀出。IO多路複用意味着能夠將標準輸入、套接字等都當作IO的一路,任何一路IO有事件發生,都將通知相應的應用程序去處理相應的IO事件,在咱們看來就反覆同時能夠處理多個事情。這就是IO複用。

信號驅動IO

在信號驅動式 I/O 模型中,應用程序使用套接口進行信號驅動 I/O,並安裝一個信號處理函數,進程繼續運行並不阻塞。當數據準備好時,進程會收到一個 SIGIO 信號,能夠在信號處理函數中調用 I/O 操做函數處理數據。

異步IO

用程序告知內核啓動某個操做,並讓內核在整個操做(包括將數據從內核拷貝到應用程序的緩衝區)完成後通知應用程序。那麼和信號驅動有啥不同?

講講select和epoll的區別?
這裏同樣的套路,先說出二者的用途,而後二者的優缺點。
select的缺點

select返回的是含有整個句柄的數組,應用程序須要遍歷整個數組才能發現哪些句柄發生了事件
select的觸發方式是水平觸發,應用程序若是沒有完成對一個已經就緒的文件描述符進行IO操做,那麼以後每次select調用仍是會將這些文件描述符通知進程
內核 / 用戶空間內存拷貝問題,select每次都會改變內核中的句柄數據結構集,於是每次select調用時都須要從用戶空間向內核空間複製全部的句柄數據結構,產生巨大的開銷
單個進程可以監視的文件描述符的數量存在最大限制,一般是1024,固然能夠更改數量
epoll實現

epoll在內核中會維護一個紅黑樹和一個雙向鏈表,紅黑樹存放經過epoll_ctl方法向epoll對象中添加進來的事件,因此不須要每次調用epoll_wait都全量複製全部的事件結構。雙向鏈表存放就緒的事件,全部添加到epoll中的事件都會與設備(網卡)驅動程序創建回調關係,也就是說,當相應的事件發生時會調用這個回調方法,這個回調方法在內核中叫ep_poll_callback,它會將發生的事件添加到rdlist雙鏈表中。調用epoll_wait就會直接返回鏈表中的就緒事件,效率高。
select適合少許活躍鏈接,通常幾千。

epoll適合大量不太活躍的鏈接。

樂觀鎖和悲觀鎖瞭解嗎?

這個問題延伸的問題會不少,好比線程安全,CAS原理,優缺點等。
啥是悲觀和樂觀,咋們面試的時候不得樂觀一些。想給面試來一波官方解釋,而後大白話解釋一波就差很少了。

官方:悲觀鎖是老是假設最壞的狀況,每次那數據都認爲別人會修改它,因此每次去那數據都要上鎖,這樣別人去拿這個數據就會阻塞。樂觀鎖就不同了,老是以爲一切都是最好的安排,每次拿數據都認爲別人不會修改,因此也就不上鎖,可是在更新的時候會判斷這個期間別人有沒有更新這個數據。

什麼是緩存穿透?如何避免?什麼是緩存雪崩?何如避免?
緩存穿透

通常來講,緩存系統會經過key去緩存查詢,若是不存在對應的value,就應該去後端系統查找(好比DB)。這個時候若是一些惡意的請求到來,就會故意查詢不存在的key,當某一時刻的請求量很大,就會對後端系統形成很大的壓力。這就叫作緩存穿透。
如何避免?

對查詢結果爲空的狀況也進行緩存,緩存時間設置短一點,或者該key對應的數據insert了以後清理緩存。對必定不存在的key進行過濾。能夠把全部的可能存在的key放到一個大的Bitmap中,查詢時經過該bitmap過濾。
緩存雪崩

當緩存服務器重啓或者大量緩存集中在某一個時間段失效,這樣在失效的時候,會給後端系統帶來很大壓力。致使系統崩潰。
如何避免?

在緩存失效後,經過加鎖或者隊列來控制讀數據庫寫緩存的線程數量。好比對某個key只容許一個線程查詢數據和寫緩存,其餘線程等待。
作二級緩存,A1爲原始緩存,A2爲拷貝緩存,A1失效時,能夠訪問A2,A1緩存失效時間設置爲短時間,A2設置爲長期。

不一樣的key,設置不一樣的過時時間,讓緩存失效的時間點儘可能均勻。

2 redis相關

若是是後端/服務端面試的同窗,怎麼說都的去找一本redis書來看看,其出現的機率只有那麼大了,切記切記。看看B站問了哪幾個問題。
redis的淘汰刪除策略瞭解嗎?
能說不了解嗎,就算是沒有據說過,咋們也能夠來一句:「很差意思面試官,這一塊還不怎麼深刻,可是從字面意思來理解巴拉巴拉」,不至於一臉懵逼。下面咱們看看redis的緩存策略

Redis中經過maxmemory參數來設定內存的使用上限,若是Redis所使用內存超過設定的最大值,那麼會根據配置文件中的策略選取要刪除的key來刪除,從而留出新的鍵值空間。主要的六種淘汰key策略

volatile-lru
在鍵空間中設置過時時間,移除哪些最近最少使用的key,佔着茅坑不拉屎的key
allkeys-lru
移除最近最少使用的key
volatile-random
在鍵空間中設置過時時間,隨機移除一個key
allkeys-random
隨機移除一個key
noeviction
當內存使用達到閥值的時候,全部引發申請內存的命令會報錯;
ok,如今知道了須要淘汰哪些key,那咱們如何去淘汰這些key

定時刪除
很簡單,設置一個鬧鐘,鬧鐘響了就刪除便可。這種方式對於內存來講仍是比較友好,內存不須要啥額外的操做,直接經過定時器就可保證儘快的刪除。對於CPU來講就有點麻煩了,若是過時鍵比較多,那麼定時器也就多,這刪除操做就會佔用太多的CPU資源
惰性刪除
每次從鍵空間獲取鍵的時候檢查鍵的過時時間,若是過時了,刪除完事。
按期刪除
每隔一段時間就去數據庫檢查,刪除過時的鍵
這種方案是定時刪除和惰性刪除的中和方法,既經過限制刪除操做執行的時長來減小對CPU時間的影響,也能減小內存的浪費。可是難點在於間隔時長鬚要根據業務狀況而定。

3 mysql

mysql中使用的鎖有哪些?何時使用行鎖,何時會使用表鎖?
InnoDB中的行鎖是經過索引上的索引項實現,主要特色是,只有經過索引條件檢索數據,InnoDB纔會使用行級鎖,不然InnoDB將使用表鎖。

這裏注意,在Mysql中,行級鎖不是鎖記錄而是鎖索引。索引又分爲主鍵索引和非主鍵索引兩種。若是在一條語句中操做了非主鍵索引,Mysql會鎖定該非主鍵索引,再鎖定相關的主鍵索引。

瞭解過間隙鎖嗎?間隙鎖的加鎖範圍是怎麼肯定的?
瞭解B+樹嗎?B+樹何時會出現結點分裂?
這個回答在上一篇的B+樹已經詳細說了。這裏簡述一下
將已滿結點進行分裂,將已滿節點後M/2節點生成一個新節點,將新節點的第一個元素指向父節點。
父節點出現已滿,將父節點繼續分裂。
一直分裂,若是根節點已滿,則須要分類根節點,此時樹的高度增長。
事務還沒執行完數據庫掛了,重啓的時候會發生什麼?
undo日誌和redo日誌分別是幹嗎的?
redo log重作日誌是InnDB存儲引擎層的,用來保證事務安全。在事務提交以前,每一個修改操做都會記錄變動後的數據,保存的是物理日誌-數據,防止發生故障的時間點,有髒頁未寫入磁盤,在重啓mysql的時候,根據redo log進行重作從而達到事務的持久性

undo log回滾日誌保存了事務發生以前的數據的一個版本,能夠用於回滾,同時也提供多版本併發控制下的讀。

簡單講講數據庫的MVCC的實現原理?
細說太多了,幾個大寫字母表明啥,這幾個大寫字母又是如何關聯起來完事。細問再深究
mysql的binlog日誌何時會使用?
首先應該知道binlog是一個二進制文件,記錄全部增刪改操做,節點之間的複製都會依靠binlog來完成。從底層原理來講,binlog有三個模式

模式1--row模式
每一行的數據被修改就會記錄在日誌中,而後在slave段對相同的數據進行修改。好比說"update xx where id in(1,2,3,4,5)",使用此模式就會記錄5條記錄
模式2--statement模式
修改數據的sql會記錄到master的binlog中。slave在複製的時候sql thread會解析成和原來maseter端執行過的相同的sql在此執行
模式3--mixed模式
mixed模式即混合模式,Mysql會根據執行的每一條具體sql區分對待記錄的日誌形式。那麼binlog的主從同步流程究竟是咋樣的

流程簡述:

Master執行完增刪改操做後都會記錄binlog日誌,當須要同步的時候會主動通知slave節點,slave收到通知後使用IO THREAD主動去master讀取binlog寫入relay日誌(中轉日誌),而後使 SQL THREAD完成對relay日誌的解析而後入庫操做,完成同步。

4 基本數據結構

使用LRU時,若是短期內會出現大量只會使用一次的數據,可能致使以前大量高頻使用的緩存被刪除,請問有什麼解決辦法?
瞭解過循環鏈表嗎?他的長度怎麼計算?
他的主要特色是鏈表中的最後一個節點的指針域指向頭結點,整個鏈表造成一個環。這裏循環鏈表判斷鏈表結束的標誌是,判斷尾節點是否是指向頭結點
哪一種數據結構能夠支持快速插入,刪除,查找等操做?
思考這個問題的時候,咱們不凡複習下不錯的二分查找,它依賴數組隨機訪問的特性,其查找時間複雜度爲O(log n)。若是咱們將元素放入鏈表中,二分查找還好使嗎?這就是今天和你們分享的跳錶

理解跳錶

假設使用單鏈表存儲n個元素,其中元素有序以下圖所示

從鏈表中查找一個元素,天然從頭開始遍歷找到須要查找的元素,此時的時間複雜度爲O(n)。那採用什麼方法能夠提升查詢的效率呢?問就是加索引,如何加,咱們從這部分數據中抽取幾個元素出來做爲單獨的一個鏈表,以下圖所示]

假設此時咋們查找元素16,首先一級索引處尋找,當找到元素14的時候,下一個節點的值爲18,意味着咱們尋找的數在這兩個數的中間。此時直接從14節點指針下移到下面的原始鏈表中,繼續遍歷,正好下一個元素就是咱們尋找的16。好了,咱們小結一下,若是從原始鏈表中尋找元素16,須要遍歷比較8次,若是經過索引鏈表尋找咱們只須要5次便可。

咱們繼續查找元素16,此時比較次數變爲4次。這樣看來,加一層索引查找的次數就變少,若是有n個元素到底有多少索引?

假設咱們按照每兩個結點就抽出一個結點做爲上一層的索引節點,第一層因此節點個數n/2,第二層爲n/4,第x級索引的結點個數是第x-1級索引的結點個數的1/2,那第x級索引結點的個數就是n/(2x)。假設索引有y級,咱們能夠獲得n/(2y)=2,從而求得y=log2n-1。

這麼多索引是否是就很浪費內存嘞?
假設原始鏈表大小爲n,那第一級索引大約有 n/2 個結點,第二級索引大約有 n/4 個結點,以此類推,每上升一級就減小一半,直到剩下 2 個結點。若是咱們把每層索引的結點數寫出來,就是一個等比數列。這幾級索引的結點總和就是 n/2+n/4+n/8…+8+4+2=n-2 。因此,跳錶的空間複雜度是 O(n) 。那還能不能下降一些呢。機智的你應該就考慮到假設每三個結點抽取一個節點做爲索引鏈表的節點。

跳錶與二叉查找樹

二者其查找的時間複雜度均爲O(logn) ,那跳錶還有哪些優點?
先看二叉查找樹,

特殊二叉查找樹
特殊二叉查找樹
這種結構會致使二叉查找樹的查找效率變爲 O(n),。

跳錶與紅黑樹

說實話,紅黑樹確實比較複雜,面試的時候讓你寫紅黑樹,你就給他大嘴巴子?
紅黑樹須要經過左右旋的方式去維持樹大小平衡。而跳錶是經過隨機函數來維護前面提到的 「 平衡性 」 。當咱們往跳錶中插入數據的時候,咱們能夠選擇同時將這個數據插入到部分索引層中。如何選擇加入哪些索引層呢?
咱們經過一個隨機函數,來決定將這個結點插入到哪幾級索引中,好比隨機函數生成了值 K ,那咱們就將這個結點添加到第一級到第 K 級這 K 級索引中。當咱們往跳錶中插入數據的時候,咱們能夠選擇同時將這個數據插入到部分索引層中。

小結

Redis中的有序集合採用了跳錶的方式來實現,其實還採用了散列表等數據結構進行融合。它在插入,刪除等都有比較快的速度,雖然紅黑樹也能夠作到,可是紅黑樹對於按照區間查找數據這個操做,跳錶能夠作到 O(logn) 的時間複雜度定位區間的起點,而後在原始鏈表中順序日後遍歷就能夠了
5 總結

請記下如下幾點:
公司招你去是幹活了,不會由於你怎麼怎麼的而下降對你的要求標準。
工具上面寫代碼和手撕代碼徹底不同。
珍惜每一次面試機會並學會覆盤。
對於應屆生主要考察的仍是計算機基礎知識的掌握,項目要求沒有那麼高,是本身作的就使勁摳細節,作測試,只有這樣,才知道會遇到什麼問題,遇到什麼難點,如何解決的。從而能夠侃侃而談了。
非科班也不要怕,怕了你就輸了!必定要多嘗試。

總結了一些2020年的面試題,這份面試題的包含的模塊分爲19個模塊,分別是: Java 基礎、容器、多線程、反射、對象拷貝、Java Web 、異常、網絡、設計模式、Spring/Spring MVC、Spring Boot/Spring Cloud、Hibernate、MyBatis、RabbitMQ、Kafka、Zookeeper、MySQL、Redis、JVM 。

獲取資料以上資料:關注公衆號:有故事的程序員,獲取學習資料。
記得點個關注+評論哦~

以上文章來自於公衆號:程序員小賤,做者藍

相關文章
相關標籤/搜索