event and data-driven apps
selector(The Selector class plays the role of a Reactor in the Reactor pattern scenario.) reactor proactor
http://www.kegel.com/c10k.html
引用
level-triggered & edge-triggered 中断：
http://stackoverflow.com/questions/1966863/level-vs-edge-trigger-network-event-mechanisms
http://venkateshabbarapu.blogspot.com/2013/03/edge-triggered-vs-level-triggered.html
level：在某个持续的状态下，会一直被触发
edge：事件发生的时候被触发，且处理事件期间不会被重复触发
completion notification VS readiness notification(notification 即 event notification):
http://stackoverflow.com/questions/1966863/level-vs-edge-trigger-network-event-mechanisms
http://venkateshabbarapu.blogspot.com/2013/03/edge-triggered-vs-level-triggered.html
level：在某个持续的状态下，会一直被触发
edge：事件发生的时候被触发，且处理事件期间不会被重复触发
completion notification VS readiness notification(notification 即 event notification):
https://chamibuddhika.wordpress.com/2012/08/11/io-demystified/
引用
The socket/file descriptors are abstracted
using Channels and Selector encapsulates the selection system call.
using Channels and Selector encapsulates the selection system call.
Scalable Event Multiplexing: epoll vs. kqueue:
http://www.eecs.berkeley.edu/~sangjin/2012/12/21/epoll-vs-kqueue.html
non-blocking and asynchronous io 之间的区别到底是什么？
https://www.ibm.com/developerworks/community/forums/html/topic?id=77777777-0000-0000-0000-000014882947
http://doc.akka.io/docs/akka/2.3.8/general/terminology.html
http://stackoverflow.com/questions/3867042/one-thread-per-client-doable?lq=1
引用
The JVM for Linux is using one to one thread mapping. This means that every Java thread is mapped to one native OS thread.
So creating a thousand of threads or more is not a good idea because it will impact your performance (context switching, cache flushes / misses, synchronization latency etc). It also doesn't make any sense if you have less than a thousand of CPUs.
The only adequate solution for the serving many clients in parallel is to use asynchronous I/O. Please see this answer on Java NIO for details.
So creating a thousand of threads or more is not a good idea because it will impact your performance (context switching, cache flushes / misses, synchronization latency etc). It also doesn't make any sense if you have less than a thousand of CPUs.
The only adequate solution for the serving many clients in parallel is to use asynchronous I/O. Please see this answer on Java NIO for details.
http://stackoverflow.com/questions/592303/asynchronous-io-in-java
引用
Java's NIO package (as of Java6), provides support for non-blocking I/O only, via Selectors. Java7 is hopefully going to ship with NIO.2, which includes asynchronous I/O support.
Non-blocking IO the kernel calls don't block under buffer-full(on writes) and buffer-empty(on reads), these states result in soft-error returns from the respective APIs.However non-blocking IO still copies data between user-space and kernel-space causing an unwanted extra copying of data which has a significant overhead when a lot of data is involved.The kernel then(may)copy the data yet again into packet size pieces with networking protocol overhead around it.Some network stacks/hardware drivers may support scatter gather to optimize the in kernel stages,but worst case is 3 copies.
Async IO accepts to remove the extra copying action during the data transition between user-space and kernel-space.This allows the kernel to directly access the data from user-space.To achieve this the application prepares memory and posts an IO request to the kernel.Control returns back to the application (the API is much like non-blocking).At some future point in time the kernel may access the user-space memory while performing the IO.Once done the kernel fires a signal like callback into user-space via the completion handler to notify the application of the IO result of request.
From a programming basis, non-blocking io (based usually on select) means that you still have to identify which sockets have incomming data on them. Async IO results in you getting a callback (or event) telling you the results of the IO action. There is also less kernel work to do, in theory asnyc io done in the kernal allows higher throughput and/or lower latency
Non-blocking IO the kernel calls don't block under buffer-full(on writes) and buffer-empty(on reads), these states result in soft-error returns from the respective APIs.However non-blocking IO still copies data between user-space and kernel-space causing an unwanted extra copying of data which has a significant overhead when a lot of data is involved.The kernel then(may)copy the data yet again into packet size pieces with networking protocol overhead around it.Some network stacks/hardware drivers may support scatter gather to optimize the in kernel stages,but worst case is 3 copies.
Async IO accepts to remove the extra copying action during the data transition between user-space and kernel-space.This allows the kernel to directly access the data from user-space.To achieve this the application prepares memory and posts an IO request to the kernel.Control returns back to the application (the API is much like non-blocking).At some future point in time the kernel may access the user-space memory while performing the IO.Once done the kernel fires a signal like callback into user-space via the completion handler to notify the application of the IO result of request.
From a programming basis, non-blocking io (based usually on select) means that you still have to identify which sockets have incomming data on them. Async IO results in you getting a callback (or event) telling you the results of the IO action. There is also less kernel work to do, in theory asnyc io done in the kernal allows higher throughput and/or lower latency
Scalable IO in Java：
http://gee.cs.oswego.edu/dl/cpjslides/nio.pdf
Reactor Pattern Explained - Part 1：（part 2 / 3 等见链接）
http://jeewanthad.blogspot.com/2013/02/reactor-pattern-explained-part-1.html
Reactor和Proactor模式比较
http://liuxun.org/blog/reactor-he-proactor-mo-shi-bi-jiao/
Reactor： http://daimojingdeyu.iteye.com/blog/828696
待整理：何谓 IO？ 及 Synchronous I/O vs Asynchronous I/O（Blocking I/O vs Non-Blocking I/O）：
http://xcybercloud.blogspot.com/2009/06/network-io-blockingnon-blocking-vs.html
http://www.ibm.com/developerworks/library/j-nio2-1/
http://blog.csdn.net/historyasamirror/article/details/5778378
http://www.artima.com/articles/io_design_patterns2.html
http://www.cppblog.com/pansunyou/archive/2012/12/06/139343.html
http://www.developer.com/java/article.php/10922_3837316_3/Non-Blocking-IO-Made-Possible-in-Java.htm
http://stackoverflow.com/questions/5529137/java-non-blocking-and-asynchronous-io-with-nio-nio-2-jsr203-reactor-proact
http://stackoverflow.com/questions/2625493/asynchronous-vs-non-blocking?rq=1
http://www.cnblogs.com/zhuYears/archive/2012/09/28/2690194.html
http://tutorials.jenkov.com/java-nio/buffers.html#flip
http://blog.csdn.net/wuxianglong/article/details/6604817
http://docs.oracle.com/javase/1.4.2/docs/guide/nio/
http://stackoverflow.com/questions/1455117/best-model-for-an-nio-implementation
http://www.daniweb.com/software-development/computer-science/threads/384575/synchronous-vs-asynchronous-blocking-vs-non-blocking
http://stackoverflow.com/questions/8546273/is-non-blocking-i-o-really-faster-than-multi-threaded-blocking-i-o-how
引用
I/O includes multiple kind of operations like
reading and writing data from hard drives, accessing network resources, calling web services or retrieving data from databases. Depending on the platform and on the kind of operation, asynchronous I/O will usually take advantage of any hardware or low level system support for performing the operation. This means that it will be performed with as little impact as possible on the CPU.
At application level, asynchronous I/O prevents threads from having to wait for I/O operations to complete. As soon as an asynchronous I/O operation is started, it releases the thread on which it was launched and a callback is registered. When the operation completes, the callback is queued for execution on the first available thread.
If the I/O operation is executed synchronously, it keeps its running thread doing nothing until the operation completes. The runtime doesn't know when the I/O operation completes, so it will periodically provide some CPU time to the waiting thread, CPU time that could have otherwise be used by other threads that have actual CPU bound operations to perform.
So, as @user1629468 mentioned, asynchronous I/O does not provide better performance but rather better scalability. This is obvious when running in contexts that have a limited number of threads available, like it is the case with web applications. Web application usually use a thread pool from which they assign threads to each request. If requests are blocked on long running I/O operations there is the risk of depleting the web pool and making the web application freeze or slow to respond.
One thing I have noticed is that asynchronous I/O isn't the best option when dealing with very fast I/O operations. In that case the benefit of not keeping a thread busy while waiting for the I/O operation to complete is not very important and the fact that the operation is started on one thread and it is completed on another adds an overhead to the overall execution.
At application level, asynchronous I/O prevents threads from having to wait for I/O operations to complete. As soon as an asynchronous I/O operation is started, it releases the thread on which it was launched and a callback is registered. When the operation completes, the callback is queued for execution on the first available thread.
If the I/O operation is executed synchronously, it keeps its running thread doing nothing until the operation completes. The runtime doesn't know when the I/O operation completes, so it will periodically provide some CPU time to the waiting thread, CPU time that could have otherwise be used by other threads that have actual CPU bound operations to perform.
So, as @user1629468 mentioned, asynchronous I/O does not provide better performance but rather better scalability. This is obvious when running in contexts that have a limited number of threads available, like it is the case with web applications. Web application usually use a thread pool from which they assign threads to each request. If requests are blocked on long running I/O operations there is the risk of depleting the web pool and making the web application freeze or slow to respond.
One thing I have noticed is that asynchronous I/O isn't the best option when dealing with very fast I/O operations. In that case the benefit of not keeping a thread busy while waiting for the I/O operation to complete is not very important and the fact that the operation is started on one thread and it is completed on another adds an overhead to the overall execution.
Java™ I/O, NIO, and NIO.2:
http://docs.oracle.com/javase/7/docs/technotes/guides/io/
IO
New I/O
New I/O APIs:
http://docs.oracle.com/javase/1.4.2/docs/guide/nio/
Asynchronous I/O, or non-blocking I/O, is a form of input/output processing that permits other processing to continue before the transmission has finished.
核心概念： Channel 的 Multiplexed(多路复用)：
A selector is a multiplexor of selectable channels, which in turn are a special type of channel that can be put into non-blocking mode. To perform multiplexed I/O operations, one or more selectable channels are first created, put into non-blocking mode, and registered with a selector. Registering a channel specifies the set of I/O operations that will be tested for readiness by the selector, and returns a selection key that represents the registration.
Selector 的 readiness selection：
引用
readiness selection 是什么？举个例子，以 network programming 为例, readiness selection 指 the ability to choose a socket that will not block when read or written.
http://underpop.online.fr/j/java/java-network-programming/javanp3-CHP-12-SECT-5.html
http://underpop.online.fr/j/java/java-network-programming/javanp3-CHP-12-SECT-5.html
Java NIO vs. IO:
https://blogs.oracle.com/slc/entry/javanio_vs_javaio
http://tutorials.jenkov.com/java-nio/nio-vs-io.html
NIO Performance Improvement compared to traditional IO in Java:
http://stackoverflow.com/questions/7611152/nio-performance-improvement-compared-to-traditional-io-in-java