10 | 如何使用异步设计提升系统性能？

个人的一点想法： 异步回调机制的本质是通过减少线程等待时占用的CPU时间片，来提供CPU时间片的利用率。 具体做法是用少数线程响应业务请求，但处理时这些线程并不真正调用业务逻辑代码，而是简单的把业务处理逻辑扔到另一个专门执行业务逻辑代码的线程后就返回了，故不会有任何等待(CPU时间片浪费)。专门执行业务逻辑的线程可能会由于IO慢导致上下文切换而浪费一些CPU时间片，但这已经不影响业务请求的响应了，而业务逻辑执行完毕后会把回调处理逻辑再扔到专门执行回调业务逻辑的线程中，这时的执行业务逻辑线程的使命已完成，线程返回，然后会去找下一个需要执行的业务逻辑，这里也没有任何等待。回调业务处理线程也是同理。 以上于《摩登时代》里的卓别林很像，每个人只做自己的那点事(卓别林只拧螺丝)。有的线程只负责响应请求(放螺丝)，有的线程只负责执行业务逻辑(拧螺丝)，有的线程只负责执行回调代码(敲螺丝)，完成后就返回并继续执行下一个相同任务(拧完这个螺丝再找下一个需要拧的螺丝)，没有相互依赖的等待(放螺丝的不等螺丝拧好就直接放下一个螺丝)。 有利就有弊，分开后是不用等别人了，但想知道之前的步骤是否已经做好了就难了。比如螺丝没有拧紧就开始敲，会导致固定不住。如果发现螺丝没拧好，敲螺丝的人就要和工头说这块板要返工，螺丝取下，重新放，重新拧，之后才能敲。 个人感觉把关联性强且无需长时间等待的操作(如大量磁盘或网络IO)打包成同步，其他用异步，这样可以在规避CPU时间片浪费的同时兼顾了一致性，降低了补偿的频率和开销。

个人的思路，欢迎老师点评下哈。 1，调用账户失败，可以在异步callBack里执行通知客户端的逻辑； 2，如果是第一次失败，那后面的那一步就不用执行了，所以转账失败；如果是第一次成功但是第二次失败，首先考虑重试，如果转账服务是幂等的,可以考虑一定次数的重试，如果不能重试，可以考虑采用补偿机制，undo第一次的转账操作。 3，CompletableFuture默认是在ForkjoinPool commonpool里执行的，也可以指定一个Executor线程池执行，借鉴guava的ListenableFuture的时间，回调可以指定线程池执行，这样就能控制这个线程池的线程数目了。

老师，我一直有一个困惑，就是想不明白为何异步可以节省线程。每次发起一个异步调用不都会创建一个新的线程吗？我理解了好几次，感觉只是异步处理线程在等待时可以让出时间片给其他线程运行啊？一直想不明白这个问题，困扰了好久，求老师解惑。

老师可能里面过多提到线程这两个字，所以很多人把异步设计理解成节约线程，其实李玥老师这里想说明的是异步是用来提高cup的利用率，而不是节省线程。 异步编程是通过分工的方式，是为了减少了cpu因线程等待的可能，让CPU一直处于工作状态。换句话说，如果我们能想办法减少CPU空闲时间，我们的计算机就可以支持更多的线程。 其实线程是一个抽象概念，我们从物理层面理解，就是单位时间内把每毫核分配处理不同的任务，从而提高单位时间内CPU的利用率。

老师，有一点不太懂，异步转账时，假如专门几个线程（Threads_quest）处理转账请求，其他的线程处理账户增减金额逻辑，虽然大量请求来的时候，Threads_quest 这几个线程可以接受请求之后扔给其他线程处理增减金额，但是由于请求量过大，不也会导致其他线程处理变慢吗，导致完整的处理也变慢

尝试回答课后习题，老师有空帮忙看下哦 思考题一、如果在异步实现中，如果调用账户服务失败，可以以账单的形式将转账失败的记录下来，比如客户在转账一段时间后 查看账单就可以知道转账是否成功，只要保证转账失败，客户的钱没有少就可以。两次调用账户服务，感觉可以这样写 /** * 转账服务的实现 */ public class TransferServiceImpl implements TransferService { @Inject private AccountService accountService; // 使用依赖注入获取账户服务的实例 @Override public CompletableFuture<Void> transfer(int fromAccount, int toAccount, int amount) { // 异步调用 add 方法从 fromAccount 扣减相应金额 return accountService.add(fromAccount, -1 * amount).exceptionally(add(fromAccount, amount)) // 然后调用 add 方法给 toAccount 增加相应金额 .thenCompose(v -> accountService.add(toAccount, amount)).exceptionally(add(toAccount, -1 * amount)); } } 思考题二、在异步实现中，回调方法OnComplete()可以在另一个线程池执行，比如rocketmq中异步实现， 再异步发送消息时，会将封装一个ResponseFuture包含回调方法、通道、请求消息id，将其请求id做为key，ResponseFuture做为value放入map中 等响应返回时，根据请求id从map中获取ResponseFuture，然后将ResponseFuture中的回调方法封装成任务放入到线程池中执行。然后执行 特定的回调方法。CompletableFuture有点需要注意的是，在不同的业务中需创建各自的线程池，否则都是共用ForkJoinPool。 写下对异步的理解，如果同步一个请求线程需要等待处理结果完，才可以处理其他请求，这样的话会导致如果请求多，创建很多线程 但是这些线程大部分都是等待处理结果，如果有后续的请求，没有其他线程及时处理会导致延迟（等待线程时间+处理时间）， 会出现机器的cpu、磁盘、内存都不高（因为等待的线程是不占CPU的）很多请求超时之类的情况。异步的话，就是让线程调用处理接口就直接返回 不用等待处理结果，后续的处理结果可以用回调的形式来处理。如果对那些不需要实时拿到结果的业务就很适合，可以提高整个系统的吞吐率

对于思考题: 1、应该可以通过编程式事物来保证数据的完整性。如何将错误结果返回给客户端，感觉这边和老师上次答疑网关如何接收服务端秒杀结果有点类似，通过方法回调，在回调方法中保存下转账成功或失败 2、在异步实现中，回调方法 OnComplete()在执行OnAllDone()回调方法的那个线程，可以通过一个异步线程池去控制回调方法的线程数，如Spring中的async就是通过结合线程池来实现异步调用 看了两遍才稍微有点思路，老师有空看看

我有一个困惑，客户端发起一个请求转账服务，此时转账服务会启动一个线程A处理该请求，然后转账再使用线程池异步调用账户服务。但是线程A还是存在，并等待处理结果的。我的问题来了，如果有10万个转账请求，转账服务还是最少开启10万个线程A的吧？

老师你好，CompletableFuture这种回调底层还是forkjoin框架，forkjoin对于io这种操作还是会阻塞线程，而且CompletableFuture默认线程数是与cpu核数一样的。在现在容器化的场景下，Cpu核数都不会很多（一般都是个位数），那么使用CompletableFuture是执行io操作是不是会更早的无响应？因为个位数的线程很快就都被阻塞了。

老师，你用CompletableFuture这种方式跟我自己用一个固定大小的线程池去submit, 然后返回Future再get有什么本质的区别吗？吞吐量上呢？