為何現在響應式程式設計在業務開發微服務開發不普及 **主要因為資料庫 IO，不是 NIO。** 不論是Java自帶的Future框架，還是 Spring WebFlux，還是 Vert.x，他們都是一種非阻塞的基於Ractor模型的框架（後兩個框架都是利用netty實現）。 在阻塞程式設計模式裡，任何一個請求，都需要一個執行緒去處理，如果io阻塞了，那麼這個執行緒也會阻塞在那。但是在非阻塞程式設計裡面，基於響應式的程式設計，執行緒不會被阻塞，還可以處理其他請求。舉一個簡單例子：假設只有一個執行緒池，請求來的時候，執行緒池處理，需要讀取資料庫 IO，這個 IO 是 NIO 非阻塞 IO，那麼就將請求資料寫入資料庫連線，直接返回。之後資料庫返回資料，這個連結的 Selector 會有 Read 事件準備就緒，這時候，再通過這個執行緒池去讀取資料處理（相當於回撥），這時候用的執行緒和之前不一定是同一個執行緒。這樣的話，執行緒就不用等待資料庫返回，而是直接處理其他請求。這樣情況下，即使某個業務 SQL 的執行時間長，也不會影響其他業務的執行。 但是，這一切的基礎，是 IO 必須是非阻塞 IO，也就是 NIO（或者 AIO）。**官方JDBC沒有 NIO，只有 BIO 實現**。這樣無法讓執行緒將請求寫入連結之後直接返回，必須等待響應。但是也就解決方案，就是通過其他執行緒池，專門處理資料庫請求並等待返回進行回撥，也就是業務執行緒池 A 將資料庫 BIO 請求交給執行緒池B處理，讀取完資料之後，再交給 A 執行剩下的業務邏輯。這樣A也不用阻塞，可以處理其他請求。但是，這樣還是有因為某個業務 SQL 的執行時間長，導致B所有執行緒被阻塞住佇列也滿了從而A的請求也被阻塞的情況，這是不完美的實現。真正完美的，需要 JDBC 實現 NIO。 Java 自帶的 Future 框架可以這麼用JDBC： ``` @GetMapping public DeferredResult