V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
papertiger9919
V2EX  ›  Java

Java 中 ServerSocketChannel 和 AsynchronousServerSocketChannel 的区别

  •  
  •   papertiger9919 · 2023-02-17 10:18:11 +08:00 · 1225 次点击
    这是一个创建于 646 天前的主题,其中的信息可能已经有所发展或是发生改变。

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

    5 条回复    2023-02-20 15:45:55 +08:00
    BBCCBB
        1
    BBCCBB  
       2023-02-17 10:44:03 +08:00
    AsynchronousServerSocketChannel 用的是 aio 模式,

    dubbo 用的 Netty, 这个 ServerSocketChannel 应该是 netty 里的? 不是 java 原生的. nio
    papertiger9919
        2
    papertiger9919  
    OP
       2023-02-17 12:20:37 +08:00 via iPhone
    @BBCCBB 这俩都是 jdk 里面的
    wangxin3
        3
    wangxin3  
       2023-02-17 15:04:11 +08:00
    前者是 1.4 的功能 后者是 1.7 的功能 考虑下 dubbo 的开源时间?
    dreamlike
        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 比以上的性能还要好
    Aresxue
        5
    Aresxue  
       2023-02-20 15:45:55 +08:00
    一个是历史原因,dubbo 开始的时间挺早的,那个时候 AsynchronousServerSocketChannel 可能刚出现甚至没出现,第二个是 java 里面并没有真正的 aio ,很多时候 aio 的实践效果反而没有 nio 性能更好。
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   2671 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 22ms · UTC 00:34 · PVG 08:34 · LAX 16:34 · JFK 19:34
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.