多线程技术 本身是为了 提高 cpu利用率 提高效率而生
因为 cpu分片机制 导致 多线程存在顺序与业务不符合情况
为了满足 正确的执行业务顺序 而诞生第一个要点线程同步 无论是控制主线程的同步等待 thread join task result task wait() 还是线程之间对于共享资源 同步的多种方式
由于线程资源是比较可贵的 性能也跟线程的创建使用 密切相关 光确保使用正确是不足够的 必须要考虑 使用多个线程情况下 资源的问题，于是诞生了第二个要点 线程池虽然thread类已经异步操作 但是 毕竟在数量上要做到优化 就必须要用一个集中管理的方式，也就是 池子的表现形式，所以 线程池在于合理的管理分配 线程池中的线程 把控线程数量，因为是要高效合理 所以 线程池的线程都为了解决快速响应的操作 全部都是后台线程
以上俩点 有明显的弊端就是 都是异步操作 需要获取 异步处理结果 来进行后续业务处理
一般的解决方案是采用 队列的方式 解耦来异步处理结果
那么遇到需要 及时获取 线程处理的结果以后面业务流程使用 就显得特别复杂
所以 Task 来了 以任务的表现形式 对线程池进行了封装 使得获取结果 更加方便 对于线程之间交互 更高效
提供的 API 丰富 使得代码在 异步处理函数这一方面得到了改善
但是还有一个弊端是业务顺序的把控，虽然线程同步 在共享资源 或者是 主线程的控制上有一个顺序的把控，但是 在复杂业务场景 多个子线程的业务执行顺序之间 也是需要把控的，如果还是通过task的 API 去控制 通过 continuewith 或者 whenany whenall的写法，实现是没有问题 但是可读性是 大打折扣
于是 async await 来了，为了更客观了解子线程在复杂场景中执行顺序，对task 进行辅助 在await 用法上 替代之前线程交互的等待，更直观知道了 每一步等待后的下一步
这就是C#5.0之后对于多线程的使用，也就是为什么async task await作为主流使用
当然如果是简单业务的使用 并不一定需要使用这种，简单的thread 或者 使用 线程池 配合 队列处理 也是完全可以的