Dan is the founder of Rectangular Software, an independent UK software company that provides development services and builds its own mobile and web applications. Dan has over a decade of experience in the software industry, building a wide variety of systems including casino, poker and spread-betting platforms, mobile applications, e-commerce websites, and network security software. His other programming interests include artificial intelligence, particularly evolutionary computation, and functional programming in Haskell. He has authored, or contributed to, a number of open source Java projects. Dan has posted 34 posts at DZone. You can read more from them at their website. View Full User Profile

Avoid NIO, Get Better Throughput

  • submit to reddit

The Java NIO (new/non-blocking I/O) API introduced in Java 1.4 is arguably the most arcane part of the standard library.  With channels, selectors, byte buffers and all the associated flipping, marking, compacting, event-handling and registering/de-registering of read/write interest, it’s an entirely different level of complexity to the old-fashioned, straightforward blocking I/O.  And if you want to use SSL with NIO then it’s a whole new world of pain.

Few have mastered NIO.  For most it provides an opportunity to really get to know your debugger.  “Should this buffer be flipped before I pass it to this method, or should the method flip it?”.  BufferOverflowExceptions and memory leaks abound.

So, in the spirit of doing the simplest thing that could possibly work, writing your own NIO code is usually best avoided unless you have a compelling reason.  Fortunately, some masochistic individuals have done a lot of the hard work so that we don’t have to.  Projects such as Grizzly and QuickServer provide proven, reusable non-blocking server components.

However, in most instances, maybe non-blocking I/O is not necessary at all? In fact, maybe it is detrimental to performance?

That’s the point that Paul Tyma makes.  He attacks some of the received wisdom about the relative merits of blocking and non-blocking servers in Java.  The characteristics of JVMs and threading libraries change as new advances are made.  Good advice often becomes bad advice over time, demonstrating the importance of making your own measurements rather than falling back on superstitions.

Paul’s experiments show that higher throughput is achieved with blocking I/O, that thread-per-socket designs actually scale well, and that the costs of context-switching and synchronisation aren’t always significant.  Paul’s slides form his talk “Thousands of Threads and Blocking I/O: The Old Way to Write Java Servers Is New Again (and Way Better)” are well worth a look.

If you are writing your own multi-threaded servers in Java, Esmond Pitt’s Fundamental Java Networking and Java Concurrency in Practice by Brian Goetz et al. are essential reading.

Originally posted on New Adventures in Software

Published at DZone with permission of its author, Dan Dyer.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Horia Muntean replied on Thu, 2008/09/04 - 4:44am


Don't be so eager to dismiss the advantages of a NIO server. When using blocking sockets if the clients are slow or have intermitent connections you can end up really quickly in a thread starvation situation.

Just try to close a blocking socket opened on a 'dead' tcp/ip connection. The calling thread can wait for hours before returning the control back.



Jordan Zimmerman replied on Thu, 2008/09/04 - 1:16pm

I saw Tyma's talk and it was excellent. To summarize, trying to write an NIO app you end up duplicating what the kernel's thread scheduler does. More than likely (!) you won't be able to beat it on performance and scalability. Besides, the NIP socket channel APIs are terrible and difficult to use.

Milind Rao replied on Mon, 2008/09/08 - 9:44am

How about NIO memory mapped files?

Zombi G replied on Fri, 2008/09/12 - 7:00pm

Blocking IO is simpler, but simply doesn't scale. And no matter, how advanced the scheduler in your OS, I bet, it can better schedule 10 threads, instead of 1000. Once I've to rewrote a server from B-IO, to NB-IO, and after it can served twice as much connection concurrently (the actual byte/sec througput is increased to 3times than before)

Jordan Zimmerman replied on Sat, 2008/09/13 - 2:13am

Everyone's mileage will vary, but Tyma's point was the blocking I/O scales very well to 1000s of threads. In particular, he proved that the NIO library is 30% slower even when used for _blocking_ sockets. It's apparently poorly implemented internally.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.