Alternative Java Selector Implementations

Question

I'm writing a high performance/low garbage application (microseconds matter) that has a networking component. One of the sore points that I've come across is the implementation of the built in Selector for Java NIO.

A few things that are problematic:

• Lots of object creation. Pretty much every call to selectedKeys() creates a lot of objects. Iterators, boxing/unboxing, you name it. Not a problem with most other cases but the application I'm writing needs to create as little garbage as possible.
• Layers upon layers of locking and synchronization. At the time the selectorImpls were built, a bunch of the Java lock primitives didn't exist. As a result it's clunky and not optimal. In my use case, there's only one thread calling select so the locking is in fact useless.

Extending or changing the selector implementation is a nonstarter. Most of the classes are final, with private and package-private members located in the sun.nio.ch.* package. Native methods also complicate things.

Are there any other more modern implementations of the selector that may be more performant?

The networking libraries I've examined just use the built in Java selector under the covers. Any help would be appreciated.

Answer 1

Maybe this lib satisfies your needs? Haven't used it myself, but looks promising. http://www.coralblocks.com/index.php/the-simplicity-of-coralreactor/

Answer 2

Netty project has an implementation that uses Native epoll edge-triggered transport:

Since 4.0.16, Netty provides the native socket transport for Linux using JNI. This transport has higher performance and produces less garbage [...]

One possible drawback for you might be, it's available on Linux only.

On the positive side, Netty is an open-source project, may be the source code will give you a hint or two.

Answer 3

Regarding your first point about lots of object creation, you can ameliorate by using the select methods that were introduced in java11, the ones that accept an action Consumer as a parameter.

Before java11, every time you call a select() method, you have to call iterator() to access the events. This would create a new iterator object which would be subject to garbage collection. And this was unfortunately enshrined in the interface (abstract base class) itself.

The new methods iterate over the events themselves, applying your action, and reducing garbage.

Here's the javadoc for the new methods: https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/nio/channels/Selector.html#select(java.util.function.Consumer,long)