为啥 async & nio jdbc driver 没有流行起来

因为异步回调, promise 这种反人类..

调用同步, 执行异步才是 java 后续的发展方向.

oracle 本来有在标准化异步的 jdbc 规范, 但有 loom 这种提案, 就放弃了, 就没必要再去搞这种反人类的回调, reactor 这种东西了..

优化啥了？
数据库就能 serve 那么多请求，开再多也没用

人的大脑就不支持多线程和异步。。。同步做事情都做不明白呢

有栈协程才是正道啊。
无栈的协程，难理解，难维护，难调试和追踪。用这个写业务是有点作死的节奏

因为提高的是资源利用率
但是节约下来的服务器成本，需要投入到人力上，而且未必够用
所以还不如招普通开发堆屎山 + 堆服务器硬抗负载

大部分 javaer 的脑子连 stream function 都玩不明白，你让他们玩 async ？

回调写法反人类啊，你看 nodejs 上了 await/async 之后，写起来自然多了

错就错在选了 Java ，高手看不上，菜鸟学不会。

显然协程最符合人类直觉

nodejs 原生支持异步调用，最后不还是整个项目在 await

javaer 上就是 vert.x 或者 webflux 。。 流式写法确实看起来难受，另外出问题 debug 贼麻烦。。

试试 go

异步恶心，现在的趋势是协程的 runtime 结合异步回调，然后只需要写同步代码

之前用 webflux 出 bug 的时候贼难查是什么原因，除非你提前在可能出错的地方埋好日志，而且代码写起来不能有任何阻塞，所有东西都靠回调，代码恶心的一批 emm
业务上来讲，不重要的操作异步处理就够了
从提高资源利用率上讲，还不如多部署几个应用节点

要搭配

async&await

或者

coroutine

Java 的异步比 ts/js 难用多了，我也不知道为什么会有这种差异

替代驱动：Reactive Relational Database Connectivity (R2DBC)

https://r2dbc.io/

上面很多大佬都是从技术角度说的，但是我想换个角度谈谈：

我个人觉得，有个很重要的点各位没有 get 到。当前这种异步真的增加了什么好处吗？

我觉得没有！绝大多数情况下，你写异步代码并不能真的在用户体验层面上提升多少性能。因为相对于代码程序的运行（甭管你是 java 还是 nodejs 还是别的什么玩意，甚至你是 python 也行），数据库的执行才是慢如蜗牛，于是你用了一堆异步，最后在用户体验上体验不出来，那有什么用，那不是吃力不讨好吗？

难不难用都是其次，主要还是最终使用效果有没有好处。真有巨大的好处，当年纸片打孔编程不比今天各位写代码难多了，照样被无数人强行啃下来用

异步目前比较好的就是通过语言层面解决，那什么 reactive webflux 写起来太繁琐，还不如等各个 jdbc 适配 loom

@abcbuzhiming

调用数据库或第三方 api or rpc 都属于 io 密集型任务，这种场景更适合异步，简单举例，一个操作需要处理 5 个 sql 语句，每个耗时 1s ，同步执行累加 5 秒，异步并行总耗时只有 1 秒，对上游调用方来说差异很大。当然 java 可以多线程并发，只是更耗资源。

异步驱动也救不了数据库瓶颈

@photon006 你是认真的么，你先告诉我数据库最多同时可以有多少个链接是活跃的，
不会认为 jdbc 链接是无状态的吧,你觉得谁来管理这些状态.....

@lyxeno #16 没有 async await

java 里面更像是一坨语法糖，思维方式转不过来，写起来会很别扭，不如用 concurrent 包来的快

这个讨论串下的回复已经说明为什么流行不起来了。

不过其实数据库层面的异步 driver 流行不起来也很正常，毕竟同步的 api 也可以丢进 worker 里面 await 。异步 api 主要是为了实现全链路异步的。

流式写法确实不直观，但是说 debug 难也有点牵强吧。主流 IDE 都有很好的对异步代码的支持了，打断点可以直接停在每层拦截或者 flatmap 回调里面，直接拿到解包后的值，倒不如说这种难度对所有需要处理时序和并发关系的都是必不可少的？如果框架支持，转成 suspend fun 后就更好读了。

但 javaboy 的思维实在是太清奇了，你跟他提技术他跟你扯用户体验，你跟他提用户体验他跟你说业务说老板不给异步代码加薪。反正错不在 java 这个时至 3022 年还没有 async/await 的语言，一切责任全归异步。

真要说异步代码怎么难懂怎么复杂，那也没有阻塞代码里面拿个破锁锁来锁去更难懂吧。异步里面只需要给可能同时访问的资源上锁，而且也可以用 actor 或者其他算法来消除这个需求，写不出对着字符串加锁的奇葩实现。

@photon006 你说的这个问题池化技术的解决

你猜为什么 go 流行起来了

rxjava 挺舒服的

深度用过 webflux ，如果是个人项目一个人维护没啥问题，人多了就麻烦了，最后还是用 kotlin 的 coroutine 去桥接，美滋滋

@photon006
“一个操作需要处理 5 个 sql 语句，每个耗时 1s ，同步执行累加 5 秒，异步并行总耗时只有 1 秒”
======
你说的这种情况，更多的在数据聚合业务里。然而现实里到底有多少聚合业务呢？我其实强调的就是这个问题，真实的现实里其实是没有多少聚合业务的，这类聚合业务最容易出现的场合是企业自己的数据统计。再更多的，对性能敏感的用户场景里，这类需求根本就不多。真要是多起来，异步模式早就流行开了。

说白了这模式为啥用的人少，就是因为大部分开发者都从现实感觉到了，这东西的使用场景偏少，代价偏大。技术这东西，能被广泛流传开，必然是有需求，流行不开就是没需求或者需求过少。好不好用都是其次的

Oracle 当时还开发过，Asynchronous Database Access API (ADBA)，但是放弃了，说用 loom 吧

应该是动力不足。Non blocking JDBC 要配合 reactive 编程模式，才有用，负责远不如连接池、应用端缓存等技术实惠。现在 WebFlux 还都没铺开，各大数据厂商也没必要做这种需要吃力但但是没人用的东西。

另外，我是第一次听说 Non blocking JDBC ，如果没猜错的话，这个 JDK 8 没有吧。JDBC 驱动规范，这种大变动，靠现在那个连橡皮图章都没有的 JCP ，是做不出来的。

因为磁盘 I/O 是阻塞的，数据库的瓶颈在磁盘 I/O, 它根本就异步不起来。在 JDBC 搞异步，就是把 SQL 都提交到数据库服务器上排队，这还不如阻塞在 application server 上排队呢

@wqhui
webflux 官方文档有就讲怎么打开调试模式的，一句话的配置，很详细的流日志都有。根本就不用提前埋日志打印

@iFerrari860

大多数人太菜了，reactive 编程模式有难度呗。
我觉得 spring webflux 很好用，自己项目全是用这，数据库也是 R2DBC 驱动