多线程 ---> 并发编程----> 异步编程--->响应式编程--->结构化并发编程

多线程 --->  并发编程----> 异步编程--->响应式编程--->结构化并发编程 

结构化并发编程内部基于 java协程 实现的

 

 

结构化并发，简化 Java 多线程编程

结构化并发：并发编程的一次飞跃

结构化并发带来了很多好处。它为调用者方法及其子任务创建了一种父子关系。例如，在上面的例子中，handle()任务是父，它的子任务 findUser()和 fetchOrder()是子。结果，整个代码块变成了原子代码。它通过线程转储中的任务层次结构来提供可观察性。它还可以在错误处理中实现短路，如果其中一个子任务失败，其他未完成的任务将被取消。如果父任务的线程在 join()调用之前或期间被中断，两个分支将在作用域退出时自动取消。这让并发代码的结构变得更加清晰，开发人员现在可以推理和跟踪代码，就好像它们是在单线程环境中运行。

 

早期的程序流程普遍使用 GOTO 语句来控制，代码十分混乱，这种意大利面条式的代码难以阅读和调试。随着编程范式的成熟，编程社区认识到 GOTO 语句是有害的。1969 年，以《计算机编程的艺术》一书而闻名的计算机科学家 Donald Knuth 表示，没有 GOTO 也可以高效地编写程序。后来，结构化编程的出现解决了所有这些缺点。看一下下面的例子：

?

1 2 3 4 5

Response handle() throws IOException {    String theUser = findUser();    int theOrder = fetchOrder();    return new Response(theUser, theOrder); }

上面的代码是结构化代码的一个例子。在单线程环境中，handle()方法被调用时将按顺序执行。fetchOrder()方法不会在 findUser()方法之前启动。如果 findUser()方法失败，下面的方法根本不会启动，handle()方法将隐式失败，这反过来确保了原子操作成功或不成功。它提供了 handle()方法及其子方法之间的父子关系，遵循错误传播的规则，并在运行时提供调用堆栈信息。　　
然而，这种方法和推理并不适用于我们当前的线程编程模型。例如，如果我们想用 ExecutorService 改写上述的代码，就像这样：

?

1 2 3 4 5 6 7

Response handle() throws ExecutionException, InterruptedException {    Future<String>  user  = executorService.submit(() -> findUser());    Future<Integer> order = executorService.submit(() -> fetchOrder());    String theUser  = user.get();   // 连接findUser    int theOrder = order.get();  // 连接fetchOrder    return new Response(theUser, theOrder); }

　　

ExecutorService 中的子任务独立运行，可能成功或失败。即使父任务被中断，中断也不会被传播到子任务，因此会造成泄漏。它没有了父关系。由于父任务和子任务将出现在线程转储不相关的线程调用堆栈上，因此调试也变得困难。尽管代码看起来具有逻辑结构，但这种结构只停留在开发人员的头脑中，而不是在执行过程中。所以，它们是非结构化的并发代码。

 

通过观察非结构化并发代码存在的这些问题，Martin Sústrik 在他的博文中创造了“结构化并发”这个术语，然后 Nathaniel J. Smith 在他关于结构化并发的文章中推广了这个术语。关于结构化并发，Oracle 技术咨询成员、Loom 项目负责人 Ron Pressler 在 InfoQ 的一个播客中说道：

?

1 2	结构化的意思是，如果你生成了什么东西，你必须等待并连接它。这里的“结构”与它在结构化编程中的含义相似。代码的块结构反映了程序的运行时行为。因此，就像结构化编程提供了顺序控制流保证，结构化并发也为并发提供了同样的保证。 有兴趣深入了解结构化并发及其背景故事的开发者可以收听 InfoQ 的博客，或者观看 Ron Pressler 在YouTube上的分享以及Inside Java的文章。