一、在没有线程池的前提下使用APM
APM可以让线程池在异步操作完成时调用指定的回调方法。它使用很少的资源，并提供了出色的性能，然而，APM 还允许通过另外三种方式发现异步操作在何时完成。
首先，如果一个线程在操作完成之前调用 EndXXX 方法，并传递 IAsyncResult 对象，调用线程会阻塞并等待操作完成。EndXXX 返回的结果会将线程唤醒。其次可以查询 IAsyncResult 的AsyncwaitHandle属性，从而得到一个WaitHandle，再在这个 WaitHandle 上调用 WaitOne，从而是一个线程阻塞等待操作完成。但是这两种操作都应该避免，因为它们会阻塞线程，可能造成线程池分类另一个线程。
第三、一个线程可以再一个循环中连续的查询 IAsyncResult 的IsCompleted 属性，从而发现操作何时完成。但轮询会浪费 CPU 时间。
二、不能取消异步 I/O 限制操作
目前没有办法取消一个正在进行的异步 I/O 限制操作。当然对于我们来说是想要这样一个功能的，但实现起来却是非常难，目前还没有看到相关例子。毕竟，如果从服务器器请求1000字节，然后又决定不再需要这些数据，其实没办法告诉服务器忘掉你的请求。在这种情况下，只能让字节照常返回，再将他们丢弃。此外，这里还存在一个竞态条件，你的取消指令可能是正在读取最后一个字节到达的。
三、内存消耗
任何时候调用 begin 异步方法，它都构造实现了IAsyncResult接口的一个实例。这意味着针对想要执行的每个异步操作，都会创建一个对象。这回增加一些开销，并在堆中创建较多的对象，导致发生更多的垃圾回收。最终的结果就是应用程序的性能变差了。因此，如果知道自己的 I/O 操作执行非常快，那么以同步方式可能更合理。
四、关于FileStream 特有的问题
创建一个 FileStream 对象时，可通过FileOptions.Asynchronous 标志指定以同步还是异步方式进行通信。这等价于调用 Win32 CreateFile 函数，并向他传递 FILE_FLAG_OVERLAPPED 标志。如果不指定这个标志。Windows 一同步方式执行所有的文件操作。当然，你仍可以使用BeginRead方法异步读取。对于应用程序来说，操作表面是异步的，但 FileStream类在内部是用另一个线程模拟异步行为。这个额外的线程纯属浪费，而且会影响到性能。
另外一个方面，可以创建 FileStream 对象时指定FileOptions.Asynchronous 标志，然后，可以调用 FileStream 的 Read 方法执行一个同步操作。在内部，FileStream 类会开始一个异步操作，然后立即调用线程进行休眠状态，知道操作完成才会被唤醒，从而来模拟同步行为。效率更加地下。但对于上面一种方式，它的效率还稍微高一点的。