面試問源碼你怎麼看

Ⅰ 【面試題解析】從 Vue 源碼分析 key 的作用

最近看了面試題中有一個這樣的題， v-for 為什麼要綁定 key？

Vue 中 key 很多人都弄不清楚有什麼作用，甚至還有些人認為不綁定 key 就會報錯。

其實沒綁定 key 的話，Vue 還是可以正常運行的，報警告是因為沒通過 Eslint 的檢查。

接下來將通過源碼一步步分析這個 key 的作用。

Virtual DOM 最主要保留了 DOM 元素的層級關系和一些基本屬性，本質上就是一個 JS 對象。相對於真實的 DOM，Virtual DOM 更簡單，操作起來速度更快。

如果需要改變 DOM，則會通過新舊 Virtual DOM 對比，找出需要修改的節點進行真實的 DOM 操作，從而減小性能消耗。

傳統的 Diff 演算法需要遍歷一個樹的每個節點，與另一棵樹的每個節點對比，時間復雜度為 O(n²)。

Vue 採用的 Diff 演算法則通過逐級對比，大大降低了復雜性，時間復雜度為 O(n)。

VNode 更新首先會經過 patch 函數， patch 函數源碼如下：

vnode 表示更新後的節點，oldVnode 表示更新前的節點，通過對比新舊節點進行操作。

1、vnode 未定義，oldVnode 存在則觸發 destroy 的鉤子函數

2、oldVnode 未定義，則根據 vnode 創建新的元素

3、oldVnode 不為真實元素並且 oldVnode 與 vnode 為同一節點，則會調用 patchVnode 觸發更新

4、oldVnode 為真實元素或者 oldVnode 與 vnode 不是同一節點，另做處理

接下來會進入 patchVnode 函數，源碼如下：

1、vnode 的 text 不存在，則會比對 oldVnode 與 vnode 的 children 節點進行更新操作

2、vnode 的 text 存在，則會修改 DOM 節點的 text

接下來在 updateChildren 函數內就可以看到 key 的用處。

key 的作用主要是給 VNode 添加唯一標識，通過這個 key，可以更快找到新舊 VNode 的變化，從而進一步操作。

key 的作用主要表現在以下這段源碼中。

updateChildren 過程為：

1、分別用兩個指針（startIndex, endIndex）表示 oldCh 和 newCh 的頭尾節點

2、對指針所對應的節點做一個兩兩比較，判斷是否屬於同一節點

3、如果4種比較都沒有匹配，那麼判斷是否有 key，有 key 就會用 key 去做一個比較；無 key 則會通過遍歷的形式進行比較

4、比較的過程中，指針往中間靠，當有一個 startIndex > endIndex，則表示有一個已經遍歷完了，比較結束

從 VNode 的渲染過程可以得知，Vue 的 Diff 演算法先進行的是同級比較，然後再比較子節點。

子節點比較會通過 startIndex、endIndex 兩個指針進行兩兩比較，再通過 key 比對子節點。如果沒設置 key，則會通過遍歷的方式匹配節點，增加性能消耗。

所以不綁定 key 並不會有問題，綁定 key 之後在性能上有一定的提升。

綜上，key 主要是應用在 Diff 演算法中，作用是為了更快速定位出相同的新舊節點，盡量減少 DOM 的創建和銷毀的操作。

希望以上內容能夠對各位小夥伴有所幫助，祝大家面試順利。

Vue 的文檔中對 key 的說明如下：

關於就地修改，關鍵在於 sameVnode 的實現，源碼如下：

可以看出，當 key 未綁定時，主要通過元素的標簽等進行判斷，在 updateChildren 內會將 oldStartVnode 與 newStartVnode 判斷為同一節點。

如果 VNode 中只包含了文本節點，在 patchVnode 中可以直接替換文本節點，而不需要移動節點的位置，確實在不綁定 key 的情況下效率要高一丟丟。

某些情況下不綁定 key 的效率更高，那為什麼大部分Eslint的規則還是要求綁定 key 呢？

因為在實際項目中，大多數情況下 v-for 的節點內並不只有文本節點，那麼 VNode 的位元組點就要進行銷毀和創建的操作。

相比替換文本帶來的一丟丟提升，這部分會消耗更多的性能，得不償失。

了解了就地修改，那麼我們在一些簡單節點上可以選擇不綁定 key，從而提高性能。

如果你喜歡我的文章，希望可以關注一下我的公眾號【前端develop】

Ⅱ 如何高效閱讀源代碼

下面是之前寫的一篇文章：《如何快速閱讀源碼》

本文探討在需要了解一個開源項目時，如何快速的理清開源項目的代碼邏輯！

以下是個人認為行之有效的方法：

本文以Mybatis為例來進行演示！

程序界有個老傳統，學習新技術時都是從「Hello World」開始的！無論是學習新語言時，列印「Hello World」；還是學習新框架時編寫個demo！那為什麼這里的「跑起來」要打個引號呢？

實際上，當你想要閱讀一個開源項目的源碼時，絕大部分情況下，你已經能夠使用這個開源項目了！所以這里的「跑起來」就不是寫個「Hello World」，也不是能跑起來的程序了！而是能__在你的腦子里「跑起來」__！什麼意思？

Mybatis你會用了吧？那麼請問Mybatis是如何執行的呢？仔細想想，你能否用完整的語句把它描述出來？

這里是Mybatis的官方入門文章！你是如何看這篇文章的？讀一遍就行了嗎？還是跟著文章跑一遍就夠了嗎？從這篇文章里你能獲得多少信息？

我們來理一下：

回答出了上面這些問題！你也就基本能在腦子里把Mybatis「跑起來」了！之後，你才能正真的開始閱讀源碼！

當你能把一個開源項目「跑起來」後，實際上你就有了對開源項目最初步的了解了！就像「 書的索引 」一樣！基於這個索引，我們一步步的進行拆解，來細化出下一層的結構和流程，期間可能需要深入技術細節，考量實現，考慮是否有更好的實現方案！也就是說後面的三步並不是線性的，而是__不斷交替執行__的一個過程！最終就形成一個完整的源碼執行流程！

繼續通過Mybatis來演示（限於篇幅，我只演示一個大概流程）！我們現在已經有了一個大概的流程了：

雖說每個點都可以往下細化，但是也分個輕重緩急！

很明顯，SqlSession去執行 sql才是Mybatis的核心！我們先從這個點入手！

首先，你當然得先下載Mybatis的源碼了（請自行下載）！

我們直接去看SqlSession！它是個介面，裡面有一堆執行sql的方法！

這里只列出了一部分方法：

SqlSession就是通過這些方法來執行sql的！我們直接看我們常用的，也是Mybatis推薦的用法，就是基於Mapper的執行！也就是說「SqlSession通過Mapper來執行具體的sql」！上面的流程也就細化成了：

那SqlSession是如何獲取Mapper的呢？Mapper又是如何執行sql的呢？

我們來看SqlSession的實現！SqlSession有兩個實現類SqlSessionManager和DefaultSqlSession！通過IDE的引用功能可以查看兩個類的使用情況。你會發現SqlSessionManager實際並沒有使用！而DefaultSqlSession是通過DefaultSqlSessionFactory構建的！所以我們來看DefaultSqlSession是如何構建Mapper的！

它直接委託給了Configuration的getMapper方法！

Configuration又委託給了MapperRegistry類的getMapper方法！

在MapperRegistry類的getMapper中：

在這里knowMappers是什麼？MapperProxyFactory又是什麼？mapperProxyFactory.newInstance(sqlSession)具體做了什麼？

其實很簡單，knowMappers是個Map，裡麵包含了class與對應的MapperProxyFactory的對應關系！MapperProxyFactory通過newInstance來構建對應的Mapper（實際上是Mapper的代理）！

快接近真相了，看mapperProxyFactory.newInstance(sqlSession)里的代碼：

這里幹了什麼？

最終實際還是委託給了sqlSession去執行具體的sql！後面具體怎麼實現的就自行查看吧！

現在我們的流程大概是這樣的一個過程：

現在我們大概知道了：

那麼，

這個問題列表可以很長，可以按個人需要去思考並嘗試回答！可能最終這些問題已經和開源項目本身沒有什麼關系了！但是你思考後的收獲要比看源碼本身要多得多！

一輪結束後，可以再次進行：

不斷的拆解->深入->改進，最終你能__通過一個開源項目，學習到遠比開源項目本身多得多的知識__！

最重要的是，你的流程是完整的。無論是最初的大致流程：

還是到最終深入的細枝末節，都是個完整的流程！

這樣的好處是，你的時間能自由控制：

而不像debug那樣的方式，需要一下子花費很長的時間去一步步的理流程，費時費力、收效很小，而且如果中斷了就很難繼續了！

本文通過梳理Mybatis源碼的一個簡單流程，來講述一個個人認為比較好的閱讀源碼的方式，並闡述此方法與傳統debug方式相比的優勢。

閱讀源碼是每個優秀開發工程師的必經之路，那麼這篇文章就來講解下為什麼要閱讀源碼以及如何閱讀源碼。

首先來說下為什麼要讀源碼，有學習源碼的必要嗎？

為什麼要閱讀源碼？

關於為什麼閱讀和學習源碼，我個人認為可能有以下幾點：

（一）吊打面試官，應對面試

為了找到更好的工作，應對面試，因為在面試中肯定會問到源碼級別的問題，比如：為什麼 HashMap 是線程不安全的？

如果你沒有閱讀過源碼，面試官可能會對回答的結果不滿意，進而導致面試結果不太理想，但如果你對源碼有所研究，並能夠很好地問答面試官的問題，這可能就是你的加分點，可以形成自己獨特的競爭力，吊打面試官，升職加薪不是夢。

（二）解決問題（bug）

在開發過程中，我們或多或少會遇到 bug，比如：在 foreach 循環里進行元素的 remove/add 操作，為啥有可能會報 異常？

我們可以先在 Google、Stack Overflow 以及對應項目的 Issues 里看有沒有類似問題以及解決辦法，如果沒有的話，我們只能通過閱讀源碼的方式去解決了。如果我們對相關源碼有所涉獵，就可以快速定位到問題所在。

（三）提升編程能力

和閱讀一本好書一樣，閱讀源碼就是和編程大牛面對面交流的機會，在許多優秀的開源項目中，它們的編碼規范和架構設計都是很棒的，另外在設計上也使用了大量的設計模式，通過閱讀和學習源碼，能夠快速提升我們的編碼水平，以及對設計模式有更深的理解。

同時，在我們閱讀完一個源碼後，可以觸類旁通，能夠快速地對其他框架的源碼進行閱讀和學習，減少時間成本。

除了上述提到的原因之外，可能還有許多，在這里就不一一贅述了，那麼在確定了要閱讀源碼之後，就讓我們看下如何閱讀源碼吧！

如何閱讀源碼？

如何閱讀源碼取決於你為什麼要讀源碼，比如：

下面大概說下閱讀源碼的幾點建議：

在閱讀之前，可以先從開源項目的官網上看它的架構設計和功能文檔，了解這個項目的 整體架構、模塊組成以及各個模塊之間的聯系 。

如果沒有對應的項目文檔，可以根據代碼的模塊進行梳理，以形成對項目的初步了解，或者 查看已有的源碼解析文章或者書籍 ，在閱讀源碼之前，了解項目的架構和思路會使閱讀源碼事半功倍。

在了解一個類的時候，可以使用 ctrl+F12 來查看類中的成員變數和方法。

可以通過 IDEA 的 Diagrams 功能去了解一個類的繼承關系。

多打 斷點調試 ，斷點追蹤源碼是很好的閱讀源碼的方式，可以先通過 debug 了解下調用邏輯，都和哪些類有關聯，有大致了解後再通過 debug 了解整體代碼的功能實現，各個類都起到了什麼作用，有沒有涉及到設計模式等。

另外，優秀的開源項目中肯定會有許多地方應用到了 設計模式 ，建議在閱讀源碼之前，需要對常用的設計模式有大致的了解，不然閱讀源碼的效率會大大降低。

如果遇到讀不懂某部分源碼的時候，可以先跳過，之後再回來看，如果屬於搞不懂這部分就茶不思飯不想的人，可以在網上找是否有該部分源碼的解析或者文檔，也可以自己通過 源碼注釋和測試用例 去閱讀學習。

一般優秀的開源項目都會有 單元測試 ，可以通過對應類的單元測試去了解方法的含義和用法，加深對源碼邏輯的理解。

在閱讀源碼的時候，可以在代碼上加上 注釋和總結 ，同時還可以畫出 時序圖和類圖 ，這樣對閱讀源碼有很大的幫助，可以很清楚地知道類之間的調用關系和依賴關系，也方便以後回顧，重新閱讀。

在這里推薦大家一個 IDEA 插件 SequenceDiagram，可以根據源碼生成調用時序圖，便於閱讀源碼。

剛開始閱讀源碼，不建議直接看框架源碼，可以先從 jdk 源碼看起：

jdk 源碼也是非常龐大的，可以分模塊來閱讀，下面是建議的閱讀順序：

其他包下的代碼也可以做下了解，JDK源碼閱讀筆記：https://github.com/wupeixuan/JDKSourceCode1.8

再有了一定的源碼閱讀經驗後，可以再去學習 Spring、Spring Boot、Dubbo、Spring Cloud 等框架的源碼。

主要介紹了為什麼讀源碼以及如何讀源碼，供大家參考，每個人都有適合自己的閱讀源碼的方式，希望可以在學習中去摸索出一套屬於自己的方式。

閱讀源碼不是一蹴而就的，這是持久戰，只要你能夠堅持下來，肯定受益匪淺。閱讀源碼的過程比較枯燥，可以在社群里一起討論學習，這樣可能效率更高些。

沒看過源代碼，都不好意思出來說了，最近剛好在看一些，來說一個。

先看一下這個庫是做什麼用的，然後提供了哪些功能。

一般會看下項目最新的情況，然後沒有關閉的issue，看下wiki，大家在討論什麼。

clone 一份到本地，然後先看下目錄結構，然後根據文檔看幾個簡單的組件的時候，一邊看掘金上的分析，一邊自己看下實現。

e le

餓了么這個框架代碼結構還是很清楚的，基本上每個組件都是分開的，所以你只要看其他的一個文件夾就行。然後一些工具的都在src文件夾。

要學會看issue，一般開源的項目都有人會來提建議，有些是bug，有些是功能，你可以看看自己是否有能力去解決，如果可以的話，你可以去fork代碼，然後自己修改，再提pr。

我最近恰好找摸索出一個梳理遺留系統架構的技巧：自底向上 找到一個典型的切面 沿著調用和回調的路徑 在代碼中添加結構化注釋（比如eclipse中加//TAG 流程A1.1 甲->>乙），這樣便得到了一個code地圖，並且在tasks視圖中看起來很直觀（看起來跟書的目錄一樣）可快速跳轉。將目錄到有道雲筆記的markdown序列圖中 就自動生成了一個序列圖。

我覺得這基本上就是可縮放的可視化架構地圖了，對維護一個比較亂和龐大的遺留系統非常有幫助，定位代碼 修改維護都方便多了。

1、需要過硬的基礎知識，這個前提。不然基本語法、常用的模式都不曉得怎麼讀。

2、多參考 歷史 版本和更新變化，好的源碼都是反復迭代出來的精華，開始就讀精華是很不明智的，所以看看版本更新說明，版本的 歷史 演變。就想人一樣是怎樣進化過來的。

3、參考別人閱讀注釋，想必在你讀源碼之前也有人讀過了源碼，並且總結，注釋。和分享原理，可供你參考，畢竟每個人讀一篇文章，理解的東西是有差異化的。

4、直接買書，有些作品直接出書就是源碼精解

5、找個大神給你慢慢分析，這個最快。娓娓道來，直接面授比啥都強。缺點是，你容易跟著他的思維走下去。

我覺得閱讀代碼就不應該高效，而應該像看小說一樣，看的過程就像是在和作者交流，有趣才是看代碼的動力。

畫圖，看數據走向，邏輯走向

先弄清楚這些代碼實現了哪些功能，然後從主線開始往下看，好的代碼光看變數和介面名稱就能明白是什麼意思？扒出源碼實現的整體框架邏輯，然後再對自己感興趣的模塊進行剖析，還是從整體把握，細節深入，慢慢地整個框架就被豐滿了。

接下來是思考為什麼要如此設計，這樣設計的好處是什麼？如果是你來做應該怎麼設計，把你覺得源碼缺點的地方進行仔細研究，了解裡面是否包含自己不清楚的細節，避免遺漏。

接下來就是根據代碼改造或者是調試錯誤，對於源碼中遇到的不理解的地方一定要弄明白，有的確實是畫蛇添足，有的有獨特的作用。

多多學習，對每一種主流框架銘記於心，對主流設計模式了如指掌，萬變不離其宗，源碼看多了，跟看一個電視機遙控器的操作說明一樣。

1、一邊閱讀代碼一邊寫注釋。這是我用過的最好的方法，對代碼理解得更深入，看一些重要代碼或者特別難懂的代碼時挺有用。更何況，注釋也是一種文檔嘛。

2、一邊閱讀代碼一邊繪制UML。這個方法適用於類之間的關系較復雜和調用層次較深的情況，我一般都是先繪制順序圖，然後為順序圖中的類繪制關系圖。

3、通過Debug來跟蹤程序的主要執行過程，這樣就可以分清主次了，閱讀的時候更有針對性。

4、類的快速閱讀。先弄清楚它在繼承鏈中的位置，看看它的內部狀態，也就是成員變數，一般來說，類的對外介面都是對成員變數的訪問、加工、代理等，然後看看它的對外介面，也就是公有成員函數，識別核心的一個或多個函數，這時候你應該可以大概了解這個類的職責或作用了。可能這個類是某個設計模式中的一個組成部分，所以，設計模式的掌握對代碼的快速閱讀也是很有幫助的。

5、帶著問題去閱讀。比如想了解android中的消息機制，那麼看看Looper、Handler、MessegeQueue這幾個類就可以了，其他的不要去看，要不然就跑題了。

下面列幾個閱讀源碼時所處的情景，在特定場景下用哪些方法： 不太熟悉業務邏輯，還不是很清楚它是幹啥的，可以用3、5。 代碼量很大，有幾十萬行，甚至百萬行，可以用2、3、5。 你無法看見程序的運行過程，比如沒有用戶界面，也有可能是無法運行的，可以用3、5。 設計復雜，用了大量的設計模式，調用鏈很深，可以用1、2、3、4、5。 時間有限，沒有那麼多時間讓你看源碼，可以用3、5。

畫出邏輯流程圖，先了解整體流程，再詳解具體函數

Ⅲ Android面試：位元組飛書5輪面試Android Framework層的源碼就問了4輪！

說起位元組跳動的這次面試經歷，真的是現在都讓我感覺背脊發涼，簡直被面試官折磨的太難受了。雖然已經工作了三年，但是也只是純粹的在寫業務，對底層並沒有一個很深的認識，這次面試經歷直接的讓我感受到我和那些一線大廠開發之間的差距，說句實話，是真的很難受。

也不多說什麼了吧，我們還是來回顧一下我在位元組跳動的這次面試經歷。 一共是面了5輪，至於為什麼面了5輪的原因，可能是面試官還是想試試我的技術水平吧 。

雖然說最終還是沒能拿到offer，但是這次的面試經歷讓我更加直觀的了解了我和大廠Android開發之間的差距，算是收益頗豐吧 。

總體來講，一面還是答得不錯的，或許是面試官覺得小瞧了我，接下來的四輪面試我彷彿遭到了嚴打

最後嘮叨幾句，希望各位沒拿到offer的真的不要灰心，可能你之前所有的失敗都是你成功的墊腳石，我面掛的時候也曾經自閉過，但更多的是反思，如何調整自己的復習計劃。在復習的時候一定要有自己的強項，能把這個知識點理解的很透徹並且把相關的知識點拓展出去。另一方面就是讓面試官看到你對這個崗位的熱情，能夠自發性地去學習與崗位相關的東西，下面給大家分享一份我珍藏的《2022最新Android中高級面試題合集》質量非常搞，希望能對你有幫助！

內容概要 ：包括 Handler、Activity相關、Fragment、service、布局優化、AsyncTask相關、Android 事件分發機制、 Binder、Android 高級必備 ：AMS,WMS,PMS、Glide、 Android 組件化與插件化等面試題和技術棧！內容特點：條理清晰，含圖像化表示更加易懂。

Android Framework 開發雖然比較偏底層，圈子窄，但是能掌握一些原理的東西，可以觸類旁通，往應用層發展也可以。目前大公司的app開發都要基於模塊化、層次化、組件化、控制項化的思路來設計架構，而這一切的基礎都建立在Android Framework系統框架底層原理實現之上。

Ⅳ 面試必問的epoll技術，從內核源碼出發徹底搞懂epoll

epoll是linux中IO多路復用的一種機制，I/O多路復用就是通過一種機制，一個進程可以監視多個描述符，一旦某個描述符就緒（一般是讀就緒或者寫就緒），能夠通知程序進行相應的讀寫操作。當然linux中IO多路復用不僅僅是epoll，其他多路復用機制還有select、poll，但是接下來介紹epoll的內核實現。

events可以是以下幾個宏的集合：

epoll相比select/poll的優勢 ：

epoll相關的內核代碼在fs/eventpoll.c文件中，下面分別分析epoll_create、epoll_ctl和epoll_wait三個函數在內核中的實現，分析所用linux內核源碼為4.1.2版本。

epoll_create用於創建一個epoll的句柄，其在內核的系統實現如下：

sys_epoll_create:

可見，我們在調用epoll_create時，傳入的size參數，僅僅是用來判斷是否小於等於0，之後再也沒有其他用處。
整個函數就3行代碼，真正的工作還是放在sys_epoll_create1函數中。

sys_epoll_create -> sys_epoll_create1:

sys_epoll_create1 函數流程如下：

sys_epoll_create -> sys_epoll_create1 -> ep_alloc:

sys_epoll_create -> sys_epoll_create1 -> ep_alloc -> get_unused_fd_flags:

linux內核中，current是個宏，返回的是一個task_struct結構（我們稱之為進程描述符）的變數，表示的是當前進程，進程打開的文件資源保存在進程描述符的files成員裡面，所以current->files返回的當前進程打開的文件資源。rlimit(RLIMIT_NOFILE) 函數獲取的是當前進程可以打開的最大文件描述符數，這個值可以設置，默認是1024。

相關視頻推薦：

支撐億級io的底層基石 epoll實戰揭秘

網路原理tcp/udp，網路編程epoll/reactor，面試中正經「八股文」

學習地址：C/C++Linux伺服器開發/後台架構師【零聲教育】-學習視頻教程-騰訊課堂

需要更多C/C++ Linux伺服器架構師學習資料加群 812855908 獲取（資料包括C/C++，Linux，golang技術，Nginx，ZeroMQ，MySQL，Redis，fastdfs，MongoDB，ZK，流媒體，CDN，P2P，K8S，Docker，TCP/IP，協程，DPDK，ffmpeg等），免費分享

__alloc_fd的工作是為進程在[start,end)之間(備註：這里start為0， end為進程可以打開的最大文件描述符數)分配一個可用的文件描述符,這里就不繼續深入下去了，代碼如下：

sys_epoll_create -> sys_epoll_create1 -> ep_alloc -> get_unused_fd_flags -> __alloc_fd:

然後，epoll_create1會調用anon_inode_getfile，創建一個file結構，如下：

sys_epoll_create -> sys_epoll_create1 -> anon_inode_getfile:

anon_inode_getfile函數中首先會alloc一個file結構和一個dentry結構，然後將該file結構與一個匿名inode節點anon_inode_inode掛鉤在一起，這里要注意的是，在調用anon_inode_getfile函數申請file結構時，傳入了前面申請的eventpoll結構的ep變數，申請的file->private_data會指向這個ep變數，同時，在anon_inode_getfile函數返回來後，ep->file會指向該函數申請的file結構變數。

簡要說一下file/dentry/inode，當進程打開一個文件時，內核就會為該進程分配一個file結構，表示打開的文件在進程的上下文，然後應用程序會通過一個int類型的文件描述符來訪問這個結構，實際上內核的進程裡面維護一個file結構的數組，而文件描述符就是相應的file結構在數組中的下標。

dentry結構（稱之為「目錄項」）記錄著文件的各種屬性，比如文件名、訪問許可權等，每個文件都只有一個dentry結構，然後一個進程可以多次打開一個文件，多個進程也可以打開同一個文件，這些情況，內核都會申請多個file結構，建立多個文件上下文。但是，對同一個文件來說，無論打開多少次，內核只會為該文件分配一個dentry。所以，file結構與dentry結構的關系是多對一的。

同時，每個文件除了有一個dentry目錄項結構外，還有一個索引節點inode結構，裡面記錄文件在存儲介質上的位置和分布等信息，每個文件在內核中只分配一個inode。 dentry與inode描述的目標是不同的，一個文件可能會有好幾個文件名（比如鏈接文件），通過不同文件名訪問同一個文件的許可權也可能不同。dentry文件所代表的是邏輯意義上的文件，記錄的是其邏輯上的屬性，而inode結構所代表的是其物理意義上的文件，記錄的是其物理上的屬性。dentry與inode結構的關系是多對一的關系。

sys_epoll_create -> sys_epoll_create1 -> fd_install:

總結epoll_create函數所做的事：調用epoll_create後，在內核中分配一個eventpoll結構和代表epoll文件的file結構，並且將這兩個結構關聯在一塊，同時，返回一個也與file結構相關聯的epoll文件描述符fd。當應用程序操作epoll時，需要傳入一個epoll文件描述符fd，內核根據這個fd，找到epoll的file結構，然後通過file，獲取之前epoll_create申請eventpoll結構變數，epoll相關的重要信息都存儲在這個結構裡面。接下來，所有epoll介面函數的操作，都是在eventpoll結構變數上進行的。

所以，epoll_create的作用就是為進程在內核中建立一個從epoll文件描述符到eventpoll結構變數的通道。

epoll_ctl介面的作用是添加/修改/刪除文件的監聽事件，內核代碼如下：

sys_epoll_ctl:

根據前面對epoll_ctl介面的介紹，op是對epoll操作的動作（添加/修改/刪除事件），ep_op_has_event(op)判斷是否不是刪除操作，如果op != EPOLL_CTL_DEL為true，則需要調用_from_user函數將用戶空間傳過來的event事件拷貝到內核的epds變數中。因為，只有刪除操作，內核不需要使用進程傳入的event事件。

接著連續調用兩次fdget分別獲取epoll文件和被監聽文件（以下稱為目標文件）的file結構變數（備註：該函數返回fd結構變數，fd結構包含file結構）。

接下來就是對參數的一些檢查，出現如下情況，就可以認為傳入的參數有問題，直接返回出錯：

當然下面還有一些關於操作動作如果是添加操作的判斷，這里不做解釋，比較簡單，自行閱讀。

在ep裡面，維護著一個紅黑樹，每次添加註冊事件時，都會申請一個epitem結構的變數表示事件的監聽項，然後插入ep的紅黑樹裡面。在epoll_ctl裡面，會調用ep_find函數從ep的紅黑樹裡面查找目標文件表示的監聽項，返回的監聽項可能為空。

接下來switch這塊區域的代碼就是整個epoll_ctl函數的核心，對op進行switch出來的有添加(EPOLL_CTL_ADD)、刪除(EPOLL_CTL_DEL)和修改(EPOLL_CTL_MOD)三種情況，這里我以添加為例講解，其他兩種情況類似，知道了如何添加監聽事件，其他刪除和修改監聽事件都可以舉一反三。

為目標文件添加監控事件時，首先要保證當前ep裡面還沒有對該目標文件進行監聽，如果存在(epi不為空)，就返回-EEXIST錯誤。否則說明參數正常，然後先默認設置對目標文件的POLLERR和POLLHUP監聽事件，然後調用ep_insert函數，將對目標文件的監聽事件插入到ep維護的紅黑樹裡面：

sys_epoll_ctl -> ep_insert:

前面說過，對目標文件的監聽是由一個epitem結構的監聽項變數維護的，所以在ep_insert函數裡面，首先調用kmem_cache_alloc函數，從slab分配器裡面分配一個epitem結構監聽項，然後對該結構進行初始化，這里也沒有什麼好說的。我們接下來看ep_item_poll這個函數調用：

sys_epoll_ctl -> ep_insert -> ep_item_poll:

ep_item_poll函數裡面，調用目標文件的poll函數，這個函數針對不同的目標文件而指向不同的函數，如果目標文件為套接字的話，這個poll就指向sock_poll，而如果目標文件為tcp套接字來說，這個poll就是tcp_poll函數。雖然poll指向的函數可能會不同，但是其作用都是一樣的，就是獲取目標文件當前產生的事件位，並且將監聽項綁定到目標文件的poll鉤子裡面（最重要的是注冊ep_ptable_queue_proc這個poll callback回調函數），這步操作完成後，以後目標文件產生事件就會調用ep_ptable_queue_proc回調函數。

接下來，調用list_add_tail_rcu將當前監聽項添加到目標文件的f_ep_links鏈表裡面，該鏈表是目標文件的epoll鉤子鏈表，所有對該目標文件進行監聽的監聽項都會加入到該鏈表裡面。

然後就是調用ep_rbtree_insert，將epi監聽項添加到ep維護的紅黑樹裡面,這里不做解釋，代碼如下：

sys_epoll_ctl -> ep_insert -> ep_rbtree_insert:

前面提到，ep_insert有調用ep_item_poll去獲取目標文件產生的事件位，在調用epoll_ctl前這段時間，可能會產生相關進程需要監聽的事件，如果有監聽的事件產生，(revents & event->events 為 true)，並且目標文件相關的監聽項沒有鏈接到ep的准備鏈表rdlist裡面的話，就將該監聽項添加到ep的rdlist准備鏈表裡面，rdlist鏈接的是該epoll描述符監聽的所有已經就緒的目標文件的監聽項。並且，如果有任務在等待產生事件時，就調用wake_up_locked函數喚醒所有正在等待的任務，處理相應的事件。當進程調用epoll_wait時，該進程就出現在ep的wq等待隊列裡面。接下來講解epoll_wait函數。

總結epoll_ctl函數：該函數根據監聽的事件，為目標文件申請一個監聽項，並將該監聽項掛人到eventpoll結構的紅黑樹裡面。

epoll_wait等待事件的產生，內核代碼如下：

sys_epoll_wait:

首先是對進程傳進來的一些參數的檢查：

參數全部檢查合格後，接下來就調用ep_poll函數進行真正的處理：

sys_epoll_wait -> ep_poll:

ep_poll中首先是對等待時間的處理，timeout超時時間以ms為單位，timeout大於0，說明等待timeout時間後超時，如果timeout等於0，函數不阻塞，直接返回，小於0的情況，是永久阻塞，直到有事件產生才返回。

當沒有事件產生時（(!ep_events_available(ep))為true）,調用__add_wait_queue_exclusive函數將當前進程加入到ep->wq等待隊列裡面，然後在一個無限for循環裡面，首先調用set_current_state(TASK_INTERRUPTIBLE)，將當前進程設置為可中斷的睡眠狀態，然後當前進程就讓出cpu，進入睡眠，直到有其他進程調用wake_up或者有中斷信號進來喚醒本進程，它才會去執行接下來的代碼。

如果進程被喚醒後，首先檢查是否有事件產生，或者是否出現超時還是被其他信號喚醒的。如果出現這些情況，就跳出循環，將當前進程從ep->wp的等待隊列裡面移除，並且將當前進程設置為TASK_RUNNING就緒狀態。

如果真的有事件產生，就調用ep_send_events函數，將events事件轉移到用戶空間裡面。

sys_epoll_wait -> ep_poll -> ep_send_events:

ep_send_events沒有什麼工作，真正的工作是在ep_scan_ready_list函數裡面：

sys_epoll_wait -> ep_poll -> ep_send_events -> ep_scan_ready_list:

ep_scan_ready_list首先將ep就緒鏈表裡面的數據鏈接到一個全局的txlist裡面，然後清空ep的就緒鏈表，同時還將ep的ovflist鏈表設置為NULL，ovflist是用單鏈表，是一個接受就緒事件的備份鏈表，當內核進程將事件從內核拷貝到用戶空間時，這段時間目標文件可能會產生新的事件，這個時候，就需要將新的時間鏈入到ovlist裡面。

僅接著，調用sproc回調函數(這里將調用ep_send_events_proc函數)將事件數據從內核拷貝到用戶空間。

sys_epoll_wait -> ep_poll -> ep_send_events -> ep_scan_ready_list -> ep_send_events_proc:

ep_send_events_proc回調函數循環獲取監聽項的事件數據，對每個監聽項，調用ep_item_poll獲取監聽到的目標文件的事件，如果獲取到事件，就調用__put_user函數將數據拷貝到用戶空間。

回到ep_scan_ready_list函數，上面說到，在sproc回調函數執行期間，目標文件可能會產生新的事件鏈入ovlist鏈表裡面，所以，在回調結束後，需要重新將ovlist鏈表裡面的事件添加到rdllist就緒事件鏈表裡面。

同時在最後，如果rdlist不為空（表示是否有就緒事件），並且由進程等待該事件，就調用wake_up_locked再一次喚醒內核進程處理事件的到達（流程跟前面一樣，也就是將事件拷貝到用戶空間）。

到這，epoll_wait的流程是結束了，但是有一個問題，就是前面提到的進程調用epoll_wait後會睡眠，但是這個進程什麼時候被喚醒呢？在調用epoll_ctl為目標文件注冊監聽項時，對目標文件的監聽項注冊一個ep_ptable_queue_proc回調函數，ep_ptable_queue_proc回調函數將進程添加到目標文件的wakeup鏈表裡面，並且注冊ep_poll_callbak回調，當目標文件產生事件時，ep_poll_callbak回調就去喚醒等待隊列裡面的進程。

總結一下epoll該函數： epoll_wait函數會使調用它的進程進入睡眠（timeout為0時除外），如果有監聽的事件產生，該進程就被喚醒，同時將事件從內核裡面拷貝到用戶空間返回給該進程。

Ⅳ 面試中的網紅Vue源碼解析之虛擬DOM，你知多少呢深入解讀diff演算法

眾所周知，在前端的面試中，面試官非常愛考dom和diff演算法。比如，可能會出現在以下場景

滴滴滴，面試官發來一個面試邀請。接受邀請📞

我們都知道， key 的作用在前端的面試是一道很普遍的題目，但是呢，很多時候我們都只浮於知識的表面，而沒有去深挖其原理所在，這個時候我們的競爭力就在這被拉下了。所以呢，深入學習原理對於提升自身的核心競爭力是一個必不可少的過程。

在接下來的這篇文章中，我們將講解面試中很愛考的虛擬DOM以及其背後的diff演算法。 請認真閱讀本文～文末有學習資源免費共享！！！

虛擬DOM是用javaScript對象描述DOM的層次結構。DOM中的一切屬性都在虛擬DOM中有對應的屬性。本質上是JS 和 DOM 之間的一個映射緩存。

要點：虛擬 DOM 是 JS 對象；虛擬 DOM 是對真實 DOM 的描述。

diff發生在虛擬DOM上。diff演算法是在新虛擬DOM和老虛擬DOM進行diff（精細化比對），實現最小量更新，最後反映到真正的DOM上。

我們前面知道diff演算法發生在虛擬DOM上，而虛擬DOM是如何實現的呢？實際上虛擬DOM是有一個個虛擬節點組成。

h函數用來產生虛擬節點（vnode）。虛擬節點有如下的屬性：
1）sel： 標簽類型，例如 p、div；
2）data： 標簽上的數據，例如 style、class、data-*；
3）children ：子節點；
4） text： 文本內容；
5）elm：虛擬節點綁定的真實 DOM 節點；

通過h函數的嵌套，從而得到虛擬DOM樹。

我們編寫了一個低配版的h函數，必須傳入3個參數，重載較弱。

形態1：h('div', {}, '文字')
形態2：h('div', {}, [])
形態3：h('div', {}, h())

首先定義vnode節點，實際上就是把傳入的參數合成對象返回。

[圖片上傳失敗...(image-7a9966-1624019394657)]
然後編寫h函數，根據第三個參數的不同進行不同的響應。

當我們進行比較的過程中，我們採用的4種命中查找策略：
1）新前與舊前：命中則指針同時往後移動。
2）新後與舊後：命中則指針同時往前移動。
3）新後與舊前：命中則涉及節點移動，那麼新後指向的節點，移到 舊後之後 。
4）新前與舊後：命中則涉及節點移動，那麼新前指向的節點，移到 舊前之前 。

命中上述4種一種就不在命中判斷了，如果沒有命中，就需要循環來尋找，移動到舊前之前。直到while(新前<=新後&&舊前<=就後)不成立則完成。

如果是新節點先循環完畢，如果老節點中還有剩餘節點(舊前和舊後指針中間的節點)，說明他們是要被刪除的節點。

如果是舊節點先循環完畢，說明新節點中有要插入的節點。

1.什麼是Virtual DOM 和Snabbdom
2.手寫底層源碼h函數
3.感受Vue核心演算法之diff演算法
4.snabbdom之核心h函數的工作原理

1、零基礎入門或者有一定基礎的同學、大中院校學生
2、在職從事相關工作1-2年以及打算轉行前端的朋友
3、對前端開發有興趣人群

Ⅵ 如何查看spring源碼

1.准備工作：在官網上下載了Spring源代碼之後，導入Eclipse，以方便查詢。
2.打開我們使用Spring的項目工程，找到Web.xml這個網站系統配置文件，在其中找到Spring的初始化信息：

<listener>
<listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
</listener>

由配置信息可知，我們開始的入口就這里ContextLoaderListener這個監聽器。
在源代碼中我們找到了這個類，它的定義是：
public class ContextLoaderListener extends ContextLoader
implements ServletContextListener {
…
/**
* Initialize the root web application context.
*/
public void contextInitialized(ServletContextEvent event) {
this.contextLoader = createContextLoader();
if (this.contextLoader == null) {
this.contextLoader = this;
}
this.contextLoader.initWebApplicationContext(event.getServletContext());
}
...
}

該類繼續了ContextLoader並實現了監聽器，關於Spring的信息載入配置、初始化便是從這里開始了，具體其他閱讀另外寫文章來深入了解。
二、關於IOC和AOP
關於Spring IOC 網上很多相關的文章可以閱讀，那麼我們從中了解到的知識點是什麼？
1）IOC容器和AOP切面依賴注入是Spring是核心。
IOC容器為開發者管理對象之間的依賴關系提供了便利和基礎服務，其中Bean工廠（BeanFactory）和上下文（ApplicationContext）就是IOC的表現形式。BeanFactory是個介面類，只是對容器提供的最基本服務提供了定義，而DefaultListTableBeanFactory、XmlBeanFactory、ApplicationContext等都是具體的實現。
介面：

public interface BeanFactory {
//這里是對工廠Bean的轉義定義，因為如果使用bean的名字檢索IOC容器得到的對象是工廠Bean生成的對象，
//如果需要得到工廠Bean本身，需要使用轉義的名字來向IOC容器檢索
String FACTORY_BEAN_PREFIX = "&";
//這里根據bean的名字，在IOC容器中得到bean實例，這個IOC容器就象一個大的抽象工廠，用戶可以根據名字得到需要的bean
//在Spring中，Bean和普通的JAVA對象不同在於：
//Bean已經包含了我們在Bean定義信息中的依賴關系的處理，同時Bean是已經被放到IOC容器中進行管理了，有它自己的生命周期
Object getBean(String name) throws BeansException;
//這里根據bean的名字和Class類型來得到bean實例，和上面的方法不同在於它會拋出異常：如果根名字取得的bean實例的Class類型和需要的不同的話。
Object getBean(String name, Class requiredType) throws BeansException;
//這里提供對bean的檢索，看看是否在IOC容器有這個名字的bean
boolean containsBean(String name);
//這里根據bean名字得到bean實例，並同時判斷這個bean是不是單件，在配置的時候，默認的Bean被配置成單件形式,如果不需要單件形式，需要用戶在Bean定義信息中標注出來，這樣IOC容器在每次接受到用戶的getBean要求的時候，會生成一個新的Bean返回給客戶使用 - 這就是Prototype形式
boolean isSingleton(String name) throws NoSuchBeanDefinitionException;
//這里對得到bean實例的Class類型
Class getType(String name) throws NoSuchBeanDefinitionException;
//這里得到bean的別名，如果根據別名檢索，那麼其原名也會被檢索出來
String[] getAliases(String name);
}

實現：
XmlBeanFactory的實現是這樣的：
public class XmlBeanFactory extends DefaultListableBeanFactory {
//這里為容器定義了一個默認使用的bean定義讀取器，在Spring的使用中，Bean定義信息的讀取是容器初始化的一部分，但是在實現上是和容器的注冊以及依賴的注入是分開的，這樣可以使用靈活的 bean定義讀取機制。
private final XmlBeanDefinitionReader reader = new XmlBeanDefinitionReader(this);
//這里需要一個Resource類型的Bean定義信息，實際上的定位過程是由Resource的構建過程來完成的。
public XmlBeanFactory(Resource resource) throws BeansException {
this(resource, null);
}
//在初始化函數中使用讀取器來對資源進行讀取，得到bean定義信息。這里完成整個IOC容器對Bean定義信息的載入和注冊過程
public XmlBeanFactory(Resource resource, BeanFactory parentBeanFactory) throws
BeansException {
super(parentBeanFactory);
this.reader.loadBeanDefinitions(resource);
}

Ⅶ 在面試PHP工程師時會被問哪些問題

面試官在面試求職的PHP工程師時所問的問題千奇百怪，但由於他們需要的是一個PHP工程師，所以他們提問的問題一般不會偏離以下幾個角度：
技術線(偏深度)：
1. 基礎知識，比如數據結構，多線程，I/O，Http協議等。
2. 語言深度，比如PHP的運行機制，性能優化，APC(以及其原理等)。
3. 源碼閱讀，比如看過哪些框架，其中的機制是怎麼樣的，往細了問。
4. 知識寬度，靜態語言，比如C、Java等，我始終覺得只會一門語言不是什麼好事情。
5. 項目經驗，做過什麼，是否復雜，負責什麼，做了什麼。
業務線(偏能力)：
1. 業務能力，也就是之前做過的項目(擔任的角色，負責的部分)。
2. 溝通能力，這一點能從溝通中就看出來。
3. 主動性，之前主動推動的事物等等，哪怕是一個小的點也可以。
4. 抗壓能力，之前做過的項目中去挖掘細節。
5. 技術寬度，了解不一定要深入，一般會問一些比較泛的，比如多語言，Linux操作，HTTP協議等。

Ⅷ 面試時項目介紹需要帶源碼嗎

如果你面試的是程序員，需要帶上源碼的。

在面試的時候能在源碼上和面試官對話，那相當於增加了工作經驗，那通過的機會還是很高的。

自學或者是應屆生，缺乏實戰經驗。那麼就要在框架的源碼上下功夫了，核心原理等內容。比如Spring、Redis等這種知名框架，在面試的時候能在源碼上和面試官對話，那通過的機會還是很高的。

只要問項目中的核心模塊業務流程，在其中挑一些技術點問如何實現的就能大概判斷是否真的做過項目了。

如果你是在校學生，還可以參加一些編程社團，或者是參加比賽，另外抓住實習機會，高效利用實習去學習。

填寫簡歷技巧：

哪怕大家以Java只過一個五子棋游戲，你也可以寫成，採用博弈搜索的演算法並且使用а-β剪枝減少演算法的復雜度。

使用大量Java的數據結構並且閱讀源碼，增加了對JDK的理解。

寫項目經驗需要注意的是重點不在於介紹項目，重點是我在項目中做了什麼。為大家梳理STAR原則描述我們的項目。

Ⅸ java面試常問問題

面試的心態很重要
如果可以的話，**建議以一個和面試官交流的心態去面試**。而且普通面試大部分問答都是有一些套路的。
面試的過程中，肯定會有答不上來的時候，這個時候，坦然的說不知道，就行了;或者再說出來點你知道的，例如思路。**重點** 答不出來的時候一定要淡定，你和面試官是平等的！反過來讓你問面試官，他也肯定有答不上來的！
java基礎必考，線程、集合（list、map、linklist、array，什麼無key遍歷map啊，鏈表倒置啊，這幾個東西的數據結構和插入查詢特性啊，線程創建方式和同步啊）相關必問。最好能說清楚常見的設計模式、要能手寫一個單列模式。
**框架** ：主要說你熟練的，會問一些，但是一般都比較基礎，只要找;除非，你說你看過這個框架的源碼，剛好面試官也比較了解。
**資料庫** 可能會問你都用過什麼，最好有一個用的熟練的，沒事兒去配置一下主從資料庫費不了多少時間，然後就好答這個問題了。sql，一般是必考的，分組查詢，排序，連結查詢。很可能會讓你手寫sql語句。我還遇到了一個讓你查前多少行的，以及不用框架實現分頁查詢的。
**源碼** 其實源碼沒有那麼的高大上，即使你說你熟練源碼，剛好面試官也熟悉，他最多也只能問問你這框架從啟動到配置完成，從接收請求，到處理完成再返回的 ** 流程**然後再問一下，你從這些源碼里學到了什麼？這個問題，建議去網路(我都是臨面試了才去網路這些有套路的問題)。
**前端** 你要是像我一樣，囂張到簡歷寫的連前端你都會不少，（不過現在確實很多公司的招聘後端的要求也要會一些前端）那就很可能要多面你一會兒了，再問問你簡歷里寫的用過的框架，手寫幾串js的代碼啊，還有可能會通過js代碼考察下對DOM概念的理解。正則表達式也是有可能的。
一般演算法和數據結構是必考的，操作系統也經常被問。如果是校招的話，筆試中還會有一些排列組合啊，語文表達啊，思維拓展啊（你咋不去高中招？高中剛畢業的時候比較符合需求！！），其次，筆試過了還會有好幾輪面試，不管你說你扣過源碼，還是跟過還可以的項目，都會被往深里問，再往深里問，再再往深里問！
如果你對於學習Java有任何問題（學習方法，學習效率，如何就業），可以隨時來咨詢我，這是我的Java交流學習扣扣qun：前面是六一五，中間是七四一，後面是六三六。 多多交流問題，互幫互助，qun里有不錯的學習教程和開發工具。

Ⅹ 請問下 android游戲開發面試 對方公司要我帶源碼過去 請問這正常嗎

您好，如果您所指的是您的個人作品的源碼，您可以自己考慮下是否有保密的必要性。如果是您之前某個公司或者其他的程序源碼，您需要徵求源碼法定擁有者的同意才行。至於公司的這個要求，完全是可以理解的，正常的，因為考察您所撰寫的源碼就能最直接的了解您的編程能力和編程習慣，能方便他們的考核。