dreamlike

@OldCarMan 可以理解为语言的 runtime 的一部分
我用 rust 举个例子，所谓的协程 runtime 就是指的从 io 轮询器(eventloop)，到基于这些 eventloop 做的 io api(async read) 一整套包揽，提供一组同步风格但是底层为异步的 io 操作

我上面的评论有些跳跃了
https://juejin.cn/post/7181664513559625788
其实可以扩大一些说 client 是否有必要都是 non blocking 的 我之前写过一篇文章来表述自己的观点
我觉得 api 是没必要的 但是底层实现是有必要的 这种应该交由 runtime 全做了

从响应式时间来看 没有帮助
但是由于我们的服务请求类型往往是比较混合的，如果用过 reactive 的 connector 可以帮助我们及时释放服务线程去处理其他请求 即下游的访问瓶颈不会限制我的整体服务性能
no block connector 最大的问题在于要提供 eventloop or 它自己维护 eventloop 同时接口也是异步的 要想利用好这种异步优势就得从头到尾改代码 我觉得不好
所以说我非常推崇有栈协程包揽整个 io 的 runtime 相当于提供了一个全局共享的 eventloop 来做这些事情，让出调度全交给 runtime 就好，同步的代码才是最好写的

先框定个范围 jdk11 Linux
前者确实是默认情况阻塞 但是可以切非阻塞搭配 selector 做事件驱动 dubbo 就是基于 netty 做的 netty 默认情况下也是这样做的
后者则是另开线程做 eventloop 做事件驱动
本质上这俩真要用调用的系统 api 都是一样的
后者性能并没有优化过 不如 netty 基于前者做的优化 chatgpt 的答案不代表就是对的
好 我们再扩大一些范围到 Linux5.10 之后，真正异步实现的 socket fd 操作就需要依赖于 io uring 来做，这个走批量提交+select buffer 甚至是 zero copy 比以上的性能还要好

从工作角度来说 积重难返和 java 交互有点问题，在传统的 servlet 里面没有这么多适合 kt 的场景，有时候包含 kt 语法糖的代码，运行时抛错行数其实有点问题
从个人角度说 kt 爽到炸 搞 dsl 真心好用 我个人又用响应式库多配合 kt corotinue 很不错，ksp 也非常好用 还能凑合用用 compose

干货满满张哈希

netty 兼容安卓我记得

深拷贝 我就比较弱智 我先序列化 json 然后反序列化
浅拷贝 我靠 vo2dto 这个插件搞的 基本走编码时代码生成的路子 出问题好查

🤔虽然这俩不是一个组的 但是我还是想问
oracle 啥时候把自家的 jdbc 做 virtual thread 兼容