Java 生态下想搞大流量下的 ws,是不是暂时只能 netty?

[5261]

最近项目想上直播和拍卖业务,自身流量也是比较大,想问下目前业界 ws 方案下是不是更推荐 netty 或者有没有其他可以参考的方案呢?

直播推流这快准备用阿里云的,直播上会用到 ws 的也就是评论,拍卖可能就是出价和评论

[sagaxu]

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

[wxw752]

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

ws 是用的 netty

[cheng6563]

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

[me1onsoda]

vertx 更好用

[Goooooos]

vertx 底层就是 netty

[ychost]

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

[ZZ74]

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

[Karte]

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

[Karte]

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

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

- 在 Medium 中, Netflix 团队遇到使用虚拟线程死锁的情况.
这个问题和 synchronized 关联. 具体可以参考 [Medium Netflix Tech]( https://netflixtechblog.com/java-21-virtual-threads-dude-wheres-my-lock-3052540e231d)

[5261]

@sagaxu 收到

[5261]

@me1onsoda 收到

[5261]

@Goooooos 收到

[5261]

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

[5261]

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

[ZeroDu]

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

[halov]

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

[ychost]

@Karte #9 JDK24 修了 synchronized 问题

[5261]

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

[5261]

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

[5261]

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

[x537196]

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

[Gress]

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

[anyele]

@Karte #9 https://openjdk.org/jeps/491 已经修复了

[siweipancc]

虚拟线程的发布文档就有提到同步关键字还没适配，要切到对应的锁实现……

[Karte]

@ychost 我知道, 所以前面增加了 JDK-21-LTS 版本

[Karte]

@anyele 我知道

[zoharSoul]

vertx 好用

[SunDShuai9797]

@halov 引用别人的评价：issues 都关了怎么用？

[aboutier]

java netty 没有替代品。

[NizumaEiji]

spring -> mq -> nodejs/go
客户端发起请求走 spring 那套
服务端下发消息走 mq + nodejs/go 那一套

[ebony0319]

@Karte 回复一下 8 楼 9 楼。

[ebony0319]

@Karte 回复一下 8 楼 9 楼，
链接一： https://mp.weixin.qq.com/s/aoFo74SSXoaEIywu-pX-Ow
链接二： https://bugs.openjdk.org/browse/JDK-8338383
链接三： https://github.com/brettwooldridge/HikariCP/issues/2151#issuecomment-2475328765 这是我在实际使用虚拟线程，压测的效果，其中遇到了一个问题。是底层导致的，后面也修复了。
我从 21 出来就用在生产使用虚拟线程，很负责的说，这个是一个续 jdk8 后一个里程碑产品。jdk8 不是一个高并发语言。尤其在高并发情况下非常鸡肋，需要非常非常对的调优。
我说一个非常简单的场景：tomcat 承接爆发流量，在 jdk8 会遇到非常尴尬的问题，如果最小线程数设置太小，爆发流量来的时候线程创建需要时间，会造成大量流量超时。如果太大在空闲时候会浪费资源。

[Karte]

@ebony0319 是的, VT 是 JDK 的里程碑. 在 HTTP 侧的确能够显著的提升响应能力. 不过在日常业务开发中也能使用, 不过需要比原有的 Thread 有更多的规范. 滥用 VT 可能并不会提升性能, 还会降低性能 (上下文 Continuation).

在没有修复 synchronize 情况下, 只建议在最贴近 IO 部分使用, 尽可能减少组建中 synchronized 所带来的影响 (没修复, 也就是 JDK-21-LTS).

在目前的 JDK-24 (non lts) 中修复了 synchronize PINED Thread 的问题, 但类似本地方法调用还是会存在 PIN. 在日常开发是可以使用了, 不过还是需要注意 VT 数量. 平台线程的数量是和计算机硬件资源对等的, 而 VT 数量则是和 JVM 内存对等的. VT 数量越多, JVM 内存占用越高, 直到 VT 任务结束释放了 Continuation.

总结:
1. 在 JDK-21-LTS 不太推荐使用. 如果使用请尽可能贴近 IO 部分.
2. JDK-21-LTS 也能使用, 前提是了解 VT 内部机制 (上下文切换, Continuation, 锁机制, 本地方法站调用).
3. 如果在业务中, 我的建议是等下一个版本的 LTS 上线. 想上也可以, 建议增加 -Djdk.tracePinnedThreads=full, 在遇到 PINNING 时会打印堆栈.

[ebony0319]

@Karte 其实已经修复了。虚拟线程本来就是适合 IO 密集场景。那个问题其实解决非常简单，如果不放心： -XX:LockingMode=2 直接遇到 synchronize 就开启重锁。
https://imgur.com/a/403FceD

[ebony0319]

@Karte 不好意思刚摁快了。这是我刚截图的现在生产一台 jdk21 的服务器，单机平均 QPS1000 ，https://imgur.com/a/403FceD , 这是最近 6 小时的 cpu 使用情况： https://imgur.com/4bmtPLS , 这是 6 小时内存的使用情况： https://imgur.com/YzN42Y5

[Karte]

@ebony0319 的确不错👍.

[conn457567]

反正不要用响应式编程，没有点经验写出来的代码真的非常坑。现在的虚拟线程还不成熟，反正我是不敢上生产环境的，有条件还是换语音用 go 或者 nodejs

[qinxi]

@5261 java8 过期这么久都不升级的企业很难说换其他语言能更好吧。