leatomic

@BiChengfei 哈哈，人这么多，你猜猜为什么上层不卷，你让上层流动性高起来你看卷不卷。不要无视核心矛盾，叛徒该死但本质问题不解决叛徒不会消失的。

@lixintcwdsg 内存占用方面（毕竟阻塞 /等待，注册事件回调后方法就返回了，响应的调用栈（的栈帧链）就回收了，回调时再重新算）还是明显 eventloop 这种香的，就是不好调试，然而对于一些经过长时间运行测试，很稳定的逻辑，例如 Netty 自身的 I/O 处理的，没事，本身更多关注业务逻辑，调试也只会调试业务逻辑的（问题基本都处在这），所以 Netty 的线程模型应该不会变，上下文切换这块不得而知。
而处理业务逻辑部分，开启虚拟线程的边界，用虚拟线程 carry 更合适，不冲突的，与其说平替，不如说互补吧

@dreamlike 上面第二段的切换值得的是阻塞的时候（目前是只包括基于 JUC 的同步器的以及网络 I/O 的吧）。类似 kt corotinue 等无栈（例如基于方法参数传递状态机的？）能不能做到这种 Hook 我也不知道，我想表达的是，JDK 应该不会支持，毕竟每次 resume 就跟新的一次方法调用一样调用链都丢了，调试困难。

@dreamlike 虚拟线程核心就是提供一个替代线程的模型吧（线程是“通用”操作系统的任务承载体，这个调度机制要支持很多特性包括一些统计，而这其中大部分都是不需要的就是太重了，除了带来不必要的元数据占用内存空间，还有这些数据的保存变更逻辑就是上下文切换，而且涉及影响其他进程还需要陷入内核模式执行），线程池解决占多余内存的问题，阻塞会导致并行度丢失于是需要引入并行度补偿机制，但在阻塞密集的时候又创建了太多 worker thread 又趋近于 thread per task 了，解决办法就是（在需要进行上下文切换的地方，就是阻塞 /等待，内在逻辑也是注册回调条件成熟唤醒）用更加轻量级的上下文切换替代线程的，就是虚拟线程的，或者额外搞一种支持注册回调并会 poll 唤醒的机制直接摊牌不阻塞了拆成有依赖关系的多个分支任务（上下文丢失除非又保存，当然可以做得比较灵活在调试时才开启，真实性能差距不得而知）。
JDK 中应该只会在确定当前任务的承载体是虚拟线程时在切换的时候才会进行虚拟线程的上下文切换（而不是线程的上下文切换）。问题来了，kt corotinue 中的代码，能有阻塞（真正意义上的，能调试的那种）的逻辑吗，如果有，发生的上下文切换，还是线程的上下文切换吧。

@Richared 上次回复是 5 天前了呀！当然你回我了就无所谓了。后面的感觉辩下去没意义了，就这样吧

@Richared 兄弟，你要吐槽的到底啥呀？你不回我的话我是不是就可以理解为是想装死了？

@Richared 这是你的需求是吧，那你要吐槽的点呢？是无法实现只提取必要的属性节点的吧？
如果是。把查询和命令区分开来，这种查询使用 EntityGraph 应该能解决才对，能说说怎么无法实现你的点在哪吗？当然实际开发中会使用 Spring ，结合其提供的 @EntityGraph 使用更方便；
鉴于你的查询条件单纯用 ById ，像 CriteriaQuery 、结合 QueryDSL 就没必要提了，如果不要求将结果组装成实体类型的，要返回 Projection 的话，无论 JPA(Hibernate)还是 Spring 也都有提供相关的支持的。

@Richared 嗯，然后重点呢？“包括你要吐槽的点，是实现不了，还是按你们的理解只能如何实现怎么个麻烦法，还是怎么个不优雅法。”

@Richared 其实你大可直接一点，说说什么业务才不算你们口中的 demo 项目的，然后贴具体涉及的实体（关系描述就行），以及需要搞定的需求。包括你要吐槽的点，是实现不了，还是按你们的理解只能如何实现怎么个麻烦法，还是怎么个不优雅法。