这些年背过的面试题——Netty篇

MessageToByteEncoder //对象编码成字节流；
MessageToMessageEncoder //一种消息类型编码成另外一种消息类型。

Netty 常用解码器类型：

ByteToMessageDecoder/ReplayingDecoder //将字节流解码为消息对象；
MessageToMessageDecoder //将一种消息类型解码为另外一种消息类型。

/*+---------------------------------------------------------------+| 魔数 2byte | 协议版本号 1byte | 序列化算法 1byte | 报文类型 1byte  |+---------------------------------------------------------------+| 状态 1byte |        保留字段 4byte     |      数据长度 4byte     | +---------------------------------------------------------------+|                   数据内容 （长度不定）                          |+---------------------------------------------------------------+ */

1. 堆内内存由 JVM GC 自动回收内存，降低了 Java 用户的使用心智，堆外内存由于不受 JVM 管理，所以在一定程度上可以降低 GC 对应用运行时带来的影响。

2. 堆外内存需要手动释放，这一点跟 C/C++ 很像，稍有不慎就会造成应用程序内存泄漏，当出现内存泄漏问题时排查起来会相对困难。

3. 当进行网络 I/O 操作、文件读写时，堆内内存都需要转换为堆外内存，然后再与底层设备进行交互，所以直接使用堆外内存可以减少一次内存拷贝。

4. 堆外内存可以方便实现进程之间、JVM 多实例之间的数据共享。

• mark：为某个读取过的关键位置做标记，方便回退到该位置；
• position：当前读取的位置；
• limit：buffer 中有效的数据长度大小；

• capacity：初始化时的空间容量。

• 废弃字节，表示已经丢弃的无效字节数据。

• 可读字节，表示 ByteBuf 中可以被读取的字节内容，可以通过 writeIndex – readerIndex 计算得出。当读写位置重叠时时，表示 ByteBuf 已经不可读。

• 可写字节，向 ByteBuf 中写入数据都会存储到可写字节区域。当 writeIndex 超过 capacity，表示 ByteBuf 容量不足，需要扩容。

• 可扩容字节，表示 ByteBuf 最多还可以扩容多少字节，最多扩容到 maxCapacity 为止，超过 maxCapacity 再写入就会出错。

1. 首先需要找到存储 2^4 连续 Page 所对应的链表，即数组下标为 4；

2. 查找 2^4 链表中是否有空闲的内存块，如果有则分配成功；

3. 如果 2^4 链表不存在空闲的内存块，则继续沿数组向上查找，即定位到数组下标为 5 的链表，链表中每个节点存储 2^5 的连续 Page；

4. 如果 2^5 链表中存在空闲的内存块，则取出该内存块并将它分割为 2 个 2^4 大小的内存块，其中一块分配给进程使用，剩余的一块链接到 2^4 链表中。

• 内存是由一定数量的 arenas 负责管理，线程均匀分布在 arenas 当中；

• 每个 arena 都包含一个 bin 数组，每个 bin 管理不同档位的内存块；

• 每个 arena 被划分为若干个 chunks，每个 chunk 又包含若干个 runs，每个 run 由连续的 Page 组成，run 才是实际分配内存的操作对象；

• 每个 run 会被划分为一定数量的 regions，在小内存的分配场景，region 相当于用户内存；

• 每个 tcache 对应一个 arena，tcache 中包含多种类型的 bin。

1. 当用户进程发起 read() 调用后，上下文从用户态切换至内核态。DMA 引擎从文件中读取数据，并存储到内核态缓冲区，这里是第一次数据拷贝。

2. 请求的数据从内核态缓冲区拷贝到用户态缓冲区，然后返回给用户进程。第二次数据拷贝的过程同时，会导致上下文从内核态再次切换到用户态。

3. 用户进程调用 send() 方法期望将数据发送到网络中，用户态会再次切换到内核态，第三次数据拷贝请求的数据从用户态缓冲区被拷贝到 Socket 缓冲区。

4. 最终 send() 系统调用结束返回给用户进程，发生了第四次上下文切换。第四次拷贝会异步执行，从 Socket 缓冲区拷贝到协议引擎中。

• 堆外内存，避免 JVM 堆内存到堆外内存的数据拷贝。

• CompositeByteBuf 类，可以组合多个 Buffer 对象合并成一个逻辑上的对象，避免通过传统内存拷贝的方式将几个 Buffer 合并成一个大的 Buffer。

• 通过 Unpooled.wrappedBuffer 可以将 byte 数组包装成 ByteBuf 对象，包装过程中不会产生内存拷贝。

• ByteBuf.slice ，slice 操作可以将一个 ByteBuf 对象切分成多个 ByteBuf 对象，切分过程中不会产生内存拷贝，底层共享一个 byte 数组的存储空间。

• Netty 使用 封装了transferTo() 方法 FileRegion，可以将文件缓冲区的数据直接传输到目标 Channel，避免内核缓冲区和用户态缓冲区之间的数据拷贝。

1. 找到数组下标 index 位置，设置新的 value。

2. 将 FastThreadLocal 对象保存到待清理的 Set 中。

• 高效查找。FastThreadLocal 在定位数据的时候可以直接根据数组下标 index 获取，时间复杂度 O(1)。而 JDK 原生的 ThreadLocal 在数据较多时哈希表很容易发生 Hash 冲突，线性探测法在解决 Hash 冲突时需要不停地向下寻找，效率较低。此外，FastThreadLocal 相比 ThreadLocal 数据扩容更加简单高效，FastThreadLocal 以 index 为基准向上取整到 2 的次幂作为扩容后容量，然后把原数据拷贝到新数组。而 ThreadLocal 由于采用的哈希表，所以在扩容后需要再做一轮 rehash。

• 安全性更高。JDK 原生的 ThreadLocal 使用不当可能造成内存泄漏，只能等待线程销毁。在使用线程池的场景下，ThreadLocal 只能通过主动检测的方式防止内存泄漏，从而造成了一定的开销。然而 FastThreadLocal 不仅提供了 remove() 主动清除对象的方法，而且在线程池场景中 Netty 还封装了 FastThreadLocalRunnable，任务执行完毕后一定会执行 FastThreadLocal.removeAll() 将 Set 集合中所有 FastThreadLocal 对象都清理掉。

Timer小根堆队列，deadline 任务位于堆顶端，弹出的始终是最优先被执行的任务。Run 操作时间复杂度 O(1)，Schedule 和Cancel 操作的时间复杂度都是 O(logn)。

DelayedQueue 采用优先级队列 PriorityQueue延迟获取对象的阻塞队列。DelayQueue中的每个对象都必须实现Delayed 接口，并重写 compareTo 和 getDelay 方法。

DelayQueue 提供了 put() 和 take() 的阻塞方法，可以向队列中添加对象和取出对象。对象被添加到 DelayQueue 后，会根据 compareTo() 方法进行优先级排序。getDelay() 方法用于计算消息延迟的剩余时间，只有 getDelay

为了解决 Timer 的设计缺陷，JDK 提供了功能更加丰富的 ScheduledThreadPoolExecutor，多线程、相对时间、对异常

Timer 的任务调度是基于系统绝对时间的，如果系统时间不正确，可能会出现问题。

public HashedWheelTimer(        ThreadFactory threadFactory, //线程池，但是只创建了一个线程        long tickDuration, //时针每次 tick 的时间，相当于时针间隔多久走到下一个 slot        TimeUnit unit,             //表示 tickDuration 的时间单位，tickDuration * unit        int ticksPerWheel,  //时间轮上一共有多少个 slot，默认 512 个。boolean leakDetection,        long maxPendingTimeouts) {//最大允许等待任务数    // 省略其他代码    wheel = createWheel(ticksPerWheel); // 创建时间轮的环形数组结构    mask = wheel.length - 1; // 用于快速取模的掩码    long duration = unit.toNanos(tickDuration); // 转换成纳秒处理    workerThread = threadFactory.newThread(worker); // 创建工作线程    leak = leakDetection || !workerThread.isDaemon() ? leakDetector.track(this) : null; // 是否开启内存泄漏检测    this.maxPendingTimeouts = maxPendingTimeouts; // 最大允许等待任务数，HashedWheelTimer 中任务超出该阈值时会抛出异常}

long time = System.nanoTime();if (/*事件轮询的持续时间大于等于 timeoutMillis*/) 
{    selectCnt = 1;} else if (/*不正常的次数 selectCnt 达到阈值 512*/) 
{    //重建Select并且SelectionKey重新注册到新Selector上      selector = selectRebuildSelector(selectCnt);}

0

0