這是一個非常好的問題。IO多路複用被視為是非常好的效能助力器。但是一般我們在使用 DB 時，還是經常性採用c3p0，tomcat connection pool等技術來與 DB 連線，哪怕整個程式已經變成以Netty為核心。這到底是為什麼？

首先糾正一個常見的誤解。IO多路複用聽上去好像是多個數據可以共享一個IO（socket連線），實際上並非如此。「IO多路複用不是指多個服務共享一個連線，而僅僅是指多個連線的管理可以在同一程序」 。

在網路服務中，IO多路複用起的作用是「一次性把多個連線的事件通知業務程式碼處理」。至於這些事件的處理方式，到底是業務程式碼迴圈著處理、丟到佇列裡，還是交給執行緒池處理，由業務程式碼決定。

對於使用DB的程式來講，不管使用多路複用，還是連線池，都要維護一組網路連線，支援併發的查詢。

為什麼併發查詢一定要使用多個連線才能完成呢？因為DB一般是使用連線作為Session管理的基本單元。

在一個連線中，SQL語句的執行必須是序列、同步的。這是由於對於每一個Session，DB都要維護一組狀態來支援查詢，比如事務隔離級別，當前Session的變數等。

只有單Session內序列執行，才能維護查詢的正確性（試想一下一組sql在不斷的增減變數，然後這組sql亂序執行會發生什麼）。

維護這些狀態需要耗費記憶體，同時也會消耗CPU和磁碟IO。這樣，限制對DB的連線數，就是在限制對DB資源的消耗。

因此，對DB來說，關鍵是要限制連線的數目。這個要求無論是DB連線池還是NIO的連線管理都能做到。

這樣問題就繞回來了，為什麼DB連線不能放到IO多路複用裡一併執行嗎？為啥大家都用連線池？

答案是，可以用IO多路複用——但是「使用JDBC不行」。JDBC是一個出現了近20年的標準，它的設計核心是BIO（因為199X年時還沒有別的IO可以用）：呼叫者在通過JDBC時執行比如query這樣的API，在沒有執行完成之前，整個呼叫執行緒被卡住。而類似於Mysql Connector/J這樣的driver完備的實現了這套語義。

當然如果DB Client的協議的連線處理和解析稍微改一下：

1. 將IO模式調整為Non-Blocking，這樣就可以掛到IO多路複用的核心上（select、epoll、kqueue……）
2. 在Non-Blocking實現的基礎之上實現資料庫協議的編碼和解析

就可以實現用IO多路複用來訪問DB。實際上很多其他語言/框架裡都是這麼幹的。比如 Nodejs，see https://github.com/sidorares/node-mysql2；或者 Vert.X 的 db 客戶端https://github.com/mauricio/postgresql-async，不要在意這個名字，它實際上同時支援mysql和postgres）。

只不過對於IO多路複用，資料庫官方似乎都沒做這種支援——他們只支援JDBC、ODBC等等這些標準協議。

那麼為什麼基於 IO 多路複用的實現不能成為預設的，官方的，而要成為偏門呢？

對於資料庫開發者來說。這種用法在整體的使用者裡佔有量非常小，所以也許不值當的花大力氣。

只需要把協議寫清楚（比如https://dev.mysql.com/doc/internals/en/client-server-protocol.html），就可以做實現。那麼社群的有興趣的人自然就可以去做。

另外一個原因是體系的支援。簡單來講，如果沒有一個大的 Reactive 的執行環境，IO 多路複用的使用會非常受限。

IO 多路複用之所以能成立，是需要「整個程式要有一個IO多路複用的驅動程式碼」——就是 select 那句呼叫——等待事件來臨，一個 blocking 的 API。整個程式必須以這個驅動程式碼為核心。

這樣就對整個程式碼的結構產生重大的影響。這種影響是沒法用簡單的介面抽象的。

Java Web 容器之所以可以使用 NIO 是因為 NIO 可以被封裝到容器內部。Web 容器對外暴露的還是傳統的多執行緒形式的Java EE介面。

如果 DB 和 Web 容器同時使用 NIO，那麼呼叫的DB連線庫與必須與容器有一個約定描述「DB的連線管理如何接入Web容器的NIO的驅動程式碼」。

在 Java 這個大環境下，不同人，不同的容器寫的程式碼不同；又或者，不使用任何常見的容器，而是自己用 NIO 去封裝一個。

這樣是無法形成程式碼上的約定的。那麼多個獨立的元件就不能很好的共享 NIO 的驅動程式碼。

上面這個用法假設整個程式應該共享一個 NIO 驅動程式碼。那麼 Web 和 DB 可不可以各用各的呢？也是可以的，但是為了保證這兩個 NIO 驅動程式碼不會相互 block，最好要分開兩個執行緒。

這樣一來就會打破一般 Web 服務一個請求處理用一個執行緒的一般做法，會讓程式邊的更復雜——你的業務程式碼和DB查詢之間必須做跨執行緒資料交換。

相反，連線池的實現就相對獨立的多，也簡單的多。外界只要配好 DB URL，使用者名稱密碼和連線池的容量引數，就可以做到自行管理連線。

而Nodejs和Vert.X是完全不同的。他們本質就是Reactive的。他們的NIO的驅動方式是其執行時的基礎——所有要在這個基礎上開發的程式碼都必須遵守同樣的NIO+非同步開發規範，使用同一個NIO的驅動。這樣DB與NIO的協作就不成問題了。

最後，「有大量場景是需要BIO的DB查詢支援的」 。批處理資料分析程式碼都是這樣的場景。這樣的程式寫成NIO就會得不償失——程式碼不容易懂，也沒有任何效率上的優勢。

類似於Nodejs這樣的執行時在此場景下，反而要利用async或等價的語法來讓程式碼看起來是同步的，這樣才容易寫。

總結一下。DB 訪問一般採用連線池這種現象是生態造成的。歷史上的 BIO + 連線池的做法經過多年的發展，已經解決了主要的問題。

在 Java 的大環境下，這個方案是非常靠譜的，成熟的。而基於 IO 多路複用的方式儘管在效能上可能有優勢，但是其對整個程式的程式碼結構要求過多，過於複雜。當然，如果有特定的需要，希望使用 IO 多路複用管理 DB 連線，是完全可行的。

PG考試相關詳情：http://www.pgccc.com.cn/