Vertx 虚拟线程孵化

[ojh]

https://github.com/vert-x3/vertx-virtual-threads-incubator/blob/main/examples/src/main/java/examples/HttpClientExample.java

public class HttpClientExample {

  public static void main(String[] args) {
    Vertx vertx = Vertx.vertx();

    HttpServer server = vertx.createHttpServer();
    server.requestHandler(request -> {
      request.response().end("Hello World");
    });
    Future<HttpServer> fut = server.listen(8080, "localhost");

    Async async = new Async(vertx);
    async.run(v -> {
      // Run on a Vert.x a virtual thread

      // Make sure server is started
      await(fut);

      // Make a simple HTTP request
      HttpClient client = vertx.createHttpClient();
      HttpClientRequest req = await(client.request(HttpMethod.GET, 8080, "localhost", "/"));
      HttpClientResponse resp = await(req.send());
      int status = resp.statusCode();
      Buffer body = await(resp.body());
      System.out.println("Got response '" + body + "'");
    });
  }
}

这里的 async 和 await 多此一举，只是把异步的 future 转成同步。感觉 Spring Webflux 和 Vertx 这类响应式的 Web 框架已经没必要了，使用基于虚拟线程的 Spring MVC 足矣，当然只是感觉没有实测过。

我也找了很久都没有关于 Servlet 和 JDBC 利用虚拟线程的文章

[PDX]

只是换了一种响应式的实现方式而已，怎么能说是没必要呢。。。。

[INCerry]

看起来还是没有直接用 async/await 那么顺眼

[Leviathann]

jdbc 没法利用虚拟线程
因为虚拟线程现在不支持 synchronized 只支持 lock

[ojh]

@Leviathann 是的，我看了下 pgsql 的驱动已经有 pr 把 `synchronized ` 改为 Lock ，但是 mysql 的没消息

[ojh]

@INCerry 其实 Java 虚拟线程本身就不需要 async/await ，阻塞调用即是挂起点。正如我上面说，Vertx 的 await 只是把自身的异步转化成同步方便虚拟线程挂起

[ychost]

Java 蛋疼的是没有提供 await 关键字，导致 NIO 的代码全是回调，加了虚拟线程之后能够像 BIO 一样写代码也是挺好的，

[micean]

很蛋疼，vertx 使用虚拟线程意义不大吧，本身就是非阻塞的风格，用不到那么多线程

[INCerry]

@ojh 虚拟线程（有栈协程）也算是一个进步吧，虽然我觉得从几个方面来说无栈协程还是占优势。

[byte10]

@ojh (⊙o⊙)…协程 最大的作用 就是为了解决异步啊。。。产生异步的情况 一般是 NIO 或者是一些 GUI 按钮事件类的回调。不然要这协程要来干啥

[byte10]

@micean 虚拟线程 并不等于 多线程，概念不一样。

@ojh Spring Webflux 肯定是多余了，这玩意贼拉胯，协程出来就是它完蛋的那天。但是 vert.x 不太一样，它的设计理念还是有很多 不一样。

[micean]

@byte10

我的意思是既然选型了 vertx ，那么业务上就不需要用到虚拟线程。比如对于传统 web ，vertx 并不优于 spring ，甚至在日志 trace 这块还要劣势

[byte10]

@micean 不一样的，vert.x 很多先进的理念，尤其在分布式服务这块。另外 vert.x 非常需要虚拟线程，否则地狱回调或者响应式编程都不是很好的开发模式。有虚拟线程就能写同步编程了，响应式编程写业务的话 是非常痛苦的。

[micean]

@byte10

Future.future(业务).compose(业务).setHandler(结果) 这种流水线式的响应式编程比 reactive 之流容易理解多了，异步和同步代码也通过 Promise 隔离开了，但是把异步和同步嵌套就无比别扭，kotlin 推出协程的时候就已经体验过了。

虚拟线程解决的应该是性能损耗的问题，而不是同步编程的问题，那么回到我之前的回复，同步的业务本身就不适合 vertx 。我用了 vertx 这么多年，最合适的场景还是 gateway 、iot 之类的数据流处理。

[byte10]

@micean Promise 模式没有本质区别，还是类似 reactive ，还是一样的。虚拟线程相对多线程肯定是提升性能的。但是虚拟线程跟异步编程相比，异步编程性能更好一些，从理论上来说。

我的观点还是一样，虚拟线程就是用来 解决 NIO 异步编程问题（如果没有 IO 业务，那么 forkjoin 就能解决大部分场景，冰不需要虚拟线程）。如果能使用同步编程，那么 gateway 实现起来更舒服。

[dreamlike]

你试试用 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
你看看这一篇文章 拉到最下面有讲

[dreamlike]

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

[ojh]

@dreamlike 牛逼，兄弟，字节招 Java 不

[dreamlike]

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