使用java.io包的Java Reactor模式

Question

I see in several application source like Minecraft and JIrcs they both use java.io to implement Reactor Plugin (if I'm not wrong) and also in this article . So, what is the difference between java.io and java.nio when implementing Reactor Pattern? I mean, like performance advantage, process efficiency etc and where i can get good tutorial if you think java.io is the good solution to implement Reactor Pattern (since google give me tons of java.nio tuts not java.io as i want)

Answer 1

It isn't really true that NIO is faster. Paul Tyma demolished that myth sometime back.

http://mailinator.blogspot.in/2008/02/kill-myth-please-nio-is-not-faster-than.html

http://paultyma.blogspot.in/2008/03/writing-java-multithreaded-servers.html

Hope that help.

Answer 2

I hope you can get a conclusion with the below information taken from the book at page no.42

java.io.* classes use the decorator design pattern . The decorator design pattern attaches responsibilities to objects at runtime. Decorators are more flexible than inheritance because the inheritance attaches responsibility to classes at compile time . The java.io.* classes use the decorator pattern to construct different combinations of behaviour at runtime based on some basic classes.

and 43.

Java has no long been suited for developing programs that perform a lot of I/O operations. Furthermore, commonly needed tasks such as file locking, non-blocking and asynchronous I/O operations and ability to map file to memory were not available. Non-blocking I/O operations were achieved through work around such as multithreading or using JNI. The New I/O API (aka NIO ) in J2SE 1/4 has changed this situation. A server's availability to handle several client requests effectively depends on how it uses I/O streams. When a server has to handle hundreds of clients simultaneously, it must be able to use I/O services concurrenty, one way to cater for this scenario in Java is to use threads but having almost one-to-one ratio of threads (100 clients will have 100 threads) is prone to anormous thread overhead and can result in performance and scalability problems due to consumtion of memory stacks (ie each thread has its stack, Refer Q34 , Q42 in Java section) and CPU context switching (ie switching between threads as opposed to doing real computation.). To overcome this problem, a new set of non-blocking I/O classes have been introduced to the Java platform in java.nio package. The non-blocking I/O mechanism is built around Selectors and channels. Channels , Buffers and Selectors are the core of the NIO.

and read more . Here are some reference links which provide Java IO vs Java NIO : Java IO Faster Than NIO – Old is New Again! , Java IO vs Java NIO and IO vs. NIO – Interruptions, Timeouts and Buffers .

Answer 3

It is important to understand the differences between blocking and non-blocking I/O. The java.io package does NOT support non-blocking I/O so it won't scale for a large number of connections. Moreover, with blocking I/O you can only resort to the terrible one-client-to-one-thread model which is completely unsuitable for low-latency systems. I suggest you take a look on this article written by me about an asynchronous network I/O library that implements the reactor pattern, so you can understand how non-blocking plays a key role in high-performance systems.