一、后端工程师的致命内耗90%的人都踩过坑从事后端开发工作的人都知晓一个令人心里难受的事实: 我们所编写的 API, 八成的时间都处于看似没做事的状态, 要么是在等待数据库给出回应, 要么是在等待网络发起请求, CPU一直长时间处于空闲未被使用的状况, 然而请求却在和输入输出相关的边界处堆积如山。为了去解决这样一个“等待难题”, 在行业里面出现了各种各样的并发模型, 从Java虚拟线程开始, 一直到Rust异步, 每一种都被吹嘘成为“后端救星”了。只不过, 那所谓的真相, 当真就是这样的情形吗? 存在工程师开展了一项极端的实验举动: 运用三种各不相同的并发模型, 去达成同一个属于IO密集型的API, 然而最终呈现出的结果, 却将许多人的认知给彻底改变了。众人之中, 有人声称虚拟线程已然躺赢, 有人夸赞Rust效率已达封神之境, 还有人坚信唯有坚持方为高并发的王道所在。究竟哪一方才堪称后端并发的最优解决方案呢? 待看过这一篇详尽实测之后, 你便决然不会再被框架所束缚绑架了。关键技术补充开源免费热度1. 实现的是, 处于生态环境下的响应式框架。其中此框架开源且免费, 其星标数量达到三万九千加。它是基于某种规范而构建的, 并且主打非阻塞IO。2. Java , 虚拟线程情况Java 21导入之际带来的中心特性内容, 是开源方式且免费取用的, 它是随着JDK本身就附带有的, 并不需要另外为其引入相关依赖, 其对于传统线程模型的资源消耗这一问题做到了彻底的优化。3. Rust Async, 也就是Rust异步, 是Rust语言原生予以支持的异步样式, 它是开源并且免费的, 还要依托Tokio等相关内容完成达成, Tokio的星标是2.9万又多, 主要突出强调的是高效以及低耗。二、核心拆解同个API3种并发模型的实战实现实验的关键极为简单, 创建一个极度简约的REST接口GET /users/{id}, 仅仅需完成三步, 接收请求, 从数据库里查询数据, 返回JSON响应, 不存在缓存, 没有复杂业务逻辑, 全然模拟真实情形里最为常见的IO密集型微服务。以确保实验具备公平性为目的, 三种实现运用了完全一样的数据库, 有着相同的表结构, 采用相同的查询方式, 并且处于相同的部署环境之中, 唯一的变量便是“并发模型 运行时”。接下来, 我们会对每种模型其实现的方式, 核心的代码, 以及运行的逻辑进行逐个的拆解。模型1编程 其一, 编程是最早解决“等待难题”的方案中的一个, 其二, 编程的核心思路是, 其三, 它不会阻塞线程, 其四, 而是把计算转变为事件流, 其五, 由事件循环来驱动执行, 其六, 在数据就绪之后再去触发后续操作。简要来讲, 便是要使得线程“不会处于空闲状态”, 于等待输入输出的这个间隙期间, 去着手处理别的请求, 借此提升并发的能力。核心代码简洁可直接复用GetMapping(/users/{id}) public Mono getUser(PathVariable String id) { return userRepository.findById(id) .map(user - new UserResponse(user.getId(), user.getName())); }关键说明: 返回值Mono表示的是一个以异步方式产生出来的单一的值, 数据库驱动其自身是属于非阻塞性质的, 在程序处于等待数据库给予响应的这个期间, 线程会被释放掉从而能够去处理别的请求, 以此来避免出现资源浪费的情况。模型2Java虚拟线程 MVCJava 21有着重磅更新, 这更新彻底打破了传统线程模型的局限, 此局限在于不用改写代码, 不用学习复杂的事件流, 还保留传统“一个请求一个线程”的模式, 然而线程变得极度“轻量化”, 并且资源消耗大幅降低。核心逻辑是, 当线程因为IO而出现阻塞的时候, JVM会去暂停这个虚拟线程, 进而调度其他的虚拟线程去执行, 在IO完成之后再进行恢复, 这等同于使用“廉价线程”达成了高并发。核心代码和传统同步代码完全一致RestController class UserController { GetMapping(/users/{id}) public UserResponse getUser(PathVariable String id) { User user userRepository.findById(id); return new UserResponse(user.getId(), user.getName()); } }关键说明: 不存在那种繁杂的包装, 而是极为普通的阻塞式Java代码, 然而其底层是由JVM来对虚拟线程进行管理的, 并不需要开发者去留意异步逻辑, 上手的成本为零。模型3Rust AsyncAxum框架Rust有着全然不同的并发思路, 它并非去隐藏异步的细节, 而是于类型系统里明确标示异步逻辑, 这种异步代码依照要求会被编译成状态机, 并且由像是Tokio这样的工具来调度执行, 最终实现兼顾高效与可控的效果。核心逻辑是, 借助async/await关键字, 去清晰明确地标记异步边界, 如此一来, 开发者能够确切知晓何处将会暂停下来等候IO, 并且在编译期的时候就会对异步逻辑实施检查, 进而避免潜在的问题。核心代码基于Axumsqlxasync fn get_user( Path(id): Path, State(pool): State, ) - Json { let user sqlx::query_as::_, User( SELECT id, name FROM users WHERE id $1 ) .bind(id) .fetch_one(pool) .await .unwrap(); Json(UserResponse { id: user.id, name: user.name }) }关键说明: 标记该函数返回使用async关键字, 标记IO等待点需用.await, 执行到这个标志处的时候会暂停下来, 等待数据库做出响应之后才会继续进行, 整个过程不存在阻塞情况, 并且资源消耗极其低。三、辩证分析没有最优解只有最适配的选择有着三种模型, 它们均能够实现同一API, 然而在开发体验方面, 在性能方面, 在资源消耗方面, 各自存在优势与劣势, 并不存在那种呈现“碾压式”态势的赢家。我们从四个核心维度出发, 以辩证的方式去拆解它们的有利之处以及不利之处, 以此来帮助你避开选择时所设下的陷阱。维度1开发体验可读性上手难度Java虚拟线程绝对是最佳的解决办法, 其代码跟传统同步代码全然相同, 用不着去学习全新的概念, 不管是刚接触的新手, 还是经验丰富的老开发者, 都能够迅速上手, 调试起来也很简便, 线性调用栈清晰明了呀。但是, 它所具备的优势之中, 其实是潜藏着局限的, 一方面是过度地依赖JVM的调度, 另一方面, 针对复杂的事件流场景来说, 灵活性显得不够充足, 并且, 没办法像那样子轻轻松松地去构建复杂的数据管道。上手Rust Async的难度处于中等水平, async/await所包含的语法呈现出简洁之态, 能够十分清晰地看见异步的边界, 然而却需要去掌握生命周期、固定等额外的概念, 编译期进行的严格检查会致使开发成本有所增加, 不过凭借此也能够避免许多线上出现的bug。该内容具备极高的上手疑难程度, 要求对编程思路予以彻底革新, 从“依序执行”转接成“搭建事件管道”, 针对那些并不熟稔的开发者而言, 等同于研习一门全新的“嵌入式语言”, 且调试期间的异步栈追踪同样极为繁杂。作思考: 于你身处的队伍而言, 究竟是更注重“开发效率”, 还是更为看重“框架灵活性”? 针对初入此行的团体来讲, 真的适宜直接着手开展此项工作吗。维度2性能 延迟表现它的优势在于, 能完全避免线程阻塞, 在那种高IO负载的场景之下, 其吞吐量保持稳定, 不会出现因为线程阻塞进而导致的波动, 所以适合对吞吐量有着极高要求的场景。然而它存在着明显的短板, 其一, 事件管道的抽象层会致使产生轻微的性能损耗, 其二, 针对简单的CRUD接口而言, 其效率反倒比不上虚拟线程高效。Java虚拟线程于多数场景里展现出优秀态势, 可轻易应对数千并发请求, 然而因受JVM垃圾回收干扰, 偶尔会出现位于尾部的那种p95/p99类型的波动情况, 对于那些较为敏感的场景而言, 就得额外去优化JVM参数。异步运行时, 内存管理, 开销极低, 尾部波动极小, 适合对要求严格的基础设施类服务, Rust Async表现最稳定, 且无托管运行时。揣测: 你的服务是“吞吐量在前”还是“在前”呢? 要是属于用户的服务, 细微的起伏会对用户体验造成影响吗?维度3资源效率内存线程消耗Rust Async取得完胜, 它没有JVM等托管运行时, 其中异步具备轻量的特点, 并且内存占用非常低, 在同样的硬件配置状况下, 能够支撑更多的并发请求, 它适合那种资源受限的场景, 像边缘服务、网关这类的。表现出色, 依靠事件循环以及小线程池, 资源耗费远比传统Java线程模型低, 具备以较少线程支持高并发的能力, 适宜微服务集群部署。Java虚拟线程虽极大程度降低了线程成本, 然而JVM自身的运行时开销仍旧存在, 与Rust相较, 内存占用以及启动速度有着显著差距, 不适用于对资源极度敏感的场景。琢磨: 你所提供服务的部署环境, 究竟是那种被称作“资源充足”的情形, 还是属于那种名为“资源受限”的状况? 耗费过多的资源, 到底会致使服务器成本增加到怎样的一个程度?维度4可观测性调试监控占据绝对优势的是, 成熟工具链历经数十年的Java生态包含虚拟线程及后续紧跟内容, 在监控方面, 有着像Boot所代表的完善解决方案, 在调试方面, 同样有着像Boot所代表的完善实施方案, 并且运维成本较低。可是存在着一个致使的短处, 那就是异步管道的栈跟踪不够直观, 当出现问题了的时候, 很难确定到具体的异常节点, 这就增加了运维的困难程度。Rust的可观测性正处于快速完善进程中, 然而现下其实依旧存在着差距, 它的诊断环节是需要施行更多手动埋点操作的, 就运维团队而言, 其学习成本是比较高的, 这种情况适合那些拥有Rust技术积累的团队。思索: 你们团队的运维能力怎样? 可不可以承受Rust异步的运维所需成本?四、现实意义选对并发模型能省一半力气有不少后端工程师, 陷入了这样一个误区, 他们盲目地去追求那所谓“最先进”的并发模型, 跟风去使用、学习Rust, 然而却忽略了自身所处的业务场景, 最终致使开发效率出现下降, 线上问题频繁发生。这场实验所带来的核心启示在于, 并发模型就是工具, 不存在好坏的区别, 仅仅存在适配与否的状况。要结合业务场景去进行选择, 如此才能够将其价值最大化地发挥出来, 甚至于能够省出一半的开发成本以及运维成本。不同场景的最优选择1. 以传统的微服务而言, 其主要是以CRUD工作为主, 并且属于IO密集型的, 在这样的情况之下, 优先选择的应当是Java虚拟线程。没有必要去改写现有的代码, 它上手的速度快, 调试起来简易, 能够轻松地去应对高并发的情况, 适合大部分的后端团队, 特别是那些从传统MVC迁移过来的团队, 几乎零成本就可以实现升级。2. 事件流、数据管道类服务优先选倘若你所提供的服务, 存在着需要去处理数量众多的事件流这种情况, 像是消息推送、数据同步这类, 那么相应的事件管道, 便能够以一种轻松的状态, 达成复杂的数据流处理操作, 并且在吞吐量方面, 具备极为显著的优势。3. 基础设施、边缘服务优先选Rust Async在网关、代理、边缘计算这类对资源效率有着极高要求的场景当中, Rust Async所具备的低耗优势以及稳定优势会被无限放大, 它能够在有限资源的状况下支撑起更高的并发量, 从而展现出其独特的价值。更为关键的是, 于工程师而言, 真正所需把握的内容, 并非某一个单一的框架, 而是“阻塞与其相反的非阻塞 IO 之间的区别”, “面对多个同时进行的并发请求时系统所展现出的行为”, “资源消耗依照负载的不同而呈现出的变化规律”, 这些处于底层的逻辑, 才是在应对全部的并发场景时所必须具备的关键核心能力。许多时候, 后端性能方面的瓶颈之处, 向来并非并发模型这类因素, 而是数据库以及网络等一系列外部依赖相关的情况。相较于困于纠结框架选型这件事情, 实实在在优先去将IO链路予以优化, 这样子才是具备最高性价比的一种选择。五、互动话题你正在用哪种并发模型踩过哪些坑对后端并发进行选型时, 从来都是一场“取舍”, 有人为了开发层面的效率, 便坚持选用Java虚拟线程, 有人为了性能能够达到极致, 于是深入钻研Rust Async, 还有人是为了业务方面的适配, 所以咬紧牙关去攻克。来留言区讨论讨论: 针对现在的项目, 请问正在使用的是哪一种并发模型? 在进行开发或者运维的过程当中, 都碰到过哪些方面的问题? 你认为哪一种模型对于当下的业务场景而言, 是最为合适的?
一、后端工程师的致命内耗90%的人都踩过坑从事后端开发工作的人都知晓一个令人心里难受的事实: 我们所编写的 API, 八成的时间都处于看似没做事的状态, 要么是在等待数据库给出回应, 要么是在等待网络发起请求, CPU一直长时间处于空闲未被使用的状况, 然而请求却在和输入输出相关的边界处堆积如山。为了去解决这样一个“等待难题”, 在行业里面出现了各种各样的并发模型, 从Java虚拟线程开始, 一直到Rust异步, 每一种都被吹嘘成为“后端救星”了。只不过, 那所谓的真相, 当真就是这样的情形吗? 存在工程师开展了一项极端的实验举动: 运用三种各不相同的并发模型, 去达成同一个属于IO密集型的API, 然而最终呈现出的结果, 却将许多人的认知给彻底改变了。众人之中, 有人声称虚拟线程已然躺赢, 有人夸赞Rust效率已达封神之境, 还有人坚信唯有坚持方为高并发的王道所在。究竟哪一方才堪称后端并发的最优解决方案呢? 待看过这一篇详尽实测之后, 你便决然不会再被框架所束缚绑架了。关键技术补充开源免费热度1. 实现的是, 处于生态环境下的响应式框架。其中此框架开源且免费, 其星标数量达到三万九千加。它是基于某种规范而构建的, 并且主打非阻塞IO。2. Java , 虚拟线程情况Java 21导入之际带来的中心特性内容, 是开源方式且免费取用的, 它是随着JDK本身就附带有的, 并不需要另外为其引入相关依赖, 其对于传统线程模型的资源消耗这一问题做到了彻底的优化。3. Rust Async, 也就是Rust异步, 是Rust语言原生予以支持的异步样式, 它是开源并且免费的, 还要依托Tokio等相关内容完成达成, Tokio的星标是2.9万又多, 主要突出强调的是高效以及低耗。二、核心拆解同个API3种并发模型的实战实现实验的关键极为简单, 创建一个极度简约的REST接口GET /users/{id}, 仅仅需完成三步, 接收请求, 从数据库里查询数据, 返回JSON响应, 不存在缓存, 没有复杂业务逻辑, 全然模拟真实情形里最为常见的IO密集型微服务。以确保实验具备公平性为目的, 三种实现运用了完全一样的数据库, 有着相同的表结构, 采用相同的查询方式, 并且处于相同的部署环境之中, 唯一的变量便是“并发模型 运行时”。接下来, 我们会对每种模型其实现的方式, 核心的代码, 以及运行的逻辑进行逐个的拆解。模型1编程 其一, 编程是最早解决“等待难题”的方案中的一个, 其二, 编程的核心思路是, 其三, 它不会阻塞线程, 其四, 而是把计算转变为事件流, 其五, 由事件循环来驱动执行, 其六, 在数据就绪之后再去触发后续操作。简要来讲, 便是要使得线程“不会处于空闲状态”, 于等待输入输出的这个间隙期间, 去着手处理别的请求, 借此提升并发的能力。核心代码简洁可直接复用GetMapping(/users/{id}) public Mono getUser(PathVariable String id) { return userRepository.findById(id) .map(user - new UserResponse(user.getId(), user.getName())); }关键说明: 返回值Mono表示的是一个以异步方式产生出来的单一的值, 数据库驱动其自身是属于非阻塞性质的, 在程序处于等待数据库给予响应的这个期间, 线程会被释放掉从而能够去处理别的请求, 以此来避免出现资源浪费的情况。模型2Java虚拟线程 MVCJava 21有着重磅更新, 这更新彻底打破了传统线程模型的局限, 此局限在于不用改写代码, 不用学习复杂的事件流, 还保留传统“一个请求一个线程”的模式, 然而线程变得极度“轻量化”, 并且资源消耗大幅降低。核心逻辑是, 当线程因为IO而出现阻塞的时候, JVM会去暂停这个虚拟线程, 进而调度其他的虚拟线程去执行, 在IO完成之后再进行恢复, 这等同于使用“廉价线程”达成了高并发。核心代码和传统同步代码完全一致RestController class UserController { GetMapping(/users/{id}) public UserResponse getUser(PathVariable String id) { User user userRepository.findById(id); return new UserResponse(user.getId(), user.getName()); } }关键说明: 不存在那种繁杂的包装, 而是极为普通的阻塞式Java代码, 然而其底层是由JVM来对虚拟线程进行管理的, 并不需要开发者去留意异步逻辑, 上手的成本为零。模型3Rust AsyncAxum框架Rust有着全然不同的并发思路, 它并非去隐藏异步的细节, 而是于类型系统里明确标示异步逻辑, 这种异步代码依照要求会被编译成状态机, 并且由像是Tokio这样的工具来调度执行, 最终实现兼顾高效与可控的效果。核心逻辑是, 借助async/await关键字, 去清晰明确地标记异步边界, 如此一来, 开发者能够确切知晓何处将会暂停下来等候IO, 并且在编译期的时候就会对异步逻辑实施检查, 进而避免潜在的问题。核心代码基于Axumsqlxasync fn get_user( Path(id): Path, State(pool): State, ) - Json { let user sqlx::query_as::_, User( SELECT id, name FROM users WHERE id $1 ) .bind(id) .fetch_one(pool) .await .unwrap(); Json(UserResponse { id: user.id, name: user.name }) }关键说明: 标记该函数返回使用async关键字, 标记IO等待点需用.await, 执行到这个标志处的时候会暂停下来, 等待数据库做出响应之后才会继续进行, 整个过程不存在阻塞情况, 并且资源消耗极其低。三、辩证分析没有最优解只有最适配的选择有着三种模型, 它们均能够实现同一API, 然而在开发体验方面, 在性能方面, 在资源消耗方面, 各自存在优势与劣势, 并不存在那种呈现“碾压式”态势的赢家。我们从四个核心维度出发, 以辩证的方式去拆解它们的有利之处以及不利之处, 以此来帮助你避开选择时所设下的陷阱。维度1开发体验可读性上手难度Java虚拟线程绝对是最佳的解决办法, 其代码跟传统同步代码全然相同, 用不着去学习全新的概念, 不管是刚接触的新手, 还是经验丰富的老开发者, 都能够迅速上手, 调试起来也很简便, 线性调用栈清晰明了呀。但是, 它所具备的优势之中, 其实是潜藏着局限的, 一方面是过度地依赖JVM的调度, 另一方面, 针对复杂的事件流场景来说, 灵活性显得不够充足, 并且, 没办法像那样子轻轻松松地去构建复杂的数据管道。上手Rust Async的难度处于中等水平, async/await所包含的语法呈现出简洁之态, 能够十分清晰地看见异步的边界, 然而却需要去掌握生命周期、固定等额外的概念, 编译期进行的严格检查会致使开发成本有所增加, 不过凭借此也能够避免许多线上出现的bug。该内容具备极高的上手疑难程度, 要求对编程思路予以彻底革新, 从“依序执行”转接成“搭建事件管道”, 针对那些并不熟稔的开发者而言, 等同于研习一门全新的“嵌入式语言”, 且调试期间的异步栈追踪同样极为繁杂。作思考: 于你身处的队伍而言, 究竟是更注重“开发效率”, 还是更为看重“框架灵活性”? 针对初入此行的团体来讲, 真的适宜直接着手开展此项工作吗。维度2性能 延迟表现它的优势在于, 能完全避免线程阻塞, 在那种高IO负载的场景之下, 其吞吐量保持稳定, 不会出现因为线程阻塞进而导致的波动, 所以适合对吞吐量有着极高要求的场景。然而它存在着明显的短板, 其一, 事件管道的抽象层会致使产生轻微的性能损耗, 其二, 针对简单的CRUD接口而言, 其效率反倒比不上虚拟线程高效。Java虚拟线程于多数场景里展现出优秀态势, 可轻易应对数千并发请求, 然而因受JVM垃圾回收干扰, 偶尔会出现位于尾部的那种p95/p99类型的波动情况, 对于那些较为敏感的场景而言, 就得额外去优化JVM参数。异步运行时, 内存管理, 开销极低, 尾部波动极小, 适合对要求严格的基础设施类服务, Rust Async表现最稳定, 且无托管运行时。揣测: 你的服务是“吞吐量在前”还是“在前”呢? 要是属于用户的服务, 细微的起伏会对用户体验造成影响吗?维度3资源效率内存线程消耗Rust Async取得完胜, 它没有JVM等托管运行时, 其中异步具备轻量的特点, 并且内存占用非常低, 在同样的硬件配置状况下, 能够支撑更多的并发请求, 它适合那种资源受限的场景, 像边缘服务、网关这类的。表现出色, 依靠事件循环以及小线程池, 资源耗费远比传统Java线程模型低, 具备以较少线程支持高并发的能力, 适宜微服务集群部署。Java虚拟线程虽极大程度降低了线程成本, 然而JVM自身的运行时开销仍旧存在, 与Rust相较, 内存占用以及启动速度有着显著差距, 不适用于对资源极度敏感的场景。琢磨: 你所提供服务的部署环境, 究竟是那种被称作“资源充足”的情形, 还是属于那种名为“资源受限”的状况? 耗费过多的资源, 到底会致使服务器成本增加到怎样的一个程度?维度4可观测性调试监控占据绝对优势的是, 成熟工具链历经数十年的Java生态包含虚拟线程及后续紧跟内容, 在监控方面, 有着像Boot所代表的完善解决方案, 在调试方面, 同样有着像Boot所代表的完善实施方案, 并且运维成本较低。可是存在着一个致使的短处, 那就是异步管道的栈跟踪不够直观, 当出现问题了的时候, 很难确定到具体的异常节点, 这就增加了运维的困难程度。Rust的可观测性正处于快速完善进程中, 然而现下其实依旧存在着差距, 它的诊断环节是需要施行更多手动埋点操作的, 就运维团队而言, 其学习成本是比较高的, 这种情况适合那些拥有Rust技术积累的团队。思索: 你们团队的运维能力怎样? 可不可以承受Rust异步的运维所需成本?四、现实意义选对并发模型能省一半力气有不少后端工程师, 陷入了这样一个误区, 他们盲目地去追求那所谓“最先进”的并发模型, 跟风去使用、学习Rust, 然而却忽略了自身所处的业务场景, 最终致使开发效率出现下降, 线上问题频繁发生。这场实验所带来的核心启示在于, 并发模型就是工具, 不存在好坏的区别, 仅仅存在适配与否的状况。要结合业务场景去进行选择, 如此才能够将其价值最大化地发挥出来, 甚至于能够省出一半的开发成本以及运维成本。不同场景的最优选择1. 以传统的微服务而言, 其主要是以CRUD工作为主, 并且属于IO密集型的, 在这样的情况之下, 优先选择的应当是Java虚拟线程。没有必要去改写现有的代码, 它上手的速度快, 调试起来简易, 能够轻松地去应对高并发的情况, 适合大部分的后端团队, 特别是那些从传统MVC迁移过来的团队, 几乎零成本就可以实现升级。2. 事件流、数据管道类服务优先选倘若你所提供的服务, 存在着需要去处理数量众多的事件流这种情况, 像是消息推送、数据同步这类, 那么相应的事件管道, 便能够以一种轻松的状态, 达成复杂的数据流处理操作, 并且在吞吐量方面, 具备极为显著的优势。3. 基础设施、边缘服务优先选Rust Async在网关、代理、边缘计算这类对资源效率有着极高要求的场景当中, Rust Async所具备的低耗优势以及稳定优势会被无限放大, 它能够在有限资源的状况下支撑起更高的并发量, 从而展现出其独特的价值。更为关键的是, 于工程师而言, 真正所需把握的内容, 并非某一个单一的框架, 而是“阻塞与其相反的非阻塞 IO 之间的区别”, “面对多个同时进行的并发请求时系统所展现出的行为”, “资源消耗依照负载的不同而呈现出的变化规律”, 这些处于底层的逻辑, 才是在应对全部的并发场景时所必须具备的关键核心能力。许多时候, 后端性能方面的瓶颈之处, 向来并非并发模型这类因素, 而是数据库以及网络等一系列外部依赖相关的情况。相较于困于纠结框架选型这件事情, 实实在在优先去将IO链路予以优化, 这样子才是具备最高性价比的一种选择。五、互动话题你正在用哪种并发模型踩过哪些坑对后端并发进行选型时, 从来都是一场“取舍”, 有人为了开发层面的效率, 便坚持选用Java虚拟线程, 有人为了性能能够达到极致, 于是深入钻研Rust Async, 还有人是为了业务方面的适配, 所以咬紧牙关去攻克。来留言区讨论讨论: 针对现在的项目, 请问正在使用的是哪一种并发模型? 在进行开发或者运维的过程当中, 都碰到过哪些方面的问题? 你认为哪一种模型对于当下的业务场景而言, 是最为合适的?
)
