JEP 462 结构化并发是一个很愚蠢的提案
Motivation
Developers manage complexity by breaking tasks down into multiple subtasks. In ordinary single-threaded code, the subtasks execute sequentially. However, if the subtasks are sufficiently independent of each other, and if there are sufficient hardware resources, then the overall task can be made to run faster (i.e., with lower latency) by executing the subtasks concurrently. For example, a task that composes the results of multiple I/O operations will run faster if each I/O operation executes concurrently in its own thread. Virtual threads (JEP 444) make it cost-effective to dedicate a thread to every such I/O operation, but managing the huge number of threads that can result remains a challenge.
开发人员通过将任务分解为多个子任务来管理复杂性。在普通的单线程代码中，子任务顺序执行。然而，如果子任务彼此充分独立，并且如果有足够的硬件资源，则可以通过同时执行子任务来使整体任务运行得更快（即，具有更低的延迟）。例如，如果每个 I/O 操作在自己的线程中并发执行，则由多个 I/O 操作组成的任务将运行得更快。虚拟线程 ( JEP 444 ) 使为每个此类 I/O 操作专用一个线程变得经济高效，但管理可能产生的大量线程仍然是一个挑战。
该提案还号称参考了 Erlang
Structured concurrency is an approach to concurrent programming that preserves the natural relationship between tasks and subtasks, which leads to more readable, maintainable, and reliable concurrent code. The term "structured concurrency" was coined by Martin Sústrik and popularized by Nathaniel J. Smith. Ideas from other languages, such as Erlang's hierarchical supervisors, inform the design of error handling in structured concurrency.
但是在 erlang 的视角, process 本身就是贯穿性的任务实体, 而 virtual thread 相当于 erlang 的 process, 按此推理, virtual thread 形成一个层次化的关系, 就可以表达任务及其子任务.
在 ExecutorService 时代, 线程很贵, Java 的 Runnable Callable 跨越了多个线程, 将任务分布于线程上, 是很高明的设计. 但 virtual thread 已经不需要这种巧妙的设计了————这不知道是进步还是退步————既然选择了 virtual thread 新的并发模型就应当以 virtual thread 出发. 遗憾的是, virtual thread 努力摆脱的 reactive 编程 在这个结构化并发的提案里又回来了.
virtual thread 再加一个 channel 就相当于 golang 了, 搞并发的不妨别管 JEP462.
