DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports
Events Video Library
Refcards
Trend Reports

Events

View Events Video Library

Related

  • Understanding Zero-Copy
  • Real-Time Market Data Processing: Designing Systems for Low Latency and High Throughput
  • How to Identify Bottlenecks and Increase Copy Activity Throughput in Azure Data Factory
  • Queuing Theory for Software Engineers

Trending

  • Retesting Best Practices for Agile Teams: A Quick Guide to Bug Fix Verification
  • Observability in Spring Boot 4
  • Building an Image Classification Pipeline With Apache Camel and Deep Java Library (DJL)
  • A Deep Dive into Tracing Agentic Workflows (Part 1)

Avoid NIO, Get Better Throughput

By 
Dan Dyer user avatar
Dan Dyer
·
Sep. 03, 08 · Interview
Likes (0)
Comment
Save
Tweet
Share
22.8K Views

Join the DZone community and get the full member experience.

Join For Free

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

Throughput (business)

Opinions expressed by DZone contributors are their own.

Related

  • Understanding Zero-Copy
  • Real-Time Market Data Processing: Designing Systems for Low Latency and High Throughput
  • How to Identify Bottlenecks and Increase Copy Activity Throughput in Azure Data Factory
  • Queuing Theory for Software Engineers

Partner Resources

×

Comments

The likes didn't load as expected. Please refresh the page and try again.

  • RSS
  • X
  • Facebook

ABOUT US

  • About DZone
  • Support and feedback
  • Community research

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Core Program
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 3343 Perimeter Hill Drive
  • Suite 215
  • Nashville, TN 37211
  • [email protected]

Let's be friends:

  • RSS
  • X
  • Facebook