1 服务端执行，最简单的同步调用方式： 缺陷： 服务端响应之前，IO会阻塞在： java.net.SocketInputStream#socketRead0 的native方法上：2 JDK NIO & Future java 1.5之后 优点：主线程可以不用等待IO响应，可以去做点其他的，比如说再发送一个IO请求，可以等到一起返回; 缺点：主线程在等待结果返回过程中依然需要等待，没有根本解决此问题;3 使用Callback回调方式 优点：主线程完成发送请求后，再也不用关心这个逻辑，去执行其他的逻辑；整个过程中已经没有线程阻塞；如 使用nio的EventLoopGroup中的线程执行完所有逻辑； 缺点：回调地狱；Callback hell ；代码可读性低、编写费劲、容易出错4 JDK 1.8 CompletableFuture 优点：解决Callback Hell的问题，JDK 1.8中提供了CompletableFuture；每一个IO操作，均可以封装为独立的CompletableFuture，从而避免回调地狱。 实现：将逆Callback逻辑，封装成一个独立的CompletableFuture，当异步线程回调时，调用 future.complete(T) ，将结果封装；thenCompose衔接，whenComplete输出； 小结：这样一来，就完美解决回调地狱问题，在主的逻辑中，看起来像是在同步的进行编码。5 源码举例 测试+结果
import java.util.concurrent.CompletableFuture; public class CompletableFutureTest { private static CompletableFuture<String> invokeAFuture(String rawASource){ CompletableFuture<String> future = new CompletableFuture<>(); System.out.println("pre-do-invokeA"); try { Thread.sleep(1000); future.complete("invokeA "+rawASource+" result = skip"); }catch (Exception e){ } return future; } private static CompletableFuture<String> invokeBFuture(String rawAResult){ CompletableFuture<String> future = new CompletableFuture<>(); System.out.println("pre-do-invokeB"); try { Thread.sleep(1000); future.complete("after A done result = "+rawAResult+", then invokeB result = success"); }catch (Exception e){ } return future; } public static void main(String[] args) { invokeAFuture("加油").thenCompose(aResult-> invokeBFuture(aResult)).whenComplete((resultB, throwable) ->{ if(throwable != null){ throwable.printStackTrace(); return; } System.out.println(resultB); }); } public static void main(String[] args) { invokeAFuture("加油").thenCompose(CompletableFutureTest::invokeBFuture).whenComplete((resultB, throwable) ->{ if(throwable != null){ throwable.printStackTrace(); return; } System.out.println(resultB); }); }} pre-do-invokeApre-do-invokeBafter A done result = invokeA 加油 result = skip, then invokeB result = success
6 小结： 1 尝试使用异步编程方式； 2 剖析内部实现原理； 3 java9 juc 包有了更抽象的flow处理方式；Java 异步编程最佳实践什么是异步？为什么要用它？
异步编程提供了一个非阻塞的，事件驱动的编程模型。 这种编程模型利用系统中多核执行任务来提供并行，因此提供了应用的吞吐率。此处吞吐率是指在单位时间内所做任务的数量。 在这种编程方式下， 一个工作单元将独立于主应用线程而执行， 并且会将它的状态通知调用线程：成功，处理中或者失败。
我们需要异步来消除阻塞模型。其实异步编程模型可以使用同样的线程来处理多个请求， 这些请求不会阻塞这个线程。想象一个应用正在使用的线程正在执行任务， 然后等待任务完成才进行下一步。 log框架就是一个很好的例子：典型地你想将异常和错误日志记录到一个目标中， 比如文件，数据库或者其它类似地方。你不会让你的程序等待日志写完才执行，否则程序的响应就会受到影响。 相反，如果对log框架的调用是异步地，应用就可以并发执行其它任务而无需等待。这是一个非阻塞执行的例子。
为了在Java中实现异步，你需要使用Future 和 FutureTask, 它们位于java.util.concurrent包下. Future是一个接口而FutureTask是它的一个实现类。实际上，如果在你的代码中使用Future, 你的异步任务会立即执行， 并且调用线程可以得到结果promise。
该做和不该做的
为了方便测试，你应该在代码中将功能从多线程中隔离出来。当在Java中编写异步代码时，你应该遵循异步模型，这样调用线程就不会被阻塞。
注意构造函数不能是异步的，你不应该在构造函数中调用异步方法。当任务互相不依赖时异步方式尤其有用。当调用任务依赖被调用任务时不应该使用异步(译者按：这对异步来说无意义，因为业务上调用线程被阻塞了).
你应该在异步方法中处理异常. 你不应该为长时间的task实现异常. 一个长时间运行的任务，如果异步执行的话, 可能会比同步执行耗费更长的时间， 因为运行时要为异步执行的方法执行线程上下文的切换， 线程状态的存储等. 你也应该注意同步的异常和异步的异常有所不同。
同步异常暗示 每次程序执行到那个程序特殊状态时就会抛出异常；异步异常的跟踪则困难的多。
所以同步和异步异常暗示同步或异步代码可能抛出异常
synchronous and asynchronous exceptions imply synchronous or asynchronous code in your program that might raise exceptions.
以上为个人经验，希望能给大家一个参考，也希望大家多多支持。
而在于当时的那份心情。可是旅行的彼时那刻我的心情一直是好的吗？
