摘要：表示連接已經(jīng)成功建立。在這個(gè)狀態(tài)下，應(yīng)用程序還有接受數(shù)據(jù)的能力，但是已經(jīng)無法發(fā)送數(shù)據(jù)。表示收到了對(duì)方的報(bào)文，并發(fā)送出了報(bào)文。狀態(tài)下的連接會(huì)等待罕見的狀態(tài)。在窗口中還沒有發(fā)出的接收方還有空間。進(jìn)程的親緣關(guān)系通常是指父子進(jìn)程關(guān)系。

只有光頭才能變強(qiáng)

本文力求簡(jiǎn)單講清每個(gè)知識(shí)點(diǎn)，希望大家看完能有所收獲

使用多線程時(shí)，不是多線程能提升程序的執(zhí)行速度，使用多線程是為了更好地利用CPU資源！

程序在執(zhí)行時(shí)，多線程是CPU通過給每個(gè)線程分配CPU時(shí)間片來實(shí)現(xiàn)的，時(shí)間片是CPU分配給每個(gè)線程執(zhí)行的時(shí)間，因時(shí)間片非常短，所以CPU通過不停地切換線程執(zhí)行。

線程不是越多就越好的，因?yàn)榫€程上下文切換是有性能損耗的，在使用多線程的同時(shí)需要考慮如何減少上下文切換

一般來說有以下幾條經(jīng)驗(yàn)

無鎖并發(fā)編程。多線程競(jìng)爭(zhēng)時(shí)，會(huì)引起上下文切換，所以多線程處理數(shù)據(jù)時(shí)，可以用一些辦法來避免使用鎖，如將數(shù)據(jù)的ID按照Hash取模分段，不同的線程處理不同段的數(shù)據(jù)

CAS算法。Java的Atomic包使用CAS算法來更新數(shù)據(jù)，而不需要加鎖。

控制線程數(shù)量。避免創(chuàng)建不需要的線程，比如任務(wù)很少，但是創(chuàng)建了很多線程來處理，這樣會(huì)造成大量線程都處于等待狀態(tài)

協(xié)程。在單線程里實(shí)現(xiàn)多任務(wù)的調(diào)度，并在單線程里維持多個(gè)任務(wù)間的切換

協(xié)程可以看成是用戶態(tài)自管理的“線程”。不會(huì)參與CPU時(shí)間調(diào)度，沒有均衡分配到時(shí)間。非搶占式的

還可以考慮我們的應(yīng)用是IO密集型的還是CPU密集型的。

如果是IO密集型的話，線程可以多一些。

如果是CPU密集型的話，線程不宜太多。

參考資料：

多線程編程-減少上下文切換（1）：https://blog.csdn.net/yxpjx/article/details/52081034

多線程上下文切換優(yōu)化與注意：https://www.cnblogs.com/signheart/p/3e3379943de1c36d5bcc7d8cee4b9825.html

或者可以反過來問：已經(jīng)有IP地址了，為什么需要MAC地址？？在zhihu上還蠻多類似的問題的：

我來簡(jiǎn)單總結(jié)一下為什么有了MAC(IP)還需要IP(MAC)：

MAC是鏈路層，IP是網(wǎng)絡(luò)層，每一層干每一層的事兒，之所以在網(wǎng)絡(luò)上分鏈路層、網(wǎng)絡(luò)層(...，就是將問題簡(jiǎn)單化。

歷史的兼容問題。

已經(jīng)有IP地址了，為什么需要MAC地址？？

現(xiàn)階段理由：DHCP基于MAC地址分配IP。

MAC地址已經(jīng)是唯一了，為什么需要IP地址？

MAC無網(wǎng)段概念，非類聚，不好管理。

如果有更好的看法，不妨在評(píng)論區(qū)下留言哦~

參考資料：

MAC地址唯一，不能滿足通信需求嗎？為什么需要IP？https://www.wukong.com/answer/6549169419812077827/

有了 IP 地址，為什么還要用 MAC 地址？https://www.zhihu.com/question/21546408

TCP 每個(gè)狀態(tài)說一下，TIME-WAIT狀態(tài)說一下

TCP總共有11個(gè)狀態(tài)，狀態(tài)之間的轉(zhuǎn)換是這樣的：

流程圖：

下面我簡(jiǎn)單總結(jié)一下每個(gè)狀態(tài)：

CLOSED：初始狀態(tài)，表示TCP連接是“關(guān)閉著的”或“未打開的”。

LISTEN：表示服務(wù)器端的某個(gè)SOCKET處于監(jiān)聽狀態(tài)，可以接受客戶端的連接。

SYN-SENT：表示客戶端已發(fā)送SYN報(bào)文。當(dāng)客戶端SOCKET執(zhí)行connect()進(jìn)行連接時(shí)，它首先發(fā)送SYN報(bào)文，然后隨即進(jìn)入到SYN_SENT狀態(tài)。

SYN_RCVD：表示服務(wù)器接收到了來自客戶端請(qǐng)求連接的SYN報(bào)文。當(dāng)TCP連接處于此狀態(tài)時(shí)，再收到客戶端的ACK報(bào)文，它就會(huì)進(jìn)入到ESTABLISHED狀態(tài)。

ESTABLISHED：表示TCP連接已經(jīng)成功建立。

FIN-WAIT-1：第一次主動(dòng)請(qǐng)求關(guān)閉連接,等待對(duì)方的ACK響應(yīng)。

CLOSE_WAIT：對(duì)方發(fā)了一個(gè)FIN報(bào)文給自己，回應(yīng)一個(gè)ACK報(bào)文給對(duì)方。此時(shí)進(jìn)入CLOSE_WAIT狀態(tài)。

接下來呢，你需要檢查自己是否還有數(shù)據(jù)要發(fā)送給對(duì)方，如果沒有的話，那你也就可以close()這個(gè)SOCKET并發(fā)送FIN報(bào)文給對(duì)方，即關(guān)閉自己到對(duì)方這個(gè)方向的連接

FIN-WAIT-2：主動(dòng)關(guān)閉端接到ACK后，就進(jìn)入了FIN-WAIT-2。在這個(gè)狀態(tài)下，應(yīng)用程序還有接受數(shù)據(jù)的能力，但是已經(jīng)無法發(fā)送數(shù)據(jù)。

LAST_ACK：當(dāng)被動(dòng)關(guān)閉的一方在發(fā)送FIN報(bào)文后，等待對(duì)方的ACK報(bào)文的時(shí)候，就處于LAST_ACK 狀態(tài)

CLOSED：當(dāng)收到對(duì)方的ACK報(bào)文后，也就可以進(jìn)入到CLOSED狀態(tài)了。

TIME_WAIT：表示收到了對(duì)方的FIN報(bào)文，并發(fā)送出了ACK報(bào)文。TIME_WAIT狀態(tài)下的TCP連接會(huì)等待2*MSL

CLOSING：罕見的狀態(tài)。表示雙方都正在關(guān)閉SOCKET連接

TIME_WAIT狀態(tài)一般用來處理以下兩個(gè)問題：

關(guān)閉TCP連接時(shí)，確保最后一個(gè)ACK正常運(yùn)輸(或者可以認(rèn)為是：等待以便重傳ACK)

網(wǎng)絡(luò)上可能會(huì)有殘余的數(shù)據(jù)包，為了能夠正常處理這些殘余的數(shù)據(jù)包。使用TIME-WAIT狀態(tài)可以確保在創(chuàng)建新連接時(shí)，先前網(wǎng)絡(luò)中殘余的數(shù)據(jù)都丟失了。

TIME_WAIT過多怎么解決？

如果在高并發(fā)，多短鏈接情景下，TIME_WAIT就會(huì)過多。

可以通過調(diào)整內(nèi)核參數(shù)解決：vi /etc/sysctl.conf 加入以下內(nèi)容設(shè)置：

reuse是表示是否允許重新應(yīng)用處于TIME-WAIT狀態(tài)的socket用于新的TCP連接；

recyse是加速TIME-WAIT sockets回收

我們可以知道TIME_WAIT狀態(tài)是主動(dòng)關(guān)閉連接的一方出現(xiàn)的，我們不要輕易去使用上邊兩個(gè)參數(shù)。先看看是不是可以重用TCP連接來盡量避免這個(gè)問題(比如我們HTTP的KeepAlive)~

參考資料：

TCP/IP詳解--TCP連接中TIME_WAIT狀態(tài)過多：https://blog.csdn.net/yusiguyuan/article/details/21445883

TCP連接的狀態(tài)詳解以及故障排查：https://blog.csdn.net/hguisu/article/details/38700899

TCP的11種狀態(tài)：https://www.cnblogs.com/qingergege/p/6603488.html

TCP是一個(gè)可靠的傳輸協(xié)議，它要保證所有的數(shù)據(jù)包都可以到達(dá)，這需要重傳機(jī)制來支撐。

重傳機(jī)制有以下幾種：

超時(shí)重傳

快速重傳

SACK 方法

滑動(dòng)窗口可以說是TCP非常重要的一個(gè)知識(shí)點(diǎn)。TCP的滑動(dòng)窗口主要有兩個(gè)作用：

提供TCP的可靠性

提供TCP的流控特性

簡(jiǎn)略滑動(dòng)窗口示意圖：

詳細(xì)滑動(dòng)窗口示意圖：

#1已收到ack確認(rèn)的數(shù)據(jù)。

#2發(fā)還沒收到ack的。

#3在窗口中還沒有發(fā)出的（接收方還有空間）。

#4窗口以外的數(shù)據(jù)（接收方?jīng)]空間）

接受端控制發(fā)送端的圖示：

TCP不是一個(gè)自私的協(xié)議，當(dāng)擁塞發(fā)生的時(shí)候，要做自我犧牲。就像交通阻塞一樣，每個(gè)車都應(yīng)該把路讓出來，而不要再去搶路了

擁塞控制主要是四個(gè)算法：

1）慢啟動(dòng)，

2）擁塞避免，

3）擁塞發(fā)生，

4）快速恢復(fù)

擁塞控制的作用：

擁塞的判斷：

重傳定時(shí)器超時(shí)

收到三個(gè)相同（重復(fù)）的 ACK

強(qiáng)烈建議閱讀：

TCP 的那些事兒（上）：https://coolshell.cn/articles/11564.html

TCP 的那些事兒（下）：https://coolshell.cn/articles/11609.html

參考資料：

TCP連續(xù)ARQ協(xié)議和滑動(dòng)窗口協(xié)議：https://www.cnblogs.com/blythe/articles/7348812.html

運(yùn)輸層

TCP/IP(十一)TCP滑動(dòng)窗口和擁塞控制：https://blog.csdn.net/endlu/article/details/51140213

TCP-IP詳解：滑動(dòng)窗口（Sliding Window）：https://blog.csdn.net/wdscq1234/article/details/52444277

TCP擁塞控制-慢啟動(dòng)、擁塞避免、快重傳、快啟動(dòng)：https://blog.csdn.net/jtracydy/article/details/52366461

TCP協(xié)議的滑動(dòng)窗口具體是怎樣控制流量的？https://www.zhihu.com/question/32255109

unix/linux環(huán)境下

僵尸進(jìn)程：

父進(jìn)程創(chuàng)建出子進(jìn)程，子進(jìn)程退出了，父進(jìn)程沒有調(diào)用wait或waitId獲取子進(jìn)程的信息(狀態(tài))，子進(jìn)程的描述符仍在系統(tǒng)中。

孤兒進(jìn)程：

父進(jìn)程退出，子進(jìn)程仍在運(yùn)行中。這些子進(jìn)程就叫做孤兒進(jìn)程，孤兒進(jìn)程將被init進(jìn)程(進(jìn)程號(hào)為1)所收養(yǎng)，并由init進(jìn)程對(duì)它們完成狀態(tài)收集工作

僵尸進(jìn)程危害：

系統(tǒng)進(jìn)程表是一項(xiàng)有限資源，如果系統(tǒng)進(jìn)程表被僵尸進(jìn)程耗盡的話，系統(tǒng)就可能無法創(chuàng)建新的進(jìn)程。

一個(gè)父進(jìn)程創(chuàng)建了很多子進(jìn)程，就是不回收，會(huì)造成內(nèi)存資源的浪費(fèi)。

解決僵尸進(jìn)程的手段：

殺掉父進(jìn)程，余下的僵尸進(jìn)程會(huì)成為孤兒進(jìn)程，最后被init進(jìn)程管理

子進(jìn)程退出時(shí)向父進(jìn)程發(fā)送SIGCHILD信號(hào)，父進(jìn)程處理SIGCHILD信號(hào)。在信號(hào)處理函數(shù)中調(diào)用wait進(jìn)行處理僵尸進(jìn)程

fork兩次：原理是將子進(jìn)程成為孤兒進(jìn)程，從而其的父進(jìn)程變?yōu)閕nit進(jìn)程，通過init進(jìn)程可以處理僵尸進(jìn)程

參考資料：

僵尸進(jìn)程和僵死進(jìn)程有什么區(qū)別?https://www.zhihu.com/question/26432067/answer/70643183

孤兒進(jìn)程與僵尸進(jìn)程[總結(jié)]：http://www.cnblogs.com/Anker/p/3271773.html

首先要知道的是：進(jìn)程和線程的關(guān)注點(diǎn)是不一樣的：

進(jìn)程間資源是獨(dú)立的，關(guān)注的是通訊問題。

線程間資源是共享的，關(guān)注的是安全問題。

操作系統(tǒng)進(jìn)程間通信的方式有哪些？

管道（pipe）：管道是一種半雙工的通信方式，數(shù)據(jù)只能單向流動(dòng)，而且只能在具有親緣關(guān)系的進(jìn)程間使用。進(jìn)程的親緣關(guān)系通常是指父子進(jìn)程關(guān)系。

有名管道（named pipe）：有名管道也是半雙工的通信方式，但是它允許無親緣關(guān)系進(jìn)程之間的通信。

消息隊(duì)列（message queue）：消息隊(duì)列是消息的鏈表，存放在內(nèi)核中并由消息隊(duì)列表示符標(biāo)示。消息隊(duì)列克服了信號(hào)傳遞信息少，管道只能承載無格式字節(jié)流以及緩沖區(qū)大小受限制等缺點(diǎn)。

共享內(nèi)存（shared memory）：共享內(nèi)存就是映射一段內(nèi)被其它進(jìn)程所訪問的內(nèi)存，共享內(nèi)存由一個(gè)進(jìn)程創(chuàng)建，但是多個(gè)進(jìn)程都可以訪問。共享內(nèi)存是最快的IPC，它是針對(duì)其它進(jìn)程通信方式運(yùn)行效率低的而專門設(shè)計(jì)的。它往往與其它通信機(jī)制。如信號(hào)量，配合使用，來實(shí)現(xiàn)進(jìn)程間的同步和通信。

套接字（socket）：套接字也是進(jìn)程間的通信機(jī)制，與其它通信機(jī)制不同的是，它可以用于不同機(jī)器間的進(jìn)程通信。

信號(hào)（signal）：信號(hào)是一種比較復(fù)雜的通信方式，用于通知接受進(jìn)程進(jìn)程某個(gè)時(shí)間已經(jīng)發(fā)生。

信號(hào)量（semaphore）：信號(hào)量是一個(gè)計(jì)數(shù)器，可以用來控制多個(gè)進(jìn)程對(duì)共享資源的訪問。

它常作為一種鎖的機(jī)制，防止某進(jìn)程正在訪問共享資源時(shí)，其它進(jìn)程也訪問該資源。因此它主要作為不同進(jìn)程或者同一進(jìn)程之間不同線程之間同步的手段。

操作系統(tǒng)線程間通信的方式有哪些？(可以直接理解成：線程之間同步的方式有哪些)

鎖機(jī)制：包括互斥鎖、條件變量、讀寫鎖

信號(hào)量機(jī)制(Semaphore)：包括無名線程信號(hào)量和命名線程信號(hào)量

信號(hào)機(jī)制(Signal)：類似進(jìn)程間的信號(hào)處理

線程間的通信目的主要是用于線程同步。

參考資料：

線程通信與進(jìn)程通信的區(qū)別：https://www.cnblogs.com/xh0102/p/5710074.html

操作系統(tǒng)——進(jìn)程，線程，鎖：https://www.cnblogs.com/biterror/p/6909653.html

操作系統(tǒng)進(jìn)程、線程：http://www.cnblogs.com/wxquare/p/5168745.html

進(jìn)程間的五種通信方式介紹：https://blog.csdn.net/wh_sjc/article/details/70283843

擴(kuò)展閱讀：

進(jìn)程間的五種通信方式介紹(詳情介紹)：https://blog.csdn.net/wh_sjc/article/details/70283843

Linux內(nèi)核調(diào)度分析（進(jìn)程調(diào)度）：https://cloud.tencent.com/developer/article/1027448

操作系統(tǒng)進(jìn)程調(diào)度算法有哪些？

先來先服務(wù)算法(FCFS)

誰先來，就誰先執(zhí)行

短進(jìn)程/作業(yè)優(yōu)先算法(SJF)

誰用的時(shí)間少、就先執(zhí)行誰

最高響應(yīng)比優(yōu)先算法(HRN)

對(duì)FCFS方式和SJF方式的一種綜合平衡

最高優(yōu)先數(shù)算法

系統(tǒng)把處理機(jī)分配給就緒隊(duì)列中優(yōu)先數(shù)最高的進(jìn)程

基于時(shí)間片的輪轉(zhuǎn)調(diào)度算法

每個(gè)進(jìn)程所享受的CPU處理時(shí)間都是一致的

最短剩余時(shí)間優(yōu)先算法

短作業(yè)優(yōu)先算法的升級(jí)版，只不過它是搶占式的

多級(jí)反饋排隊(duì)算法

設(shè)置多個(gè)就緒隊(duì)列，分別賦予不同的優(yōu)先級(jí)，如逐級(jí)降低，隊(duì)列1的優(yōu)先級(jí)最高

參考筆記：

操作系統(tǒng)第四篇【處理機(jī)調(diào)度】

此部分是看別人的博文已經(jīng)寫得很好了，分享給大家~

ConcurrentHashMap中的擴(kuò)容是否需要對(duì)整個(gè)表上鎖？

總結(jié)(摘抄)要點(diǎn)：

通過給每個(gè)線程分配桶區(qū)間(默認(rèn)一個(gè)線程分配的桶是16個(gè))，避免線程間的爭(zhēng)用。

通過為每個(gè)桶節(jié)點(diǎn)加鎖，避免 putVal 方法導(dǎo)致數(shù)據(jù)不一致。

同時(shí)，在擴(kuò)容的時(shí)候，也會(huì)將鏈表拆成兩份，這點(diǎn)和 HashMap 的 resize 方法類似。

參考資料：

并發(fā)編程——ConcurrentHashMap擴(kuò)容逐行分析https://www.jianshu.com/p/2829fe36a8dd

《Java源碼分析》：ConcurrentHashMap JDK1.8：https://blog.csdn.net/u010412719/article/details/52145145

什么是一致性Hash算法（原理）？

總結(jié)(摘抄)要點(diǎn)：

一致性Hash算法將整個(gè)哈希值空間組織成一個(gè)虛擬的圓環(huán)，好處就是提高容錯(cuò)性和可擴(kuò)展性。

對(duì)于節(jié)點(diǎn)的增減都只需重定位環(huán)空間中的一小部分?jǐn)?shù)據(jù)。

參考資料：

一致 Hash 算法分析：https://crossoverjie.top/2018/01/08/Consistent-Hash/

面試必備：什么是一致性Hash算法？https://zhuanlan.zhihu.com/p/34985026

MySQL date、datetime和timestamp類型的區(qū)別

總結(jié)(摘抄)要點(diǎn)：

date精確到天，datetime和timestamp精確到秒

datetime和timestamp的區(qū)別：

timestamp會(huì)跟隨設(shè)置的時(shí)區(qū)變化而變化，而datetime保存的是絕對(duì)值不會(huì)變化

timestamp儲(chǔ)存占用4個(gè)字節(jié)，datetime儲(chǔ)存占用8個(gè)字節(jié)

可表示的時(shí)間范圍不同，timestamp只能到表示到2038年，datetime可到9999年

參考資料：

MySQL date、datetime和timestamp類型的區(qū)別：https://zhuanlan.zhihu.com/p/23663741

判斷一個(gè)鏈表是否有環(huán)(實(shí)際上就是看看有無遍歷到重復(fù)的節(jié)點(diǎn))，解決方式(3種)：

for遍歷兩次

使用hashSet做緩存，記錄已遍歷過的節(jié)點(diǎn)

使用兩個(gè)指針，一前一后遍歷，總會(huì)出現(xiàn)前指針==后指針的情況

參考資料：

漫畫算法：如何判斷鏈表有環(huán)？http://blog.jobbole.com/106227/

判斷兩個(gè)無環(huán)鏈表是否相交，解決方式(2種)：

將第一個(gè)鏈表尾部的next指針指向第二個(gè)鏈表，兩個(gè)鏈表組成一個(gè)鏈表。

判斷這一個(gè)鏈表是否有環(huán)，有環(huán)則相交，無環(huán)則不相交

直接判斷兩個(gè)鏈表的尾節(jié)點(diǎn)是否相等，如果相等則相交，否則不相交

判斷兩個(gè)有環(huán)鏈表是否相交(注:當(dāng)一個(gè)鏈表中有環(huán)，一個(gè)鏈表中沒有環(huán)時(shí)，兩個(gè)鏈表必不相交)：

找到第一個(gè)鏈表的環(huán)點(diǎn)，然后將環(huán)斷開（當(dāng)然不要忘記了保存它的下一個(gè)節(jié)點(diǎn)），然后再來遍歷第二個(gè)鏈表，如果發(fā)現(xiàn)第二個(gè)鏈表從有環(huán)變成了無環(huán)，那么他們就是相交的嘛，否則就是不相交的了。

參考資料：

判斷兩個(gè)鏈表是否相交并找出交點(diǎn)：https://blog.csdn.net/jiary5201314/article/details/50990349

判斷單鏈表是否存在環(huán)，判斷兩個(gè)鏈表是否相交問題詳解：http://www.cppblog.com/humanchao/archive/2008/04/17/47357.html

HTTP協(xié)議的Keep-Alive意圖在于連接復(fù)用，同一個(gè)連接上串行方式傳遞請(qǐng)求-響應(yīng)數(shù)據(jù)

TCP的KeepAlive機(jī)制意圖在于?；睢⑿奶?，檢測(cè)連接錯(cuò)誤

參考資料：

聊聊 TCP 中的 KeepAlive 機(jī)制：http://www.importnew.com/27624.html

如果大家有更好的理解方式或者文章有錯(cuò)誤的地方還請(qǐng)大家不吝在評(píng)論區(qū)留言，大家互相學(xué)習(xí)交流~~~

如果想看更多的原創(chuàng)技術(shù)文章，歡迎大家關(guān)注我的微信公眾號(hào):Java3y。Java技術(shù)群討論：742919422。公眾號(hào)還有海量的視頻資源哦，關(guān)注即可免費(fèi)領(lǐng)取。

可能感興趣的鏈接：

文章的目錄導(dǎo)航(微信公眾號(hào)端)：https://zhongfucheng.bitcron.com/post/shou-ji/wen-zhang-dao-hang

文章的目錄導(dǎo)航(PC端)：http://www.zhongfucheng.bitcron.com/post/shou-ji/pcduan-wen-zhang-dao-hang

海量精美腦圖：http://www.zhongfucheng.bitcron.com/post/shou-ji/nao-tu-da-quan