最近在複習找工作,把自己總結的頻繁出現在面試中的知識點跟大家分享一下,希望對大家找工作有幫助,不足之處還請批評指正!一起加油哦!
持續更新。。。。。。
-
Linux命令複習
-
計算機網絡
-
瀏覽器輸入一個地址回車之後都發生了啥?
(參考:https://blog.csdn.net/jiao_0509/article/details/82491299)
- 1、第一步,解析域名對應的IP地址,首先到瀏覽器緩存中查找,再到系統緩存中查找(查找本地hosts文件),然後到dns服務器中查找(域名服務器中的查找採用迭代查詢)。
- 2、第二步,瀏覽器與目標服務器建立TCP連接,主機瀏覽器通過DNS解析得到了目標服務器的IP地址後,與服務器建立TCP連接。這其中包括三次握手。
- 3、連接成功建立後,瀏覽器通過http協議發送請求,瀏覽器向主機發起一個HTTP-GET方法報文請求。請求中包含訪問的URL,也就是http://www.csdn.com/ ,KeepAlive,長連接,還有User-Agent用戶瀏覽器操作系統信息,編碼等。這個過程中有可能會發生重定向操作(如:爲了負載均衡)。
- 4、服務器處理請求。服務器接收到獲取請求,然後處理並返回一個響應。
- 5、服務器發出一個HTML響應。返回狀態碼200 OK,表示服務器可以響應請求,返回報文。
- 6、釋放TCP連接,四次揮手。
- 7、瀏覽器顯示頁面。在瀏覽器沒有完整接受全部HTML文檔時,它就已經開始顯示這個頁面了,瀏覽器接收到返回的數據包,根據瀏覽器的渲染機制對相應的數據進行渲染。渲染後的數據,進行相應的頁面呈現和腳步的交互。
-
迭代查詢的過程:
根域名服務器告訴本地域名服務器,下一次應查詢的頂級域名服務器dns.net的IP地址。本地域名服務器向頂級域名服務器dns.net進行查詢。頂級域名服務器dns.net告訴本地域名服務器,下一次應查詢的權限域名服務器dns.csdn.net的IP地址。本地域名服務器向權限域名服務器dns.csdn.net進行查詢。權限域名服務器dns.csdn.net告訴本地域名服務器,所查詢的主機www.csdn.net的IP地址。本地域名服務器最後把結果告訴主機。
-
TCP三次握手過程:
- 1、瀏覽器所在的客戶機向服務器發出連接請求報文(SYN標誌爲1);
- 2、服務器接收報文後,同意建立連接,向客戶機發出確認報文(SYN,ACK標誌位均爲1);
- 3、客戶機接收到確認報文後,再次向服務器發出報文,確認已接收到確認報文;此處客戶機與服務器之間的TCP連接建立完成,開始通信
-
TCP四次揮手過程:
- 1、 瀏覽器所在主機向服務器發出連接釋放報文,然後停止發送數據;
- 2、服務器接收到釋放報文後發出確認報文,然後將服務器上未傳送完的數據發送完;
- 3、 服務器數據傳輸完畢後,向客戶機發送連接釋放報文;
- 4、客戶機接收到報文後,發出確認,然後等待一段時間後,釋放TCP連接。
-
tcp四次揮手中的TIME_WAIT狀態存在的理由?
(參考:https://blog.csdn.net/stpeace/article/details/75714797)
- 1、TIME_WAIT存在的理由之一是:儘可能護送最後的ACK達到對端。
- 2、 TIME_WAIT存在的理由之二是:新舊四元組互不干擾。
-
TCP 和 UTP 有什麼區別?(深入回答)
(參考:https://www.cnblogs.com/xiaomayizoe/p/5258754.html)
- 1、TCP面向連接(如打電話要先撥號建立連接);UDP是無連接的,即發送數據之前不需要建立連接。
- 2、TCP提供可靠的服務。也就是說,通過TCP連接傳送的數據,無差錯,不丟失,不重複,且按序到達;UDP盡最大努力交付,即不保證可靠交付。
- 3、TCP面向字節流,實際上是TCP把數據看成一連串無結構的字節流;UDP是面向報文的,UDP沒有擁塞控制,因此網絡出現擁塞不會使源主機的發送速率降低(對實時應用很有用,如IP電話,實時視頻會議等)
- 4、每一條TCP連接只能是點到點的;UDP支持一對一,一對多,多對一和多對多的交互通信
- 5、TCP首部開銷20字節;UDP的首部開銷小,只有8個字節。
- 6、TCP的邏輯通信信道是全雙工的可靠信道,UDP則是不可靠信道
-
HTTP請求post和get請求的區別?
(參考:https://segmentfault.com/a/1190000009512784)
- 1、get把請求的數據放在url上,即HTTP協議頭上,post把數據放在HTTP的包體內(requrest body)。
- 2、get提交的數據最大是2k(原則上url長度無限制,那麼get提交的數據也沒有限制咯?限制實際上取決於瀏覽器,(大多數)瀏覽器通常都會限制url長度在2K個字節,即使(大多數)服務器最多處理64K大小的url。也沒有卵用。)。
- 3、post理論上沒有限制。實際上IIS4中最大量爲80KB,IIS5中爲100KB。
- 4、GET產生一個TCP數據包,瀏覽器會把http header和data一併發送出去,服務器響應200(返回數據);
- 5、POST產生兩個TCP數據包,瀏覽器先發送header,服務器響應100 continue,瀏覽器再發送data,服務器響應200 ok(返回數據)。
- 6、GET在瀏覽器回退時是無害的,POST會再次提交請求。
- 7、GET產生的URL地址可以被Bookmark,而POST不可以。
- 8、GET請求會被瀏覽器主動cache,而POST不會,除非手動設置。
- 9、GET請求只能進行url編碼,而POST支持多種編碼方式。
- 10、GET請求參數會被完整保留在瀏覽器歷史記錄裏,而POST中的參數不會被保留。
- 11、GET只接受ASCII字符的參數的數據類型,而POST沒有限制
- Get請求效率高啊!
-
-
數據庫
-
一條SQL執行的很慢的原因?
(參考:http://www.matools.com/blog/190432671)
- 一個 SQL 執行的很慢,我們要分兩種情況討論:
- 1、大多數情況下很正常,偶爾很慢,則有如下原因:(1) 數據庫在刷新髒頁,例如 redo log 寫滿了需要同步到磁盤。(2) 執行的時候,遇到鎖(其他用戶在操作相同的表),如表鎖、行鎖。
- 2、這條 SQL 語句一直執行的很慢,則有如下原因:(1) 沒有用上索引:例如該字段沒有索引;由於對字段進行運算、函數操作導致無法用索引。(2) 數據庫選錯了索引
-
MySQL有哪些存儲引擎以及他們之間的區別?
(參考:https://blog.csdn.net/suifeng3051/article/details/52669644#commentBox ; https://blog.csdn.net/zgrgfr/article/details/74455547>)
- InnoDB 和 MyISAM之間的區別:
- 1.InnoDB支持事物,而MyISAM不支持事物
- 2.InnoDB支持行級鎖,而MyISAM支持表級鎖
- 3.InnoDB支持MVCC, 而MyISAM不支持
- 4.InnoDB支持外鍵,而MyISAM不支持
- 5.InnoDB不支持全文索引,而MyISAM支持。
- 6、InnoDB是聚集索引,MyISAM是非聚集索引
-
查看正在執行的Sql語句的執行狀態
- mysql>show processlist
-
說說MySQL事務。說說ACID是什麼?
- 原子性(Atomicity)
- 事務被視爲不可分割的最小單元,事務的所有操作要麼全部提交成功,要麼全部失敗回滾。
- 一致性(Consistency)
- 數據庫在事務執行前後都保持一致性狀態。在一致性狀態下,所有事務對一個數據的讀取結果都是相同的。
- 隔離性(Isolation)
- 一個事務所做的修改在最終提交以前,對其它事務是不可見的。
- 持久性(Durability)
- 一旦事務提交,則其所做的修改將會永遠保存到數據庫中。即使系統發生崩潰,事務執行的結果也不能丟失。
- 原子性(Atomicity)
-
事務的隔離級別?(由若到強)
- 未提交讀(READ UNCOMMITTED)
- 事務中的修改,即使沒有提交,對其它事務也是可見的。
- 提交讀(READ COMMITTED)
- 一個事務只能讀取已經提交的事務所做的修改。換句話說,一個事務所做的修改在提交之前對其它事務是不可見的。
- 可重複讀(REPEATABLE READ)
- 保證在同一個事務中多次讀取同樣數據的結果是一樣的。
- 可串行化(SERIALIZABLE)
- 強制事務串行執行。
- 未提交讀(READ UNCOMMITTED)
-
-
Java和JVM
-
說說垃圾回收?(參考)
- 老年代,新生代,永生代(方法區)的區別等,各自使用的回收算法,新生代又分eden和survivor區
- 新生代:少了存活,複製算法;老年代:標記—整理/標記—清理算法
- >15年齡,存到老年代
-
如果想要讓多個線程執行到某個點,都達到之後再繼續執行,可以用java的那些類來實現?
- CountDownLatch 和CyclicBarrier
-
什麼是反射?
- JAVA反射機制是在運行狀態中,對於任意一個類,都能夠知道這個類的所有屬性和方法;對於任意一個對象,都能夠調用它的任意一個方法和屬性;這種動態獲取的信息以及動態調用對象的方法的功能稱爲java語言的反射機制。
-
反射有什麼用?
-
IO阻塞與非阻塞是什麼?各自有啥好處?知道多路複用嗎?瞭解過 select 嗎?說說他與 epoll 的區別?
- IO請求的兩個階段:
- 1.等待資源階段:IO請求一般需要請求特殊的資源(如磁盤、RAM、文件),當資源被上一個使用者使用沒有被釋放時,IO請求就會被阻塞,直到能夠使用這個資源。
- 2.使用資源階段:真正進行數據接收和發生。
- 在等待數據階段,IO分爲阻塞IO和非阻塞IO。
- 1.阻塞IO: 資源不可用時,IO請求一直阻塞,直到反饋結果(有數據或超時)。
- 2.非阻塞IO:資源不可用時,IO請求離開返回,返回數據標識資源不可用
- 在使用資源階段,IO分爲同步IO和異步IO。
- 1.同步IO:應用阻塞在發送或接收數據的狀態,直到數據成功傳輸或返回失敗。
- 2.異步IO:應用發送或接收數據後立刻返回,數據寫入OS緩存,由OS完成數據發送或接收,並返回成功或失敗的信息給應用。
- IO請求的兩個階段:
-
NIO 與普通 I/O 的區別主要有以下兩點:
- NIO 是非阻塞的;
- NIO 面向塊,I/O 面向流。
-
樂觀鎖、悲觀鎖定義及其應用?
(參考:https://blog.csdn.net/fhy569039351/article/details/83040384)
-
樂觀鎖:
- 總是認爲不會產生併發問題,每次去取數據的時候總認爲不會有其他線程對數據進行修改,因此不會上鎖,但是在更新時會判斷其他線程在這之前有沒有對數據進行修改,一般會使用版本號機制或CAS操作實現。
- 樂觀鎖適用於多讀的應用類型,這樣可以提高吞吐量,像數據庫如果提供類似於write_condition機制的其實都是提供的樂觀鎖。
-
悲觀鎖:
- 顧名思義,就是很悲觀,總是假設最壞的情況,每次取數據時都認爲其他線程會修改,所以都會加鎖(讀鎖、寫鎖、行鎖等),當其他線程想要訪問數據時,都需要阻塞掛起。可以依靠數據庫實現,如行鎖、讀鎖和寫鎖等,都是在操作之前加鎖,在Java中,synchronized的思想也是悲觀鎖。
-
附CAS簡介:
- CAS是由CPU硬件實現,所以執行相當快.CAS有三個操作參數:內存地址,期望值,要修改的新值,當期望值和內存當中的值進行比較不相等的時候,表示內存中的值已經被別線程改動過,這時候失敗返回,當相等的時候,將內存中的值改爲新的值,並返回成功。
-
爲什麼重寫equals一定要重寫hashcode
(參考:https://blog.csdn.net/xl_1803/article/details/80445481 講的很清楚)
-
CurrentHashMap 1.7和1.8的區別?
(參考:https://blog.csdn.net/qq296398300/article/details/79074239 https://www.cnblogs.com/softidea/p/10261414.html)
-
1、JDK1.8的實現降低鎖的粒度,JDK1.7版本鎖的粒度是基於Segment的,包含多個HashEntry,而JDK1.8鎖的粒度就是HashEntry(首節點)
-
2、JDK1.8版本的數據結構變得更加簡單,使得操作也更加清晰流暢,因爲已經使用synchronized來進行同步,所以不需要分段鎖的概念,也就不需要Segment這種數據結構了,由於粒度的降低,實現的複雜度也增加了
-
3、JDK1.8使用紅黑樹來優化鏈表,基於長度很長的鏈表的遍歷是一個很漫長的過程,而紅黑樹的遍歷效率是很快的,代替一定閾值的鏈表,這樣形成一個最佳拍檔
-
總結:JDK1.7版本:ReentrantLock + Segment + HashEntry
JDK1.8版本:synchronized + CAS + HashEntry + 紅黑樹
-
-
JDK1.8爲什麼使用內置鎖synchronized來代替重入鎖ReentrantLock?
-
1、因爲粒度降低了,在相對而言的低粒度加鎖方式,synchronized並不比ReentrantLock差,在粗粒度加鎖中ReentrantLock可能通過Condition來控制各個低粒度的邊界,更加的靈活,而在低粒度中,Condition的優勢就沒有了
-
2、JVM的開發團隊從來都沒有放棄synchronized,而且基於JVM的synchronized優化空間更大,使用內嵌的關鍵字比使用API更加自然
-
3、在大量的數據操作下,對於JVM的內存壓力,基於API的ReentrantLock會開銷更多的內存,雖然不是瓶頸,但是也是一個選擇依據
-
-
-
-
Spring
-
說說AOP(面向切面編程)、IOC(控制反轉)、DI(依賴注入)?
(參考:https://blog.csdn.net/a745233700/article/details/80959716)
- AOP,一般稱爲面向切面,其實現的關鍵在於代理模型(JDK動態代理和CGLib動態代理),作爲面向對象的一種補充,用於將那些與業務無關,但卻對多個對象產生影響的公共行爲和邏輯,抽取並封裝爲一個可重用的模塊,這個模塊被命名爲“切面”(Aspect),減少系統中的重複代碼,降低了模塊間的耦合度,同時提高了系統的可維護性。可用於權限認證、日誌、事務處理。
- IOC就是控制反轉,是指創建對象的控制權的轉移,以前創建對象的主動權和時機是由自己把控的,而現在這種權力轉移到Spring容器中,並由容器根據配置文件去創建實例和管理各個實例之間的依賴關係,對象與對象之間鬆散耦合,也利於功能的複用。
- DI依賴注入,和控制反轉是同一個概念的不同角度的描述,即 應用程序在運行時依賴IoC容器來動態注入對象需要的外部資源。最直觀的表達就是,IOC讓對象的創建不用去new了,可以由spring自動生產,使用java的反射機制,根據配置文件在運行時動態的去創建對象以及管理對象,並調用對象的方法的。Spring的IOC有三種注入方式 :構造器注入、setter方法注入、根據註解注入。
-
-
數據結構:
-
爲什麼有了平衡樹還需要紅黑樹?
- 平衡樹太嚴格,插入很容易打破平衡,經常需要調整,影響插入效率,而紅黑樹是一種折中方案。
- 1、紅黑樹放棄了追求完全平衡,追求大致平衡,在與平衡二叉樹的時間複雜度相差不大的情況下,保證每次插入最多只需要三次旋轉就能達到平衡,實現起來也更爲簡單。
- 2、平衡二叉樹追求絕對平衡,條件比較苛刻,實現起來比較麻煩,每次插入新節點之後需要旋轉的次數不能預知。
-
項目用到redis,知道跳躍表嗎?說說他是怎麼實現的,查找時間複雜度?
- 時間複雜度log(n)
-
手撕排序算法
(參考:https://blog.csdn.net/fhy569039351/article/details/91050130)
- 快速排序
- 歸併排序
- 插入排序
- 堆排序
-
-
操作系統
-
其他方面
-
Docker與VM虛擬機的不同點
- 1、虛擬化技術依賴物理CPU和內存,是硬件級別的;而docker構建在操作系統上,利用操作系統的containerization容器技術,所以docker甚至可以在虛擬機上運行。
- 2、啓動速度快,比VM快太多了,啓動、停止、開始、重啓都是秒級甚至毫秒級。
- 3、輕量級虛擬化,在一臺服務器上可以部署100~1000個Container容器。而VM一臺服務器能部署10到20就很不錯了。
- 4、Docker是單線程,Docker設計者極力推崇“一個容器一個進程的方式”。無法很好地模擬一個完整的環境。
- 5、當停止一個虛擬機時,可能除了一些臨時文件,沒有文件會被刪除(業務產生的文件);但當停止一個Docker容器,對初始狀態(創建容器所用的鏡像的狀態)做的所有變化都會丟失。這是使用Docker時必須做出的最大思維變化之一:容器是短暫和一次性的。所以有種說法,例如mysql這樣的數據庫還是不要用Docker的好,因爲數據庫在使用過程中會有很多業務數據。
- 6、Docker的安全性目前比VM要差。VM做到資源完全隔離,而Docker會共享資源,這就帶來了安全的風險。
-
hash一致性算法?
-