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
方式使用更頻繁。