v 友们好,如题,
ServerSocketChannel 在 select 和 read 的时候会阻塞,
而 AsynchronousServerSocketChannel 在 accept 和 read 时完全是异步的,
dubbo 源码里面用的是前者(只搜到 ServerSocketChannel ),为什么不用后者?后者似乎性能更好一些?
问了 chatgpt ,她也说后者性能好,但是为什么 dubbo 都没用呢?

v 友们好,如题,
ServerSocketChannel 在 select 和 read 的时候会阻塞,
而 AsynchronousServerSocketChannel 在 accept 和 read 时完全是异步的,
dubbo 源码里面用的是前者(只搜到 ServerSocketChannel ),为什么不用后者?后者似乎性能更好一些?
问了 chatgpt ,她也说后者性能好,但是为什么 dubbo 都没用呢?
1 BBCCBB Feb 17, 2023 AsynchronousServerSocketChannel 用的是 aio 模式, dubbo 用的 Netty, 这个 ServerSocketChannel 应该是 netty 里的? 不是 java 原生的. nio |
2 papertiger9919 OP @BBCCBB 这俩都是 jdk 里面的 |
3 ponder09 Feb 17, 2023 前者是 1.4 的功能 后者是 1.7 的功能 考虑下 dubbo 的开源时间? |
4 dreamlike Feb 17, 2023 via Android 先框定个范围 jdk11 Linux 前者确实是默认情况阻塞 但是可以切非阻塞搭配 selector 做事件驱动 dubbo 就是基于 netty 做的 netty 默认情况下也是这样做的 后者则是另开线程做 eventloop 做事件驱动 本质上这俩真要用调用的系统 api 都是一样的 后者性能并没有优化过 不如 netty 基于前者做的优化 chatgpt 的答案不代表就是对的 好 我们再扩大一些范围到 Linux5.10 之后,真正异步实现的 socket fd 操作就需要依赖于 io uring 来做,这个走批量提交+select buffer 甚至是 zero copy 比以上的性能还要好 |
5 Aresxue Feb 20, 2023 一个是历史原因,dubbo 开始的时间挺早的,那个时候 AsynchronousServerSocketChannel 可能刚出现甚至没出现,第二个是 java 里面并没有真正的 aio ,很多时候 aio 的实践效果反而没有 nio 性能更好。 |