Java NIO 言过其实且过于复杂 | AI生成和翻译
问题：关于 Java NIO 有哪些不受欢迎的观点？
回答：
Java NIO（New I/O）在 Java 1.4 中引入，常被称赞为实现了非阻塞 I/O、缓冲区、通道和选择器，从而能够高效处理大量连接。然而，一些不受欢迎的观点挑战了其广泛的炒作和其相对于传统阻塞 I/O (java.io) 被认为的优越性。
以下是一些从开发者讨论中得出的主要不受欢迎的观点：
-
NIO 被过度炒作，并非天生更快：非阻塞 NIO 经常被宣传用于高性能服务器，但在许多情况下——尤其是在现代内核和线程实现下——使用每个连接一个线程的阻塞 I/O 在延迟和吞吐量上可能更快。NIO 的选择器增加了开销，原生 NIO 很少比多线程阻塞 I/O 更快，除非处理数千个空闲连接。
-
对于大多数应用程序而言，复杂性超过了收益：NIO 的 API 原始、底层，并且以难以正确使用而闻名（例如，管理 ByteBuffer、部分读/写和选择器）。这会导致代码有 bug 且难以维护。许多开发者认为，除非高并发有要求，否则不值得费力，对于大多数项目来说，传统 I/O 更简单且足够。
-
NIO 仅在极端可伸缩性场景下有必要，而非通用用途：它在并发性高（例如，数千个连接）的场景中对于资源效率非常有用，但对于典型应用程序，带有线程池的阻塞 I/O 表现良好且更容易理解。响应式编程和 NIO 有时被视为过度炒作的趋势而非必需品。
-
即使在阻塞模式下，NIO 也几乎没有优势：在阻塞模式下使用 NIO 通道与传统流相比，并不能提供显着的性能提升，反而增加了不必要的复杂性。
-
存在更好的替代方案：Netty 或 Grizzly 等框架抽象了 NIO 的难度，这暗示原生 NIO 太难直接使用。有些人倾向于使用执行器或更高级别的抽象而不是原生 NIO。
这些观点与 NIO 总是“更好”或现代的普遍看法形成对比。在实践中，应根据需求进行选择：简单性和可读性通常胜过为并发而进行的过早优化。
参考：
- https://www.reddit.com/r/java/comments/5ns3ad/is_reactive_nio_being_overhyped/
- https://mailinator.blogspot.com/2008/02/kill-myth-please-nio-is-not-faster-than.html
- https://stackoverflow.com/questions/12892536/how-to-choose-java-nio-vs-io
- https://stackoverflow.com/questions/5223175/advantages-of-java-nio-in-blocking-mode-versus-traditional-i-o
- https://www.reddit.com/r/java/comments/56y6nh/why_is_nio_still_not_popular/
- https://stackoverflow.com/questions/4877292/java-nio-vs-new-thread-for-each-socket