最近项目想上直播和拍卖业务,自身流量也是比较大,想问下目前业界 ws 方案下是不是更推荐 netty 或者有没有其他可以参考的方案呢?
直播推流这快准备用阿里云的,直播上会用到 ws 的也就是评论,拍卖可能就是出价和评论

不要直接用 netty ，用 vertx 或者 quarkus

我们公司是做会议的，直播推流用阿里云再找个云服务商做备份，单一服务商遇到问题的时候哭都来不及。

ws 是用的 netty

用 Java 21 虚拟线程同步处理一把梭，别想着那些啥响应式啥的异步啥的提高性能了。

vertx 更好用

vertx 底层就是 netty

虚拟线程吧，响应式编程复杂度太高了，甚至比切换 kotlin 的成本都高

老老实实用 netty
大流量+响应式编程到时都不知道死哪里...

虚拟线程不推荐使用.
1: 虚拟线程的出现是减少 IO 的产生, 如果是非 IO 操作使用虚拟线程只会增加应用负担.
2: 虚拟线程是通过用户态上进行上下文切换减少内核态切换. 虚拟线程使用 Continuation 实现的, 这个是个对象, 也就是会占用内存. 当你操作越多, 内存占用也会疯涨. 原有平台线程 (Thread) 则是由物理资源 (系统资源) 限制, 而虚拟线程则没有这层限制, 操作不好容易导致 OOM.

就目前的 JDK-21-LTS 的虚拟线程还存在致命问题:

• 在使用 synchronized 场景下会将虚拟线程 PIN 到平台线程 (锁在了某一个线程上)
  这是由于当前对 synchronized 的实现需要直到锁当前持有的线程对象. 而虚拟线程是上层包装出来的, 所以必须强绑到某一个平台线程 (Thread) 上才能实现. 如果在 IO 操作下会基本和平台线程无异.

• 在 Medium 中, Netflix 团队遇到使用虚拟线程死锁的情况.
  这个问题和 synchronized 关联. 具体可以参考 Medium Netflix Tech

  收到

  收到

  收到

  还是哥专业啊~ 理论上我们新项目不会上新的 jdk 版本,还是继续用 Java8

  有的时候我觉得 Java 对于中小企业真是一种负担,明明可以用 Go 来做业务开发,能减少不少服务器成本!

  别搞 java8 了，起码 17 起步，现在各个生态配台早都跟上了。netty 是稳健的选择多少年市场验证过了

  github.com/tywo45/t-io 要不看看 tio 不过好像这个框架用的人不多 评价不高

  ＃9 JDK24 修了 synchronized 问题

  那 JDK21 的人不就是小白鼠了!

  升级 JDK 不是说我想升就能升,企业用 Java 要的是稳定!

  reactor netty 这玩意和上面提到的 vertx 有啥区别呢?

  服务器成本是最低成本，人员和维护成本才是最高的

  用 JDK24 的虚拟线程，修复 synchronized 会挂起平台线程的问题了