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