更新
我问了一个错误的问题，改写了（基于答案和评论的重要信息）：
.net的异步操作是否是真正的异步，有没有任何好的来源，因此IOCP或异步（重叠）？有没有快速的方法来确定几个类是否正在这样做？
Example of not trusting framework developers blindly
创建FileStream的自然起点是静态File.Open（）方法，该文档没有提及所创建的FileStream的同步性！它也不允许您提供FileOptions（用于指定魔术FileOptions.Asynchronous标志）。
相反，FileStream是使用FileOptions.None创建的。任何异步操作都是由Stream基类的强制实现悄然伪造的，它只是将相应的同步方法包装在委托中，并使用BeginInvoke（）方法在线程池上调用它。
这偏离了通常的“成功之坑”设计理念，即.NET中的所有内容似乎都按照您的想法运行，无需仔细阅读文档和/或逐渐发现模糊的捕获和陷阱时间。
我一直在尝试在.NET中找到有关使用 IO完成端口的信息。
有没有什么好方法可以知道给定的.NET类是否正在使用 IO完成端口？ （每次使用新课时都不必运行一些测试。
我为某些类和方法尝试了msdn文档，但我找不到任何内容。
更好的是，如果有一些列表使用IOCP列出了类。
答案 0 :(得分：19)
I / O完成端口是一个强大的平台实现细节，.NET不能盲目依赖可用。它没有，它让CLR主机实现了对操作系统支持的粘合剂。底层托管接口是IHostIoCompletionManager，自.NET 2.0起可用
因此，如果您想要确保实际使用它们，那么您需要获取您使用的CLR主机的来源。这很难得到，有很多，您需要申请Microsoft的工作才能访问源代码。源代码中只有SSCLI20主机可用，它已过时且仅涵盖默认主机。这本身已经过调整，允许PAL提供I / O完成端口，实际上并不存在于您运行的真实CLR主机中。
您没有具体考虑您考虑的平台。一些猜测：
强调这些仅仅是受到证据支持的有根据的猜测。这个问题非常奇怪，如果你发现异步I / O是由重叠的I / O完成的，那就不像你有另一种选择。
答案 1 :(得分：18)
通常，如果使用Windows内核支持的异步IO实现BCL，则它们仅提供异步API。暴露不使用异步内核IO的异步方法将是众所周知的异步同步反模式，BCL设计人员肯定知道这种反模式。这不仅没用，而且对性能和误导性有害。他们不这样做。
Windows可以使用IOCP或使用常规重叠IO执行异步IO。两者都是高效的，异步的，因此比阻塞IO更具可扩展性。
所有这些对您来说都是透明的。依赖async是真正的异步，同步是真正的同步。
如果有疑问，请使用Reflector窥视引擎盖。每当我这样做，我都发现了我刚才所说的。我还没有看到一个偏离的案例。
您在Reflector中看到的是BCL正在调用相关Win32 API的异步版本。作为一个例子，我将检查文件和套接字：
FileStream.BeginRead通过指向Win32Native.ReadFileNative结构的指针间接调用NativeOverlapped。通过调用Overlapped.Pack获得指针。完成回调以这种方式存储。无法跟踪如何使用Reflector调用回调，因为该部分存在于CLR的本机部分中。我无法判断IOCP是否正在使用中，但我可以判断正在使用异步IO。Socket.BeginRead间接致电WSARecv。代码非常复杂。 BCL似乎能够使用重叠IO以及IOCP，具体取决于操作系统。检查在Socket.InitializeSockets进行。决定使用哪种IO存储在Socket.UseOverlappedIO中。如果该变量为false，则最终调用Socket.BindToCompletionPort。因此对于套接字而言，它显然是现代操作系统上的IOCP。对于我无法分辨的文件。
我个人对使用什么样的异步IO并不特别感兴趣，只要它是非阻塞的。情况就是这样。