国产美女主播视频一区_国产精品蜜臀在线观看_亚洲成人动漫一区_亚洲视屏在线播放

今天給大家分享騰訊春招的實(shí)習(xí)面經(jīng)，崗位Java后端，主要問(wèn)了MySQL、Java、網(wǎng)絡(luò)這三大塊。

(資料圖片僅供參考)

求職者覺(jué)得這場(chǎng)面試非常有收獲，雖然都是基礎(chǔ)問(wèn)題，但是往下深挖根莖葉脈全部相連。反問(wèn)環(huán)節(jié)面試官給了他很多建議，包括面試、策略、基礎(chǔ)、算法等等，是一次寶貴的學(xué)習(xí)經(jīng)歷。

MySQL

介紹一下MySQL的索引機(jī)制

索引可以幫助我們快速搜索數(shù)據(jù)，innodb 存儲(chǔ)引擎用的是 b+樹(shù)索引，葉子節(jié)點(diǎn)存放的是索引+數(shù)據(jù)，非葉子節(jié)點(diǎn)只存放索引。

可以按照四個(gè)角度來(lái)分類(lèi)索引。

聯(lián)合索引是什么？

通過(guò)將多個(gè)字段組合成一個(gè)索引，該索引就被稱(chēng)為聯(lián)合索引。

比如，將商品表中的 product_no 和 name 字段組合成聯(lián)合索引(product_no, name)，創(chuàng)建聯(lián)合索引的方式如下：

CREATEINDEXindex_product_no_nameONproduct(product_no,name);

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

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

也就是說(shuō)，聯(lián)合索引查詢(xún)的 B+Tree 是先按 product_no 進(jìn)行排序，然后再 product_no 相同的情況再按 name 字段排序。

因此，使用聯(lián)合索引時(shí)，存在最左匹配原則，也就是按照最左優(yōu)先的方式進(jìn)行索引的匹配。在使用聯(lián)合索引進(jìn)行查詢(xún)的時(shí)候，如果不遵循「最左匹配原則」，聯(lián)合索引會(huì)失效，這樣就無(wú)法利用到索引快速查詢(xún)的特性了。

什么是聚簇索引？

聚簇索引的 B+Tree 的葉子節(jié)點(diǎn)存放的是實(shí)際數(shù)據(jù)，所有完整的用戶(hù)記錄都存放在主鍵索引的 B+Tree 的葉子節(jié)點(diǎn)里。

什么是覆蓋索引？

在查詢(xún)時(shí)使用了二級(jí)索引，如果查詢(xún)的數(shù)據(jù)能在二級(jí)索引里查詢(xún)的到，那么就不需要回表，這個(gè)過(guò)程就是覆蓋索引。如果查詢(xún)的數(shù)據(jù)不在二級(jí)索引里，就會(huì)先檢索二級(jí)索引，找到對(duì)應(yīng)的葉子節(jié)點(diǎn)，獲取到主鍵值后，然后再檢索主鍵索引，就能查詢(xún)到數(shù)據(jù)了，這個(gè)過(guò)程就是回表。

整個(gè)索引查詢(xún)的過(guò)程是怎樣的？

InnoDB 里的 B+ 樹(shù)中的每個(gè)節(jié)點(diǎn)都是一個(gè)數(shù)據(jù)頁(yè)，結(jié)構(gòu)示意圖如下：

B+ 樹(shù)如何實(shí)現(xiàn)快速查找主鍵為 6 的記錄，以上圖為例子：

可以看到，在定位記錄所在哪一個(gè)頁(yè)時(shí)，也是通過(guò)二分法快速定位到包含該記錄的頁(yè)。定位到該頁(yè)后，又會(huì)在該頁(yè)內(nèi)進(jìn)行二分法快速定位記錄所在的分組（槽號(hào)），最后在分組內(nèi)進(jìn)行遍歷查找。

事務(wù)的隔離級(jí)別有哪些？

臟讀、幻讀、不可重讀分別是什么意思？

InnoDB 多版本并發(fā)控制的具體原理，底層細(xì)節(jié)？

對(duì)于「讀提交」和「可重復(fù)讀」隔離級(jí)別的事務(wù)來(lái)說(shuō)，它們是通過(guò) Read View 來(lái)實(shí)現(xiàn)的，它們的區(qū)別在于創(chuàng)建 Read View 的時(shí)機(jī)不同，大家可以把 Read View 理解成一個(gè)數(shù)據(jù)快照，就像相機(jī)拍照那樣，定格某一時(shí)刻的風(fēng)景。

Read View 有四個(gè)重要的字段：

對(duì)于使用 InnoDB 存儲(chǔ)引擎的數(shù)據(jù)庫(kù)表，它的聚簇索引記錄中都包含下面兩個(gè)隱藏列：

在創(chuàng)建 Read View 后，我們可以將記錄中的 trx_id 劃分這三種情況：

一個(gè)事務(wù)去訪問(wèn)記錄的時(shí)候，除了自己的更新記錄總是可見(jiàn)之外，還有這幾種情況：

這種通過(guò)「版本鏈」來(lái)控制并發(fā)事務(wù)訪問(wèn)同一個(gè)記錄時(shí)的行為就叫 MVCC（多版本并發(fā)控制）。

next Key是什么，怎么實(shí)現(xiàn)？

Next-Key Lock 稱(chēng)為臨鍵鎖，是 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ù)記錄前面的間隙中。

索引失效的場(chǎng)景有哪些，你知道什么改進(jìn)方法嗎？

提交事務(wù)的一整個(gè)過(guò)程，每個(gè)日志都是怎么工作的？

具體更新一條記錄 UPDATE t_user SET name = "xiaolin" WHERE id = 1;的流程如下:

Java

JVM內(nèi)存區(qū)域 每一個(gè)區(qū)域的內(nèi)容？

JVM的內(nèi)存結(jié)構(gòu)主要分為以下幾個(gè)部分：

JVM異常問(wèn)題？

String保存在哪里呢

String 保存在字符串常量池中，不同于其他對(duì)象，它的值是不可變的，且可以被多個(gè)引用共享。

java版本改動(dòng)問(wèn)題 有哪些主要區(qū)別？

怎么找到需要回收的垃圾？

Java中的垃圾回收機(jī)制通過(guò)判斷對(duì)象是否可達(dá)來(lái)確定哪些對(duì)象可以被回收。當(dāng)一個(gè)對(duì)象沒(méi)有任何引用指向它時(shí)，它就可以被回收，這個(gè)過(guò)程由JVM的垃圾回收器自動(dòng)完成。

JVM使用可達(dá)性分析算法來(lái)判斷對(duì)象是否可達(dá)。從GC Roots對(duì)象開(kāi)始，通過(guò)一系列的引用鏈來(lái)遍歷所有的對(duì)象，如果一個(gè)對(duì)象不可達(dá)，則說(shuō)明它已經(jīng)死亡，可以被回收了。

在Java中，有4種引用類(lèi)型：強(qiáng)引用、軟引用、弱引用和虛引用。其中，強(qiáng)引用是最常見(jiàn)的引用類(lèi)型，只要強(qiáng)引用存在，垃圾回收器就不會(huì)回收該對(duì)象。軟引用、弱引用和虛引用則分別表示對(duì)對(duì)象的軟引用、弱引用和虛引用，當(dāng)垃圾回收器進(jìn)行垃圾回收時(shí)，會(huì)根據(jù)不同的引用類(lèi)型來(lái)決定是否回收對(duì)象。

有哪些常見(jiàn)的垃圾回收器，舉幾個(gè)說(shuō)說(shuō)？

其中，Serial收集器和Parallel收集器是新生代收集器，CMS和G1是老年代收集器。

HashMap底層怎么實(shí)現(xiàn)的 ？線(xiàn)程安全嗎？

HashMap底層是基于數(shù)組和鏈表實(shí)現(xiàn)的。簡(jiǎn)單來(lái)說(shuō)，HashMap將key通過(guò)hash算法映射到數(shù)組中，然后在對(duì)應(yīng)的鏈表中查找value。當(dāng)多個(gè)key的hash值相同時(shí)，會(huì)在同一個(gè)數(shù)組位置上使用鏈表來(lái)存儲(chǔ)這些key-value。但是，當(dāng)鏈表長(zhǎng)度太長(zhǎng)時(shí)，會(huì)影響HashMap的性能，因此在中，當(dāng)鏈表長(zhǎng)度超過(guò)閾值時(shí)，會(huì)將鏈表轉(zhuǎn)換為紅黑樹(shù)，以提高查找效率。

HashMap不是線(xiàn)程安全的，因?yàn)槎鄠€(gè)線(xiàn)程同時(shí)訪問(wèn)HashMap時(shí)可能會(huì)導(dǎo)致數(shù)據(jù)不一致的問(wèn)題。可以使用ConcurrentHashMap來(lái)實(shí)現(xiàn)線(xiàn)程安全的Map。

紅黑樹(shù)是什么？

紅黑樹(shù)是一種自平衡的二叉查找樹(shù)，可以保證在最壞情況下基本動(dòng)態(tài)操作的時(shí)間復(fù)雜度為O(log n)。紅黑樹(shù)中的每個(gè)節(jié)點(diǎn)都有一個(gè)顏色屬性，可以是紅色或黑色。紅黑樹(shù)滿(mǎn)足以下5個(gè)性質(zhì)：

通過(guò)這些性質(zhì)，紅黑樹(shù)可以保證在插入和刪除節(jié)點(diǎn)時(shí)，自動(dòng)調(diào)整樹(shù)的結(jié)構(gòu)，以保持樹(shù)的平衡和性質(zhì)的滿(mǎn)足。相比于普通的二叉查找樹(shù)，紅黑樹(shù)的平衡性更好，查找、插入和刪除都具有更穩(wěn)定的時(shí)間復(fù)雜度，因此在很多場(chǎng)景下被廣泛應(yīng)用。

什么是公平鎖和非公平鎖？

公平鎖和非公平鎖是針對(duì)鎖的獲取方式而言的。

公平鎖是指多個(gè)線(xiàn)程按照申請(qǐng)鎖的順序來(lái)獲取鎖，即先到先得的原則。當(dāng)線(xiàn)程A釋放鎖后，線(xiàn)程B、C、D依次獲取鎖，如果此時(shí)線(xiàn)程E申請(qǐng)鎖，則它需要等待B、C、D依次獲取到鎖并釋放鎖后才能獲取鎖。

非公平鎖是指多個(gè)線(xiàn)程獲取鎖的順序是隨機(jī)的，不保證公平性。當(dāng)線(xiàn)程A釋放鎖后，線(xiàn)程B、C、D等線(xiàn)程都可以通過(guò)競(jìng)爭(zhēng)獲取到鎖，而此時(shí)線(xiàn)程E也可以通過(guò)競(jìng)爭(zhēng)獲取到鎖。

在實(shí)際應(yīng)用中，公平鎖可以避免饑餓現(xiàn)象，但是由于需要維護(hù)線(xiàn)程隊(duì)列，因此效率相對(duì)較低。而非公平鎖由于不需要維護(hù)線(xiàn)程隊(duì)列，因此效率相對(duì)較高，但是可能會(huì)導(dǎo)致某些線(xiàn)程長(zhǎng)時(shí)間無(wú)法獲取鎖。

ThreadLocal 是什么？

ThreadLocal是Java中的一個(gè)線(xiàn)程封閉技術(shù)，它可以讓每個(gè)線(xiàn)程都擁有自己?jiǎn)为?dú)的變量副本，從而保證線(xiàn)程安全。ThreadLocal提供了一種線(xiàn)程本地存儲(chǔ)的機(jī)制，為每個(gè)線(xiàn)程提供一個(gè)獨(dú)立的變量副本，使得每個(gè)線(xiàn)程中的變量互不干擾。

計(jì)算機(jī)網(wǎng)絡(luò)

TCP 三次握手、四次揮手的過(guò)程？

三次握手的過(guò)程：

四次揮手的過(guò)程：

為什么要三次握手、四次揮手？

三次握手的原因：

四次次揮手的原因：

LINUX有哪些IO機(jī)制？

select poll epoll，底層實(shí)現(xiàn)有什么區(qū)別？

select 和 poll 并沒(méi)有本質(zhì)區(qū)別，它們內(nèi)部都是使用「線(xiàn)性結(jié)構(gòu)」來(lái)存儲(chǔ)進(jìn)程關(guān)注的 Socket 集合。

在使用的時(shí)候，首先需要把關(guān)注的 Socket 集合通過(guò) select/poll 系統(tǒng)調(diào)用從用戶(hù)態(tài)拷貝到內(nèi)核態(tài)，然后由內(nèi)核檢測(cè)事件，當(dāng)有網(wǎng)絡(luò)事件產(chǎn)生時(shí)，內(nèi)核需要遍歷進(jìn)程關(guān)注 Socket 集合，找到對(duì)應(yīng)的 Socket，并設(shè)置其狀態(tài)為可讀/可寫(xiě)，然后把整個(gè) Socket 集合從內(nèi)核態(tài)拷貝到用戶(hù)態(tài)，用戶(hù)態(tài)還要繼續(xù)遍歷整個(gè) Socket 集合找到可讀/可寫(xiě)的 Socket，然后對(duì)其處理。

很明顯發(fā)現(xiàn)，select 和 poll 的缺陷在于，當(dāng)客戶(hù)端越多，也就是 Socket 集合越大，Socket 集合的遍歷和拷貝會(huì)帶來(lái)很大的開(kāi)銷(xiāo)，因此也很難應(yīng)對(duì) C10K。

epoll 是解決 C10K 問(wèn)題的利器，通過(guò)兩個(gè)方面解決了 select/poll 的問(wèn)題。

BIO 和 NIO 的區(qū)別？

Java中，BIO和NIO都是IO模型，它們的主要區(qū)別在于：

算法

鏈表判斷相交

publicListNodegetIntersectionNode(ListNodeheadA,ListNodeheadB){if(headA==null||headB==null)returnnull;ListNodepA=headA,pB=headB;while(pA!=pB){pA=pA==null?headB:;pB=pB==null?headA:;}returnpA;}

面試總結(jié)

求職者的感覺(jué)

非常有收獲的一次面試，值得之后自己?jiǎn)为?dú)寫(xiě)一寫(xiě)文章去記錄一下。基礎(chǔ)不牢地動(dòng)山搖，雖然都是基礎(chǔ)問(wèn)題，但是往下深挖根莖葉脈全部相連，這些問(wèn)題面試題里面都有解，但是自己真的是只知道表面，淺淺看個(gè)大概就上戰(zhàn)場(chǎng)了，還有就是非常感謝面試官，反問(wèn)環(huán)節(jié)給了我很多建議，包括面試、策略、基礎(chǔ)、算法等等，是一次寶貴的學(xué)習(xí)經(jīng)歷，說(shuō)不遺憾是假的，但我很開(kāi)心，有所收獲就好。

求職者的不足之處

基礎(chǔ)不夠扎實(shí)，很多只知其表不知其里，而且面試官經(jīng)驗(yàn)豐富，非常敏銳，當(dāng)時(shí)壓力也很大，被問(wèn)倒了心態(tài)也不穩(wěn)，有的可以答出來(lái)的也沒(méi)想起來(lái)怎么說(shuō)。

沒(méi)有幾個(gè)答的特別好的，稍微說(shuō)一點(diǎn)就會(huì)被問(wèn)深直到不會(huì)，這里就不貼當(dāng)時(shí)回答了，說(shuō)的都很淺，下來(lái)每一個(gè)問(wèn)題都要仔細(xì)研究，要將知識(shí)連接成網(wǎng)。

自己給自己構(gòu)造一個(gè)場(chǎng)景，順著把用到的技術(shù)全部梳理一遍，能講出這個(gè)整體過(guò)程，有頭有尾，才能真的理解，比如hashmap插入數(shù)據(jù)的過(guò)程、threadlocal創(chuàng)建釋放的過(guò)程、String怎么實(shí)現(xiàn)的字符串拼接、SpringBoot框架搭建的每一步等等。

歡迎學(xué)編程的朋友們加入魚(yú)皮的，和上萬(wàn)名學(xué)編程的同學(xué)共享知識(shí)、交流進(jìn)步，學(xué)習(xí)原創(chuàng)項(xiàng)目并享有答疑指導(dǎo)服務(wù)。