【建議收藏】2020年中高級Android大廠面試祕籍，爲你保駕護航金三銀四，直通大廠

時間  2020-07-10 標籤 建議收藏 2020年 中高級 android 大廠 面試 祕籍 爲你 保駕 護航 直通

前言

成爲一名優秀的Android開發，須要一份完備的知識體系，在這裏，讓咱們一塊兒成長爲本身所想的那樣~。

🔥 A awesome android expert interview questions and answers（continuous updating ...）css

從幾十份頂級面試倉庫和300多篇高質量面經中總結出一份全面成體系化的Android高級面試題集。

隨着Android技術發展的成熟，Kotlin、大前端技術Flutter、RN、小程序等一會兒就進入了咱們的視野內，同時，Android自身的技術棧也正在不斷擴展，好比在國外大熱的Jetpack。所以，Android開發者們愈來愈焦慮，愈來愈迷茫，每一個人的時間和精力是有限的，咱們到底應該學什麼纔能有效地提升自身的競爭力呢?其實，首先咱們應該優先深刻學習工做中用到的技術，其次，關注這2年來Android最新的面試題所涉及的知識點，根據自身的實際狀況有選擇地進行鍼對性的學習和提高。只有這樣，自身才不會被所謂的 互聯網寒冬 嚇倒。Awesome-Android-Interview蒐集了國內一線及二線互聯網公司最常出現的面試題，很是全面，但願能讓你們比較系統的反覆學習，以快速提高本身。這篇文章筆者花費了很是大的精力和時間，但願獲得你們的支持。Android面試中常涉及的問題有以下幾方面：html

  • 一、計算機基礎：TCP/IP, HTTP/HTTPS, Socket、（Linux）操做系統、數據庫相關。
  • 二、Java基礎：面向對象、反射、泛型、集合類庫相關。
  • 三、Java併發：線程/線程池，volatile，悲觀鎖/樂觀鎖等等。
  • 四、Jvm虛擬機：好比執行過程、JMM模型、Java的GC回收原理、類加載器。
  • 五、數據結構和算法：劍指Offer + LeetCode高頻題集。
  • 六、Android基礎：啓動模式、動畫、自定義View。
  • 七、Android進階：性能優化、Binder、AIDL、進程間通訊、AMS/WMS/PMS、事件分發、滑動衝突、View的繪製流程、重要的Android源碼和開源庫分析。
  • 八、Android高新技術：模塊化、組件化、熱更新、插件化實現原理。
  • 九、最後，若是你會其餘的開發方式或語言也會加分很多。好比Flutter、ReactNative、Python、先後端開發。

目錄

2020年中高級Android大廠面試祕籍，爲你保駕護航金三銀四，直通大廠(計算機基礎篇）

2020年中高級Android大廠面試祕籍，爲你保駕護航金三銀四，直通大廠(Java篇）前端

2020年中高級Android大廠面試祕籍，爲你保駕護航金三銀四，直通大廠(Android基礎篇）node

2020年中高級Android大廠面試祕籍，爲你保駕護航金三銀四，直通大廠(Android高級篇上）linux

2020年中高級Android大廠面試祕籍，爲你保駕護航金三銀四，直通大廠(Android高級篇下）android

面試就猶如考試，就像高考衝刺前咱們所作的事，無非就是將每個知識點理解並記憶。要經過面試當然須要必定的技巧，但毫不是靠僞造與吹流弊，經過一段時間沉下心來閉關修煉，等到春暖花開時，即可以出山收割，步入大廠，薪資翻番，豈不美哉？git

注意：每類知識點對應面試題的出現頻率按 ⭐ 的級數共分爲三級，分別爲 ⭐、 ⭐⭐、⭐⭐⭐，若是時間充分，建議至少將 ⭐⭐及以 上的知識點搞懂，若是時間比較緊急，則建議優先將 ⭐⭐⭐ 題目都弄懂。
爲了更好地分類學習，建議跳轉到本項目對應的 Github地址，歡迎Star、Fork、Watch~

最後，借用脈脈上的一副大廠職級薪資對應圖，給你們的機車多加點油，祝開車順利，一帆風順~github

計算機網絡

1、HTTP/HTTPS （⭐⭐⭐）

一、HTTP與HTTPS有什麼區別？

HTTPS是一種經過計算機網絡進行安全通訊的傳輸協議。HTTPS經由HTTP進行通訊，但利用SSL/TLS來加密數據包。HTTPS開發的主要目的，是提供對網站服務器的身份 認證，保護交換數據的隱私與完整性。web

HTPPS和HTTP的概念：面試

HTTPS（全稱：Hypertext Transfer Protocol over Secure Socket Layer），是以安全爲目標的HTTP通道，簡單講是HTTP的安全版。即HTTP下加入SSL層，HTTPS的安全基礎是SSL，所以加密的詳細內容就須要SSL。 它是一個URI scheme（抽象標識符體系），句法類同http:體系。用於安全的HTTP數據傳輸。https:URL代表它使用了HTTP，但HTTPS存在不一樣於HTTP的默認端口及一個加密/身份驗證層（在HTTP與TCP之間）。這個系統的最初研發由網景公司進行，提供了身份驗證與加密通信方法，如今它被普遍用於萬維網上安全敏感的通信，例如交易支付方面。

超文本傳輸協議 (HTTP-Hypertext transfer protocol) 是一種詳細規定了瀏覽器和萬維網服務器之間互相通訊的規則，經過因特網傳送萬維網文檔的數據傳送協議。

https協議須要到ca申請證書，通常免費證書不多，須要交費。http是超文本傳輸協議，信息是明文傳輸，https 則是具備安全性的ssl加密傳輸協議http和https使用的是徹底不一樣的鏈接方式用的端口也不同,前者是80,後者是443。http的鏈接很簡單,是無狀態的HTTPS協議是由SSL+HTTP協議構建的可進行加密傳輸、身份認證的網絡協議 要比http協議安全HTTPS解決的問題：1 . 信任主機的問題. 採用https 的server 必須從CA 申請一個用於證實服務器用途類型的證書. 改證書只有用於對應的server 的時候,客戶度纔信任次主機2 . 防止通信過程當中的數據的泄密和被竄改

以下圖所示，能夠很明顯的看出兩個的區別：

image

注：TLS是SSL的升級替代版，具體發展歷史能夠參考傳輸層安全性協議。

HTTP與HTTPS在寫法上的區別也是前綴的不一樣，客戶端處理的方式也不一樣，具體說來：

若是URL的協議是HTTP，則客戶端會打開一條到服務端端口80（默認）的鏈接，並向其發送老的HTTP請求。
若是URL的協議是HTTPS，則客戶端會打開一條到服務端端口443（默認）的鏈接，而後與服務器握手，以二進制格式與服務器交換一些SSL的安全參數，附上加密的 HTTP請求。
因此你能夠看到，HTTPS比HTTP多了一層與SSL的鏈接，這也就是客戶端與服務端SSL握手的過程，整個過程主要完成如下工做：

交換協議版本號
選擇一個兩端都瞭解的密碼
對兩端的身份進行認證
生成臨時的會話密鑰，以便加密信道。
SSL握手是一個相對比較複雜的過程，更多關於SSL握手的過程細節能夠參考TLS/SSL握手過程

SSL/TSL的常見開源實現是OpenSSL，OpenSSL是一個開放源代碼的軟件庫包，應用程序能夠使用這個包來進行安全通訊，避免竊聽，同時確認另外一端鏈接者的身份。這個包普遍被應用在互聯網的網頁服務器上。 更多源於OpenSSL的技術細節能夠參考OpenSSL。

二、Http1.1和Http1.0及2.0的區別？

HTTP1.0和HTTP1.1的一些區別

HTTP1.0最先在網頁中使用是在1996年，那個時候只是使用一些較爲簡單的網頁上和網絡請求上，而HTTP1.1則在1999年纔開始普遍應用於如今的各大瀏覽器網絡請求中，同時HTTP1.1也是當前使用最爲普遍的HTTP協議。 主要區別主要體如今：

  • 一、緩存處理，在HTTP1.0中主要使用header裏的If-Modified-Since,Expires來作爲緩存判斷的標準，HTTP1.1則引入了更多的緩存控制策略例如Entity tag，If-Unmodified-Since, If-Match, If-None-Match等更多可供選擇的緩存頭來控制緩存策略。
  • 二、帶寬優化及網絡鏈接的使用，HTTP1.0中，存在一些浪費帶寬的現象，例如客戶端只是須要某個對象的一部分，而服務器卻將整個對象送過來了，而且不支持斷點續傳功能，HTTP1.1則在請求頭引入了range頭域，它容許只請求資源的某個部分，即返回碼是206（Partial Content），這樣就方便了開發者自由的選擇以便於充分利用帶寬和鏈接。
  • 三、錯誤通知的管理，在HTTP1.1中新增了24個錯誤狀態響應碼，如409（Conflict）表示請求的資源與資源的當前狀態發生衝突；410（Gone）表示服務器上的某個資源被永久性的刪除。
  • 四、Host頭處理，在HTTP1.0中認爲每臺服務器都綁定一個惟一的IP地址，所以，請求消息中的URL並無傳遞主機名（hostname）。但隨着虛擬主機技術的發展，在一臺物理服務器上能夠存在多個虛擬主機（Multi-homed Web Servers），而且它們共享一個IP地址。HTTP1.1的請求消息和響應消息都應支持Host頭域，且請求消息中若是沒有Host頭域會報告一個錯誤（400 Bad Request）。
  • 五、長鏈接，HTTP 1.1支持長鏈接（PersistentConnection）和請求的流水線（Pipelining）處理，在一個TCP鏈接上能夠傳送多個HTTP請求和響應，減小了創建和關閉鏈接的消耗和延遲，在HTTP1.1中默認開啓Connection： keep-alive，必定程度上彌補了HTTP1.0每次請求都要建立鏈接的缺點。

SPDY

在講Http1.1和Http2.0的區別以前，還須要說下SPDY，它是HTTP1.x的優化方案：

2012年google如一聲驚雷提出了SPDY的方案，優化了HTTP1.X的請求延遲，解決了HTTP1.X的安全性，具體以下：

  • 一、下降延遲，針對HTTP高延遲的問題，SPDY優雅的採起了多路複用（multiplexing）。多路複用經過多個請求stream共享一個tcp鏈接的方式，解決了HOL blocking的問題，下降了延遲同時提升了帶寬的利用率。
  • 二、請求優先級（request prioritization）。多路複用帶來一個新的問題是，在鏈接共享的基礎之上有可能會致使關鍵請求被阻塞。SPDY容許給每一個request設置優先級，這樣重要的請求就會優先獲得響應。好比瀏覽器加載首頁，首頁的html內容應該優先展現，以後纔是各類靜態資源文件，腳本文件等加載，這樣能夠保證用戶能第一時間看到網頁內容。
  • 三、header壓縮。前面提到HTTP1.x的header不少時候都是重複多餘的。選擇合適的壓縮算法能夠減少包的大小和數量。
  • 四、基於HTTPS的加密協議傳輸，大大提升了傳輸數據的可靠性。
  • 五、服務端推送（server push），採用了SPDY的網頁，例如個人網頁有一個sytle.css的請求，在客戶端收到sytle.css數據的同時，服務端會將sytle.js的文件推送給客戶端，當客戶端再次嘗試獲取sytle.js時就能夠直接從緩存中獲取到，不用再發請求了。SPDY構成圖：

image

SPDY位於HTTP之下，TCP和SSL之上，這樣能夠輕鬆兼容老版本的HTTP協議(將HTTP1.x的內容封裝成一種新的frame格式)，同時能夠使用已有的SSL功能。

HTTP2.0和HTTP1.X相比的新特性

  • 新的二進制格式（Binary Format），HTTP1.x的解析是基於文本。基於文本協議的格式解析存在自然缺陷，文本的表現形式有多樣性，要作到健壯性考慮的場景必然不少，二進制則不一樣，只認0和1的組合。基於這種考慮HTTP2.0的協議解析決定採用二進制格式，實現方便且健壯。
  • 多路複用（MultiPlexing），即鏈接共享，即每個request都是是用做鏈接共享機制的。一個request對應一個id，這樣一個鏈接上能夠有多個request，每一個鏈接的request能夠隨機的混雜在一塊兒，接收方能夠根據request的 id將request再歸屬到各自不一樣的服務端請求裏面。
  • header壓縮，如上文中所言，對前面提到過HTTP1.x的header帶有大量信息，並且每次都要重複發送，HTTP2.0使用encoder來減小須要傳輸的header大小，通信雙方各自cache一份header fields表，既避免了重複header的傳輸，又減少了須要傳輸的大小。
  • 服務端推送（server push），同SPDY同樣，HTTP2.0也具備server push功能。

須要更深的理解請點擊這裏

三、Https 請求慢的解決辦法

一、不經過DNS解析，直接訪問IP

二、解決鏈接沒法複用

http/1.0協議頭裏能夠設置Connection:Keep-Alive或者Connection:Close，選擇是否容許在必定時間內複用鏈接（時間可由服務器控制）。可是這對App端的請求成效不大，由於App端的請求比較分散且時間跨度相對較大。

方案1.基於tcp的長鏈接 (主要）
移動端創建一條本身的長連接通道，通道的實現是基於tcp協議。基於tcp的socket編程技術難度相對複雜不少，並且須要本身定製協議。但信息的上報和推送變得更及時，請求量爆發的時間點還能減輕服務器壓力（避免頻繁建立和銷燬鏈接）

方案2.http long-polling
客戶端在初始狀態發送一個polling請求到服務器，服務器並不會立刻返回業務數據，而是等待有新的業務數據產生的時候再返回，因此連接會一直被保持。一但結束當前鏈接，立刻又會發送一個新的polling請求，如此反覆，保證一個鏈接被保持。
存在問題：
1）增長了服務器的壓力
2）網絡環境複雜場景下，須要考慮怎麼重建健康的鏈接通道
3）polling的方式穩定性很差
4）polling的response可能被中間代理cache住
……

方案3.http streaming
和long-polling不一樣的是，streaming方式經過再server response的頭部增長「Transfer Encoding:chuncked」來告訴客戶端後續還有新的數據到來
存在問題：
1）有些代理服務器會等待服務器的response結束以後纔將結果推送給請求客戶端。streaming不會結束response
2）業務數據沒法按照請求分割
……

方案4.web socket
和傳統的tcp socket類似，基於tcp協議，提供雙向的數據通道。它的優點是提供了message的概念，比基於字節流的tcp socket使用更簡單。技術較新，不是全部瀏覽器都提供了支持。

三、解決head of line blocking

它的緣由是隊列的第一個數據包（隊頭）受阻而致使整列數據包受阻

使用http pipelining，確保幾乎在同一時間把request發向了服務器

四、Http的request和response的協議組成

一、Request組成

客戶端發送一個HTTP請求到服務器的請求消息包括如下格式：

請求行（request line）、請求頭部（header）、空行和請求數據四個部分組成。

image

請求行以一個方法符號開頭，以空格分開，後面跟着請求的URI和協議的版本。

Get請求例子

GET /562f25980001b1b106000338.jpg HTTP/1.1
Host    img.mukewang.com
User-Agent  Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.106 Safari/537.36
Accept  image/webp,image/*,*/*;q=0.8
Referer http://www.imooc.com/
Accept-Encoding gzip, deflate, sdch
Accept-Language zh-CN,zh;q=0.8

第一部分：請求行，用來講明請求類型,要訪問的資源以及所使用的HTTP版本.
GET說明請求類型爲GET,[/562f25980001b1b106000338.jpg]爲要訪問的資源，該行的最後一部分說明使用的是HTTP1.1版本。
第二部分：請求頭部，緊接着請求行（即第一行）以後的部分，用來講明服務器要使用的附加信息
從第二行起爲請求頭部，HOST將指出請求的目的地.User-Agent,服務器端和客戶端腳本都能訪問它,它是瀏覽器類型檢測邏輯的重要基礎.該信息由你的瀏覽器來定義,而且在每一個請求中自動發送等等
第三部分：空行，請求頭部後面的空行是必須的
即便第四部分的請求數據爲空，也必須有空行。
第四部分：請求數據也叫主體，能夠添加任意的其餘數據。
這個例子的請求數據爲空。

POST請求例子

POST / HTTP1.1
Host:www.wrox.com
User-Agent:Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022)
Content-Type:application/x-www-form-urlencoded
Content-Length:40
Connection: Keep-Alive

name=Professional%20Ajax&publisher=Wiley

第一部分：請求行，第一行明瞭是post請求，以及http1.1版本。

第二部分：請求頭部，第二行至第六行。

第三部分：空行，第七行的空行。

第四部分：請求數據，第八行。

二、Response組成

通常狀況下，服務器接收並處理客戶端發過來的請求後會返回一個HTTP的響應消息。

HTTP響應也由四個部分組成，分別是：狀態行、消息報頭、空行和響應正文。

image

第一部分：狀態行，由HTTP協議版本號， 狀態碼， 狀態消息 三部分組成。

第一行爲狀態行，（HTTP/1.1）代表HTTP版本爲1.1版本，狀態碼爲200，狀態消息爲（ok）

第二部分：消息報頭，用來講明客戶端要使用的一些附加信息

第二行和第三行爲消息報頭，
Date:生成響應的日期和時間；Content-Type:指定了MIME類型的HTML(text/html),編碼類型是UTF-8

第三部分：空行，消息報頭後面的空行是必須的

第四部分：響應正文，服務器返回給客戶端的文本信息。

空行後面的html部分爲響應正文。

五、談談對http緩存的瞭解。

HTTP的緩存機制也是依賴於請求和響應header裏的參數類實現的，最終響應式從緩存中去，仍是從服務端從新拉取，HTTP的緩存機制的流程以下所示：

image

HTTP的緩存能夠分爲兩種：

強制緩存：須要服務端參與判斷是否繼續使用緩存，當客戶端第一次請求數據是，服務端返回了緩存的過時時間（Expires與Cache-Control），沒有過時就能夠繼續使用緩存，不然則不適用，無需再向服務端詢問。
對比緩存：須要服務端參與判斷是否繼續使用緩存，當客戶端第一次請求數據時，服務端會將緩存標識（Last-Modified/If-Modified-Since與Etag/If-None-Match）與數據一塊兒返回給客戶端，客戶端將二者都備份到緩存中 ，再次請求數據時，客戶端將上次備份的緩存 標識發送給服務端，服務端根據緩存標識進行判斷，若是返回304，則表示通知客戶端能夠繼續使用緩存。
強制緩存優先於對比緩存。

上面提到強制緩存使用的的兩個標識：

Expires：Expires的值爲服務端返回的到期時間，即下一次請求時，請求時間小於服務端返回的到期時間，直接使用緩存數據。到期時間是服務端生成的，客戶端和服務端的時間可能有偏差。
Cache-Control：Expires有個時間校驗的問題，全部HTTP1.1採用Cache-Control替代Expires。
Cache-Control的取值有如下幾種：

private: 客戶端能夠緩存。
public: 客戶端和代理服務器均可緩存。
max-age=xxx: 緩存的內容將在 xxx 秒後失效
no-cache: 須要使用對比緩存來驗證緩存數據。
no-store: 全部內容都不會緩存，強制緩存，對比緩存都不會觸發。
咱們再來看看對比緩存的兩個標識：

Last-Modified/If-Modified-Since

Last-Modified 表示資源上次修改的時間。

當客戶端發送第一次請求時，服務端返回資源上次修改的時間：

Last-Modified: Tue, 12 Jan 2016 09:31:27 GMT

客戶端再次發送，會在header裏攜帶If-Modified-Since。將上次服務端返回的資源時間上傳給服務端。

If-Modified-Since: Tue, 12 Jan 2016 09:31:27 GMT

服務端接收到客戶端發來的資源修改時間，與本身當前的資源修改時間進行對比，若是本身的資源修改時間大於客戶端發來的資源修改時間，則說明資源作過修改， 則返回200表示須要從新請求資源，不然返回304表示資源沒有被修改，能夠繼續使用緩存。

上面是一種時間戳標記資源是否修改的方法，還有一種資源標識碼ETag的方式來標記是否修改，若是標識碼發生改變，則說明資源已經被修改，ETag優先級高於Last-Modified。

Etag/If-None-Match

ETag是資源文件的一種標識碼，當客戶端發送第一次請求時，服務端會返回當前資源的標識碼：

ETag: "5694c7ef-24dc"

客戶端再次發送，會在header裏攜帶上次服務端返回的資源標識碼：

If-None-Match:"5694c7ef-24dc"
服務端接收到客戶端發來的資源標識碼，則會與本身當前的資源嗎進行比較，若是不一樣，則說明資源已經被修改，則返回200，若是相同則說明資源沒有被修改，返回 304，客戶端能夠繼續使用緩存。

六、Http長鏈接。

Http1.0是短鏈接，HTTP1.1默認是長鏈接，也就是默認Connection的值就是keep-alive。可是長鏈接實質是指的TCP鏈接，而不是HTTP鏈接。TCP鏈接是一個雙向的通道，它是能夠保持一段時間不關閉的，所以TCP鏈接纔有真正的長鏈接和短鏈接這一說。

Http1.1爲何要用使用tcp長鏈接？

長鏈接是指的TCP鏈接，也就是說複用的是TCP鏈接。即長鏈接狀況下，多個HTTP請求能夠複用同一個TCP鏈接，這就節省了不少TCP鏈接創建和斷開的消耗。

此外，長鏈接並非永久鏈接的。若是一段時間內（具體的時間長短，是能夠在header當中進行設置的，也就是所謂的超時時間），這個鏈接沒有HTTP請求發出的話，那麼這個長鏈接就會被斷掉。

須要更深的理解請點擊這裏

七、Https加密原理。

加密算法的類型基本上分爲了兩種：

  • 對稱加密，加密用的密鑰和解密用的密鑰是同一個，比較有表明性的就是 AES 加密算法；
  • 非對稱加密，加密用的密鑰稱爲公鑰，解密用的密鑰稱爲私鑰，常用到的 RSA 加密算法就是非對稱加密的；

此外，還有Hash加密算法

HASH算法：MD5, SHA1, SHA256

相比較對稱加密而言，非對稱加密安全性更高，可是加解密耗費的時間更長，速度慢。

想了解更多加密算法請點擊這裏

HTTPS = HTTP + SSL，HTTPS 的加密就是在 SSL 中完成的。

這就要從 CA 證書講起了。CA 證書其實就是數字證書，是由 CA 機構頒發的。至於 CA 機構的權威性，那麼是毋庸置疑的，全部人都是信任它的。CA 證書內通常會包含如下內容：

  • 證書的頒發機構、版本
  • 證書的使用者
  • 證書的公鑰
  • 證書的有效時間
  • 證書的數字簽名 Hash 值和簽名 Hash 算法
  • ...

客戶端如何校驗 CA 證書？

CA 證書中的 Hash 值，實際上是用證書的私鑰進行加密後的值（證書的私鑰不在 CA 證書中）。而後客戶端獲得證書後，利用證書中的公鑰去解密該 Hash 值，獲得 Hash-a ；而後再利用證書內的簽名 Hash 算法去生成一個 Hash-b 。最後比較 Hash-a 和 Hash-b 這兩個的值。若是相等，那麼證實了該證書是對的，服務端是能夠被信任的；若是不相等，那麼就說明該證書是錯誤的，可能被篡改了，瀏覽器會給出相關提示，沒法創建起 HTTPS 鏈接。除此以外，還會校驗 CA 證書的有效時間和域名匹配等。

#### HTTPS 中的 SSL 握手創建過程

假設如今有客戶端 A 和服務器 B ：

  • 一、首先，客戶端 A 訪問服務器 B ，好比咱們用瀏覽器打開一個網頁 www.baidu.com ，這時，瀏覽器就是客戶端 A ，百度的服務器就是服務器 B 了。這時候客戶端 A 會生成一個隨機數1，把隨機數1 、本身支持的 SSL 版本號以及加密算法等這些信息告訴服務器 B 。
  • 二、服務器 B 知道這些信息後，而後確認一下雙方的加密算法，而後服務端也生成一個隨機數 B ，並將隨機數 B 和 CA 頒發給本身的證書一同返回給客戶端 A 。
  • 三、客戶端 A 獲得 CA 證書後，會去校驗該 CA 證書的有效性，校驗方法在上面已經說過了。校驗經過後，客戶端生成一個隨機數3 ，而後用證書中的公鑰加密隨機數3 並傳輸給服務端 B 。
  • 四、服務端 B 獲得加密後的隨機數3，而後利用私鑰進行解密，獲得真正的隨機數3。
  • 五、最後，客戶端 A 和服務端 B 都有隨機數一、隨機數二、隨機數3，而後雙方利用這三個隨機數生成一個對話密鑰。以後傳輸內容就是利用對話密鑰來進行加解密了。這時就是利用了對稱加密，通常用的都是 AES 算法。
  • 六、客戶端 A 通知服務端 B ，指明後面的通信用對話密鑰來完成，同時通知服務器 B 客戶端 A 的握手過程結束。
  • 七、服務端 B 通知客戶端 A，指明後面的通信用對話密鑰來完成，同時通知客戶端 A 服務器 B 的握手過程結束。
  • 八、SSL 的握手部分結束，SSL 安全通道的數據通信開始，客戶端 A 和服務器 B 開始使用相同的對話密鑰進行數據通信。

簡化以下：

  • 一、客戶端和服務端創建 SSL 握手，客戶端經過 CA 證書來確認服務端的身份；
  • 二、互相傳遞三個隨機數，以後經過這隨機數來生成一個密鑰；
  • 三、互相確認密鑰，而後握手結束；
  • 四、數據通信開始，都使用同一個對話密鑰來加解密；

能夠發現，在 HTTPS 加密原理的過程當中把對稱加密和非對稱加密都利用了起來。即利用了非對稱加密安全性高的特色，又利用了對稱加密速度快，效率高的好處。

須要更深的理解請點擊這裏

八、HTTPS 如何防範中間人攻擊？

什麼是中間人攻擊？

當數據傳輸發生在一個設備（PC/手機）和網絡服務器之間時，攻擊者使用其技能和工具將本身置於兩個端點之間並截獲數據；儘管交談的兩方認爲他們是在與對方交談，可是實際上他們是在與幹壞事的人交流，這即是中間人攻擊。

有幾種攻擊方式？

  • 一、嗅探：

嗅探或數據包嗅探是一種用於捕獲流進和流出系統/網絡的數據包的技術。網絡中的數據包嗅探就好像電話中的監聽。

  • 二、數據包注入：

在這種技術中，攻擊者會將惡意數據包注入常規數據中。這樣用戶便不會注意到文件/惡意軟件，由於它們是合法通信流的一部分。

  • 三、會話劫持：

在你登陸進你的銀行帳戶和退出登陸這一段期間便稱爲一個會話。這些會話一般都是黑客的攻擊目標，由於它們包含潛在的重要信息。在大多數案例中，黑客會潛伏在會話中，並最終控制它。

  • 四、SSL剝離：

在SSL剝離攻擊中，攻擊者使SSL/TLS鏈接剝落，隨之協議便從安全的HTTPS變成了不安全的HTTP。

HTTPS 如何防範中間人攻擊：

請見https加密原理。

九、有哪些響應碼，分別都表明什麼意思？

1** 信息，服務器收到請求，須要請求者繼續執行操做

2** 成功，操做被成功接收並處理

3** 重定向，須要進一步的操做以完成請求

4** 客戶端錯誤，請求包含語法錯誤或沒法完成請求

5** 服務器錯誤，服務器在處理請求的過程當中發生了錯誤

2、TCP/UDP （⭐⭐⭐）

一、爲何tcp要通過三次握手，四次揮手？

重要標誌位

ACK ： TCP協議規定，只有ACK=1時有效，也規定鏈接創建後全部發送的報文的ACK必須爲1

SYN(SYNchronization) ： 在鏈接創建時用來同步序號。當SYN=1而ACK=0時，代表這是一個鏈接請求報文。對方若贊成創建鏈接，則應在響應報文中使SYN=1和ACK=1. 所以, SYN置1就表示這是一個鏈接請求或鏈接接受報文。

FIN （finis）即完，終結的意思， 用來釋放一個鏈接。當 FIN = 1 時，代表此報文段的發送方的數據已經發送完畢，並要求釋放鏈接。

三次握手、四次揮手過程

三次握手：

第一次握手：創建鏈接。客戶端發送鏈接請求報文段，將SYN位置爲1，Sequence Number爲x；而後，客戶端進入SYN_SEND狀態，等待服務器的確認；

第二次握手：服務器收到SYN報文段。服務器收到客戶端的SYN報文段，須要對這個SYN報文段進行確認，設置Acknowledgment Number爲x+1(Sequence Number+1)；同時，本身本身還要發送SYN請求信息，將SYN位置爲1，Sequence Number爲y；服務器端將上述全部信息放到一個報文段（即SYN+ACK報文段）中，一併發送給客戶端，此時服務器進入SYN_RECV狀態；

第三次握手：客戶端收到服務器的SYN+ACK報文段。而後將Acknowledgment Number設置爲y+1，向服務器發送ACK報文段，這個報文段發送完畢之後，客戶端和服務器端都進入ESTABLISHED狀態，完成TCP三次握手。

四次揮手：

第一次分手：主機1（能夠使客戶端，也能夠是服務器端），設置Sequence Number和Acknowledgment Number，向主機2發送一個FIN報文段；此時，主機1進入FIN_WAIT_1狀態；這表示主機1沒有數據要發送給主機2了；

第二次分手：主機2收到了主機1發送的FIN報文段，向主機1回一個ACK報文段，Acknowledgment Number爲Sequence Number加1；主機1進入FIN_WAIT_2狀態；主機2告訴主機1，我「贊成」你的關閉請求；

第三次分手：主機2向主機1發送FIN報文段，請求關閉鏈接，同時主機2進入LAST_ACK狀態；

第四次分手：主機1收到主機2發送的FIN報文段，向主機2發送ACK報文段，而後主機1進入TIME_WAIT狀態；主機2收到主機1的ACK報文段之後，就關閉鏈接；此時，主機1等待2MSL後依然沒有收到回覆，則證實Server端已正常關閉，那好，主機1也能夠關閉鏈接了。

「三次握手」的目的是「爲了防止已失效的鏈接請求報文段忽然又傳送到了服務端，於是產生錯誤」。主要目的防止server端一直等待，浪費資源。換句話說，便是爲了保證服務端能收接受到客戶端的信息並能作出正確的應答而進行前兩次(第一次和第二次)握手，爲了保證客戶端可以接收到服務端的信息並能作出正確的應答而進行後兩次(第二次和第三次)握手。

「四次揮手」緣由是由於tcp是全雙工模式，接收到FIN時意味將沒有數據再發來，可是仍是能夠繼續發送數據。

二、TCP可靠傳輸原理實現（滑動窗口）。

確認和重傳：接收方收到報文後就會進行確認，發送方一段時間沒有收到確認就會重傳。

數據校驗。

數據合理分片與排序，TCP會對數據進行分片，接收方會緩存爲按序到達的數據，從新排序後再提交給應用層。

流程控制：當接收方來不及接收發送的數據時，則會提示發送方下降發送的速度，防止包丟失。

擁塞控制：當網絡發生擁塞時，減小數據的發送。

關於滑動窗口、流量控制、擁塞控制實現原理請點擊這裏

三、Tcp和Udp的區別？

一、基於鏈接與無鏈接；

二、對系統資源的要求（TCP較多，UDP少）；

三、UDP程序結構較簡單；

四、流模式與數據報模式 ；

五、TCP保證數據正確性，UDP可能丟包；

六、TCP保證數據順序，UDP不保證。

四、如何設計在 UDP 上層保證 UDP 的可靠性傳輸？

傳輸層沒法保證數據的可靠傳輸，只能經過應用層來實現了。實現的方式能夠參照tcp可靠性傳輸的方式。如不考慮擁塞處理，可靠UDP的簡單設計以下：

  • 一、添加seq/ack機制，確保數據發送到對端
  • 二、添加發送和接收緩衝區，主要是用戶超時重傳。
  • 三、添加超時重傳機制。

具體過程便是：送端發送數據時，生成一個隨機seq=x，而後每一片按照數據大小分配seq。數據到達接收端後接收端放入緩存，併發送一個ack=x的包，表示對方已經收到了數據。發送端收到了ack包後，刪除緩衝區對應的數據。時間到後，定時任務檢查是否須要重傳數據。

目前有以下開源程序利用udp實現了可靠的數據傳輸。分別爲RUDP、RTP、UDT:

一、RUDP（Reliable User Datagram Protocol）

RUDP 提供一組數據服務質量加強機制，如擁塞控制的改進、重發機制及淡化服務器算法等。

二、RTP（Real Time Protocol）

RTP爲數據提供了具備實時特徵的端對端傳送服務，如在組播或單播網絡服務下的交互式視頻音頻或模擬數據。

三、UDT（UDP-based Data Transfer Protocol）

UDT的主要目的是支持高速廣域網上的海量數據傳輸。

關於RUDP、RTP、UDT的更多介紹請查看此處

3、其它重要網絡概念 （⭐⭐）

一、socket斷線重連怎麼實現，心跳機制又是怎樣實現？

socket概念

套接字（socket）是通訊的基石，是支持TCP/IP協議的網絡通訊的基本操做單元。它是網絡通訊過程當中端點的抽象表示，包含進行網絡通訊必須的五種信息：鏈接使用的協議，本地主機的IP地址，本地進程的協議端口，遠地主機的IP地址，遠地進程的協議端口。

爲了區別不一樣的應用程序進程和鏈接，許多計算機操做系統爲應用程序與TCP／IP協議交互提供了套接字(Socket)接口。應 用層能夠和傳輸層經過Socket接口，區分來自不一樣應用程序進程或網絡鏈接的通訊，實現數據傳輸的併發服務。

創建socket鏈接

創建Socket鏈接至少須要一對套接字，其中一個運行於客戶端，稱爲ClientSocket ，另外一個運行於服務器端，稱爲ServerSocket 。

套接字之間的鏈接過程分爲三個步驟：服務器監聽，客戶端請求，鏈接確認。

  • 服務器監聽：服務器端套接字並不定位具體的客戶端套接字，而是處於等待鏈接的狀態，實時監控網絡狀態，等待客戶端的鏈接請求。
  • 客戶端請求：指客戶端的套接字提出鏈接請求，要鏈接的目標是服務器端的套接字。爲此，客戶端的套接字必須首先描述它要鏈接的服務器的套接字，指出服務器端- - 套接字的地址和端口號，而後就向服務器端套接字提出鏈接請求。

鏈接確認：當服務器端套接字監聽到或者說接收到客戶端套接字的鏈接請求時，就響應客戶端套接字的請求，創建一個新的線程，把服務器端套接字的描述發 給客戶端，一旦客戶端確認了此描述，雙方就正式創建鏈接。而服務器端套接字繼續處於監聽狀態，繼續接收其餘客戶端套接字的鏈接請求。

SOCKET鏈接與TCP鏈接

建立Socket鏈接時，能夠指定使用的傳輸層協議，Socket能夠支持不一樣的傳輸層協議（TCP或UDP），當使用TCP協議進行鏈接時，該Socket鏈接就是一個TCP鏈接。

Socket鏈接與HTTP鏈接

因爲一般狀況下Socket鏈接就是TCP鏈接，所以Socket鏈接一旦創建，通訊雙方便可開始相互發送數據內容，直到雙方鏈接斷開。但在實際網 絡應用中，客戶端到服務器之間的通訊每每須要穿越多箇中間節點，例如路由器、網關、防火牆等，大部分防火牆默認會關閉長時間處於非活躍狀態的鏈接而致使 Socket 鏈接斷連，所以須要經過輪詢告訴網絡，該鏈接處於活躍狀態。

而HTTP鏈接使用的是「請求—響應」的方式，不只在請求時須要先創建鏈接，並且須要客戶端向服務器發出請求後，服務器端才能回覆數據。

不少狀況下，須要服務器端主動向客戶端推送數據，保持客戶端與服務器數據的實時與同步。此時若雙方創建的是Socket鏈接，服務器就能夠直接將數 據傳送給客戶端；若雙方創建的是HTTP鏈接，則服務器須要等到客戶端發送一次請求後才能將數據傳回給客戶端，所以，客戶端定時向服務器端發送鏈接請求， 不只能夠保持在線，同時也是在「詢問」服務器是否有新的數據，若是有就將數據傳給客戶端。TCP(Transmission Control Protocol)　傳輸控制協議

socket斷線重連實現

正常鏈接斷開客戶端會給服務端發送一個fin包，服務端收到fin包後纔會知道鏈接斷開。
而斷網斷電時客戶端沒法發送fin包給服務端，因此服務端沒辦法檢測到客戶端已經短線。
爲了緩解這個問題，服務端須要有個心跳邏輯，就是服務端檢測到某個客戶端多久沒發送任何數據過來就認爲客戶端已經斷開，
這須要客戶端定時向服務端發送心跳數據維持鏈接。

心跳機制實現

長鏈接的實現：心跳機制，應用層協議大多都有HeartBeat機制，一般是客戶端每隔一小段時間向服務器發送一個數據包，通知服務器本身仍然在線。並傳輸一些可能必要的數據。使用心跳包的典型協議是IM，好比QQ/MSN/飛信等協議

一、在TCP的機制裏面，自己是存在有心跳包的機制的，也就是TCP的選項：SO_KEEPALIVE。
系統默認是設置的2小時的心跳頻率。可是它檢查不到機器斷電、網線拔出、防火牆這些斷線。
並且邏輯層處理斷線可能也不是那麼好處理。通常，若是隻是用於保活仍是能夠的。經過使用TCP的KeepAlive機制（修改那個time參數），可讓鏈接每隔一小段時間就產生一些ack包，以下降被踢掉的風險，固然，這樣的代價是額外的網絡和CPU負擔。

二、應用層心跳機制實現。

二、Cookie與Session的做用和原理。

  • Session是在服務端保存的一個數據結構，用來跟蹤用戶的狀態，這個數據能夠保存在集羣、數據庫、文件中。
  • Cookie是客戶端保存用戶信息的一種機制，用來記錄用戶的一些信息，也是實現Session的一種方式。
Session：

因爲HTTP協議是無狀態的協議，因此服務端須要記錄用戶的狀態時，就須要用某種機制來識具體的用戶，這個機制就是Session.典型的場景好比購物車，當你點擊下單按鈕時，因爲HTTP協議無狀態，因此並不知道是哪一個用戶操做的，因此服務端要爲特定的用戶建立了特定的Session，用用於標識這個用戶，而且跟蹤用戶，這樣才知道購物車裏面有幾本書。這個Session是保存在服務端的，有一個惟一標識。在服務端保存Session的方法不少，內存、數據庫、文件都有。集羣的時候也要考慮Session的轉移，在大型的網站，通常會有專門的Session服務器集羣，用來保存用戶會話，這個時候 Session 信息都是放在內存的。

具體到Web中的Session指的就是用戶在瀏覽某個網站時，從進入網站到瀏覽器關閉所通過的這段時間，也就是用戶瀏覽這個網站所花費的時間。所以從上述的定義中咱們能夠看到，Session其實是一個特定的時間概念。

當客戶端訪問服務器時，服務器根據需求設置Session，將會話信息保存在服務器上，同時將標示Session的SessionId傳遞給客戶端瀏覽器，

瀏覽器將這個SessionId保存在內存中，咱們稱之爲無過時時間的Cookie。瀏覽器關閉後，這個Cookie就會被清掉，它不會存在於用戶的Cookie臨時文件。

之後瀏覽器每次請求都會額外加上這個參數值，服務器會根據這個SessionId，就能取得客戶端的數據信息。

若是客戶端瀏覽器意外關閉，服務器保存的Session數據不是當即釋放，此時數據還會存在，只要咱們知道那個SessionId,就能夠繼續經過請求得到此Session的信息，由於此時後臺的Session還存在，固然咱們能夠設置一個Session超時時間，一旦超過規定時間沒有客戶端請求時，服務器就會清除對應SessionId的Session信息。

Cookie

Cookie是由服務器端生成，發送給User-Agent（通常是web瀏覽器），瀏覽器會將Cookie的key/value保存到某個目錄下的文本文件內，下次請求同一網站時就發送該Cookie給服務器（前提是瀏覽器設置爲啓用Cookie）。Cookie名稱和值能夠由服務器端開發本身定義，對於JSP而言也能夠直接寫入Sessionid，這樣服務器能夠知道該用戶是否合法用戶以及是否須要從新登陸等。

三、IP報文中的內容。

image

版本：IP協議的版本，目前的IP協議版本號爲4，下一代IP協議版本號爲6。

首部長度：IP報頭的長度。固定部分的長度（20字節）和可變部分的長度之和。共佔4位。最大爲1111，即10進制的15，表明IP報頭的最大長度能夠爲15個32bits（4字節），也就是最長可爲15*4=60字節，除去固定部分的長度20字節，可變部分的長度最大爲40字節。

服務類型：Type Of Service。

總長度：IP報文的總長度。報頭的長度和數據部分的長度之和。

標識：惟一的標識主機發送的每一分數據報。一般每發送一個報文，它的值加一。當IP報文長度超過傳輸網絡的MTU（最大傳輸單元）時必須分片，這個標識字段的值被複制到全部數據分片的標識字段中，使得這些分片在達到最終目的地時能夠依照標識字段的內容從新組成原先的數據。

標誌：共3位。R、DF、MF三位。目前只有後兩位有效，DF位：爲1表示不分片，爲0表示分片。MF：爲1表示「更多的片」，爲0表示這是最後一片。

片位移：本分片在原先數據報文中相對首位的偏移位。（須要再乘以8）

生存時間：IP報文所容許經過的路由器的最大數量。每通過一個路由器，TTL減1，當爲0時，路由器將該數據報丟棄。TTL 字段是由發送端初始設置一個 8 bit字段.推薦的初始值由分配數字 RFC 指定，當前值爲 64。發送 ICMP 回顯應答時常常把 TTL 設爲最大值 255。

協議：指出IP報文攜帶的數據使用的是那種協議，以便目的主機的IP層能知道要將數據報上交到哪一個進程（不一樣的協議有專門不一樣的進程處理）。和端口號相似，此處採用協議號，TCP的協議號爲6，UDP的協議號爲17。ICMP的協議號爲1，IGMP的協議號爲2.

首部校驗和：計算IP頭部的校驗和，檢查IP報頭的完整性。

源IP地址：標識IP數據報的源端設備。

目的IP地址：標識IP數據報的目的地址。

最後就是可變部分和數據部分。

4、常見網絡流程機制 （⭐⭐）

一、瀏覽器輸入地址到返回結果發生了什麼？

整體來講分爲如下幾個過程:

一、DNS解析，此外還有DNSy優化（DNS緩存、DNS負載均衡）

二、TCP鏈接

三、發送HTTP請求

四、服務器處理請求並返回HTTP報文

五、瀏覽器解析渲染頁面

六、鏈接結束

Web前端的本質

將信息快速並友好的展現給用戶並可以與用戶進行交互。

如何儘快的加載資源（網絡優化）？

答案就是能不從網絡中加載的資源就不從網絡中加載，當咱們合理使用緩存，將資源放在瀏覽器端，這是最快的方式。若是資源必須從網絡中加載，則要考慮縮短鏈接時間，即DNS優化部分;減小響應內容大小，即對內容進行壓縮。另外一方面，若是加載的資源數比較少的話，也能夠快速的響應用戶。

操做系統（⭐⭐⭐）

一、操做系統如何管理內存的？

二、進程調度。

三、說下Linux進程和線程的區別。

進程和線程的主要差異在於它們是不一樣的操做系統資源管理方式。進程有獨立的地址空間，一個進程崩潰後，在保護模式下不會對其它進程產生影響，而線程只是一個進程中的不一樣執行路徑。線程有本身的堆棧和局部變量，但線程之間沒有單獨的地址空間，一個線程死掉就等於整個進程死掉，因此多進程的程序要比多線程的程序健壯，但在進程切換時，耗費資源較大，效率要差一些。但對於一些要求同時進行而且又要共享某些變量的併發操做，只能用線程，不能用進程。

1) 簡而言之,一個程序至少有一個進程,一個進程至少有一個線程。

2) 線程的劃分尺度小於進程，使得多線程程序的併發性高。

3) 另外，進程在執行過程當中擁有獨立的內存單元，而多個線程共享內存，從而極大地提升了程序的運行效率。

4) 線程在執行過程當中與進程仍是有區別的。每一個獨立的線程有一個程序運行的入口、順序執行序列和程序的出口。可是線程不可以獨立執行，必須依存在應用程序中，由應用程序提供多個線程執行控制。

5) 從邏輯角度來看，多線程的意義在於一個應用程序中，有多個執行部分能夠同時執行。但操做系統並無將多個線程看作多個獨立的應用，來實現進程的調度和管理以及資源分配。這就是進程和線程的重要區別。

四、你能解釋一下Linux的軟連接和硬連接嗎？

Linux連接分兩種，一種被稱爲硬連接（Hard Link），另外一種被稱爲符號連接（Symbolic Link）。默認狀況下，ln命令產生硬連接。

硬鏈接

硬鏈接指經過索引節點來進行鏈接。在Linux的文件系統中，保存在磁盤分區中的文件無論是什麼類型都給它分配一個編號，稱爲索引節點號(Inode Index)。在Linux中，多個文件名指向同一索引節點是存在的。通常這種鏈接就是硬鏈接。硬鏈接的做用是容許一個文件擁有多個有效路徑名，這樣用戶就能夠創建硬鏈接到重要文件，以防止「誤刪」的功能。其緣由如上所述，由於對應該目錄的索引節點有一個以上的鏈接。只刪除一個鏈接並不影響索引節點自己和其它的鏈接，只有當最後一個鏈接被刪除後，文件的數據塊及目錄的鏈接纔會被釋放。也就是說，文件真正刪除的條件是與之相關的全部硬鏈接文件均被刪除。

軟鏈接

另一種鏈接稱之爲符號鏈接（Symbolic Link），也叫軟鏈接。軟連接文件有相似於Windows的快捷方式。它其實是一個特殊的文件。在符號鏈接中，文件其實是一個文本文件，其中包含的有另外一文件的位置信息。

五、安卓權限管理，爲什麼在清單中註冊權限，安卓APP就能夠使用，反之不能夠？

此題考查Android的權限管理在Android的安全架構中的做用。

Android 是一個權限分隔的操做系統，其中每一個應用都有其獨特的系統標識（Linux 用戶 ID 和組 ID）。系統各部分也分隔爲不一樣的標識。Linux 據此將不一樣的應用以及應用與系統分隔開來。

其餘更詳細的安全功能經過「權限」機制提供，此機制會限制特定進程能夠執行的具體操做，而且根據 URI 權限受權臨時訪問特定的數據段。

Android 安全架構的中心設計點是：在默認狀況下任何應用都沒有權限執行對其餘應用、操做系統或用戶有不利影響的任何操做。這包括讀取或寫入用戶的私有數據（例如聯繫人或電子郵件）、讀取或寫入其餘應用程序的文件、執行網絡訪問、使設備保持喚醒狀態等。

因爲每一個 Android 應用都是在進程沙盒中運行，所以應用必須顯式共享資源和數據。它們的方法是聲明須要哪些權限來獲取基本沙盒未提供的額外功能。應用以靜態方式聲明它們須要的權限，而後 Android 系統提示用戶贊成。

數據庫 （⭐）

一、數據庫的四大特徵，數據庫的隔離級別？

事務（Transaction）是併發控制的基本單位。所謂的事務，它是一個操做序列，這些操做要麼都執行，要麼都不執行，它是一個不可分割的工做單位。例如，銀行轉帳工做：從一個帳號扣款並使另外一個帳號增款，這兩個操做要麼都執行，要麼都不執行。因此，應該把它們當作一個事務。事務是數據庫維護數據一致性的單位，在每一個事務結束時，都能保持數據一致性。事務具備如下4個基本特徵：

數據庫的四大特徵：

（1）原子性（Atomicity）

原子性是指事務包含的全部操做要麼所有成功，要麼所有失敗回滾。

（2）一致性（Consistency）

一個事務執行以前和執行以後都必須處於一致性狀態。

（3）隔離性（Isolation）

隔離性是當多個用戶併發訪問數據庫時，好比操做同一張表時，數據庫爲每個用戶開啓的事務，不能被其餘事務的操做所幹擾，多個併發事務之間要相互隔離。

（4）持久性（Durability）

持久性是指一個事務一旦被提交了，那麼對數據庫中的數據的改變就是永久性的。

數據庫的隔離級別：

1）Serializable(串行化)：可避免髒讀、不可重複讀、幻讀的發生。

2）Repeatable read (可重複讀)：可避免髒讀、不可重複讀的發生。

3）Read committed (讀已提交)：可避免髒讀的發生。

4）Read uncommitted (讀未提交)：最低級別，任何狀況都沒法保證。

二、數據庫設計中常講的三範式是指什麼？

1）第一範式1NF(域的原子性)

若是數據庫表中的全部字段值都是不可分解的原子值，就說明該數據庫表知足了第一範式

2）第二範式2NF(表中除主鍵外的字段都徹底依賴主鍵)

第二範式是在第一範式基礎上創建的。第二範式有兩個重點:(1)表中必須有主鍵；(2)其餘非主屬性必須徹底依賴主鍵，不能只依賴主鍵的一部分（主要針對聯合主鍵而言）。

3）第三範式3NF（表中除主鍵外的字段都徹底直接依賴，不能是傳遞依賴）

不能是傳遞依賴，即不能存在：非主鍵列 A 依賴於非主鍵列 B，非主鍵列 B 依賴於主鍵的狀況。第二範式和第三範式區分的關鍵點：2NF：非主鍵列是否徹底依賴於主鍵，仍是依賴於主鍵的一部分；3NF：非主鍵列是直接依賴於主鍵，仍是直接依賴於非主鍵列。

數據結構和算法（⭐⭐⭐）

對於算法面試準備，無疑就是刷《劍指Offer》+ LeetCode 效果最佳。刷《劍指Offer》是爲了創建全面的算法面試思惟，打下堅實的基礎，刷LeetCode則是爲了避免斷強化與開闊咱們本身的算法思想。這兩塊 CS-Notes 中已經實現地很完美了，建議你們將《劍指Offer》刷完，而後再至少刷100道LeetCode題目以上。

一、劍指 Offer 題解

二、Leetcode 題解

讚揚

若是這個庫對您有很大幫助，您願意支持這個項目的進一步開發和這個項目的持續維護。你能夠掃描下面的二維碼，讓我喝一杯咖啡或啤酒。很是感謝您的捐贈。謝謝！

<div align="center">
<img src="https://user-gold-cdn.xitu.io/2020/3/1/170961575de964f2?w=1080&h=1457&f=jpeg&s=93345" width=20%><img src="https://user-gold-cdn.xitu.io/2020/3/1/1709615761d9b6c5?w=990&h=1540&f=jpeg&s=110691" width=20%>
</div>

Contanct Me

● 微信 && 微信羣：

歡迎關注個人微信：bcce5360。因爲微信羣人數太多沒法生成羣邀二維碼，因此麻煩你們想進微信羣的朋友們，加我微信拉你進羣（PS：微信羣的學習氛圍與各項福利將會超乎你的想象）。

● QQ羣：

2千人QQ羣， Awesome-Android學習交流羣，QQ羣號：959936182， 歡迎你們加入~

About me

很感謝您閱讀這篇文章，但願您能將它分享給您的朋友或技術羣，這對我意義重大。

但願咱們能成爲朋友，在 Github、掘金上一塊兒分享知識。

联系我们 沪ICP备13005482号-10