1. 为什么现在还要认真学一遍Java网络编程我经常被刚入行的朋友问到一个问题现在都是Spring Boot MyBatis一把梭业务代码里几乎不会直接写ServerSocket为什么面试还要问Socket、问TCP、问BIO/NIO这个问题其实挺有意思但它背后的答案恰恰是Java网络编程没有被淘汰的原因。先说结论Java网络编程不是让你在业务代码里手写一个HTTP服务器而是让你真正理解数据在网络里是怎么流动的你的应用在什么环节会卡住以及为什么高性能框架Netty能跑到十万级并发而你抄网上的Demo一压测就崩。绝大多数Java面试题里出现网络编程这三个字考察的并不是你有没有在简历上写熟悉Socket编程而是你有没有建立完整的网络模型认知。比如面试官问TCP为什么要三次握手如果你只能背出防止重复连接那你大概率没搞懂这个问题真正在问什么如果你能顺带讲清楚两次握手会导致历史失效连接误入四次握手又浪费那这一题就变成加分项了。这篇文章我不会从那种网络编程从入门到放弃的角度去罗列API而是按我自己梳理知识的方式来讲先搞清楚网络协议解决什么问题再理解Java的Socket本质上封装了什么然后一步步拆出BIO、NIO、Netty这条演进路线背后各自解决的核心矛盾最后把面试里最高频的考点串一遍。无论你是刚接触Java基础想入门还是在准备Java面试题库里的八股文这篇文章应该都能给你一条相对清晰的线。2. 网络初识HTTP、Socket、TCP/IP各自到底管什么2.1 先把TCP/IP四层模型和OSI七层模型的关系说透新手最容易懵的地方就是看到一张七层网络模型图就开始背物理层、数据链路层、网络层、传输层...背完之后依然不知道该用它干什么。我建议换个视角来看网络分层本质上是一种分工协议每一层只解决一个特定范围的问题层与层之间通过标准接口交互。拿你每天都在用的场景举例。你在浏览器输入https://www.xxx.com按下回车这一瞬间发生了什么应用层HTTP/HTTPS浏览器构造一个HTTP请求内容是我要GET这个页面的数据。它不关心数据怎么走只定义请求和响应的格式。传输层TCP系统把这份HTTP报文交给TCP协议TCP负责把它可靠地送到目标机器的对应端口。它不管目标机器在哪只负责端到端的可靠性。网络层IPIP协议负责寻址和路由把数据包从你的机器一路转发到目标机器的IP地址。数据链路层和物理层数据最终变成电信号/光信号经过路由器和交换机一跳一跳地传递。理解这个分层之后再看Java网络编程就清爽了Java的Socket本质上是操作系统提供给应用层的一个网络编程接口它让你不需要直接操作网卡驱动只需要通过文件描述符FD的方式收发数据。你写的代码工作在应用层甚至传输层之上但底层的TCP可靠性、IP路由、链路层传输全都由操作系统和网络设备搞定了。OSI七层模型和TCP/IP四层模型的关系更简单OSI是理论模型TCP/IP是实际运行的模型。很多教科书让你背七层实际工作里你只需要知道TCP/IP这四层的边界——面试时说到HTTP是基于TCP的DNS是基于UDP的这类判断就是在这套分层的基础上。2.2 TCP三次握手和四次挥手面试必问背后的真实语义关于三次握手网上已经有很多文章但大多数只讲了流程没讲本质。我试着用一个生活化的类比来讲。假设你要给一个朋友寄一箱贵重物品你们需要先确认双方都有收发能力第一次握手你发消息说在吗我准备给你寄东西SYN1, seqx。这句话的意义是让朋友确认你的发送能力是好的。第二次握手朋友收到后回复在的可以寄我也准备接收SYN1, ACK1, seqy, ackx1。这句话同时确认了两件事朋友确认了你的发送能力你也确认了朋友的接收能力是好的。第三次握手你收到回复后再回一句好我开始寄了ACK1, acky1。这句的意义是让朋友确认你的接收能力也是好的。所以三次握手的核心本质是通信双方要确认自己和对方的收发能力都正常同时还要协调一个关键参数——初始序列号ISN。为什么必须有第三次因为第二次握手的消息如果丢了发送方无从判断是朋友没收到消息还是朋友没能力回复。只有第三次握手到达接收方才能确定发送方能收。四次挥手就不对称了因为TCP是双工通信每个方向的关闭都要单独确认。你发送我要关闭FIN对方回复知道了ACK这只是关闭了你到对方的方向对方也必须发送一次FIN你再回ACK两个方向都关闭了连接才算真正结束。那为什么常见面试题还会问TIME_WAIT因为主动关闭方发送完最后一次ACK后要等待2MSL报文最大生存时间的两倍再释放连接目的是防止最后一次ACK丢失导致对端重发FIN同时让网络中残留的报文过期消失。这也是为什么高并发场景下服务端主动断开连接会被汹涌的TIME_WAIT困住。2.3 Socket连接与HTTP请求的边界问题有些人一直搞不清楚Socket连接和HTTP请求是什么关系每次HTTP请求都要新建一个Socket吗其实HTTP/1.1的Connection: keep-alive就是在复用同一个Socket连接发送多个HTTP请求。你写Java网络编程时Socket对象就是一个TCP连接的客户端句柄你可以在这个连接上不断发送HTTP报文当然要注意请求之间的顺序和响应读取边界。等到响应头里出现Connection: close你再关闭这个Socket。换句话说Socket是传输层概念上的连接通道HTTP是应用层概念上的请求格式。同一个Socket可以承载多个HTTP请求这也是连接池技术如HttpClient连接池、数据库连接池能够存在的前提。3. Java网络编程API拆解从URL到Socket再到DatagramSocket3.1 不要跳过URL类和InetAddress类很多人学Java网络编程时一上来就看ServerSocket、Socket把URL、InetAddress当成工具类跳过了。我反而建议先把这两个类搞明白因为它们是理解应用层和传输层分工的最短路径。先看InetAddress它做的事情是域名解析。你写InetAddress.getByName(www.baidu.com)底层调用的就是DNS协议返回一个IP地址对象。这里有个常见的坑getByName是阻塞式的如果在网络环境差的情况下解析一个不存在的域名它会卡住直到超时。所以在实际项目中我一般会建议用InetAddress做简单的本机IP获取和域名测试但不要在业务主线程里直接调用它去解析域名。再看URL类它帮你解析一个统一资源定位符的全部组成部分URL url new URL(https://user:passwww.example.com:8080/path/to/file?namejava#section); System.out.println(协议: url.getProtocol()); System.out.println(主机: url.getHost()); System.out.println(端口: url.getPort()); System.out.println(路径: url.getPath()); System.out.println(查询参数: url.getQuery()); System.out.println(锚点: url.getRef());这里值得注意的一个细节是getPort()在没有显式端口时会返回-1你要自己根据协议补默认端口HTTP是80HTTPS是443。很多人写爬虫时在这里踩过坑——解析出的端口是-1就直接发起请求导致报错。URL类还有一个openConnection()方法它会返回一个URLConnection对象这也是最原始的HTTP客户端方式。Java 11之后有了java.net.http.HttpClient比URLConnection好用太多支持HTTP/2和响应式流。但作为初学理解应用层协议如何基于传输层Socket实现用URLConnection跑一个简单的GET请求依然是很好的练习。3.2 核心中的核心Socket和ServerSocket的编程模型现在进入正题。Java的TCP Socket编程模型本质上就是两个文件描述符之间的双向字节流读写。服务端代码的基本骨架// 1. 创建ServerSocket并绑定端口 ServerSocket serverSocket new ServerSocket(8080); System.out.println(服务端已启动监听端口 8080); while (true) { // 2. 阻塞等待客户端连接accept()返回一个新的Socket Socket clientSocket serverSocket.accept(); System.out.println(收到客户端连接: clientSocket.getRemoteSocketAddress()); // 3. 处理客户端请求此处为单线程串行处理 try (BufferedReader in new BufferedReader( new InputStreamReader(clientSocket.getInputStream())); PrintWriter out new PrintWriter(clientSocket.getOutputStream(), true)) { String line; while ((line in.readLine()) ! null) { System.out.println(收到数据: line); out.println(服务端回显: line); } } catch (IOException e) { e.printStackTrace(); } finally { clientSocket.close(); } }客户端基本骨架Socket socket new Socket(127.0.0.1, 8080); try (BufferedReader in new BufferedReader( new InputStreamReader(socket.getInputStream())); PrintWriter out new PrintWriter(socket.getOutputStream(), true); BufferedReader console new BufferedReader(new InputStreamReader(System.in))) { String input; while ((input console.readLine()) ! null) { out.println(input); String response in.readLine(); System.out.println(服务端响应: response); } } catch (IOException e) { e.printStackTrace(); }这段代码可以跑通但请注意两个关键点。第一accept()是阻塞调用。当没有客户端连接进来时线程会一直卡在accept()这一行。这是Java传统BIO模型最本质的特征一个线程只能同时处理一个连接。如果客户端A连接后一直不发数据服务端线程就阻塞在readLine()上客户端B再连进来也必须在accept()那里排队。这就是BIO 一连接一线程的由来。第二readLine()是按行读取的。这意味着如果双方没有约定好一行就是一条完整消息的协议格式就会出现粘包或半包问题。后面我会专门讲这个。3.3 无连接传输DatagramSocket和UDP的适用场景TCP提供可靠字节流UDP只提供尽力而为的数据报。Java里对应的是DatagramSocket和DatagramPacket。UDP编程模型比TCP简单很多没有连接建立和断开的过程你只需要准备好数据包发出去就行。服务端示例DatagramSocket socket new DatagramSocket(9999); byte[] buffer new byte[1024]; DatagramPacket packet new DatagramPacket(buffer, buffer.length); while (true) { socket.receive(packet); // 阻塞等待接收数据报 String msg new String(packet.getData(), 0, packet.getLength()); System.out.println(收到UDP消息: msg 来自 packet.getSocketAddress()); // 回显 byte[] response (echo: msg).getBytes(); DatagramPacket responsePacket new DatagramPacket( response, response.length, packet.getSocketAddress()); socket.send(responsePacket); }UDP的场景其实比很多人想的要广。DNS查询就是UDP视频直播的实时音视频流通常也是UDP因为丢几帧问题不大但延迟必须低游戏状态同步经常用UDP。面试里如果被问到UDP什么时候用不要只说不要求可靠的时候更准确的表述是能容忍偶发丢包、但必须低延迟的场景以及请求-响应模型简单到不需要连接的场景如DNS。3.4 从Java代码看TCP连接的关闭细节连接关闭这块是踩坑重灾区。我至少见过三次线上故障是因为关闭顺序不对导致的。正确的关闭顺序应该是先关闭输出流或调用shutdownOutput()再等待对方关闭输入流最后关闭Socket。为什么因为TCP是全双工的你调用close()会同时关闭读写方向如果此时读缓冲区里还有对方发来的数据就会被丢弃对方也会收到RST而不是正常的FIN触发异常。一个隐蔽的坑是在try-with-resources里同时声明BufferedReader和PrintWriter时代码块结束时两个流会依次关闭这通常没问题。但如果你的PrintWriter用了自动flush构造函数第二个参数为true而你又忘记调用socket.close()连接不会立刻释放只能等GC回收或操作系统超时。所以我个人的习惯是在代码块里显式调用shutdownOutput()发送FIN然后读取到EOF最后再让资源自动关闭。4. 从BIO到NIO再到Netty性能瓶颈的根源与三次范式演进4.1 BIO为什么说一个连接一个线程是不可持续的上面的ServerSocket模型就是一个最典型的BIO。它的问题用一句话说每个连接都需要一个独立的线程去阻塞等待读写线程是昂贵资源连接多了系统必然崩溃。这里要纠正一个常见的误区很多人以为BIO的性能差是因为多线程本身性能差其实不是。多线程是BIO唯一能拿出来的方案问题是线程在内核态和用户态之间切换、线程栈内存占用、以及大量线程阻塞在read上导致CPU空转这三重成本叠加起来让几千个连接就足以拖垮一台服务器。我自己以前压测过一个简单的BIO EchoServer开500个连接持续发送数据CPU直接跑到100%线程数暴涨到700多。这不是代码写得有问题而是模型天花板决定的。4.2 NIO用事件驱动解决线程不该为等待买单的问题NIONon-blocking I/O的核心思路完全变了一个线程可以同时管理成千上万个连接它不再阻塞在某个连接的读写上而是通过Selector统一监听所有注册的通道哪条通道有数据可读/可写就去处理哪条。这个模型用一句话概括把等我变成了我先做别的你有数据了叫我。这就引出了Java NIO三大件Buffer数据读写的中转容器读写操作都需要经过它。Channel面向连接的通道比传统流更底层支持双向操作。Selector多路复用器监听多个通道的事件。NIO服务端的核心骨架大致是Selector selector Selector.open(); ServerSocketChannel serverChannel ServerSocketChannel.open(); serverChannel.bind(new InetSocketAddress(8080)); serverChannel.configureBlocking(false); serverChannel.register(selector, SelectionKey.OP_ACCEPT); while (true) { selector.select(); // 阻塞等待就绪事件 IteratorSelectionKey keys selector.selectedKeys().iterator(); while (keys.hasNext()) { SelectionKey key keys.next(); keys.remove(); if (key.isAcceptable()) { SocketChannel client serverChannel.accept(); client.configureBlocking(false); client.register(selector, SelectionKey.OP_READ); } else if (key.isReadable()) { // 从channel中读取数据到buffer } } }这里最核心也最容易搞错的一点是configureBlocking(false)必须在注册之前设置。如果把SocketChannel设成阻塞模式再注册到Selectorselect()就会直接返回而且什么都不通知你程序看起来正常但实际已死锁。这个坑我当年就踩过排查了一下午才发现是创建顺序的问题。NIO还有一个被很多人忽略的细节Buffer的读写翻转。你要先buffer.clear()再channel.read(buffer)读完之后必须buffer.flip()再buffer.get()否则位置指针不对读到的全是脏数据。这跟BIO流的编程习惯差异极大导致很多人看NIO代码觉得绕。4.3 IO多路复用的底层支撑select、poll与epoll面试时经常会连环追问Java NIO的Selector底层是什么这时候就要谈到Linux的select、poll和epoll了。简单说select和poll是早期方案它们的问题是每次调用都要把全部文件描述符从用户态拷贝到内核态内核线性扫描一遍找出就绪的事件再拷贝回来。连接数越多开销越大而且select还有1024个文件描述符的上限。epoll是Linux下的高性能方案它做了三件事用户态只做一次注册内核用事件回调的方式记住关注的连接不需要每次全量拷贝。就绪事件直接通过内存映射mmap返回给用户态省去拷贝。没有连接数上限只受系统内存限制。用生活化的类比select/poll像是一个保安每隔一段时间把所有房间的门都敲一遍问有没有人需要外出不管有没有人回应他都要巡一圈epoll则像是每个房间门口装了感应器保安只去感应器响了的地方处理。Java NIO的Selector在不同操作系统上底层实现不同Linux 2.6之后用epollmacOS用kqueueWindows用IOCP。这也是为什么网上很多NIO Demo在mac上跑和Linux上跑表现不一样的原因之一。4.4 Netty为什么它是Java网络编程的最终答案既然有了NIO为什么实际项目里大家几乎不用原生NIO而是一窝蜂上Netty答案是原生NIO的API设计太反人类边界条件太容易写错。你在原生NIO里要自己处理的事情包括但不限于半包/粘包问题没有现成协议解码器你得自己缓存半包数据。写完数据后部分写入的场景channel.write()可能只写了一半你需要记录剩余位置并关注OP_WRITE事件。空闲连接检测需要自己实现心跳机制。断线重连、优雅停机、线程模型调优——这些全都是裸NIO的坑。Netty把这些全部封装好了它提供了ByteBuf替代ByteBuffer不需要手动flip、ChannelHandler流水线机制、内置HTTP/WebSocket/ProtoBuf等几十种编解码器、自带可控的线程池模型。Netty把正确性和易用性同时给你了代价是你得学它的抽象概念。从学习路线上说我建议不要一上来就啃Netty。先把BIO写透再把NIO的Selector流程跑通一次理解OP_ACCEPT、OP_READ、OP_WRITE这三个事件是什么再去看Netty的EventLoopGroup和ChannelPipeline就会觉得豁然开朗。5. 网络编程避坑实录粘包、拆包、线程模型与十万级并发问题5.1 粘包和拆包原理、演示与解决方法只要用TCP做协议传输就绕不开粘包和拆包。这不是Java特有的问题是TCP字节流特性决定的。TCP是流式协议没有消息边界。发送方调用了两次send()接收方可能一次read()就把两段数据全读出来了这叫粘包发送方只调用了send()一次接收方可能两次read()才读完这叫拆包。原因也很好理解TCP底层有缓冲区、MSS分段、Nagle算法数据在传输过程中会被合并或拆分接收方只能按字节流的顺序去读无法知道哪几个字节是一整条消息。解决这个问题有四种常见方案固定长度每个消息都定长比如总是发64字节不足补零。实现最简单但空间浪费大。分隔符以\n或自定义特殊字符作为消息结束标志。实现容易但正文里如果出现分隔符需要转义而且效率一般。长度字段消息头里带一个字节长度字段接收方先读长度再读对应字节数。这是最通用的方案Netty的LengthFieldBasedFrameDecoder就是这个原理。自定义协议结合版本号、消息类型、长度、正文、校验码适用于复杂场景。面试里问你如何解决粘包你如果能当场画出一个消息头结构前4字节是长度、后面是正文再说明如何在接收缓冲区累积数据、按长度截取、剩余部分留给下次处理基本就能拿满分。5.2 线程模型选择BIO的线程池改良、NIO的Reactor、Netty的EventLoop很多初级程序员写过BIO加线程池的服务端以为这就高枕无忧了ExecutorService pool Executors.newFixedThreadPool(8); while (true) { Socket socket serverSocket.accept(); pool.submit(() - handle(socket)); }这个模型比串行好但它仍然是BIO模型——阻塞型IO的线程池改良。核心问题依旧存在如果客户端连接数超过线程数多余的连接只能排队每个连接即使空闲也要占住一个线程。它只解决了并发处理的问题没有解决大量空闲连接的问题。Reactor模型才是NIO的正确打开方式。它的核心是事件分发器Reactor监听事件然后把事件分发给对应的处理器。用生活类比就是前台只有一个接待员Reactor线程来了任何客人的请求连接事件、读事件、写事件他都按类别转给对应的业务专员Handler处理自己不阻塞在具体业务上。Netty的线程模型就是Reactor的变体BossGroup通常是1个线程负责处理OP_ACCEPT接收连接后把SocketChannel注册给WorkerGroup。WorkerGroup通常是CPU核数×2负责处理读写事件执行ChannelHandler链。每个Channel在整个生命周期内由一个固定的EventLoop线程处理所以业务Handler中不需要考虑多线程同步问题。理解这套模型之后再去看Netty源码你会发现所谓高性能的核心不是魔法而是合理地把阻塞操作从IO线程中剥离、最小化线程切换、最大化内存复用。5.3 实时通信场景如何实现一个带心跳的Socket应用如果要在两个Java应用之间维持长连接做实时通信一个永远绕不开的问题是怎么判断连接还活着TCP本身没有应用层心跳虽然SO_KEEPALIVE开关可以做最基础的探活但它默认两个小时的探测周期在业务场景下完全不适用。通用的做法是应用层心跳客户端每隔固定时间比如30秒发送一个心跳包Ping。服务端收到心跳后更新该连接的最后活跃时间并回复一个Pong。服务端启动一个定时任务周期性扫描所有连接如果某个连接的最后活跃时间超过阈值比如90秒就主动关闭它。在Netty中这个功能直接用IdleStateHandler就能实现ChannelPipeline pipeline ch.pipeline(); // 读空闲60秒、写空闲30秒、全空闲0秒不检测时触发事件 pipeline.addLast(new IdleStateHandler(60, 30, 0)); pipeline.addLast(new HeartbeatHandler());在HeartbeatHandler里重写userEventTriggered方法判断如果是IdleStateEvent且为READER_IDLE就关闭连接或发送心跳。这比自己在每个业务线程里维护时间戳要优雅得多。5.4 千万级并发前你一定会踩的内存和线程问题跟很多做高并发中间件的朋友聊下来发现一个共性在线程模型设计上都还好最容易爆的是内存。Typical的NIO模型下每个连接都会分配两个缓冲区读缓冲区和写缓冲区。假设每个缓冲区分配32KB10万个连接就是6.4GB的内存消耗直接把你机器打爆。这就是为什么NIO编程里必须谨慎控制缓冲区的分配时机和大小必须对内存池化复用——这恰恰是Netty的PooledByteBufAllocator在做的事。它在堆外内存里划出一大块区域重复使用避免每个连接都新建缓冲区。还有一个低级但常见的坑Nagle算法与延迟ACK的联动导致小包延迟。默认TCP开启了Nagle它会合并小包减少网络传输次数但如果服务端又开启了TCP_DELAY_ACK就会出现一端等凑包、一端等合包的僵持。低延迟场景下可以关闭NaglesetTcpNoDelay(true)但如果你在做高吞吐批处理打开Nagle反而是好事。没有绝对的对错只有场景匹配。6. 高频面试考点串讲从三次握手到Netty的追问链路6.1 把八股文变成理解链Java面试里网络编程的常见问题其实并不是零散的它们之间有一条完整的追问链路。拿这组问题来验证一下你的理解Q: TCP为什么需要三次握手A: 确认双方收发能力 同步初始序列号。Q: TCP四次挥手为什么比握手多一次A: 双工连接需要分别关闭两个方向。Q: 大量TIME_WAIT怎么处理A: 减少主动断开、开启tcp_tw_reuse在合适的场景下、应用层连接复用。Q: HTTP和TCP是什么关系A: HTTP是应用层报文格式TCP是底层的可靠传输通道HTTP可以复用TCP连接。Q: 怎么定位一个Java网络应用连接数打满但不报错的问题A: 用ss -ant看连接状态用jstack看线程阻塞位置用jstat看GC判断是连接泄漏还是线程阻塞。你自己回答一遍就能发现如果前面基础概念是理解的而不是背的这些问题全都能串起来。6.2 手写一个最简单的HTTP服务器来验证理解如果面试官让你手写一个Socket版HTTP服务器你该怎么办其实只需要三件事先读HTTP请求头找到路径按需组织响应体把状态行、响应头、空行、响应体按顺序写回Socket。ServerSocket serverSocket new ServerSocket(8080); while (true) { try (Socket socket serverSocket.accept()) { BufferedReader in new BufferedReader(new InputStreamReader(socket.getInputStream())); PrintWriter out new PrintWriter(socket.getOutputStream(), true); String requestLine in.readLine(); System.out.println(请求行: requestLine); // 读掉请求头直到空行 String header; do { header in.readLine(); } while (header ! null !header.isEmpty()); String body htmlbodyh1Hello, Java Network/h1/body/html; out.println(HTTP/1.1 200 OK); out.println(Content-Type: text/html; charsetutf-8); out.println(Content-Length: body.getBytes(UTF-8).length); out.println(); out.println(body); } }这里注意一个坑Content-Length必须算字节数而不是字符串长度。很多人写中文页面时用body.length()结果浏览器一直处于加载状态就是因为Content-Length比实际字节数小浏览器等不到剩余数据。这个小Demo跑通之后你对HTTP和Socket的关系理解会上一个台阶。6.3 从会用到会调优JVM和操作系统层面的网络参数最后补充几个实战调优时大概率会用到的参数这也是从会用API迈向能解决生产问题的分水岭。JVM层面-Djava.net.preferIPv4Stacktrue在双栈环境下强制走IPv4避免IPv6导致的连接异常。-Dsun.net.client.defaultConnectTimeout3000和-Dsun.net.client.defaultReadTimeout3000给URLConnection体系设置默认超时时间否则可能无限期等待。操作系统层面Linuxnet.core.somaxconnServerSocket的backlog参数对应的系统实际队列上限。很多人调用new ServerSocket(port, 50)以为队列有50但系统若配成128你会发现没有变化反过来系统若默认16你的50也无效。net.ipv4.ip_local_port_range客户端可用端口范围高并发连接打满时如果端口耗尽会报Cant assign requested address。Java层面Socket关键参数socket.setTcpNoDelay(true); // 关闭Nagle降低延迟 socket.setKeepAlive(true); // 开启TCP探活但注意默认时间很长 socket.setSoTimeout(3000); // 读超时防止线程无限阻塞 socket.setSoLinger(true, 0); // 关闭时立即发送RST而非FIN慎用这些参数没有绝对的最优配置关键是搞清楚每个参数影响哪一层的哪个行为然后针对你的业务场景做取舍。比如低延迟游戏服务器会关Nagle、开TCP_NODELAY、把SO_TIMEOUT设短但同步HTTP客户端如果设了短读超时遇到慢接口就会频繁报错。7. 一条值得参考的Java网络编程学习路线如果你看完这篇还是不知道从哪里下手我按自己的经验给你一条相对平滑的路径。第一阶段跑完一次最原始的Socket通信。把上面那对EchoServer和EchoClient复制下来跑通然后改动几个点尝试连续发送100条消息看服务端怎么收加上setSoTimeout(1000)设置读超时看客户端什么表现关闭Nagle抓包对比关闭前后IP包的变化。这个阶段的目标是建立连接、读、写、关闭的直觉。第二阶段实现一个单文件HTTP服务器。不要依赖Spring Boot纯Java实现支持GET/POST能解析查询参数能返回JSON。这个练习会逼你把HTTP报文的格式、Content-Length、字符集编码这些细节全踩一遍。第三阶段手写一个带线程池和事件循环的NIO聊天室。这是我最推荐的过渡项目。要求支持多客户端同时连接、广播消息、记录上线下线日志。你用原生NIO能写出来并解决粘包问题Netty就不远了。第四阶段项目里用Netty实现一个自定义协议网关。定义自己的消息格式版本号类型长度正文实现编解码器加心跳加断线重连。做完这个你简历上写熟悉Java网络编程和高性能通信框架才算有底气。我个人在实际项目里的体会是面试问网络编程本质上不是考你记住了多少API而是考你在面对数据不确定、连接不确定、失败不确定的分布式环境时能不能做出正确的设计判断。这需要的是对网络模型底层逻辑的把握而不是对代码片段的记忆。真心建议你花一个周末把三次握手、粘包拆包、Reactor模型这三件事亲手验证一遍跑一堆Demo、抓一次包、压一次测这比刷一百道八股文都有用。