同步/异步机制异步就要异步到底这说法正确吗？

摘要

同步与异步是IO操作与CPU指令协作方式的不同

同步sync

1.阻塞blocking：同一条线程独自完成IO操作和CPU指令操作，全程阻塞

2.非阻塞non-blocking：系统内核封装了检查IO的执行线程，等资源加载完后通知应用程序线程进行操作处理，虽然不用等待资源下载，但本质上还是阻塞，只是阻塞的位置变了。

ps：无论是阻塞还是非阻塞，io读写和cpu执行指令是耦合的，系统内核拷贝数据到程序进程的过程还是阻塞的，这样做可以保证执行顺序，所以在阻塞的情况下CPU满载不一定是CPU的锅，很大可能在于IO

异步async

解耦了IO操作和CPU执行指令，IO操作和CPU执行指令都暴露出去，让程序控制， cpu不去参与IO的事情，IO处理完回调给应用程序便可，数据交互无需拷贝一份到程序进程，通过内存映射的方式避免了CPU的参与，但这样做执行顺序无法控制！
就因为IO CPU各做各的事情，二者都能充分利用起来，异步系统下很清晰的可以看到并发的瓶颈是在IO还是在CPU，可以及时做出相应决策。

.net core/.net 异步区别

为什么我们常听说要使用异步就要重头异步到底，不然性能可能更差，这句话其实是针对.NetFramework的。

.net下的异步

在.NetFramework中由于SynchronizationContext的存在，await返回必然会回归主线程

举个例子

public int Test()
{
    return GetAsync()
}
public async Task GetAsync()
{
    return 1;
}

同步下执行Test()方法的是主线程，但在Test()里调用了异步方法GetAsync()，系统就会分派另一条线程去运行，这时候主线程就可以去搞其他任务了，当GetAsync()任务执行完毕时候，系统会通过SynchronizationContext把主线程回调回来，接回Test()继续执行下去，但假设这时候主线程正在处理一个很耗时的任务，那回调就会发生阻塞，直至主线程完事才回调完成，程序才能继续走下去，这个过程是非常影响性能的。

ps：如果你希望 GetAsync() 执行完后不需要等主线程，你就需要配置ConfigureAwait(false)，这样就等于告诉系统，我不需要原来的主线程来干活，随便找个线程给我就行，但这样会丢失了主线程的一些信息（HttpContext/Language/TimeZone）。

public int Test()
{
    return GetAsync().ConfigureAwait(false).GetAwaiter().GetResult();
}

.net core下的异步

在.NetCore中已经剔除了SynchronizationContext，剔除他的主要原因主要是性能和进一步简化操作
在.NetCore中我们不用继续关心异步同步混用情况下，是否哪里没有设置ConfigureAwait(false) 会导致的死锁问题，因为在.netcore中的async/await 可能在任何线程上执行，并且可能并行运行！