@Async、CompletableFuture、异步非阻塞、响应式编程

@Async

spring提供的，使用时是通过线程执行的，spring会提供默认的线程池(同样底层是ThreadPool)，我们也可以自定义线程池代替默认的是执行。

虽然名字是异步，但执行后的结果是Future或void或Asyncresult，需要自己手动获取结果，并不能主动监听，执行完成后做一些处理。所以我认为只能算非堵塞的一种方式，不能算响应式异步。

简单用法

https://www.jianshu.com/p/10b8776166a4

https://blog.csdn.net/qq_22076345/article/details/82194482

https://blog.csdn.net/u011663149/article/details/88561868

CompletableFuture

原先的Future虽然可以通过Callable得到线程的执行结果，比如主线程开一条子线程工作，过一会主线程去拿结果，但主线程还是要调用get方法，只要调用get，其实就会阻塞，主线程在拿到子线程结果前一直被堵塞。 如果想结合两个子线程结果，也得自己去设计

而CompletableFuture实现了非堵塞、异步、响应式编程。当子线程运行结束后可以直接对结果进行处理，提供了丰富的api，把这些场景都设计好了。子线程是否有返回值、是否异步用其他线程还是用本线程、是否用指定线程池。

但和Future相同的是，只要是主线程去拿子线程的结果，在子线程执行完前，主线程还是要堵塞的，除非设置堵塞时间。

转载两篇入门:

https://www.cnblogs.com/happyliu/p/9462703.html

https://www.cnblogs.com/dennyzhangdd/p/7010972.html.

转载api，易于理解的各场景简单实例：

https://www.jianshu.com/p/6bac52527ca4

CompletableFuture必须由线程池去执行，不指定线程池也有默认的线程池。如果里面只是执行简单的逻辑，就增加了上下文切换，还得主线程切换到CompletableFuture线程中，我认为不值得。

我认为最合适的情况是，CompletableFuture中执行的逻辑和主线程后续逻辑无关，web开发让主线程可以继续接口逻辑直到返回接口内容，同时CompletableFuture中io堵塞严重，值得这次上下文切换。或者有多个线程结合结果用CompletableFuture。

如果CompletableFuture中没有io堵塞，但也想要CompletableFuture.thenApply之类的后续处理，不如主线程完成逻辑，然后单开子线程完成后续处理，也不影响接口的响应时间。

异步非阻塞

转载响应式编程https://blog.csdn.net/get_set/article/details/79466402说明异步、同步、阻塞、非阻塞的概念

从调用者和服务提供者的角度来看，阻塞、非阻塞以及同步、异步可以这么理解：

阻塞和非阻塞反映的是调用者的状态，当调用者调用了服务提供者的方法后，如果一直在等待结果返回，否则无法执行后续的操作，那就是阻塞状态；如果调用之后直接返回，从而可以继续执行后续的操作，那可以理解为非阻塞的。
同步和异步反映的是服务提供者的能力，当调用者调用了服务提供者的方法后，如果服务提供者能够立马返回，并在处理完成后通过某种方式通知到调用者，那可以理解为异步的；否则，如果只是在处理完成后才返回，或者需要调用者再去主动查询处理是否完成，就可以理解为是同步的。
举个例子，老刘买了个洗衣机，当他启动了洗衣机后如果一直在等待洗衣机工作结束好晾衣服，那他就是阻塞的；如果他启动洗衣机之后就去看电视了，估摸快洗完了就时不时来看看，那他就是非阻塞的，因为老刘可以去做另一件事。但老刘不能知道这洗衣机啥时候洗完/是否洗完，那么这台洗衣机就是同步方式工作的；老刘后来换了一台可以在洗完衣服播放音乐的洗衣机，这样就不用时不时来看了，虽然启动之后洗衣机不能立刻返回给老刘干净的衣服，但是可以在工作完成之后通知在看电视的老刘，所以新的洗衣机就是异步工作的。

响应式编程

https://blog.csdn.net/get_set/article/details/79466657讲的真好