今天，今天我們聊一個(gè)不常見的 Java 面試題：為什么數(shù)據(jù)庫連接池不采用 IO 多路復(fù)用？

這是一個(gè)非常好的問題。IO多路復(fù)用被視為是非常好的性能助力器。但是一般我們在使用 DB 時(shí)，還是經(jīng)常性采用c3p0，tomcat connection pool等技術(shù)來與 DB 連接，哪怕整個(gè)程序已經(jīng)變成以Netty為核心。這到底是為什么？

首先糾正一個(gè)常見的誤解。IO多路復(fù)用聽上去好像是多個(gè)數(shù)據(jù)可以共享一個(gè)IO（socket連接），實(shí)際上并非如此。「IO多路復(fù)用不是指多個(gè)服務(wù)共享一個(gè)連接，而僅僅是指多個(gè)連接的管理可以在同一進(jìn)程」。在網(wǎng)絡(luò)服務(wù)中，IO多路復(fù)用起的作用是「一次性把多個(gè)連接的事件通知業(yè)務(wù)代碼處理」。至于這些事件的處理方式，到底是業(yè)務(wù)代碼循環(huán)著處理、丟到隊(duì)列里，還是交給線程池處理，由業(yè)務(wù)代碼決定。

對于使用DB的程序來講，不管使用多路復(fù)用，還是連接池，都要維護(hù)一組網(wǎng)絡(luò)連接，支持并發(fā)的查詢。

為什么并發(fā)查詢一定要使用多個(gè)連接才能完成呢？因?yàn)镈B一般是使用連接作為Session管理的基本單元。在一個(gè)連接中，SQL語句的執(zhí)行必須是串行、同步的。這是由于對于每一個(gè)Session，DB都要維護(hù)一組狀態(tài)來支持查詢，比如事務(wù)隔離級別，當(dāng)前Session的變量等。只有單Session內(nèi)串行執(zhí)行，才能維護(hù)查詢的正確性（試想一下一組sql在不斷的增減變量，然后這組sql亂序執(zhí)行會(huì)發(fā)生什么）。維護(hù)這些狀態(tài)需要耗費(fèi)內(nèi)存，同時(shí)也會(huì)消耗CPU和磁盤IO。這樣，限制對DB的連接數(shù)，就是在限制對DB資源的消耗。

因此，對DB來說，關(guān)鍵是要限制連接的數(shù)目。這個(gè)要求無論是DB連接池還是NIO的連接管理都能做到。

這樣問題就繞回來了，為什么DB連接不能放到IO多路復(fù)用里一并執(zhí)行嗎？為啥大家都用連接池？

答案是，可以用IO多路復(fù)用——但是「使用JDBC不行」。JDBC是一個(gè)出現(xiàn)了近20年的標(biāo)準(zhǔn)，它的設(shè)計(jì)核心是BIO（因?yàn)?99X年時(shí)還沒有別的IO可以用）：調(diào)用者在通過JDBC時(shí)執(zhí)行比如query這樣的API，在沒有執(zhí)行完成之前，整個(gè)調(diào)用線程被卡住。而類似于Mysql Connector/J這樣的driver完備的實(shí)現(xiàn)了這套語義。

當(dāng)然如果DB Client的協(xié)議的連接處理和解析稍微改一下：

1. 將IO模式調(diào)整為Non-Blocking，這樣就可以掛到IO多路復(fù)用的內(nèi)核上（select、epoll、kqueue……）

2. 在Non-Blocking實(shí)現(xiàn)的基礎(chǔ)之上實(shí)現(xiàn)數(shù)據(jù)庫協(xié)議的編碼和解析

就可以實(shí)現(xiàn)用IO多路復(fù)用來訪問DB。實(shí)際上很多其他語言/框架里都是這么干的。比如 Nodejs，see https://github.com/sidorares/node-mysql2；或者 Vert.X 的 db 客戶端https://github.com/mauricio/postgresql-async，不要在意這個(gè)名字，它實(shí)際上同時(shí)支持mysql和postgres）。只不過對于IO多路復(fù)用，數(shù)據(jù)庫官方似乎都沒做這種支持——他們只支持JDBC、ODBC等等這些標(biāo)準(zhǔn)協(xié)議。

那么為什么基于 IO 多路復(fù)用的實(shí)現(xiàn)不能成為默認(rèn)的，官方的，而要成為偏門呢？

對于數(shù)據(jù)庫開發(fā)者來說。這種用法在整體的用戶里占有量非常小，所以也許不值當(dāng)?shù)幕ù罅狻Ｖ恍枰褏f(xié)議寫清楚（比如https://dev.mysql.com/doc/internals/en/client-server-protocol.html），就可以做實(shí)現(xiàn)。那么社區(qū)的有興趣的人自然就可以去做。

另外一個(gè)原因是體系的支持。簡單來講，如果沒有一個(gè)大的 Reactive 的運(yùn)行環(huán)境，IO 多路復(fù)用的使用會(huì)非常受限。

IO 多路復(fù)用之所以能成立，是需要「整個(gè)程序要有一個(gè)IO多路復(fù)用的驅(qū)動(dòng)代碼」——就是 select 那句調(diào)用——等待事件來臨，一個(gè) blocking 的 API。整個(gè)程序必須以這個(gè)驅(qū)動(dòng)代碼為核心。這樣就對整個(gè)代碼的結(jié)構(gòu)產(chǎn)生重大的影響。這種影響是沒法用簡單的接口抽象的。

Java Web 容器之所以可以使用 NIO 是因?yàn)?NIO 可以被封裝到容器內(nèi)部。Web 容器對外暴露的還是傳統(tǒng)的多線程形式的Java EE接口。

如果 DB 和 Web 容器同時(shí)使用 NIO，那么調(diào)用的DB連接庫與必須與容器有一個(gè)約定描述「DB的連接管理如何接入Web容器的NIO的驅(qū)動(dòng)代碼」。在 Java 這個(gè)大環(huán)境下，不同人，不同的容器寫的代碼不同；又或者，不使用任何常見的容器，而是自己用 NIO 去封裝一個(gè)。這樣是無法形成代碼上的約定的。那么多個(gè)獨(dú)立的組件就不能很好的共享 NIO 的驅(qū)動(dòng)代碼。

上面這個(gè)用法假設(shè)整個(gè)程序應(yīng)該共享一個(gè) NIO 驅(qū)動(dòng)代碼。那么 Web 和 DB 可不可以各用各的呢？也是可以的，但是為了保證這兩個(gè) NIO 驅(qū)動(dòng)代碼不會(huì)相互 block，最好要分開兩個(gè)線程。這樣一來就會(huì)打破一般 Web 服務(wù)一個(gè)請求處理用一個(gè)線程的一般做法，會(huì)讓程序邊的更復(fù)雜——你的業(yè)務(wù)代碼和DB查詢之間必須做跨線程數(shù)據(jù)交換。

相反，連接池的實(shí)現(xiàn)就相對獨(dú)立的多，也簡單的多。外界只要配好 DB URL，用戶名密碼和連接池的容量參數(shù)，就可以做到自行管理連接。

而Nodejs和Vert.X是完全不同的。他們本質(zhì)就是Reactive的。他們的NIO的驅(qū)動(dòng)方式是其運(yùn)行時(shí)的基礎(chǔ)——所有要在這個(gè)基礎(chǔ)上開發(fā)的代碼都必須遵守同樣的NIO+異步開發(fā)規(guī)范，使用同一個(gè)NIO的驅(qū)動(dòng)。這樣DB與NIO的協(xié)作就不成問題了。

最后，「有大量場景是需要BIO的DB查詢支持的」。批處理數(shù)據(jù)分析代碼都是這樣的場景。這樣的程序?qū)懗蒒IO就會(huì)得不償失——代碼不容易懂，也沒有任何效率上的優(yōu)勢。類似于Nodejs這樣的運(yùn)行時(shí)在此場景下，反而要利用async或等價(jià)的語法來讓代碼看起來是同步的，這樣才容易寫。

總結(jié)一下。DB 訪問一般采用連接池這種現(xiàn)象是生態(tài)造成的。歷史上的 BIO + 連接池的做法經(jīng)過多年的發(fā)展，已經(jīng)解決了主要的問題。在 Java 的大環(huán)境下，這個(gè)方案是非常靠譜的，成熟的。而基于 IO 多路復(fù)用的方式盡管在性能上可能有優(yōu)勢，但是其對整個(gè)程序的代碼結(jié)構(gòu)要求過多，過于復(fù)雜。當(dāng)然，如果有特定的需要，希望使用 IO 多路復(fù)用管理 DB 連接，是完全可行的。

來源：zhihu.com/question/23084473

END

2022年Java原創(chuàng)面試題庫連載中

更多內(nèi)容，點(diǎn)擊上方名片查看