2022最新 Netty底层数据交互源码剖析二

最新推荐文章于 2023-04-28 14:12:06 发布

猿华

最新推荐文章于 2023-04-28 14:12:06 发布

阅读量686

点赞数

分类专栏： Netty 文章标签： java netty 源码

本文链接：https://blog.csdn.net/m0_52255061/article/details/126411248

版权

Netty 专栏收录该内容

4 篇文章 0 订阅

订阅专栏

Netty底层数据交互源码剖析

上一章讲了服务端初始化、注册事件、绑定端口、eventloop线程池的来龙去脉；在上一节的基础上，讲解这一节：如何处理客户端连接事件；以及数据交互，话不多说、直接开车

Netty

Netty底层数据交互源码剖析

Netty服务端事件响应底层实现

上文我们讲了eventLoop启动之后会有一个线程一直死循环执行调用select方法；那么客户端想要连接的话必然会触发accpet事件，也就是说必然会执行到eventLoop的run方法;所以这一章咱们就从这个方法开始看起！

select方法就不用看了，我们假设来了一个客户端连接，必然就会触发accept事件；直接看processKey方法

接着就是看read方法，一看就是个重点方法！

可以发现，Netty其实就是在帮我们写Nio的代码而已，我们自己写NIO代码时也会调用这个方法处理连接事件然后生成一个channel，之后客户端的所有读写操作就会在这个channel上进行！

但是Netty肯定不能就这么了事了；

可以看到，Netty做了封装，所以封装的逻辑肯定是蛮重要的！点进去看看

在此之前可以先回想一下，服务端启动的时候也初始化了一个ServerSocketChannel,它是怎么做的呢？

初始化Channel
创建pipeline
设置感兴趣的事件
将channel注册到selector中

跟着这个思路我们往下看看源码：

很好，看到创建pipeline了，逻辑和之前的一样，就是初始化头尾节点双向链表！

socketChannel就创建完毕了，并将之放到buf列表属性当中返回；

接着就看fireChannelRead这个方法，根据经验可知，该方法时责任链方法，会调用每个handler中的channelRead方法！

但是这有个细节，pipeline是谁的pipeline？网上查看可以发现，这个pipeline其实是Server Socket Channel中的pipeline，所以调用的也就是ServerSocketChannel中的handler

具体会调用到哪儿呢？就得看看上一章中serversocketchannek中的handler有哪些？

所以咱们直接看这个handler中的fireChannelRead方法即可

到这就只有一个疑问：childHandler是啥？

还记得我们刚开始创建Bootstrap的时候赋的值嘛？

所以我们完全可以大胆猜测一下，这个方法无非就是完善socketChannel，将handler加入到链表当中取；后续在这个channel完成数据读写的功能

那就接着往下看

channel创建好了之后，里面发生事件总得有线程来执行吧，这就轮到workerGroup来处理了，

目前为止：SocketChannel 设置了一个感兴趣事件：OP_READ，然后初始化了pipeline，一切准备就绪之后，将其注册到一个EventLoop上，也就是workerGroup中得EventLoop

然后后续得流程就和ServerSocketChannel注册到BossGroup中得EventLoop上是一样得了！在上文有完整的注册流程；

也即是线程模型图中的第三步

总结一下：

processSelect Keys将有连接事件的客户端请求调用accpet方法构建一个SocketChannel,然后将其封装成为NIOSocketChanel,这个Channel里面设置了感兴趣事件Read,以及创建并初始化了pipeline; 将pipeline完善后注册到workerGroup中的一个EventLoop上，之后该channel产生的事件就交给该EventLoop去实现了！比如后续客户端向服务端发送消息就会触发Read；

那么现在就来看看Read事件触发后EventLoop是怎么处理的！逻辑还是在run方法中；

这时候unsafe代表的就是NioSocketChannel了；接着往下:

Os将客户端发送的数据拷贝到bytebuf中，接下来就会调用业务读数据了！

相信看到这里大家都一目了然了，整个Netty核心在心里面都大概有个底了吧！

以上就是Netty核心数据交互源码，主线流程也就走完了！也就是模型图中的345部分都看过一遍了！说到底Netty就是在帮我们写NIO的代码；关键内容还是他的主从线程模型以及数据交互！

Netty高并发架构设计

主从Reactor线程模型
NIO多路复用非阻塞
无锁串行化设计思想
支持高性能序列化协议
零拷贝(直接内存的使用)
ByteBuf内存池设计
灵活的TCP参数配置能力
并发优化

无锁串行化设计思想

在大多数场景下，并行多线程处理可以提升系统的并发性能。但是，如果对于共享资源的并发访问处理不当，会带来严重的锁竞争，这最终会导致性能的下降。为了尽可能的避免锁竞争带来的性能损耗，可以通过串行化设计，即消息的处理尽可能在同一个线程内完成，期间不进行线程切换，这样就避免了多线程竞争和同步锁。NIO的多路复用就是一种无锁串行化的设计思想(理解下Redis和Netty的线程模型)

为了尽可能提升性能，Netty采用了串行无锁化设计，在IO线程内部进行串行操作，避免多线程竞争导致的性能下降。表面上看，串行化设计似乎CPU利用率不高，并发程度不够。但是，通过调整NIO线程池的线程参数，可以同时启动多个串行化的线程并行运行，这种局部无锁化的串行线程设计相比一个队列-多个工作线程模型性能更优。

Netty的NioEventLoop读取到消息之后，直接调用ChannelPipeline的fireChannelRead(Object msg)，只要用户不主动切换线程，一直会由NioEventLoop调用到用户的Handler，期间不进行线程切换，这种串行化处理方式避免了多线程操作导致的锁的竞争，从性能角度看是最优的。

DirectMemeory直接内存详解

也就是堆外内存！

什么是堆外内存？

直接内存（Direct Memory）并不是虚拟机运行时数据区的一部分，也不是Java虚拟机规范中定义的内存区域，某些情况下这部分内存也

会被频繁地使用，而且也可能导致OutOfMemoryError异常出现。Java里用DirectByteBuffer可以分配一块直接内存(堆外内存)，元空间

对应的内存也叫作直接内存，它们对应的都是机器的物理内存。

为什么要使用堆外内存

/**
 * 直接内存与堆内存的区别
 */
public class DirectMemoryTest {

    public static void heapAccess() {
        long startTime = System.currentTimeMillis();
        //分配堆内存
        ByteBuffer buffer = ByteBuffer.allocate(1000);
        for (int i = 0; i < 100000; i++) {
            for (int j = 0; j < 200; j++) {
                buffer.putInt(j);
            }
            buffer.flip();
            for (int j = 0; j < 200; j++) {
                buffer.getInt();
            }
            buffer.clear();
        }
        long endTime = System.currentTimeMillis();
        System.out.println("堆内存访问:" + (endTime - startTime) + "ms");
    }

    public static void directAccess() {
        long startTime = System.currentTimeMillis();
        //分配直接内存
        ByteBuffer buffer = ByteBuffer.allocateDirect(1000);
        for (int i = 0; i < 100000; i++) {
            for (int j = 0; j < 200; j++) {
                buffer.putInt(j);
            }
            buffer.flip();
            for (int j = 0; j < 200; j++) {
                buffer.getInt();
            }
            buffer.clear();
        }
        long endTime = System.currentTimeMillis();
        System.out.println("直接内存访问:" + (endTime - startTime) + "ms");
    }

    public static void heapAllocate() {
        long startTime = System.currentTimeMillis();
        for (int i = 0; i < 100000; i++) {
            ByteBuffer.allocate(100);
        }
        long endTime = System.currentTimeMillis();
        System.out.println("堆内存申请:" + (endTime - startTime) + "ms");
    }

    public static void directAllocate() {
        long startTime = System.currentTimeMillis();
        for (int i = 0; i < 100000; i++) {
            ByteBuffer.allocateDirect(100);
        }
        long endTime = System.currentTimeMillis();
        System.out.println("直接内存申请:" + (endTime - startTime) + "ms");
    }

    public static void main(String args[]) {
        for (int i = 0; i < 10; i++) {
            heapAccess();
            directAccess();
        }

        System.out.println();

        for (int i = 0; i < 10; i++) {
            heapAllocate();
            directAllocate();
        }
    }
}

从程序运行结果看出直接内存申请较慢，但访问效率高。在java虚拟机实现上，本地IO一般会直接操作直接内存（直接内存=>系统调用=>硬盘/网卡），而非直接内存则需要二次拷贝（堆内存=>直接内存=>系统调用=>硬盘/网卡）。

直接内存源码分析

public static ByteBuffer allocateDirect(int capacity) {
    return new DirectByteBuffer(capacity);
}
DirectByteBuffer(int cap) {                   // package-private
    super(-1, 0, cap, cap);
    boolean pa = VM.isDirectMemoryPageAligned();
    int ps = Bits.pageSize();
    long size = Math.max(1L, (long)cap + (pa ? ps : 0));
    //判断是否有足够的直接内存空间分配，可通过-XX:MaxDirectMemorySize=<size>参数指定直接内存最大可分配空间，如果不指定默认为最大堆内存大小，
    //在分配直接内存时如果发现空间不够会显示调用System.gc()触发一次full gc回收掉一部分无用的直接内存的引用对象，同时直接内存也会被释放掉
    //如果释放完分配空间还是不够会抛出异常java.lang.OutOfMemoryError
   Bits.reserveMemory(size, cap);

    long base = 0;
    try {
        // 调用unsafe本地方法分配直接内存
        base = unsafe.allocateMemory(size);
    } catch (OutOfMemoryError x) {
        // 分配失败，释放内存
        Bits.unreserveMemory(size, cap);
        throw x;
    }
    unsafe.setMemory(base, size, (byte) 0);
    if (pa && (base % ps != 0)) {
        // Round up to page boundary
        address = base + ps - (base & (ps - 1));
    } else {
        address = base;
    }
    
    // 使用Cleaner机制注册内存回收处理函数，当直接内存引用对象被GC清理掉时，
    // 会提前调用这里注册的释放直接内存的Deallocator线程对象的run方法
    cleaner = Cleaner.create(this, new Deallocator(base, size, cap));
    att = null;
}


// 申请一块本地内存。内存空间是未初始化的，其内容是无法预期的。
// 使用freeMemory释放内存，使用reallocateMemory修改内存大小
public native long allocateMemory(long bytes);

// openjdk8/hotspot/src/share/vm/prims/unsafe.cpp
UNSAFE_ENTRY(jlong, Unsafe_AllocateMemory(JNIEnv *env, jobject unsafe, jlong size))
  UnsafeWrapper("Unsafe_AllocateMemory");
  size_t sz = (size_t)size;
  if (sz != (julong)size || size < 0) {
    THROW_0(vmSymbols::java_lang_IllegalArgumentException());
  }
  if (sz == 0) {
    return 0;
  }
  sz = round_to(sz, HeapWordSize);
  // 调用os::malloc申请内存，内部使用malloc这个C标准库的函数申请内存
  void* x = os::malloc(sz, mtInternal);
  if (x == NULL) {
    THROW_0(vmSymbols::java_lang_OutOfMemoryError());
  }
  //Copy::fill_to_words((HeapWord*)x, sz / HeapWordSize);
      return addr_to_java(x);
UNSAFE_END

核心方法就是调用malloc方法分配内存，只是系统调用，会触发用户态转内核态！

使用直接内存的优缺点：

优点：

不占用堆内存空间，减少了发生GC的可能

java虚拟机实现上，本地IO会直接操作直接内存（直接内存=>系统调用=>硬盘/网卡），而非直接内存则需要二次拷贝（堆内存=>直接内存=>系统调用=>硬盘/网卡）

缺点：

初始分配较慢

没有JVM直接帮助管理内存，容易发生内存溢出。为了避免一直没有FULL GC，最终导致直接内存把物理内存耗完。我们可以指定直接内存的最大值，通过-XX：MaxDirectMemorySize来指定，当达到阈值的时候，调用system.gc来进行一次FULL GC，间接把那些没有被使用的直接内存回收掉。

Netty零拷贝源码

图：使用直接内存零拷贝与不使用零拷贝的对比

Netty的接收和发送ByteBuf采用DIRECT BUFFERS，使用堆外直接内存进行Socket读写，不需要进行字节缓冲区的二次拷贝。

如果使用传统的JVM堆内存（HEAP BUFFERS）进行Socket读写，JVM会将堆内存Buffer拷贝一份到直接内存中，然后才能写入Socket中。JVM堆内存的数据是不能直接写入Socket中的。相比于堆外直接内存，消息在发送过程中多了一次缓冲区的内存拷贝。

可以看下netty的读写源码，比如read源码NioByteUnsafe.read()

回到netty读数据的源码：

ByteBuf内存池设计

直接内存的缺点是什么？

不方便回收
分配较慢

所以，一个ByteBuf来之不易，走也不容易；所以干脆将他留下来不就行了；这就是内存池诞生的初衷；既然来自不易，用完之后保存起来不就好了！

随着JVM虚拟机和JIT即时编译技术的发展，对象的分配和回收是个非常轻量级的工作。但是对于缓冲区Buffer(相当于一个内存块)，情况却稍有不同，特别是对于堆外直接内存的分配和回收，是一件耗时的操作。为了尽量重用缓冲区，Netty提供了基于ByteBuf内存池的缓冲区重用机制。需要的时候直接从池子里获取ByteBuf使用即可，使用完毕之后就重新放回到池子里去。下面我们一起看下Netty ByteBuf的实现：

Netty怎么使用内存池的呢？

那就继续看看分配直接内存的代码

点进去发现线程缓存获取ByteBuf池化对象，

ByteBuff扩容机制源码剖析

扩容机制较为简单：

从64字节开始，每次两倍递增扩容：64, 128, 256 ······

当阈值到达4M之后，就不再是成倍扩容了，而是按照步长为4M慢慢扩容，每次加4M;

minNewCapacity：表用户需要写入的值大小
threshold：阈值，为Bytebuf内部设定容量的最大值
maxCapacity：Netty最大能接受的容量大小，一般为int的最大值

源码解读：进入ByteBuf源码中，深入分析其扩容方法： idea源码进入：ByteBuf.writeByte()->AbstractByteBuf->calculateNewCapacity

照例来一波总结

总结

继续上节的内容讲了当有连接建立时服务端底层做了哪些事情；无非就是生成socketChannel并初始化pipeline设置事件为读事件；最后将其注册到workerGroup中的其中一个EventLoop上，底层流程与上一节ServerSocketChannel一样的流程！

以及当触发读事件时EventLoop做了哪些工作才保证了数据的正常到达，这里又涉及到了Netty直接内存的概念以及零拷贝原理；

最后把整个netty的设计精髓做了一些专门的讲解以及源码级别剖析！

最后贴一张整个Netty源码流程图！

猿华

关注

0
点赞
踩
1

收藏

觉得还不错? 一键收藏
2
评论
2022最新 Netty底层数据交互源码剖析二

当有连接建立时服务端底层做了哪些事情；无非就是生成socketChannel并初始化pipeline设置事件为读事件；最后将其注册到workerGroup中的其中一个EventLoop上，底层流程与上一节ServerSocketChannel一样的流程！以及当触发读事件时EventLoop做了哪些工作才保证了数据的正常到达，这里又涉及到了Netty直接内存的概念以及零拷贝原理；最后把整个netty的设计精髓做了一些专门的讲解以及源码级别剖析！最后贴一张整个Netty源码流程图！...
复制链接

扫一扫