本文共 3128 字，大约阅读时间需要 10 分钟。

    non-blocking IO vs async IO and implementation in Java You understand the terms correctly. As noted, "non-blocking async IO" would be redundant. If the underlying I/O mechanism is non-blocking, it doesn't need to be async, and vice-versa. Maybe whoever described it that way means it's non-blocking because it's been made async. (Example: the android-async-http library is an async wrapper around synchronous socket I/O.)  ====================================================== Async I/O is generally async because the I/O mechanism is blocking. In this context, asynchronous simply means it's done in another thread. ====================================================== If the I/O is non-blocking outside the API, it's because it's been made asynchronous on some level inside the API. That's why it's redundant to say "non-blocking async I/O." Non-blocking and async imply each other. ======================================================  synchronous blocking synchronous non-blocking asynchronous Both synchronous non-blocking and asynchronous would be considered non-blocking as the calling thread is not waiting on the IO to complete. So while non-blocking asynchronous io might be redundant, they are not one in the same. When I open a file I can open it in non-blocking mode. What does this mean? It means when I issue a read() it won't block. It will either return me the bytes that are available or indicate that there are no bytes available. If I didn't enable non-blocking io the read() would block until data was available. I might want to enable non-blocking io if I want a thread to handle multiple io requests. For instance, I could use select() to find out what file descriptors, or maybe sockets, have data available to read. I then do synchronous reads on those file descriptors. None of those reads should block because I already know data is available, plus I have opened the file descriptors in non-blocking mode. =========================================================== Asynchronous io is where you issue an io request. That request is queued, and thus doesn't block the issuing thread. You are notified when either the request failed or has completed successfully. =========================================================== AIO与NIO的区别，在Client端体现为用户线程得到通知的时间点 在NIO中，当发生相应读写事件时，用户线程得到通知，表明数据已就绪，开始同步调用非阻塞读写函数 在AIO中，当发生相应事件时，用户线程得到通知，表明I/O操作已经由操作系统异步完成，用户线程只需事先向内核申明I/O缓冲区、注册handler并定义回调的completed方法即可 AIO与NIO的区别，在Server端体现为Reactor/Proactor的区别，在NIO中，监控的事件通常为数据的到达；在AIO中，监控的是事件通常为I/O的完成 ============================================================ 综上： 1、分类 所谓的blocking、non-blocking、asynchronous I/O，是针对用户程序而言的，用户程序根据场景选择使用对应的I/O API。 等待数据就绪（操作） 读写数据(操作完成)  blocking模式   阻塞   阻塞 non-blocking模式   只阻塞select线程 数据已就绪，同步读取，无需阻塞等待  asynchronous模式    发起操作(connect,read/write,bind等)     处理操作完成的通知，或通过Future<?>获取结果 2、non-blocking与async 2.1 两者相互协作。non-blocking模式下，多路复用调用select的线程是阻塞的，读写数据的线程是同步操作的，读写数据的线程与select线程之间，可看做异步的，select线程只捕捉事件并通知读写线程； 2.2 而asynchronous模式下，对于用户线程确实是无阻塞并且完全异步处理的，用户线程只需要发起操作，在需要关心的时候获取操作结果，或者操作有结果后通过 已注册的回调对象去处理。但是Future<?>.get() 是同步的调用，如果在发起操作的线程里调用，跟blocking模式效果几乎一样。因此asynchronous模式的handler 方式使用更频繁。

转载地址：http://nphii.baihongyu.com/