为什么在netty的眼里jdk的许多实现都不是非常高效?

如果有不清楚netty是什么的小伙伴可自行查询相关资料，本文不对netty进行讲解。

用一句话概括的话，Netty是一个高性能、异步事件驱动的网络应用框架，它被设计用于构建可扩展的服务器和客户端应用程序.

先说结论

我们不能脱离使用场景谈高效。JDK的设计在通用性上更好，而Netty的设计更适合高并发、网络通信的场景。

两者的区别

随便举几个例子，比较下两者实现上的区别。

1. ThreadLocal实现

就底层的哈希算法而言，ThreadLocal是基于非波拉契散列法和开放寻址，计算结果在空间分布上更加均匀。

而Netty的FastThreadLocal是基于数组下标递增，有效避免了哈希碰撞，并降低了rehash的开销，更适合高并发的场景。

2. 堆外内存释放机制

JDK提供堆外内存的封装类DirectByteBuffer，初始化时会默认开启Cleaner，作用是当DirectByteBuffer被GC时能自动调用Cleaner.clean()清理堆外内存，避免泄漏。

但Cleaner在内存分配和回收上会带来额外的性能开销。为此Netty提供了No Cleaner策略，不再创建Cleaner，而是通过retain/release操作手动释放，从而获得性能提升。

不过，或许是认识到了该策略带来的内存泄漏风险，Netty 5又将No Cleaner策略设置为默认不开启，作为可选择的高阶用法，需要通过指定JVM启动参数来开启。

3. 线程池实现

JDK的线程池内部维护了一个类型为BlockingQueue的taskqueue来保存任务队列，当线程从该队列获取任务会产生锁竞争降低性能。

Netty的解决办法是，每个channel创建时固定绑定到一个IO线程(NioEventLoop)上，其后channel上产生的IO任务也固定由这个线程处理，避免了线程池级别上的任务竞争。

不过你可能会提出疑问：除了IO任务，IO线程还会处理一些其他线程提交的异步任务和定时任务呀，在线程内部不是仍然会发生任务队列竞争吗？

原来Netty在这里使用了JCTools提供的MpscQueue（多生产者单消费者队列），它内部使用CAS避免了JDK中BlockingQueue的锁竞争，从来带来更好的性能。Netty在内部大量使用了MpscQueue，如HashedWheelTimer、Recycler、PoolThreadCache，这些场合都适合使用这种无锁非阻塞队列。

4.同步阻塞模型

JDK 标准的 java.net 包中的 Socket 和 ServerSocket API 主要是基于传统的阻塞 I/O 模型，这意味着当线程调用 read 或 write 方法时，如果数据尚未准备好或传输未完成，则线程会进入阻塞状态，无法执行其他任务，这会导致资源利用率低下，尤其是面对大量并发连接时。

5.内存管理与缓冲区复用

JDK 中直接使用 ByteBuffer 进行 I/O 操作时，每次读写操作可能都需要创建新的缓冲区实例，而 Netty 则通过 ByteBuf 实现了更高效的内存管理和缓冲区池化，减少内存分配和垃圾回收带来的开销。

6.线程模型优化

Netty 使用 Reactor 模式，结合多路复用器（Selector）来实现单线程处理多个 Channel，避免了为每个连接创建独立线程导致的上下文切换和系统资源消耗。

JDK NIO 类虽然提供了 Selector，但使用起来相对复杂且容易出错，Netty 在此基础上封装了高级抽象，简化了编程模型，并提供了一套完整的事件驱动机制。

7.零拷贝

Netty 支持 Java 的直接内存和零拷贝技术，允许数据直接从磁盘到网络堆栈之间传输，而不必经过用户空间多次复制，大大提高了数据传输效率。

8.批处理与合并小包

Netty 提供了对小包合并和批处理的支持，可以有效地减少操作系统层面的小包传输，提高整体吞吐量。

9.内置协议支持与编解码优化

Netty 内置了大量的协议支持，如 HTTP/1.x、HTTP/2、WebSocket 等，并且针对这些协议进行了性能优化，例如，通过链式编解码处理器，可以在不引入额外内存拷贝的情况下完成数据的序列化和反序列化。

综上所述:相对于标准 JDK 实现，Netty 在诸多方面都进行了深度优化和定制，从而实现了更高的性能和更低的延迟，特别适合构建高性能的网络服务应用。

以上为全部内容。