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

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

@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 驱动