一、計算機網(wǎng)絡(luò)
1.1 三次握手&四次揮手
客戶端——發(fā)送帶有SYN標(biāo)志的數(shù)據(jù)包——服務(wù)端 一次握手 Client進(jìn)入syn_sent狀態(tài)
服務(wù)端——發(fā)送帶有SYN/ACK標(biāo)志的數(shù)據(jù)包——客戶端 二次握手 服務(wù)端進(jìn)入syn_rcvd
客戶端——發(fā)送帶有ACK標(biāo)志的數(shù)據(jù)包——服務(wù)端 三次握手 連接就進(jìn)入Established狀態(tài)
為什么一定要三次
假設(shè)A發(fā)送消息給B AB兩端都需要確保自己的發(fā)送能力&接受能力沒問題
第一次 A-》B
A視角
A接收能力 | A發(fā)送能力 | B接收能力 | B發(fā)送能力 |
---|---|---|---|
未知 | 未知 | 未知 | 未知 |
B視角
A接收能力 | A發(fā)送能力 | B接收能力 | B發(fā)送能力 |
---|---|---|---|
未知 | 沒問題 | 沒問題 | 未知 |
第二次 B-》A
A視角
A接收能力 | A發(fā)送能力 | B接收能力 | B發(fā)送能力 |
---|---|---|---|
沒問題 | 沒問題 | 沒問題 | 沒問題 |
B視角
A接收能力 | A發(fā)送能力 | B接收能力 | B發(fā)送能力 |
---|---|---|---|
未知 | 沒問題 | 沒問題 | 未知 |
第三次 A-》B
A視角
A接收能力 | A發(fā)送能力 | B接收能力 | B發(fā)送能力 |
---|---|---|---|
沒問題 | 沒問題 | 沒問題 | 沒問題 |
B視角
A接收能力 | A發(fā)送能力 | B接收能力 | B發(fā)送能力 |
---|---|---|---|
沒問題 | 沒問題 | 沒問題 | 沒問題 |
1.1.1 四次揮手
由于TCP半關(guān)閉特性(half-close),TCP可以在連接的一端結(jié)束他的消息發(fā)送后還能接受另一端的消息。所以AB兩端都需要告訴對方我這里消息發(fā)送結(jié)束了悯衬,另一方都需要確認(rèn)筋粗。
其中timeWait是為了避免消息發(fā)送結(jié)束請求超時击胜,在重新建立新的連接后到達(dá)導(dǎo)致的數(shù)據(jù)問題。也可以理解為保存上下文暇唾,如果消息發(fā)送結(jié)束請求發(fā)送完成后并沒有受到確認(rèn)消息策州,而上下文信息已經(jīng)被刪掉的話就無法重試了。
TIME_WAIT時間會被設(shè)定為2MSL旁仿,MSL是報文最大生存時間枯冈。
可以參考:TCP四次揮手詳解(含常見面試題)
1.2 網(wǎng)絡(luò)架構(gòu)
OSI七層:物理層办悟、數(shù)據(jù)鏈路層病蛉、網(wǎng)絡(luò)層、傳輸層俗孝、會話層魄健、表示層沽瘦、應(yīng)用層
TCP/IP五層:物理層、數(shù)據(jù)鏈路層苛蒲、網(wǎng)絡(luò)層绿满、傳輸層喇颁、應(yīng)用層
應(yīng)用層:HTTP、SMTP蔫浆、DNS瓦盛、FTP
傳輸層:TCP 、UDP
網(wǎng)絡(luò)層:ICMP 挠唆、IP玄组、路由器谒麦、防火墻
數(shù)據(jù)鏈路層:網(wǎng)卡绕德、網(wǎng)橋、交換機
物理層:中繼器、集線器
基于TCP的協(xié)議:HTTP城丧、FTP豌鹤、SMTP
基于UDP的協(xié)議:RIP布疙、DNS、SNMP
1.2.1 TCP滑動窗口 & 擁塞控制 & 粘包原因和解決方法
https://zhuanlan.zhihu.com/p/650019037
1.2.2http&https
https結(jié)局了http的不安全的缺陷 在tcp和http之間加入了ssl/tls協(xié)議 在三次握手的基礎(chǔ)上加入了ssl/tls協(xié)議握手過程后方可進(jìn)行加密的數(shù)據(jù)傳輸
https用了對稱加密 & 非對稱加密 后者用于交換密鑰 后者用于加密銘文數(shù)據(jù)
https用了摘要算法 保障數(shù)據(jù)不被更改截型,根據(jù)內(nèi)容生成摘要
https利用了數(shù)字證書 借用第三方結(jié)構(gòu)CA 證書可信公鑰就是可信的
http/2 相較之前做了頭部壓縮 消除了重復(fù)的部分 明文報文改成二進(jìn)制 增加了傳輸效率 傳輸模式不在按照順序發(fā)送宦焦,按照數(shù)據(jù)流模式波闹,每個數(shù)據(jù)流有一個獨一無二的編號涛碑。多路復(fù)用 并發(fā)發(fā)多個請求不需要按照順序來 防止頭部阻塞問題
1.2.3 udp
http/3 底層不再使用tcp 而是使用udp
udp的QUIC協(xié)議可以實現(xiàn)可靠性傳輸
QUIC協(xié)議
這個需要去看下
二蒲障、MYSQL
2.1
三、操作系統(tǒng)
為什么要有用戶態(tài)和內(nèi)核態(tài)
由于需要限制不同的程序之間的訪問能力, 防止他們獲取別的程序的內(nèi)存數(shù)據(jù), 或者獲取外圍設(shè)備的數(shù)據(jù), 并發(fā)送到網(wǎng)絡(luò)
用戶態(tài)切換到內(nèi)核態(tài)的3種方式
a. 系統(tǒng)調(diào)用
主動調(diào)用滋捶,系統(tǒng)調(diào)用的機制其核心還是使用了操作系統(tǒng)為用戶特別開放的一個中斷來實現(xiàn)重窟,例如Linux的int 80h中
b. 異常
當(dāng)CPU在執(zhí)行運行在用戶態(tài)下的程序時巡扇,發(fā)生了某些事先不可知的異常,比如缺頁異常乖坠,這時會觸發(fā)切換內(nèi)核態(tài)處
理異常熊泵。
c. 外圍設(shè)備的中斷
當(dāng)外圍設(shè)備完成用戶請求的操作后甸昏,會向CPU發(fā)出相應(yīng)的中斷信號施蜜,這時CPU會由用戶態(tài)到內(nèi)核態(tài)的切換。
操作系統(tǒng)的進(jìn)程空間
頁式管理缸沃、段式管理趾牧、段頁式管理
頁式管理
在頁式存儲管理中武氓,將程序的邏輯地址劃分為固定大小的頁(page)仇箱,而物理內(nèi)存劃分為同樣大小的頁框剂桥,程序加 載時,可以將任意一頁放入內(nèi)存中任意一個頁框美尸,這些頁框不必連續(xù),從而實現(xiàn)了離散分離恕酸。頁式存儲管理的優(yōu)點 是:沒有外碎片(因為頁的大小固定)蕊温,但會產(chǎn)生內(nèi)碎片(一個頁可能填充不滿)
優(yōu)點:沒有外碎片义矛,每個內(nèi)碎片不超過頁的大小盟萨。
缺點:程序全部裝入內(nèi)存捻激,要求有相應(yīng)的硬件支持胞谭,如地址變換機構(gòu)缺頁中斷的產(chǎn)生和選擇淘汰頁面等都要求有相應(yīng)的硬件支持。增加了機器成本和系統(tǒng)開銷
段式管理
將程序的地址空間劃分為若干段(segment),如代碼段势就,數(shù)據(jù)段泉瞻,堆棧段;這樣每個進(jìn)程有一個二維地址空間, 相互獨立苞冯,互不干擾袖牙。段式管理的優(yōu)點是:沒有內(nèi)碎片(因為段大小可變,改變段大小來消除內(nèi)碎片)舅锄。但段換入 換出時鞭达,會產(chǎn)生外碎片(比如4k的段換5k的段,會產(chǎn)生1k的外碎片)(分配的空間用完了 但是每個頁之間的空隙)
優(yōu)點:可以分別編寫和編譯皇忿,可以針對不同類型的段采取不同的保護(hù),可以按段為單位來進(jìn)行共享鳍烁,包括通過動態(tài)鏈接進(jìn)行代碼共享叨襟。
缺點:會產(chǎn)生碎片。
段頁式管理
段?式管理機制結(jié)合了段式管理和?式管理的優(yōu)點幔荒。簡單來說段?式管理機制就是把主存先分成若干段糊闽,每個段又 分成若干?梳玫,也就是說 段?式管理機制 中段與段之間以及段的內(nèi)部的都是離散的
優(yōu)缺點
https://zhuanlan.zhihu.com/p/512331932
頁面置換算法
先進(jìn)先出FIFO
缺點:沒有考慮到實際的頁面使用頻率,性能差右犹、與通常頁面使用的規(guī)則不符合提澎,實際應(yīng)用較少
最近最久未使用LRU
原理:選擇最近且最久未使用的頁面進(jìn)行淘汰
優(yōu)點:考慮到了程序訪問的時間局部性,有較好的性能念链,實際應(yīng)用也比較多
缺點:沒有合適的算法盼忌,只有適合的算法,lFU钓账、random都可以
最佳置換算法OPT
原理:每次選擇當(dāng)前物理塊中的頁面在未來長時間不被訪問的或未來不再使用的頁面進(jìn)行淘汰
優(yōu)點:具有較好的性能碴犬,可以保證獲得最低的缺頁率
缺點:過于理想化,但是實際上無法實現(xiàn)(沒辦法預(yù)知未來的頁面)
死鎖
死鎖的條件
互斥條件:進(jìn)程對所分配到的資源不允許其他進(jìn)程訪問梆暮,若其他進(jìn)程訪問該資源服协,只能等待至占有該資源的進(jìn)程釋
放該資源;
請求與保持條件:進(jìn)程獲得一定的資源后啦粹,又對其他資源發(fā)出請求偿荷,阻塞過程中不會釋放自己已經(jīng)占有的資源
非剝奪條件:進(jìn)程已獲得的資源,在未完成使用之前唠椭,不可被剝奪跳纳,只能在使用后自己釋放
循環(huán)等待條件:系統(tǒng)中若干進(jìn)程組成環(huán)路,環(huán)路中每個進(jìn)程都在等待相鄰進(jìn)程占用的資源
四贪嫂、Redis
寫時復(fù)制 CopyOnWrite
https://www.cnblogs.com/jelly12345/p/15223184.html
當(dāng)父進(jìn)程或者子進(jìn)程對共享的內(nèi)存進(jìn)行修改時寺庄,共享的內(nèi)存才會以頁為單位進(jìn)行拷貝,父進(jìn)程會保留原有的物理空間力崇,而子進(jìn)程會使用拷貝后的新物理空間斗塘;
面向?qū)ο笕筇匦?/h1>
特性:封裝、繼承亮靴、多態(tài)
封裝:對抽象的事物抽象化成一個對象馍盟,并對其對象的屬性私有化,同時提供一些能被外界訪問屬性的方法茧吊;
繼承:子類擴展新的數(shù)據(jù)域或功能贞岭,并復(fù)用父類的屬性與功能,單繼承搓侄,多實現(xiàn)瞄桨;
多態(tài):通過繼承(多個子類對同一方法的重寫)、也可以通過接口(實現(xiàn)接口并覆蓋接口)
CopyOnWriteArrayList
https://www.zhihu.com/question/438808963/answer/1673676355
synchronize & ReentrantLock
synchronize 效率低是因為依賴于底層的操作系統(tǒng)的MutexLoCK 會從用戶態(tài)轉(zhuǎn)核心態(tài) 同時鎖的粒度 還有并發(fā)性受限
ReentrantLock
IOC容器初始化加載Bean流程:
四個階段
? 實例化 Instantiation
? 屬性賦值 Populate
? 初始化 Initialization
? 銷毀 Destruction
完整流程
- 實例化一個Bean--也就是我們常說的new;
- 按照Spring上下文對實例化的Bean進(jìn)行配置--也就是IOC注入;
- 如果這個Bean已經(jīng)實現(xiàn)了BeanNameAware接口讶踪,會調(diào)用它實現(xiàn)的setBeanName(String)方法讲婚,也就是根據(jù)就是Spring配置文件中Bean的id和name進(jìn)行傳遞
- 如果這個Bean已經(jīng)實現(xiàn)了BeanFactoryAware接口,會調(diào)用它實現(xiàn)setBeanFactory(BeanFactory)也就是Spring配置文件配置的Spring工廠自身進(jìn)行傳遞;
- 如果這個Bean已經(jīng)實現(xiàn)了ApplicationContextAware接口俊柔,會調(diào)用setApplicationContext(Application-Context)方法筹麸,和4傳遞的信息一樣但是因為ApplicationContext是BeanFactory的子接口活合,所以更加靈活
- 如果這個Bean關(guān)聯(lián)了BeanPostProcessor接口,將會調(diào)用postProcessBeforeInitialization()方法物赶,Bean PostProcessor經(jīng)常被用作是Bean內(nèi)容的更改白指,由于這個是在Bean初始化結(jié)束時調(diào)用那個的方法,也可以被應(yīng)用于內(nèi)存或緩存技術(shù)
- 如果Bean在Spring配置文件中配置了init-method屬性會自動調(diào)用其配置的初始化方法酵紫。
- 如果這個Bean關(guān)聯(lián)了BeanPostProcessor接口告嘲,將會調(diào)用postProcessAfterInitialization(),打印日志或者三級緩存技術(shù)里面的bean升級
- 以上工作完成以后就可以應(yīng)用這個Bean了奖地,那這個Bean是一個Singleton的橄唬,所以一般情況下我們調(diào)用同一個id的Bean會是在內(nèi)容地址相同的實例,當(dāng)然在Spring配置文件中也可以配置非Singleton参歹,這里我們不做贅述仰楚。
- 當(dāng)Bean不再需要時,會經(jīng)過清理階段犬庇,如果Bean實現(xiàn)了DisposableBean這個接口僧界,或者根據(jù)spring配置的destroy-method屬性,調(diào)用實現(xiàn)的destroy()方法
循環(huán)依賴
#######三級緩存解決循環(huán)依賴問題
#######懶加載@Lazy解決循環(huán)依賴問題
Spring啟動的時候會把所有bean信息(包括XML和注解)解析轉(zhuǎn)化成Spring能夠識別的BeanDefinition并存到 Hashmap里供下面的初始化時用臭挽,然后對每個 BeanDefinition 進(jìn)行處理捂襟。普通 Bean 的初始化是在容器啟動初始 化階段執(zhí)行的,而被lazy-init=true修飾的 bean 則是在從容器里第一次進(jìn)行context.getBean() 時進(jìn)行觸發(fā)欢峰。
紅黑樹
其他
CI框架
Nginx內(nèi)存模型
io磁盤尋道
索引原理 &聚集葬荷、非聚集
Mysql性能優(yōu)化
不利用外鍵搜索 & 索引失效的情況
MYSQL safePoint
一致性hash算法
concurrentHashMap
HashMap為什么線程不安全
Mybatis和Hibernate區(qū)別
Java內(nèi)存模型 主存&本地內(nèi)存
Java時間監(jiān)聽機制& 源碼解析
reentrantLock
Spring源碼
核心類
- defaultListableBeanFactory
- abstractautowireCapableBeanFactory
- GenericBeanDefinition