异步编程的最高境界，就是根本不用关心它是不是异步

.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是如何优雅的，最自然的语法，天才的想法。思路大致是这样：

1. 假设先做个很重的API，为了异步，那就立刻返回一个AsyncResult<真实返回类型>，就是不是立刻得到结果的那种，同时在单独的线程池里执行本来的动作。 一般的编程模式是，让用户通过回调来处理结果：

string someFunction() {AsyncResult<真实返回值类型> asyncResult = someApi(...);asyncResult.onComplete( 真实结果 -> {...对结果的处理...} );return something;
}

1. 就在这时，有哪位聪明人，觉得可以让编译器作者事儿，只要代码里加个标记就行了，这就是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()
...

就这么想着想着改巴改巴就成了。

更具体的，就随手转帖一个有关.NET async/await的实现背后 « 司维的思维。

async/await多美啊，实在符合自然思维，看到await，就明白后面的代码会等会儿再执行，暂时可以回家吃饭去了。

但是，也有缺点，await只能取得一个结果，然后就不搞了。 这对于陆陆续续出若干个结果的API，就没什么作用，难道把一个流作为返回值，那最终，还是需要RxJava那种针对流处理的Publisher/Subscriber+Callback的方式。 这就是yield的登场了，它没有async/await直观好懂，就不多说了。

顺便转个 JavaScript async/await 函数的含义和用法 - 阮一峰的网络日志，里面也有提到yield，看看就知道了。

真想不到以前弱弱的Java和JavaScript成长到现在这么强大，真真是凝聚着无数高手们的心血，硬是挤得.NET直哆嗦（即使.NET在实现上依然优于Java，但是事儿不是那么单纯的）。真是白让我以前那么喜欢.NET。