NET Core aync await任务模型的劣化问题

在写测试用例时，顺手做了一个TASK模型的压力测试。发现TASK模型的性能极其低下！

数据处理逻辑：

        1：主程序不停发送数据修改命令

        2：数据管理器，接收命令，缓存命令。

        3：后台线程分批次处理，一次处理一批命令，按照命令内容读写数据，修改文件。

        4：完成后， 调用Task.Start函数，让等候该批次任务的命令执行后续操作。

         5：完成后续操作，完成处理流程。

问题：

        在使用接口避开Socket操作后，只剩下对文件系统的操作时，系统的效率极其低下。CPU使用率不超过1%，磁盘使用率不超过1%（最大0.9M/S）。硬件性能完全没有发挥出来！

        进一步分下，发现主要是命令排队存在问题：

          

大量的操作是一个命令执行一次，仅少数几次，会有多个命令同时执行。并没有在缓冲区缓存大量数据，让文件操作效率更高。

原因分析：

       从等待任务的各种迹象看，导致缓冲逻辑失效的根本原因是 TASK的等待操作。Task.ContinueWith函数，会导致任务等待，这种等待不是线程阻塞，但当任务队列达到配置的最大值后，系统会阻塞新建Task。阻止新建任务，可以从源头上降低系统吞吐能力，保证系统稳定性。

    对于该问题的处理办法就是： 避免使用ContinueWith函数，该函数会导致阻塞逻辑产生，和lock语句相同！

    所有ContinueWith函数都已换成 await 关键字。  这种多线程的理解差异，对使用begin-end方式进行异步开发的老人而言，需要不少的时间来理解！