
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 利用虚拟线程的文章
1 PDX 2022 年 8 月 11 日 只是换了一种响应式的实现方式而已,怎么能说是没必要呢。。。。 |
2 INCerry 2022 年 8 月 11 日 看起来还是没有直接用 async/await 那么顺眼 |
3 Leviathann 2022 年 8 月 11 日 jdbc 没法利用虚拟线程 因为虚拟线程现在不支持 synchronized 只支持 lock |
4 ojh OP @Leviathann 是的,我看了下 pgsql 的驱动已经有 pr 把 `synchronized ` 改为 Lock ,但是 mysql 的没消息 |
5 ojh OP @INCerry 其实 Java 虚拟线程本身就不需要 async/await ,阻塞调用即是挂起点。正如我上面说,Vertx 的 await 只是把自身的异步转化成同步方便虚拟线程挂起 |
6 ychost 2022 年 8 月 11 日 Java 蛋疼的是没有提供 await 关键字,导致 NIO 的代码全是回调,加了虚拟线程之后能够像 BIO 一样写代码也是挺好的, |
7 micean 2022 年 8 月 11 日 很蛋疼,vertx 使用虚拟线程意义不大吧,本身就是非阻塞的风格,用不到那么多线程 |
9 byte10 2022 年 8 月 11 日 @ojh (⊙o⊙)…协程 最大的作用 就是为了解决异步啊。。。产生异步的情况 一般是 NIO 或者是一些 GUI 按钮事件类的回调。不然要这协程要来干啥 |
10 byte10 2022 年 8 月 11 日 |
11 micean 2022 年 8 月 12 日 |
12 byte10 2022 年 8 月 12 日 @micean 不一样的,vert.x 很多先进的理念,尤其在分布式服务这块。另外 vert.x 非常需要虚拟线程,否则地狱回调或者响应式编程都不是很好的开发模式。有虚拟线程就能写同步编程了,响应式编程写业务的话 是非常痛苦的。 |
13 micean 2022 年 8 月 12 日 @byte10 Future.future(业务).compose(业务).setHandler(结果) 这种流水线式的响应式编程比 reactive 之流容易理解多了,异步和同步代码也通过 Promise 隔离开了,但是把异步和同步嵌套就无比别扭,kotlin 推出协程的时候就已经体验过了。 虚拟线程解决的应该是性能损耗的问题,而不是同步编程的问题,那么回到我之前的回复,同步的业务本身就不适合 vertx 。我用了 vertx 这么多年,最合适的场景还是 gateway 、iot 之类的数据流处理。 |
14 byte10 2022 年 8 月 12 日 @micean Promise 模式没有本质区别,还是类似 reactive ,还是一样的。虚拟线程相对多线程肯定是提升性能的。但是虚拟线程跟异步编程相比,异步编程性能更好一些,从理论上来说。 我的观点还是一样,虚拟线程就是用来 解决 NIO 异步编程问题(如果没有 IO 业务,那么 forkjoin 就能解决大部分场景,冰不需要虚拟线程)。如果能使用同步编程,那么 gateway 实现起来更舒服。 |
15 dreamlike 2022 年 8 月 14 日 你试试用 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 你看看这一篇文章 拉到最下面有讲 |
16 dreamlike 2022 年 8 月 14 日 对于原本的 vertx 开发来讲,确实是重大好消息,这样就可以保证同步风格开发了,原来的 ThreadLocal 之类的也可以使用了,juc 包也可以直接上了,补起来一部分短板,甚至一些不使用 sychronized 实现的阻塞式的 client 也可以直接用了,属于是直接扩展了生态,建立起了同步阻塞和异步非阻塞的桥梁而没有 kt 协程的染色问题,我觉得非常的好 如果不从 vertx 角度看 而从业务开发的便利性看确实不如 springmvc+loom (如果 pin 住 carrier 的问题可以解决) |