有这个问题说明你应该是 j8 左右的版本，这个是内部实现问题 select 会持有和 register 相同的一把锁 具体请看
https://bugs.openjdk.org/browse/JDK-6446653
11 改了一次实现 就不会了
但是还是推荐 register 和 select 在同一个线程中执行，比如说先投递到 select 对应的线程队列中一个 register 任务 再调用 wakeup 让它从 select 中返回

selectionKey.interestOps(SelectionKey.OP_WRITE) 这个等价于 channel.register(selector, SelectionKey.OP_WRITE)
只是声明你需要监听什么事件 并不是触发可写的事件
默认情况下应该是直接 select 出来的就是可写的

我们这边确实不怎么写单测 靠在 pre 或者 boe 环境自测，最后找 qa 跑测试看覆盖率，覆盖率过了才能发版，没有后面这一步发流水线的时候 qa 不给点 也就发不了

用 quarkus 不行吗？
进可以使用声明式路由 退可以直接 netty 写 channelhandler

@ojh 招 来飞书 lark enterprise application 下面很多 java 不过有时候要使用字节基建就得用 go 写 faas 了

对于原本的 vertx 开发来讲，确实是重大好消息，这样就可以保证同步风格开发了，原来的 ThreadLocal 之类的也可以使用了，juc 包也可以直接上了，补起来一部分短板，甚至一些不使用 sychronized 实现的阻塞式的 client 也可以直接用了，属于是直接扩展了生态，建立起了同步阻塞和异步非阻塞的桥梁而没有 kt 协程的染色问题，我觉得非常的好
如果不从 vertx 角度看 而从业务开发的便利性看确实不如 springmvc+loom （如果 pin 住 carrier 的问题可以解决）

你试试用 springmvc 默认参数+jdbc （比如说 mysql-connector ）跑跑看就知道了
loom 增强不了这两样
https://dreamlike-vertx.gitbook.io/qing-you-hou-duan-xiao-ce/dreamlike-de-si-huo/project-loom-java-xu-ni-ji-de-xian-cheng-he-ji-suan-xu-ti/wei-shi-mo-jvm-xu-yao-you-zhan-xie-cheng
你看看这一篇文章 拉到最下面有讲

@kkkiio 我并没有在说这种需要一堆 setter 和 getter 模式好，我的意思是在 lombok 这种 hack 标准库的行为不好

回复 a 很好啊
保持兼容性实际上是保持公开接口的语义不变，即使内部再怎么更新也能保持旧有代码的兼容性
lombok 这种反射去修改 ast 的做法还有某些库依赖于某些内部特定实现(比如说美团那个热加载依赖于 classload 的一个实现)本来就不太好，是一种典型的反模式 会锁死版本
这种 hack 标准库的行为确实是应该通知用户的，用户不太可能去慢慢去看依赖库的代码实现，jdk 的这个提示很好

java 的最大意义还得是 jvm ，真写代码不如 kotlin 表达力，kotlin dsl 多好。
如果只是写 spring 这种业务脚本，用啥都一样

https://github.com/openjdk/jcstress
openjdk 推荐测试用的是这个

"它主打 高性能，低占用，生态丰富 ，宣称可全面替代 Spring" 一直没这么说过，这两个是完全的不同的东西，spring 是大而全的框架生态，vertx 只是一个 io 工具包，提供了基于 netty 生态中的缺少的各种 client 。真正和 spring 对比的是 quarkus 。
vertx 写 web 还是推荐使用 kotlin+协程去转异步风格到同步风格，java 语法对异步原生支持不太好，除非 loom release 而且把 continuation api 放出来，不然保持性能的前提下 java 转同步风格很困难
关于你觉得写的起来和 node 一样 其实 node vertx gin axum 这种的组织结构都是这样的
如果你想的话还是要遵循 vertical 这种部署模式以享受 actor 模型带来的天然分布式和线程封闭的优点，如果觉得有点困难也可以主动忽略掉这种特性