探究Redis網(wǎng)絡模型究竟有多強大（中）

3.2.1 創(chuàng)建socket

創(chuàng)建socket這一步和客戶端沒啥區(qū)別，不同的是這個socket我們稱之為 等待連接socket（或監(jiān)聽socket） 。

3.2.2 綁定端口號

bind()函數(shù)會將端口號寫入上一步生成的監(jiān)聽socket中，這樣一來，監(jiān)聽socket就完整保存了服務端的IP和端口號。

3.2.3 listen()的真正作用

listen(<Server描述符>, <最大連接數(shù)>);

很多小伙伴一定會對這個listen()有疑問，監(jiān)聽socket都已經(jīng)創(chuàng)建完了，端口也已經(jīng)綁定完了，為什么還要多調(diào)用一個listen()呢？

我們剛說過監(jiān)聽socket和客戶端創(chuàng)建的socket沒什么區(qū)別，問題就出在這個沒什么區(qū)別上。

socket被創(chuàng)建出來的時候都默認是一個 主動socket ，也就說，內(nèi)核會認為這個socket之后某個時候會調(diào)用connect()主動向別的設備發(fā)起連接。這個默認對客戶端socket來說很合理，但是監(jiān)聽socket可不行，它只能等著客戶端連接自己，因此我們需要調(diào)用listen()將監(jiān)聽socket從主動設置為被動，明確告訴內(nèi)核：你要接受指向這個監(jiān)聽socket的連接請求！

此外，listen()的第2個參數(shù)也大有來頭！監(jiān)聽socket真正接受的應該是已經(jīng)完整完成3次握手的客戶端，那么還沒完成的怎么辦？總得找個地方放著吧。于是內(nèi)核為每一個監(jiān)聽socket都維護了兩個隊列：

• 半連接隊列（未完成連接的隊列）

這里存放著暫未徹底完成3次握手的socket（為了防止半連接攻擊，這里存放的其實是占用內(nèi)存極小的request _sock，但是我們直接理解成socket就行了），這些socket的狀態(tài)稱為SYN_RCVD。

• 已完成連接隊列

每個已完成TCP3次握手的客戶端連接對應的socket就放在這里，這些socket的狀態(tài)為ESTABLISHED。

文字太多了，有點干，上個圖！

listen與3次握手

解釋一下動圖中的內(nèi)容：

1. 客戶端調(diào)用connect()函數(shù)，開始3次握手，首先發(fā)送一個SYN X的報文（X是個數(shù)字，下同）；
2. 服務端收到來自客戶端的SYN，然后在監(jiān)聽socket對應的半連接隊列中創(chuàng)建一個新的socket，然后對客戶端發(fā)回響應SYN Y，捎帶手對客戶端的報文給個ACK；
3. 直到客戶端完成第3次握手，剛才新創(chuàng)建的socket就會被轉(zhuǎn)移到已連接隊列；
4. 當進程調(diào)用accept()時，會將已連接隊列頭部的socket返回；如果已連接隊列為空，那么進程將被睡眠，直到已連接隊列中有新的socket，進程才會被喚醒，將這個socket返回 。

第4步就是阻塞的本質(zhì)啊，朋友們！

3.3 答疑時間

Q1.隊列中的對象是socket嗎？

呃。。。乖，咱就把它當成socket就好了，這樣容易理解，其實具體里邊存放的數(shù)據(jù)結(jié)構(gòu)是啥，我也很想知道，等我寫完這篇文章，我研究完了告訴你。

Q2.accept()這個函數(shù)你還沒講是啥意思呢？

accept()函數(shù)是由服務端調(diào)用的，用于從已連接隊列中返回一個socket描述符；如果socket為阻塞式的，那么如果已連接隊列為空，accept()進程就會被睡眠。BIO恰好就是這個樣子。

Q3.accept()為什么不直接把監(jiān)聽socket返回呢？

因為在隊列中的socket經(jīng)過3次握手過程的控制信息交換，socket的4元組的信息已經(jīng)完整了，用做socket完全沒問題。

監(jiān)聽socket就像一個客服，我們給客服打電話，然后客服找到解決問題的人，幫助我們和解決問題的人建立聯(lián)系，如果直接把監(jiān)聽socket返回，而不使用連接socket，就沒有socket繼續(xù)等待連接了。

哦對了，accept()返回的socket也有個名字，叫 連接socket 。

3.4 BIO究竟阻塞在哪里

拿Server端的BIO來說明這個問題，阻塞在了serverSocket.accept()以及bufferedReader.readLine()這兩個地方。有什么辦法可以證明阻塞嗎？

簡單的很！你在serverSocket.accept(); 的下一行打個斷點，然后debug模式運行BIOServerSocket，在沒有客戶端連接的情況下，這個斷點絕不會觸發(fā)！同樣，在bufferedReader.readLine();下一行打個斷點，在已連接的客戶端發(fā)送數(shù)據(jù)之前，這個斷點絕不會觸發(fā)！

readLine()的阻塞還帶來一個非常嚴重的問題，如果已經(jīng)連接的客戶端一直不發(fā)送消息，readLine()進程就會一直阻塞（處于睡眠狀態(tài)），結(jié)果就是代碼不會再次運行到accept()，這個ServerSocket沒辦法接受新的客戶端連接。

解決這個問題的核心就是別讓代碼卡在readLine()就可以了，我們可以使用新的線程來readLine()，這樣代碼就不會阻塞在readLine()上了。

3.5 改造BIO

改造之后的BIO長這樣，這下子服務端就可以隨時接受客戶端的連接了，至于啥時候能read到客戶端的數(shù)據(jù)，那就讓線程去處理這個事情吧。

public class BIOServerSocketWithThread {
    public static void main(String[] args) {
        ServerSocket serverSocket = null;

        try {
            serverSocket = new ServerSocket(8099);
            System.out.println("啟動服務：監(jiān)聽端口:8099");
            // 等待客戶端的連接過來,如果沒有連接過來，就會阻塞
            while (true) {
                // 表示阻塞等待監(jiān)聽一個客戶端連接,返回的socket表示連接的客戶端信息
                Socket socket = serverSocket.accept(); //連接阻塞
                System.out.println("客戶端：" + socket.getPort());
                // 表示獲取客戶端的請求報文
                new Thread(new Runnable() {
                    @Override
                    public void run() {
                        try {
                            BufferedReader bufferedReader = new BufferedReader(
                                    new InputStreamReader(socket.getInputStream())
                            );
                            String clientStr = bufferedReader.readLine();
                            System.out.println("收到客戶端發(fā)送的消息：" + clientStr);

                            BufferedWriter bufferedWriter = new BufferedWriter(
                                    new OutputStreamWriter(socket.getOutputStream())
                            );
                            bufferedWriter.write("ok\\n");
                            bufferedWriter.flush();
                        } catch (Exception e) {
                            //...
                        }

                    }
                }).start();
            }
        } catch (IOException e) {
            // 錯誤處理
        } finally {
            // 其他處理
        }
    }
}

事情的順利進展不禁讓我們飄飄然，我們居然是使用高階的多線程技術解決了BIO的阻塞問題，雖然目前每個客戶端都需要一個單獨的線程來處理，但accept()總歸不會被readLine()卡死了。

BIO改造之后

所以我們改造完之后的程序是不是就是非阻塞IO了呢？

想多了。。。我們只是用了點奇技淫巧罷了，改造完的代碼在系統(tǒng)調(diào)用層面該阻塞的地方還是阻塞，說白了，Java提供的API完全受限于操作系統(tǒng)提供的系統(tǒng)調(diào)用，在Java語言級別沒能力改變底層BIO的事實！

Java沒這個能力!

3.6 掀開BIO的遮羞布

接下來帶大家看一下改造之后的BIO代碼在底層都調(diào)用了哪一些系統(tǒng)調(diào)用，讓我們在底層上對上文的內(nèi)容加深一下理解。

給大家打個氣，接下來的內(nèi)容其實非常好理解，大家跟著文章一步步地走，一定能看得懂，如果自己動手操作一遍，那就更好了。

對了，我下來使用的JDK版本是JDK8。

strace是Linux上的一個程序，該程序可以追蹤并記錄參數(shù)后邊運行的進程對內(nèi)核進行了哪些系統(tǒng)調(diào)用。

strace -ff -o out java BIOServerSocketWithThread

其中:

• -o:

將系統(tǒng)調(diào)用的追蹤信息輸出到out文件中，不加這個參數(shù)，默認會輸出到標準錯誤stderr。

• -ff

如果指定了-o選項，strace會追蹤和程序相關的每一個進程的系統(tǒng)調(diào)用，并將信息輸出到以進程id為后綴的out文件中。舉個例子，比如BIOServerSocketWithThread程序運行過程中有一個ID為30792的進程，那么該進程的系統(tǒng)調(diào)用日志會輸出到out.30792這個文件中。

我們運行strace命令之后，生成了很多個out文件。

這么多進程怎么知道哪個是我們需要追蹤的呢？我就挑了一個容量最大的文件進行查看，也就是out.30792，事實上，這個文件也恰好是我們需要的，截取一下里邊的內(nèi)容給大家看一下。

可以看到圖中的有非常多的行，說明我們寫的這么幾行代碼其實默默調(diào)用了非常多的系統(tǒng)調(diào)用，拋開細枝末節(jié)，看一下上圖中我重點標注的系統(tǒng)調(diào)用，是不是就是上文中我解釋過的函數(shù)？我再詳細解釋一下每一步，大家聯(lián)系上文，會對BIO的底層理解的更加通透。

1. 生成監(jiān)聽socket，并返回socket描述符7，接下來對socket進行操作的函數(shù)都會有一個參數(shù)為7；
2. 將8099端口綁定到監(jiān)聽socket，bind的第一個參數(shù)就是7，說明就是對監(jiān)聽socket進行的操作；
3. listen()將監(jiān)聽socket（參數(shù)為7）設置為被動接受連接的socket，并且將隊列的長度設置為50；
4. 實際上就是System.out.println("啟動服務：監(jiān)聽端口:8099");這一句的系統(tǒng)調(diào)用，只不過中文被編碼了，所以我特意把:8099圈出來證明一下;

額外說兩點：

其一：可以看到，這么一句簡單的打印輸出在底層實際調(diào)用了兩次write系統(tǒng)調(diào)用，這就是為什么不推薦在生產(chǎn)環(huán)境下使用打印語句的原因，多少會影響系統(tǒng)性能；

其二：write()的第一個參數(shù)為1，也是文件描述符，表示的是標準輸出stdout。

5. 系統(tǒng)調(diào)用阻塞在了poll()函數(shù)，怎么看出來的阻塞？out文件的每一行運行完畢都會有一個 = 返回值，而poll()目前沒有返回值，因此阻塞了。實際上poll()系統(tǒng)調(diào)用對應的Java語句就是serverSocket.accept();。

不對啊？為什么底層調(diào)用的不是accept()而是poll()?poll()應該是多路復用才是啊。在JDK4之前，底層確實直接調(diào)用的是accept()，但是之后的JDK對這一步進行了優(yōu)化，除了調(diào)用accept()，還加上了poll()。poll()的細節(jié)我們下文再說，這里可以起碼證明了poll()函數(shù)依然是阻塞的，所以整個BIO的阻塞邏輯沒有改變。

接下來我們起一個客戶端對程序發(fā)起連接，直接用Linux上的nc程序即可，比較簡單：

nc localhost 8099

發(fā)起連接之后（但并未主動發(fā)送信息），out.30792的內(nèi)容發(fā)生了變化：

1. poll()函數(shù)結(jié)束阻塞，程序接著調(diào)用accept()函數(shù)返回一個連接socket，該socket的描述符為8；
2. 就是System.out.println("客戶端：" + socket.getPort());的底層調(diào)用；
3. 底層使用clone()創(chuàng)造了一個新進程去處理連接socket，該進程的pid為31168，因此JDK8的線程在底層其實就是輕量級進程；
4. 回到poll()函數(shù)繼續(xù)阻塞等待新客戶端連接。

由于創(chuàng)建了一個新的進程，因此在目錄下對多出一個out.31168的文件，我們看一下該文件的內(nèi)容：

發(fā)現(xiàn)子進程阻塞在了recvfrom()這個系統(tǒng)調(diào)用上，對應的Java源碼就是bufferedReader.readLine();，直到客戶端主動給服務端發(fā)送消息，阻塞才會結(jié)束。

3.7 BIO總結(jié)

到此為止，我們就通過底層的系統(tǒng)調(diào)用證明了BIO在accept()以及readLine()上的阻塞。最后用一張圖來結(jié)束BIO之旅。

BIO模型

BIO之所以是BIO，是因為系統(tǒng)底層調(diào)用是阻塞的，上圖中的進程調(diào)用recv，其系統(tǒng)調(diào)用直到數(shù)據(jù)包準備好并且被復制到應用程序的緩沖區(qū)或者發(fā)生錯誤為止才會返回，在此整個期間，進程是被阻塞的，啥也干不了。