本文只讨论OverLapped I/O的三种异步模型及完成端口，像select、SWASelect不作讨论，讨论顺序从劣到优，方便于循序渐进地对比，更容易区分各模型之间的差别。
1. OverLapped I/O 设备内核对象模型，这种模型虽然采用异步，但为了知道对象是否触发，需要一直挂起线程，换个角度来说，与同步的差异不大。
2. OverLapped I/O 事件内核对象模型，这模型比较前一种就先进多了，它可以同时等待多个事件，但是waitForMultipleObject最多只能等待64个事件，也就是说如果server有6400个连接的话，就需要100个线程。我们知道线程之间上下文切换是很耗CPU的。这样在多连接多并发的情况下还是达不到我们期望的高性能。
3. OverLapled I/O 完成例程模型，这模型较之前又有很大的改进。少了单线程最多只能处理64个事件的限制，但它在高性能方面还是存在一个问题，就是它是那个线程请求就那个线程处理，这样会存在个别CPU核空闲着，而个别CPU核又很吃紧的情况。简而言之，少了负载均衡。
4. 完成端口。完成端口是几种模型中最先进的，它预先申请好线程，一般有多少个核就申请多少个线程，这样可以避免线程间切换而浪费CPU无谓的开销。当有请求到来，完成端口会均衡地分配到每个线程中去，从而达到CPU各核之间的负载均衡。
考虑到单文字描述还不够直观对比，下面再给一个简化后对比的表：
|
模型 |
与前一种对比优点 |
缺点 |
|
设备内核对象模型 |
--- |
与同步的差异不大 |
|
事件内核对象模型 |
可以同时等待多个事件 |
每个线程最多只能等待64个事件，多线程下增加了CPU上下文切换的开销 |
|
完成例程模型 |
少了单线程最多只能处理64个事件的限制，减少多线程上下文切换的开销 |
没有CPU的负载均衡 |
|
完成端口 |
使用CPU负载均衡，充分利用CPU各核 |
--- |