Java 很强，但是 Java 的路还很长

[karottc]

看了隔壁吹爆 java21 的帖子之后，我去详细研读了下 Java21 的新特性。

首先承认，这么多年了，Java 的强已经被证明了，毋庸质疑，但是 Java 也有各种弱点（这里就不说了）。

其次，Java21 两大更新：虚拟线程正式版，分代 ZGC 。确实也非常的好，但是远没到吹爆的程度。

尤其是虚拟线程，这个光秃秃的虚拟线程，如果没有配套的话，完全不足以促使现有框架大规模适配，这是我仔细阅读 Java21 相关 JEP 之后的感觉。

因为和虚拟线程配套的两个重要特性在 Java21 上还是预览版，还不是正式版，所以目前虚拟线程场景虽然正式版了，但是场景还很受限。

和虚拟线程配套的两个重要特性是：

1. 结构性并发： https://openjdk.org/jeps/453
2. 范围值： https://openjdk.org/jeps/446

有兴趣的朋友，我也强烈建议大家仔细阅读下，读完了，一定回过头来同意我上面的观点——虚拟线程虽好，但还需要完善配套。

只有一个虚拟线程，现有框架就不会大量跟进，那么生态就不会有大变化，基本还是还目前一样。

然而等这两个配套上正式，框架肯定是基于 LTS 开发，然而下个 LTS 版本是 2 年后了，也就是 2025 年 9 月。又是几年过去了。

不过，很巧的是，2025 年正好是 Java 的 30 岁（ 1995 年开始算），希望到时候 30 而立的 Java 正能立起来吧。

[mmdsun]

Spring 6 、spring boot 已经可以用了。

spring:
thread-executor: virtual

https://www.baeldung.com/spring-6-virtual-threads

[mmdsun]

@mmdsun 附个 spring 的 doc:

https://spring.io/blog/2022/10/11/embracing-virtual-threads

[Akitora]

结构性并发很有 kt 的味儿

[urnoob]

Java 的世界里总有大神能给你玩出花来。

[Leviathann]

roman 对比 virtual thread 和 kotlin coroutine ，认为 kotlin coroutine 其中有一个优势就是 structured concurrency by default ，也就是 correct by default

而 virtual thread 则要额外使用一些 api ，正确的事却需要额外的工作，但是程序员天然地倾向于选择更不繁琐更少样板代码的实现。

[WispZhan]

@Leviathann roman 也说了，这两者设计目标就不一样

[james122333]

非常好 工作可以尝试 但私下继续玩我的 shell
java 还是会继续肥肿下去

[mingring]

java 的最终形态应该是 C#。

[franklinre]

是不是虚拟线程出来了，webflux 就不需要了？

[bthulu]

C#支持 Java 虚拟机是不是最优解?

[boatrain1111]

@franklinre 希望能革 webflux 的命

[dragondove]

为啥每次一提到 java ，就会有人过来讲 C#。是 jvm 平台上的语言不够多还是都不够好？连 jvm 平台上的其他语言都干不过 java ，凭啥 C#来到 jvm 就能干掉 java 啊。而且 C#很难转到 jvm 平台，两者的泛型实现就不一致。

[dragondove]

个人认为 java 保持语法的简单可以有效限制 jvm 搞出什么大变化，这对于其他运行在 jvm 上的语言是非常友好的。

[karottc]

@franklinre 很有可能，协程类（虚拟线程）的同步写法，能达到 webflux 的异步效果，复杂的就被淘汰了

[nothingistrue]

外行人看 Java ，首先要干得事是区分 Oracle Java 和市场主流 Java ，再精细点还要区分欧美社区 Java 跟国内市场 Java 。
@dragondove #12 .NET 平台（至少是目前）不如 Java 平台，但 Oracle Java 不如微软 C#。

[mmdsun]

@franklinre 并不是，虚拟线程只是对 ReactiveX-style APIs 的补充和增加。

反应式编程范式有很多优点。最早起源于微软的 Rx.NET ，那个时候也有协程了。干嘛还还开发各种 Rx 库呢。
而且 webflux 你也可以自己定义线程换成虚拟线程的。

[dtgxx]

看了帖子之后 感觉你们 java 水平都好高啊。。

[mmdsun]

@mingring
@bthulu

C#风格 async /await 确实好。但如果 Java 要这么改，会对兼容性破坏很大。
相反 Java 这套虚拟线程的升级成本很低，而且相比 C#这种 stateless coroutine ，有栈协程的功能更强大，也调试更方便。

async /await 还有感染函数之类的问题没有解决。

[voidmnwzp]

你说的对,但 jdk8 是美国 oracle 公司 2014 年 3 月份发布的 java 开发工具包.......

[abcbuzhiming]

@bthulu java 的虚拟机其实因为太早出现，历史包袱非常重，不是一个好的选择

[byte10]

@franklinre webflux 这种风格挺奇怪的，如果单纯是为优化异步回调地狱的问题，那么用虚拟现场就可以解决掉。如果是用于解决其他的场景，那还是可以继续用的。它这种设计模式还是挺有意思的，它应该跟虚拟线程结合一起使用，解决异步问题，又能使用上 响应式的设计模式。

[yazinnnn]

回调地狱是地狱, monad 地狱也是地狱

loom 革不了 reactive 的命

两者打算解决的问题根本不一样

loom 主要是解决 bio 阻塞线程的问题, reactive 主要解决伸缩性和松耦合的问题

[pengjl]

不得不说，我现在还是在使用 1.8

[windyboy]

java 最近感觉强的地方是 graalvm
直接变成可执行二进制

[Narcissu5]

@mmdsun .net 最早引入 async/await 的时候也就是在同步方法外就了个 Async 结尾的异步方法，不会有多大的兼容性问题。async/await 的最大问题是侵入性太强，这东西从实现的角度说不难，java 一直不跟进就是觉得不够优雅

[hello2090]

单位电脑 i5-9500 8G 内存，跑得动 java21 吗？

[Masoud2023]

你说得对

[offswitch]

@hello2090 这跟 java21 没关系，你的工具的问题，做开发大概率不够，现在 16G 起步，32G 最好。

[t6gfx4ddv3]

我用 kotlin 用得挺好的，语法不大改我是没动力回 java 了，太繁琐了

[diagnostics]

@byte10 reactive 核心感觉还是 backpressure 能力

[diagnostics]

@windyboy 初看好像也很强，实际上抛弃了 Java 多平台的特性，而且 AOT 性能不一定有 JIT 强，Java 只是初始化的延迟较高，用 Azul 的 ReadyNOW 也能解决

[dqzcwxb]

特性越多不是更难以升级吗?最好升级的是兼容旧版本且无太多外在 api 才对吧
试想一下,如果虚拟线程需要你强制更新代码实现和调用才能使用那才是大部分人会放弃升级的理由
而目前虚拟线程仅仅只需要替换线程池实现而已,这个升级成本可以简化到一行代码但是可以提升 io 密集型任务性能更好的压榨 cpu 这样升级才是简单低成本吧?

[dragondove]

如果不管语法，java 其实主要被诟病的也就是运行时吃内存了，虽然 aot 编译能解决大部分，但是 aot 编译的成本可不低，超大的内存占用，超长的编译时间，而且性能也更差，不符合当前企业需求的场景。我个人对 java 更期待的是 project valhalla 和 project panama ，valhalla 项目实现后可以降低很多的内存占用（特化泛型来支持基础类型泛型，还有数值类之类的功能）（貌似还有一个 jep 在优化对象头大小的）。panama 的话主要是方便调用 cpp ，这样接入一些 ai 的生态会方便很多。（当然，我作为 linux wayland 桌面用户，更迫切的需求是 wakefield https://openjdk.org/projects/wakefield/ )
希望 java 越来越好

[karottc]

@mmdsun 我用 springboot2.7 试了一把，也可以用，而且非常强，太棒了。

[byte10]

@diagnostics backpressure 问题，用虚拟线程应该不存在了把，直接阻塞了😂

[diagnostics]

@byte10 #35 对于 Server 端应用呢？考虑 Servlet 的场景，为每个 session 创建一条线程，最大能接多少链接呢？这里设置一个固定值不可靠的，因为你设置大了，背后的 DB 的瓶颈在哪里，设置小了，utilization 不够了。

另外 Fibers 本质上我看文档感觉其实也就是个在线程池上虚拟各种东西，相比于 Reactive 只是：

1. API 简化了
2. 底层用了 OS 级别的 interrupt 支持？我感觉又不像

[byte10]

@diagnostics 你考虑的也是有点道理。DB 那边还是 要支持高并发的数据库才行

[ysy950803]

Java 估计还是历史包袱的缘故，想实现个语法糖都这么难，看看 Kotlin 的协程，真的人性化且简洁易懂，尤其是搞 Android 的话，早点用 Kotlin ，节约时间珍惜生命。

[james122333]

@diagnostics

然而 jar 包随便拿个 decompiler 东西就见光了 XD

[james122333]

云厂商每天都在偷笑有那么多程序可以参考

[ewe]

@voidmnwzp 哈哈哈哈 idea 启动！

[diagnostics]

@james122333 #39 HTML,JS 反编译都不用你咋不说呢？