在写测试用例时，顺手做了一个TASK模型的压力测试。发现TASK模型的性能极其低下！
数据处理逻辑：
1：主程序不停发送数据修改命令
2：数据管理器，接收命令，缓存命令。
3：后台线程分批次处理，一次处理一批命令，按照命令内容读写数据，修改文件。
4：完成后， 调用Task.Start函数，让等候该批次任务的命令执行后续操作。
5：完成后续操作，完成处理流程。
问题：
在使用接口避开Socket操作后，只剩下对文件系统的操作时，系统的效率极其低下。CPU使用率不超过1%，磁盘使用率不超过1%（最大0.9M/S）。硬件性能完全没有发挥出来！
进一步分下，发现主要是命令排队存在问题：
大量的操作是一个命令执行一次，仅少数几次，会有多个命令同时执行。并没有在缓冲区缓存大量数据，让文件操作效率更高。
原因分析：
从等待任务的各种迹象看，导致缓冲逻辑失效的根本原因是 TASK的等待操作。Task.ContinueWith函数，会导致任务等待，这种等待不是线程阻塞，但当任务队列达到配置的最大值后，系统会阻塞新建Task。阻止新建任务，可以从源头上降低系统吞吐能力，保证系统稳定性。
哎~。微软的技术都是看起来好，较真起来就没用了！