无阻塞编程模型

时间 2019-11-21 标签阻塞编程模型

无阻塞编程模型涉及到异步回调流， Task， async await，线程池，并发编程，并行编程，大并发架构，操做系统之上编程模型的发展等等。html

我这段时间对这个领域的现状进行了一些收集整理和批判，请看：程序员

《后线程时代的应用程序架构》 http://www.javashuo.com/article/p-blioukym-ga.html数据库

《我支持使用 async await》 http://www.javashuo.com/article/p-kfsmekfd-cv.html编程

单纯从执行效率看，也许同步方法最直接，效率也最高。只要配合线程池合理使用线程就能够。服务器

异步方法的意义在于实现无阻塞模式，闭包

而无阻塞模式的意义要在大并发且 IO 等待时间显著、IO 可能长时间等待、 IO 等待时间不肯定（可能有意外）的时候才会体现出来。架构

什么是 IO 等待？ IO 等待本质上是 CPU 对外部设备的等待。并发

从应用上说， IO 等待就是访问数据库，调用 WebApi，读写文件， RPC 等。异步

假设线程池有 1000 个线程，能够同时处理 1000 个用户的请求，每一个请求都须要访问数据库，async

若是数据库的查询缓慢，则这 1000 个线程可能都会去等待数据库，当有第 1001 个以上的用户访问网站时，线程池将没有多余的线程去处理第 1001 个以上的用户的请求，这种状况若是持续一段时间，就会变成服务器不能提供服务，若是数据库处于 “挂掉” 的异常状态，则 Web 服务器线程池里的 1000 个线程都将长期等待数据库而挂起，这样服务器就不能提供服务，或者变得异常缓慢（对用户而言）。

微服务的 “雪崩”，大概也是从这里来的。

且从广义的角度来说，线程池的 1000 个线程原本还能够有一部分去作其它工做（不须要访问数据库的工做，或是访问其它数据库的工做），但都卡在访问 A 数据库这里了。

可是，咱们又不能采用无限制的建立线程（New Thread）的方式，过多的线程会花费比较多的切换时间，也会占用比较大的内存空间，好比 1 个线程的堆栈是 1 MB，则 1024 个线程的堆栈空间总和就是 1024 * 1 MB = 1 GB 。

因此，须要对线程池里的线程作一个角色分工来解决这个问题，这就是 “m Work， n IO” ，

“m Work， n IO” 就是 m 个工做线程， n 个 IO 线程。

m 个工做线程在无阻塞的状态下工做。

若是是单核 CPU，则能够退化为 “1 Work， n IO” 。

若是 1 个 CPU 核上只有 1 个工做线程，则称为 “单体”（monosome， monad）。

Javascript 是单体。

咱们能够来看看 3 种方式的 Sequence 图：

1 调用同步方法，如 fileStream.Read() 方法，

2 调用 async 方法再 task.ContinueWith() ，

3 调用 async 方法，使用 await，

1 调用同步方法，如 fileStream.Read() 方法，

2 调用 async 方法再 task.ContinueWith() ，

3 调用 async 方法，使用 await，

“状态机” 就是将函数参数、局部变量等上下文保存在 “状态” 中，将 “状态” 保存在堆里，以取代传统的函数调用把参数、局部变量等上下文保存在栈里的作法。

假设有个 Foo() 方法，

Foo()

{

…… // Part 1

await xxxAsync();

…… // Part 2

}

编译器会将 Foo() 方法中 await 以前的代码变成一个 Foo_Part1() 方法， Foo() 方法中 await 以后的代码变成一个 Foo_Part2() 方法，

这样 Foo() 方法就被 “分割” 成 3 个部分：

1 Foo_Part1()

2 await xxxAsync()

3 Foo_Part2()

在执行的时候，状态机就能够按 “步骤” 调用这 3 个部分，

先调用 Foo_Part1() ，再调用 xxxAsync()，以后转入异步方法执行，本次调用结束。

当 xxxAsync() 执行完成后，会调用回调，回调调用状态机，状态机接着以前的 “步骤”，继续执行 Foo_Part2() 。

这整个过程连贯起来，就是 Foo_Part1() -> xxxAsync() -> Foo_Part2，这正还原了程序员写的源代码中的执行流程。

程序员写的源代码看起来是一个顺序同步的执行过程，但其实是一个异步无阻塞的执行过程。

为何要用状态机？由于要实现异步架构，同时还要尽可能保持函数层层调用的逻辑层次结构。

好比，若是在执行中抛出异常，在异常信息中，能够看到函数的调用层次，能够看到异常是从 “Foo_Part1()” 中抛出来的，

这样咱们就清楚异常出现在那一行代码，

若是异常是从 “Foo_Part2()” 中抛出来的，那咱们也知道异常出如今 await xxxAsync(); 以后的代码里。

因此， async await 是一个语法糖，有网友说是编译器的 “黑魔法”，我总以为 async await 这个语法糖有点大，能够叫 “语法蛋糕” 。

而要实现真正的 “n IO” 无阻塞，还须要操做系统也用无阻塞的方式来实现 IO 。

假设有 n 个 IO 线程，操做系统应该用 1 个或 n 个线程去 “轮流” 等待多个设备的响应或者一个设备对多个请求的响应，

而不该该固定 1 个线程去等待 1 个请求的响应。

这种用线程 “轮流” 去等待设备响应的作法，就是 IOCP 。

理论上，只要 CPU 的处理速度足够快， 1 个线程能够等待（处理） n 个设备对 m 个请求的响应。

反之，若是固定 1 个线程 “负责” 等待 1 个请求的响应，则 n 个请求须要 n 个线程，

若是某设备的处理速度缓慢或者故障，而对该设备的请求是频繁的，则 IO 线程都会去等待这个设备，这就堵塞了。

因而就没有线程来处理其它设备的 IO 了。

这就回到了本文开篇提出的问题。

经过上面 3 个 Sequence 图，咱们能够看到：

相比同步方法，就单次调用而言，异步方法并不会减小线程切换的次数，异步方法的意义在于无阻塞。

可是从整体来看，无阻塞显著的减小了线程的数量，更少的线程意味着更少的切换。

因此，从整体来看，异步方法也是减小了线程切换次数的。

无阻塞是有利的，是计算机软件体系在后线程时代的一次发展进化。

无阻塞还能够用于 SOA ，好比 SOA 中会有这样的场景，一个业务须要调用若干个服务来完成。

这样，就能够这样写代码：

Foo()

{

…… // 一些操做

Task t1 = Service1Async();

Task t2 = Service2Async();

Task t3 = Service3Async();

await Task.WhenAll( { t1, t2, t3} );

…… // 3 个服务都调用完成时要执行的操做

}

因为服务完成的时间多是不肯定的，因此若是等服务 1 完成再调用服务 2，服务 2 完成再调用服务 3，这样效率就比较低。

因此，经过无阻塞的方式，并发调用多个服务，而后等待服务所有完成，再作下一步操做，这样能够提升效率。

固然，这里的 “等待”，也是无阻塞的。 ^^

在无阻塞编程中，不能调用 Thread.Sleep() 来延时，这会阻塞线程，占用线程，

而应该用 await Task.Delay() 方法来延时，或是用 Timer 来设定一个定时任务，把延时后要作的工做放到这个定时任务里，

固然， await Task.Delay() 更加的直观，但我猜 await Task.Delay() 内部也是用 Timer 原理实现的。

而用 Timer 定时任务来实现延时，这和 Javascript 的 window.setTimeout() 又是恰如其分的类似。

简单的状况， Task t; t.ContinueWith( 回调 ); 能够很好的完成异步调用。 Lambda 式匿名函数、闭包以及 Task 的封装已经使代码很简洁直观。

可是对于一些场景，好比业务系统三层架构里 DAL 层访问数据库，对数据进行一些处理后返回 BL 层， BL 层又把结果返回 UI 层，

咱们能够调用 Async 方法访问数据库，以实现无阻塞，但这种须要对结果进行处理并层层返回的场景，用异步回调的话代码就很麻烦，

而 async await 正是为了解决 “过多的异步回调把代码切割的支离破碎” 的问题，因此 async await 是良性的。

无阻塞 编程模型

无阻塞编程模型