结构化并发

在多线程模型中，下面几个问题给程序员带来了更多复杂性和更重的心智负担。

• 这个任务什么时候开始，什么时候结束？
• 怎么做到当所有子任务都结束，主任务再结束？
• 假如某个子任务失败，主任务如何终止掉其他子任务？
• 如何保证所有子任务在某个特定的超时时间内返回，无论它成功还是失败？
• 更进一步，如何保证主任务在规定的时间内返回，无论其成功还是失败，同时终止掉它产生的所有子任务？
• 主任务已经结束了，子任务还在运行，是不是存在资源泄漏？

有没有一种编程范式，既可以解决这些问题，又具有相对比较低的认知门槛，同时也不需要像Golang Context那样侵入应用程序的接口？结构化并发(Structured Concurrency)就是这样一种并发编程范式。

2016年，ZerMQ的作者Martin Sústrik在他的文章[5]中第一次形式化的提出结构化并发这个概念。2018年Nathaniel J. Smith (njs)在Python中实现了这一范式- trio[6]，并在Notes on structured concurrency, or: Go statement considered harmful[7]一文中进一步阐述了Structured Concurrency。同时期，Roman Elizarov也提出了相同的理念[8]，并在Kotlin中实现了大家熟知的kotlinx.coroutine[9]。2019年，OpenJDK loom project也开始引入structured concurrency，作为其轻量级线程和协程的一部分。

Structured Concurrency核心在于通过一种structured的方法实现并发程序，用具有明确入口点和出口点的控制流结构来封装并发“线程”（可以是系统级线程也可以是用户级线程，也就是协程，甚至可以是进程）的执行，确保所有派生“线程”在出口之前完成。如下例：

func main_func() {
  go myfunc()
  go anotherfunc()
  <rest of program>...
}

假设上图中的代码具有structured concurrency特性（这里用的是golang的语法来展示）。main_func里，创建了两个子任务：myfunc(), anotherfunc()，这里的func是一个控制流结构，入口就是func调用开始，出口是func调用结束，派生出来的两个子任务需要在main_func调用结束之前先完成。当main_func结束，它涉及到的资源也都会被释放掉。外部调用者无法也无需感知main_func里面到底是串行的还是并行的，它只需要调用main_func，然后等待它结束即可。这就是所谓的Structured。