來源：zhihu.com/question/23084473
今天我們聊一個不常見的 Java 面試題：為什么資料庫連接池不采用 IO 多路復用？
這是一個非常好的問題，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的協議的連接處理和決議稍微改一下：
- 將IO模式調整為Non-Blocking，這樣就可以掛到IO多路復用的內核上（select、epoll、kqueue……）
- 在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 連接，是完全可行的，
近期熱文推薦：
1.1,000+ 道 Java面試題及答案整理(2022最新版)
2.勁爆！Java 協程要來了，，，
3.Spring Boot 2.x 教程，太全了！
4.別再寫滿屏的爆爆爆炸類了，試試裝飾器模式，這才是優雅的方式！！
5.《Java開發手冊（嵩山版）》最新發布，速速下載！
覺得不錯，別忘了隨手點贊+轉發哦！
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/477515.html
標籤：Java