Karte

@ebony0319 的确不错👍.

@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 时会打印堆栈.

@anyele 我知道

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

就目前的 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)

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

用 var 能够减少类型申明 (虽然可以通过 .val 快速申明), 但是会显示隐藏掉函数返回类型. 如果是一个新人进来看到一堆 var 关键字, 就得对每个方法进行 CTRL+Q 查阅方法返回数据类型, 或者进入方法内部查看, 相对不是十分便捷.

同样的, 由于 var 显示隐藏了对象的结构信息, 可以有效的把冗杂的类名或者泛型隐藏. 整体代码看起来会相对清爽 (但阅读同样存在障碍).

具体用还是不用, 一方面取决于团队内部, 还有一方面取决当前项目构型.
如果项目构型没有使用 var 关键字, 那尽可能不要使用, 会显著增加阅读代码的障碍 (虽然不是很大, 但有些人会觉得很头疼).
如果团队内部都支持, 建议在新项目内使用, 老项目则按部就班.

最好能在使用前与团队内部进行交流探讨, 让团队都了解这个特性, 并尝试了解他们所抵触的原因, 尝试对其进行化解才会更有效的推动新特性的使用.

@Karte 还有就是大拇指滚轮, 在看一些资料时很有用 (虽然使用率远不及虚拟桌面切换).

Master 3s, 别买 Vertical. 虽然 Vertical 符合人体工学, 但是没有 Master 3s 用的舒服.

3s 比 vertical 多了一个大拇指按键, 可以快速的在多个虚拟窗口中来回切换, 而 vertical 是没有的.