我正在选择一个网络库来实现一个不能节省任何微秒的客户端/服务器系统。它将实现自己的协议来发送和接收消息。我正在寻找一个好的NIO框架，它将允许我轻松开发服务器和客户端，而不必太担心低级选择器的细节。每个人都推荐我Netty，但我想在为我的团队提交框架之前尝试2或3种其他替代方案。我不太喜欢Netty的一件事是它如何通过自己的ByteBuf实现和引用计数来处理ByteBuffers。任何人都可以分享你的想法和替代方案吗？
我们开发了一个NIO网络库，该库在环回上执行不到2微秒，而不会为GC产生任何垃圾。正如 Peter Lawrey 所提到的，原生 JDK 选择器会产生很多垃圾，但是我们通过实现自己的 epoll 选择器修复了所有这些垃圾泄漏。忙于等待选择器线程对于延迟很有帮助，但必须有一个平衡，以免烧毁芯片或消耗大量能量。我们的选择器实现使用低级技巧来实现一种节能模式，以照顾这种平衡。
除了CoralReactor，你还可以看看Grizzly和Mina，但我们还没有玩过这些框架。
有关一些Netty TCP性能基准测试，您可以在此处查看。
这是假设你真的想节省每一微秒。大多数应用程序没有如此严格的要求。
如果要节省微秒，则需要对专用 CPU 上的线程使用忙于等待的非阻塞 NIO。这不能很好地扩展，因为您需要拥有足够的CPU，但确实可以最大程度地减少处理IO的延迟。我建议您也绑定隔离的CPU，以最大程度地减少抖动。
您将需要避免使用选择器，因为它们会阻止和/或创建相当多的垃圾，以增加GC暂停。
此外，为了最大限度地减少延迟，您将需要使用低延迟，内核旁路网络适配器，如Solarflare。
您将需要使用推送解析器，以便在下载时可以解码/解析长消息。也就是说，您不会想等到收到整个消息后再开始。
结合使用这些技巧可以为每个请求或入站事件节省10-30微秒。
Netty是可扩展性的更好解决方案，即更高的净吞吐量，但延迟成本很小，大多数基于支持Web服务的框架也是如此，其中毫秒延迟是可以容忍的。
