TCP 三次握手 → Socket → Netty 追问链#

追问路径#

Q: TCP三次握手过程？
→ 客户端SYN → 服务端SYN+ACK → 客户端ACK；三次主要为防止历史重复的SYN建立错误连接，同时同步双方初始序列号(ISN)
  Q: 服务端accept之后连接怎么处理？
  → Socket编程：accept()返回已连接Socket，传统BIO模式一个连接分配一个线程处理
    Q: BIO的问题是什么？
    → 线程资源耗尽：每个连接一个线程，1万连接需要1万线程(每线程预留~1MB栈虚拟地址，实际占用几十到几百KB，另有调度开销)，上限约1万连接
      ├─ Q: NIO怎么解决的？
      │  → Selector多路复用：一个线程监听多个Channel的IO事件(OP_ACCEPT/OP_READ/OP_WRITE)
      │    Q: select/poll/epoll有什么区别？
      │    → select(fd_set位图，fd值<1024)/poll(pollfd数组，无固定上限，受ulimit -n约束)/epoll(红黑树+就绪链表, O(1)事件通知)
      │      Q: epoll的ET和LT模式？
      │      → LT(水平触发, 只要有数据就通知)/ET(边缘触发, 新数据到达才通知一次, 须配非阻塞IO循环读到EAGAIN否则连接卡住)
      │        Q: Netty用的哪种？
      │        → 默认NIO传输走JDK Selector(Linux上是epoll LT)；原生epoll传输用JNI调用epoll_wait，4.1默认ET，4.2起固定LT(EPOLL_MODE已废弃)
      └─ Q: 生产环境为什么用Netty不直接用Java NIO？
         → Java NIO的Selector有epoll空轮询bug(CPU 100%)；Netty自动检测并重建Selector
           Q: Netty的线程模型？
           → 主从Reactor：BossGroup(1-2线程accept新连接) + WorkerGroup(CPU核数×2线程处理IO)
             Q: Netty的内存管理有什么特点？
             → PooledByteBufAllocator池化 + 堆外内存(DirectByteBuffer, 省掉一次从JVM堆到native内存的拷贝) + 引用计数释放

涉及知识点#

• TCP三次握手与四次挥手 — 连接建立与断开
• TCP可靠传输机制 — 序号/确认/重传/滑动窗口
• TCP粘包与拆包 — Netty的LengthFieldBasedFrameDecoder
• BIO-NIO-AIO对比 — IO模型演进
• select-poll-epoll对比 — 多路复用实现差异
• epoll原理 — 红黑树+就绪链表+回调机制
• IO多路复用 — 一个线程处理多连接的核心思想
• Reactor模式 — 高性能网络编程的核心模式
• 零拷贝原理 — sendfile/mmap减少数据拷贝
• 用户态与内核态 — 系统调用与内存拷贝开销

核心串联逻辑#

1. TCP握手建立可靠连接后，服务端accept()返回Socket
2. BIO → NIO：BIO一连接一线程，上万连接时线程内存和上下文切换开销都很大(1MB栈只是虚拟地址预留)；NIO通过Selector一线程管多连接
3. epoll优势：O(1)事件通知(vs select O(n))，无fd数量限制(vs select 1024)，ET模式减少事件触发次数
4. Netty封装：解决JDK NIO的epoll空轮询bug，提供主从Reactor线程模型，池化内存管理
5. 堆外内存：DirectByteBuffer绕过JVM堆，Socket读写少一次从堆到native的memcpy
6. 代码示例：

   // Netty主从Reactor典型配置
   EventLoopGroup bossGroup = new NioEventLoopGroup(1);     // accept线程（4.2起此类废弃，改用MultiThreadIoEventLoopGroup+NioIoHandler.newFactory()）
   EventLoopGroup workerGroup = new NioEventLoopGroup();     // 默认CPU*2
   ServerBootstrap b = new ServerBootstrap();
   b.group(bossGroup, workerGroup)
    .channel(NioServerSocketChannel.class)
    .childHandler(new ChannelInitializer<>() { /* Pipeline配置 */ });

   java

面试回答串联#

30秒速答#

TCP三次握手建连后，BIO每连接一线程上限约1万。NIO通过Selector多路复用让单线程管多连接。Linux上epoll用红黑树+就绪链表实现O(1)事件通知。生产用Netty的主从Reactor——BossGroup负责accept，WorkerGroup负责IO读写。

2分钟展开答#

TCP三次握手确认双方收发能力后建立连接。传统BIO模型每个连接一个线程阻塞读写，线程栈预留约1MB虚拟地址(实际占用几十到几百KB)，上万连接时内存和上下文切换开销都很大。NIO通过Selector多路复用让一个线程监听多个Channel的IO事件。Linux上epoll用红黑树管理fd+就绪链表存储就绪事件，事件通知是O(1)而select是O(n)，也没有1024的fd数量限制。epoll有LT(水平触发)和ET(边缘触发)两种模式，Netty默认的NIO传输走JDK Selector，是LT；原生epoll传输在4.1默认ET，4.2起固定用LT。为什么不直接用Java NIO？因为JDK的Selector有epoll空轮询bug会导致CPU 100%，Netty自动检测并重建Selector解决了这个问题。Netty的线程模型是主从Reactor——BossGroup 1-2个线程负责accept新连接，WorkerGroup默认CPU核数×2个线程处理IO读写，Handler链式处理业务。内存管理上Netty用PooledByteBufAllocator池化+堆外内存(DirectByteBuffer)，省掉一次从JVM堆到native内存的memcpy。

相关追问链#

• MQ可靠性-顺序-积压-事务消息追问链 — Kafka/RocketMQ底层使用Netty做网络传输
• 进程线程-调度-上下文切换-协程追问链 — IO模型与线程调度的关系