最全技術面試180題:阿里11面試+網易+百度+美團!
網絡編程
-
ISO模型與協議
-
http1.0:需要使用keep-alive參數來告知服務器端要建立一個長連接
-
http1.1:默認長連接。支持只發送header信息,可以用作權限請求。支持Host域。
-
http2.0:多路復用的技術,做到同一個連接並發處理多個請求。HTTP2.0使用HPACK算法對header的數據進行壓縮。支持HTTP2.0的web server請求數據的時候,服務器會順便把一些客戶端需要的資源一起推送到客戶端,免得客戶端再次創建連接發送請求到服務器端獲取。這種方式非常合適加載靜態資源。
-
會話層:負責管理主機之間的會話進程,負責建立、管理、終止進程之間的會話。
-
傳輸層:將上層數據分段並提供端到端的、可靠的或不可靠的傳輸,還要處理端到端的差錯控制和流量控制問題。協議TCP、UDP、SPX
-
網絡層:對子網間的數據包進行路由選擇。此外,網絡層還可以實現擁塞控制、網際互連等功能。協議IP、IPX、RIP、OSPF
-
數據鏈路層:在不可靠的物理介質上提供可靠的傳輸。該層的作用包括:物理地址尋址、數據的成幀、流量控制、數據的檢錯、重發等。協議SDLC、HDLC、PPP、STP、幀中繼
-
TCPIP模型與協議
-
應用層:單位是數據段,協議有FTP、TELNET、HTTP、SMTP、SNMP、TFTP、NTP、DNS
-
運輸層:單位是數據包,協議有TCP、UDP
-
網絡層:單位是數據幀,協議有IP
-
網絡接口層:單位是比特,ARP、RARP
-
三次握手與四次揮手
-
BIO NIO AIO
-
BIO:同步阻塞IO,每個請求都要一個線程來處理。
-
NIO:同步非阻塞IO,一個線程可以處理多個請求,適用於短連接、小數據。
-
AIO:異步非阻塞IO,一個線程處理多個請求,使用回調函數實現,適用於長連接、大數據。
-
DDOS攻擊原理與防御方式
-
HTTP Get Flood:發送大量會產生sql查詢的連接,使得數據庫負載很高。
-
CSRF跨站請求偽造原理攻擊者盜用了你的身份,以你的名義發送惡意請求。
-
CSRF攻擊是源於WEB的隱式身份驗證機制!WEB的身份驗證機制雖然可以保證一個請求是來自於某個用戶的瀏覽器,但卻無法保證該請求是用戶批准發送的!
-
防御方式:1.驗證碼;2. 后台生成token,讓前端請求攜帶。3.使用對稱加密,后端隨機給前端一個密鑰,前端進行加密,后端解密。
-
會話劫持通過暴力破解、 預測、竊取(通過XSS攻擊)等方式獲取到用戶session
-
XSS攻擊XSS攻擊是Web攻擊中最常見的攻擊方法之一,它是通過對網頁注入可執行代碼且成功地被瀏覽器執行,達到攻擊的目的,形成了一次有效XSS攻擊,一旦攻擊成功,它可以獲取用戶的聯系人列表,然后向聯系人發送虛假詐騙信息,可以刪除用戶的日志等等,有時候還和其他攻擊方式同時實施比如SQL注入攻擊服務器和數據庫、Click劫持、相對鏈接劫持等實施釣魚,它帶來的危害是巨大的,是web安全的頭號大敵。
-
XSS反射型攻擊,惡意代碼並沒有保存在目標網站,通過引誘用戶點擊一個鏈接到目標網站的惡意鏈接來實施攻擊的。
-
XSS存儲型攻擊,惡意代碼被保存到目標網站的服務器中,這種攻擊具有較強的穩定性和持久性,比較常見場景是在博客,論壇等社交網站上,但OA系統,和CRM系統上也能看到它身影,比如:某CRM系統的客戶投訴功能上存在XSS存儲型漏洞,黑客提交了惡意攻擊代碼,當系統管理員查看投訴信息時惡意代碼執行,竊取了客戶的資料,然而管理員毫不知情,這就是典型的XSS存儲型攻擊。
-
解決方法
-
在表單提交或者url參數傳遞前,對需要的參數進行過濾
-
過濾用戶輸入。檢查用戶輸入的內容中是否有非法內容。如<>(尖括號)、”(引號)、 ‘(單引號)、%(百分比符號)、;(分號)、()(括號)、&(& 符號)、+(加號)等
28.RPC與HTTP服務的區別
數據庫原理
-
MYISAM與innodb搜索引擎原理MyISAM引擎使用B+Tree作為索引結構,葉節點的data域存放的是數據記錄的地址。其采用索引文件與數據文件,索引文件只存放索引,葉子節點存放數據的物理地址。數據文件存放數據。其索引方式是非聚集的。
-
InnoDB也使用B+Tree作為索引結構。但是它的主索引與數據都放在一個文件中。這種索引叫做聚集索引,因為InnoDB的數據文件本身要按主鍵聚集,所以InnoDB要求表必須有主鍵(MyISAM可以沒有),如果沒有顯式指定,則MySQL系統會自動選擇一個可以唯一標識數據記錄的列作為主鍵,如果不存在這種列,則MySQL自動為InnoDB表生成一個隱含字段作為主鍵,這個字段長度為6個字節,類型為長整形。
-
區別一:InnoDB的主索引與數據都放在一個文件中。而MYISAM是分開存放的。
-
區別二:InnoDB的輔助索引data域存儲相應記錄主鍵的值而不是地址。
-
區別三:InnoDB的主鍵索引是聚集索引,而MYISAM不是聚集索引。
3.索引,聚簇索引和二級索引的加鎖區別
-
聚集(clustered)索引,也叫聚簇索引。數據行的物理順序與列值(一般是主鍵的那一列)的邏輯順序相同,一個表中只能擁有一個聚集索引。
-
非聚集(unclustered)索引。該索引中索引的邏輯順序與磁盤上行的物理存儲順序不同,一個表中可以擁有多個非聚集索引。會發生二次查詢。
-
稠密索引:稠密索引文件中的索引塊保持鍵的順序與文件中的排序順序一致。
-
稀疏索引:稀疏索引沒有為每個數據都創建一個索引,它比稠密索引節省了更多的存儲空間,但查找給定值的記錄需更多的時間。只有當數據文件是按照某個查找鍵排序時,在該查找鍵上建立的稀疏索引才能被使用,而稠密索引則可以應用在任何的查找鍵。
-
聯合索引:將一張表中多個列組成聯合索引(col1,col2,col3),其生效方式滿足最左前綴原則。
-
覆蓋索引:對於二級索引而言,在innodb中一般是需要先根據二級索引查詢到主鍵,然后在根據一級索引查詢到數據。但是如果select的列都在索引中,就避免進行一級查詢。
4.主鍵選擇
-
在使用InnoDB存儲引擎時,如果沒有特別的需要,請永遠使用一個與業務無關的自增字段作為主鍵。
-
where 1 = 1:能夠方便我們拼sql,但是使用了之后就無法使用索引優化策略,因此會進行全表掃描,影響效率。
5.分表分庫
-
水平拆分:依據表中的數據的邏輯關系,將同一個表中的數據依照某種條件拆分到多台數據庫(主機)上面。按照1個或多個字段以及相應的規則,將一張表重的數據分到多張表中去。比如按照id%5的規則,將一張大表拆分成5張小表。適合具有超大表的系統。
-
垂直拆分:依照不同的表(或者Schema)來切分到不同的數據庫(主機)之上。一般按照模塊來分庫。適合各業務之間耦合度非常低的系統。
6.隔離級別
-
read uncommit:讀不加鎖,寫加共享鎖。會產生臟讀、幻讀。
-
read commit:讀加共享鎖,寫加排它鎖,但不加間隙鎖。間隙鎖的主要作用是防止不可重復讀,但會加大鎖的范圍。
-
repeatable read(innodb默認):讀加共享鎖,寫加間隙排它鎖。注意,Innodb對這個級別進行了特殊處理,使得這個級別能夠避免幻讀,但不是所有引擎都能夠防止幻讀!(網易面試官問)
-
serialization:會給整張表加鎖,強一致,但是效率低。
7.innodb中的鎖
-
MVCC(multi-Version Concurrency Control):讀不加鎖,讀寫不沖突。適合寫少讀多的場景。讀操作分為:快照讀(返回記錄的可見版本,不加鎖)、當前讀(記錄的最新版本,加鎖,保證其它記錄不修改)。
-
LBCC(Lock-Based Concurrency Control):
-
join原理Simple Nested-Loop Join:效率最低,按照join的次序,在join的屬性上一個個掃描,並合並結果。
-
Index Nested-Loop Join:效率最高,join的屬性上面有索引,根據索引來匹配。
-
Block Nested-Loop Join:用於沒有索引的列。它會采用join buffer,將外表的值緩存到join buffer中,然后與內表進行批量比較,這樣可以降低對外表的訪問頻率
8.galera
-
多主架構:真正的多點讀寫的集群,在任何時候讀寫數據,都是最新的。
-
同步復制,各節點間無延遲且節點宕機不會導致數據丟失。
-
緊密耦合,所有節點均保持相同狀態,節點間無不同數據。
-
無需主從切換操作。
-
無需進行讀寫分離。
-
並發復制:從節點在APPLY數據時,支持並行執行,有更好的性能表現。
-
故障切換:在出現數據庫故障時,因為支持多點寫入,切的非常容易。
-
熱插拔:在服務期間,如果數據庫掛了,只要監控程序發現的夠快,不可服務時間就會非常少。在節點故障期間,節點本身對集群的影響非常小。
-
自動節點克隆:在新增節點,或者停機維護時,增量數據或者基礎數據不需要人工手動備份提供,Galera Cluster會自動拉取在線節點數據,最終集群會變為一致。
-
對應用透明:集群的維護,對應用程序是透明的,幾乎感覺不到。
9.LSM Tree,主要應用於nessDB、leveldb、hbase
-
核心思想的核心就是放棄部分讀能力,換取寫入的最大化能力。它假設假定內存足夠大,因此不需要每次有數據更新就必須將數據寫入到磁盤中,而可以先將最新的數據駐留在內存中,等到積累到最后多之后,再使用歸並排序的方式將內存內的數據合並追加到磁盤隊尾。(使用歸並排序是要因為帶排序樹都是有序樹)
-
LSM具有批量特性,存儲延遲。B樹在insert的時候可能會造成分裂,可能會造成隨機讀寫。而LSM將多次單頁隨機寫,變成一次多頁隨機寫,復用了磁盤尋道時間,極大提升效率。
-
LSM Tree放棄磁盤讀性能來換取寫的順序性。
-
一般會使用Bloom Filter來優化LSM。當將內存中的數據與磁盤數據合並的時候,先要判斷數據是否有重復,如果不用Bloom Filter就需要在磁盤上一層層地找,而使用了之后就會降低搜索代價。
多線程
-
synchronized、CAS
-
Collections
-
支持高並發的數據結構,如ConcurrentHashMap
-
基於AQS實現的鎖、信號量、計數器原理
-
Runnable與Callable的區別
-
線程池
-
作用
-
減少在創建和銷毀線程上所花的時間以及系統資源的開銷 。
-
當前任務與主線程隔離,能實現和主線程的異步執行,特別是很多可以分開重復執行的任務。
8.阻塞隊列
9.threadlocal
Spring框架
-
IOC/DI
-
Core、Beans、Context、Expression Language
-
JDBC、ORM、OXM、JMS、Transaction
-
AOP
-
Web
-
Test
-
@Autowired原理
-
工廠模式
-
反射
-
自動配置@ConfigurationProperties(prefix = "hello"):讀取以hello為開頭的配置,屬性類使用
-
@Configuration:指名當前類為配置類
-
@EnableConfigurationProperties(Properties):指名配置屬性類
-
@ConditionalOnClass(Condition.class):條件類,只有Condition.class存在,當前配置類才生效
-
Spring Boot在spring.factories配置了很多全限定名的配置類。
Redis
核心原理
-
常用數據類型String:二進制安全,可以存任何數據,比如序列化的圖片。最大長度位512M.
-
Hash:是KV對集合,本質是String類型的KV映射,適合存儲對象。
-
List:簡單字符串鏈表,可以在left、right兩邊插入,本質是雙向鏈表。緩沖區也是用這個實現。
-
Set:String類型的無序集合,內部實現是一個 value永遠為null的HashMap,實際就是通過計算hash的方式來快速排重的,這也是set能提供判斷一個成員是否在集合內的原因。
-
zset:有序集合,每個元素會關聯一個double類型的score,然后根據score進行排序。注意:元素不能重復,但是score是可以重復的。使用HashMap和跳躍表(SkipList)來保證數據的存儲和有序,HashMap里放的是成員到score的映射,而跳躍表里存放的是所有的成員,排序依據是HashMap里存的score.
-
pub/sub:在Redis中,你可以設定對某一個key值進行消息發布及消息訂閱,當一個key值上進行了消息發布后,所有訂閱它的客戶端都會收到相應的消息。
持久化
-
RDB:一種是手動執行持久化命令來持久化快照;另一種是在配置文件中配置策略,來自動持久化。持久化命令有save、bgsave兩種,bgsave會調用fork命令,產生子進程來進行持久化,而父進程繼續處理數據,但是持久化的快照是fork那一刻的快照,因此這種策略可能會丟失一部分數據。特點:每次都記錄所有數據,恢復快,子進程不影響父進程性能。
-
AOF:append only file,將每條操作命令都記錄到appendonly.aof文件中,但是不會立馬寫入硬盤,我們可以配置always(每有一個命令,都同步)、everysec(每秒同步一次)、no(沒30秒同步一次)。往往everysec就夠了。aof數據損失要比RDB小。特點:有序記錄所有操作,數據丟失更少,會對操作做壓縮優化,bgrewriteaof也會fork子進程,不影響父進程性能
事務
-
Transactions:不是嚴格的ACID的事務,但是這個Transactions還是提供了基本的命令打包執行的功能(在服務器不出問題的情況下,可以保證一連串的命令是順序在一起執行的,中間有會有其它客戶端命令插進來執行)。
-
Redis還提供了一個Watch功能,你可以對一個key進行Watch,然后再執行Transactions,在這過程中,如果這個Watched的值進行了修改,那么這個Transactions會發現並拒絕執行。
KafKA
-
topic
-
broker
-
partition
-
consumer
-
producer
-
stream
-
存儲機制
-
網絡模型
-
注意:partition之間是無序的
-
消息隊列的生產者消費者中消費者沒有收到消息怎么辦,消息有順序比如1.2.3但是收到的卻是1.3.2怎么辦?消息發過來的過程中損壞或者出錯怎么辦
Spring security
-
攔截器棧
-
@PreAuthorize
-
@PostAuthorize
-
支持Expression Language
jvm原理
內存模型、垃圾收集器、CMS與G1是重點
垃圾收集算法
-
標記-清除(CMS)容易產生碎片,當碎片太多會提前觸發Full GC
-
復制(年輕代基本用這個算法)會浪費一半的可能感覺
-
標記-整理(serial Old、Parallel Old)
-
Serial:采用單線程stop-the-world的方式進行收集。當內存不足時,串行GC設置停頓標識,待所有線程都進入安全點(Safepoint)時,應用線程暫停,串行GC開始工作,采用單線程方式回收空間並整理內存。串行收集器特別適合堆內存不高、單核甚至雙核CPU的場合。
-
ParNew
-
Parallel Scavenge
CMS:
-
初始標記(stop of world)
-
並行標記、預清理
-
重新標記(stop of world)
-
並行清理
G1
將堆分成很多region,可以同時堆年輕代與老年代進行收集
-
初始標記(stop of world):初始標記(Initial Mark)負責標記所有能被直接可達的根對象(原生棧對象、全局對象、JNI對象)
-
並行標記:
-
重新標記(stop of world):
-
清理(stop of world):
-
重置
gc觸發條件
-
從年輕代分區拷貝存活對象時,無法找到可用的空閑分區,會觸發Minor GC
-
從老年代分區轉移存活對象時,無法找到可用的空閑分區,會觸發Major GC
-
分配巨型對象時在老年代無法找到足夠的連續分區,會觸發Major GC
-
可達性分析:通過檢查一塊內存空間能否被root達到,來判斷是否對其進行回收。
jdk不同版本新增的部分特性
jvm調優
-
VisualVM:JDK自帶JVM可視化工具,能過對內存、gc、cpu、thread、class、變量等等信息進行可視化。
設計模式
-
單例雙重檢查
-
觀察者模式
-
裝飾者模式:jdk中輸入輸出流用到了該模式
-
適配器模式:jdk中Reader、writer用到了該模式
-
代理模式
-
靜態代理
-
JDK動態代理
-
Cglib到動態代理
-
生產者消費者模式
-
工廠模式
項目管理與運維工具
-
git+Jenkins
-
maven
-
K8Spod:Pod是所有業務類型的基礎,所有的容器均在Pod中運行,它是一個或多個容器的組合。每一個Pod都會被指派一個唯一的Ip地址,在Pod中的每一個容器共享網絡命名空間,包括Ip地址和網絡端口。Pod能夠被指定共享存儲卷的集合,在Pod中所有的容器能夠訪問共享存儲卷,允許這些容器共享數據。
-
kubelet:kubelet負責管理pods和它們上面的容器,images鏡像、volumes、etc。
-
ingress,用於負載均衡
-
docker
-
docker與虛擬機的區別
數據結構
-
平衡二叉樹AVL
-
高度log(n)
-
插入時間復雜度log(n)
-
紅黑樹
-
插入時間復雜度log(n)
-
查找時間復雜度log(n)
-
在查找是,紅黑樹雖然復雜度也是log(n),但是從效率上比要略低於AVL。但是其優勢在於插入元素的時候,不會像AVL那樣頻繁地旋轉。
-
B+Tree:只有葉子節點存值,非葉子節點只存key和child,因此同樣大小的物理頁上能存放更多的節點。每一層的節點數量越多,意味着層次越少,也就意味着IO次數越少,因此非常適合數據庫以及文件系統。
-
大根堆:采用數組存儲樹,是一個完全樹。先插入到數組最后的位置上,然后采用上浮的思想,將該元素與比它小的父元素調換,直到parent>target,浮到root;然后將root與未排序的最后一個元素交換位置;重復以上步驟,直到所有元素都有序。插入如查找的復雜度都是log(n)。
-
優先隊列PriorityQueue,Java中使用小根堆實現,非線程安全。
-
優先阻塞隊列PriorityBlockQueue,線程安全。
算法
-
快排
-
時間復雜度O(nlog(n))
-
空間復雜度O(log(n))
-
堆排序
-
時間復雜度O(nlog(n))
-
空間復雜度O(1)
-
歸並排序
-
時間復雜度O(nlog(n))
-
空間復雜度O(n)
-
跳表時間復雜度O(log(n))
-
空間復雜度O(2n)
-
高度O(log(n))
分布式
cap理論
-
可用性
-
一致性
-
分區容忍性:對網絡斷開的容忍度,有點像魯棒性
-
拜占庭將軍問題
Raft 算法
-
有leader、follower、candidate
同步流程
-
由客戶端提交數據到Leader節點。
-
由Leader節點把數據復制到集群內所有的Follower節點。如果一次復制失敗,會不斷進行重試。
-
Follower節點們接收到復制的數據,會反饋給Leader節點。
-
如果Leader節點接收到超過半數的Follower反饋,表明復制成功。於是提交自己的數據,並通知客戶端數據提交成功。
-
由Leader節點通知集群內所有的Follower節點提交數據,從而完成數據同步流程。
zookeeper
-
Zab(Zookeeper Atomic Broadcast)協議,有兩種模式:
-
它們分別是:恢復模式(選主)和廣播模式(同步)。
-
有兩種算法:1. basic paxos;2. fast paxos(默認)
-
文件系統:zookeeper的通知機制、分布式鎖、隊列管理、配置管理都是基於文件系統的。
-
分布式鎖:有了zookeeper的一致性文件系統,鎖的問題變得容易。鎖服務可以分為兩類,一個是保持獨占,另一個是控制時序。
-
獨占鎖:將zookeeper上的一個znode看作是一把鎖,通過createznode的方式來實現。所有客戶端都去創建 /distribute_lock 節點,最終成功創建的那個客戶端也即擁有了這把鎖。用完刪除掉自己創建的distribute_lock 節點就釋放出鎖。
-
控制時序鎖:/distribute_lock 已經預先存在,所有客戶端在它下面創建臨時順序編號目錄節點,和選master一樣,編號最小的獲得鎖,用完刪除。
-
隊列管理,分為同步隊列、非同步隊列
-
數據復制的好處
-
容錯:一個節點出錯,不致於讓整個系統停止工作,別的節點可以接管它的工作;
-
提高系統的擴展能力 :把負載分布到多個節點上,或者增加節點來提高系統的負載能力;
-
提高性能:讓客戶端本地訪問就近的節點,提高用戶訪問速度。
5.一致性hash算法原理
微服務
Spring cloud
-
網關:zuul
-
分布式版本化配置 config
-
服務注冊和發現:Eureka,配置時需要注意多久刷新列表一次,多久監測心跳等。
-
service-to-service 調用
-
負載均衡:Ribbon;在生成RestTemplate的bean時,通過@LoadBalanced注解可以使得RestTemplate的調用
-
斷路器:Hystrix
-
監控:spring admin。在啟動類上加@EnableAdminServer注解。
java web
-
servlet工作原理
-
tomcat工作原理,好文,強推
-
container
linux
-
系統結構,講得很好,強推
-
硬鏈接與軟連接
-
硬鏈接:數據節點通過引用計數的方式來對指向它的硬鏈接計數,當計數為0就刪除。
-
軟連接:我們可以把它看成是快捷方式,它只是記錄了某個文件的硬鏈接的路徑,如果我們把源文件刪除,再重新創建一個相同名字的文件,那么軟連接指向的就是新創建的文件。
-
虛擬文件系統(VFS):文件系統是有很多實現的,比如ext2、ext3、FAT等等,而VFS則是存在於應用程序與文件系統中間,它封裝了open、close、read、write等等操作文件系統的接口,為應用程序屏蔽掉不同文件系統之間的差異。
-
VFS數據結構
其它
-
bitmap,大文件交集
-
Elasticsearch索引原理
-
從內存到屏幕經歷了啥
-
高並發場景的限流,你怎么來確定限流限多少,模擬場景和實際場景有區別怎么解決,
百度面試
-
說一下redis與kafka,redis持久化策略
-
git中rebase與merge區別
-
docker底層原理,依賴操作系統的什么
-
ls -l | grep xxx的執行過程,盡可能的細,是多進程還是單進程?
-
兩個有序數組求中位數
-
算法 3Sum、中序遍歷非遞歸實現、循環打印矩陣
-
final、finally、finanize
-
jvm內存模型
-
垃圾回收器
-
Spring特點介紹下
-
Synchronize與ReentrantLock的區別、使用場景
-
CAS使用場景
-
聊了下git+jekins+K8S+docker實現自動化部署
-
innodb原理,使用場景,與MYISAM在場景上的區別
-
weakReference、softReference等
-
Hbase的原理,LSM Tree
-
Linux中,哪種進程可以使用管道
美團
-
權限模型
-
介紹下線程池,阻塞隊列的用法,無界隊列真的無界嗎?
-
說一下redis
-
kafka存儲模型與網絡模型
-
zookeeper與redis實現分布式鎖
-
樂觀鎖與悲觀鎖
-
算法:有n個人,給你ai與aj的身高關系,如ai比aj高,進行身高排序,如果條件不滿足,則輸出“不滿足”
-
Spring boot的特性


溫馨提示
如果你喜歡本文,請分享到朋友圈,想要獲得更多信息,請關注我。關注本文說說你的看法吧,下方評論哦。。。Java勸退師........
想獲取上方資料加群:859729143 點擊閱讀原文即可進群
掃一掃即可領取資料學習
微信掃一掃
關注該公眾號