最传统的IO模型是在阅读和写作过程中阻止这种现象。当用户线程发出IO请求时，内核会返回检查数据是否准备就绪。如果您还没有准备好，您将等待数据准备就绪，并且用户线程将处于阻止状态。用户线程将交出CPU。准备就绪时，内核将将数据复制到用户线程，并将结果返回到用户线程中，以便用户线程可以释放块状态。典型的阻止IO模型如下：
当用户线程启动读取操作时，它不需要等待，而是立即获得结果。如果结果是错误，则表明数据尚未准备就绪，因此可以再次发送读取操作。内核已经准备就绪，并且再次需要用户线程的请求，然后他立即将数据编写为用户线程并返回。因此，实际上，在非封锁IO模型中，用户线程需要不断询问内核数据是否已经准备就绪，也就是说，非块IO不会交出CPU，但将始终占据CPU。典型的非块IO模型通常如下：
Multi -Way Reuse IO模型当前已使用更多模型。JavaNio实际上是多路重用IO。只有当插座真正具有读取事件时，实际io读取和写入操作才能真正调用。因为在多路重用io模型中，您只需要使用一个线程来管理多个插座。因此，它大大降低了资源的财产。如果没有事件，它将始终在此处阻止，因此此方法将导致用户线程阻止。Multi-Way REUSE IO模式可以通过线程管理多个插座。只有当插座读取和写入事件发生时，资源才能进行实际的读写操作。因此，多路重用IO更适合大量连接
为什么多道路重新使用IO比非块IO更有效？
因为在非屏体IO中，用户线程不断问插座，在多路重用io中，在每个插座状态下执行内核，这比用户线程高得多。
多路重用IO的缺点
多路重用IO模型检查是否有事件是通过旋转到达的，并响应到达的事件。，这将影响新的事件旋转训练
在信号驱动器IO模型中，当用户线程启动IO请求操作时，它将向相应的套接字注册信号功能，然后用户线程将继续执行。当内核数据准备就绪时，您可以在信号函数中调用IO读取和写入操作以执行实际的IO请求操作
异步IO模型是理想的IO模型。在异步IO模型中，当用户线程启动读取操作时，您可以立即开始执行其他操作。另一方面，从内核的角度来看，当它收到异步读取时，它将立即返回，表明该读取读取请求已成功启动，因此不会在用户线程上生成任何块。然后，内核将等待准备数据，然后将数据复制到用户线程。所有这些完成后，内核将向用户线程发送信号，并告诉它已完成读取操作。
换句话说，用户线程无需参与实际的整个IO操作。它只需要启动请求。当内核返回的成功信号表示已完成IO操作并可以直接使用数据时。换句话说，在异步IO模型中，IO操作的两个阶段都不会阻止用户线程。这两个阶段均由内核自动完成，然后发送信号以告知已完成的用户线程。
无需在用户线程中再次调用IO函数以进行特定读取和写作。这与信号驱动程序模型不同。在信号驱动程序模型中，当用户线程接收到数据准备就绪的信号时，则需要用户线程调用IO函数以执行实际读取和写入操作。接收信号表示IO操作已完成，并且无需在用户线程中调用IO函数以进行实际的读取和写作操作。
请注意，异步IO需要由操作系统的底层支持。在Java7中，提供异步IO。