异步编程的最高境界，就是根本不用关心它是不是异步
.NET的async/await方式最先达到了这个境界。
和async/await写法相比，Java的什么ExecutorService以及回调之类设计都是惭愧无比的。当然，习惯了也没啥，反正那Java的lamda表达式用着也可以接受。
人不知道更好的东西的时候其实也就无所谓难受，更何况现在Java强势，.NET就算有好东西也发不出太大的影响...
不过可以想象，如果Java9支持了这个写法，那么那些RxJava什么的和回调有关系的各种lib都会成为二等公民（对于某数据流式处理还是需要的）。
其实那么多牛人，怎么会想不到这点呢，为啥还不改呢？也许是不想承受抄袭的骂名，而是想改得直接超越.NET的，也许是专利限制，谁知道呢。
想来又不是要改JVM，只是改点编译器罢，支持把await的后的代码自动编程回调函数，再把系统的一些费时间的method给多封装一个返回AsyncResult<SomeReturnType>之类的method，多大的事儿啊，改了吧。
那些getter/setter不支持的事儿就不和你计较了，反正还有个Lombk预编译加上@Gettr/@Setter之类的就可以了。可这个async/await不然，就不容易由第三方用类似的方法实现了。
顺便普及一下async+await是如何优雅的，最自然的语法，天才的想法。思路大致是这样：
- 假设先做个很重的API，为了异步，那就立刻返回一个AsyncResult<真实返回类型>，就是不是立刻得到结果的那种，同时在单独的线程池里执行本来的动作。 一般的编程模式是，让用户通过回调来处理结果：
string someFunction() { AsyncResult <真实返回值类型> asyncResult = someApi(...); asyncResult.onComplete( 真实结果 -> { ...对结果的处理... } ); return something;} - 就在这时，有哪位聪明人，觉得可以让编译器作者事儿，只要代码里加个标记就行了，这就是await的登场了
string someFunction() { 真实返回值类型> result = await someApi(...); ...对结果的处理... return something;} 相当于编译器自动把await语句后面的知道函数末尾的所有语句都编译成了一个临时的Lamda表达式了。 3. 但是这样一来，异步的特性会逐层传染,当前所在的函数someFunction也就立刻返回了，那到底返回成什么好呢，这就是async的登场了。
async string someFunction() { 真实返回值类型> result = await someApi(...); ...对结果的处理... return something;} 这就是告诉编译器，谁要是调用someFunction，他也必须用await罩一下。
string x = await someFunction()...
就这么想着想着改巴改巴就成了。
更具体的，就随手转帖一个。
async/await多美啊，实在符合自然思维，看到await，就明白后面的代码会等会儿再执行，暂时可以回家吃饭去了。
但是，也有缺点，await只能取得一个结果，然后就不搞了。 这对于陆陆续续出若干个结果的API，就没什么作用，难道把一个流作为返回值，那最终，还是需要RxJava那种针对流处理的Publisher/Subscriber+Callback的方式。 这就是yield的登场了，它没有async/await直观好懂，就不多说了。
顺便转个 ，里面也有提到yield，看看就知道了。
真想不到以前弱弱的Java和JavaScript成长到现在这么强大，真真是凝聚着无数高手们的心血，硬是挤得.NET直哆嗦（即使.NET在实现上依然优于Java，但是事儿不是那么单纯的）。真是白让我以前那么喜欢.NET。