很多刚接触Java网络编程的朋友一上来就被各种概念砸得头晕Socket、ServerSocket、BIO、NIO、Netty、粘包半包……网上教程要么太浅只给个Echo例子就没了要么太深直接甩源码分析。所以我一直想写一份“精简版”的Java网络编程梳理把最核心的脉络和真正的实战要点挑出来。这份内容是我在多个后端项目里反复用到的经验总结适合刚入门的新手快速建立知识框架也适合写过一些代码但总感觉“糊里糊涂”的读者查漏补缺。先声明这不是一本系统教材而是把真正会决定你项目成败的那几个关键点拉出来讲透。1. 内容整体设计与思路拆解1.1 为什么需要一份“精简版”网络编程指南Java网络编程的内容其实非常庞杂从最底层的TCP/IP协议到JDK自带的Socket、ServerSocket再到NIO、NIO.2最后还有各种封装好的框架。如果按教科书顺序学很多人两个月都走不到能实际写业务的那一步。我见过太多人卡在同一个问题明明把Socket的API背熟了到了真实项目中一听“百万连接”“高并发”又不知道怎么动手。精简版的定位不是省略知识而是先画出主干。主干就三条一是搞清楚TCP连接的本质二是掌握阻塞I/O和非阻塞I/O的区别三是知道在什么场景下该用什么工具。三条主干打通之后你再去读Netty源码、看操作系统网络原理方向都不会跑偏。所谓“精简”是把那些三个月后才用得上的细节暂时往后放。1.2 这份内容适合谁能解决什么问题如果你是刚学完Java基础语法想看看网络编程到底怎么玩这份内容可以帮你快速上手一个能跑通的Socket服务端。如果你已经写过简单的Socket程序但总觉得性能不行、并发一高就崩溃这份内容会把线程模型和NIO的差异讲清楚让你明白问题出在哪。如果你正在做微服务、RPC框架、实时消息推送之类的项目这里关于粘包拆包、消息边界的处理经验可以直接复用。一句话概括看完之后你能独立用Java实现一个能处理多客户端连接的TCP服务端并且知道在什么情况下应该转向NIO或Netty而不是在所有场景里都硬写BIO。1.3 核心知识地图先看树再看叶我建议用一张脑图来建立整体视角但在这里只能用文字描述。整个Java网络编程的知识树大概是这样的最底层是传输层协议我们主要关心TCP和UDP往上是JDK提供的网络API分三类——传统BIO、NIO以及NIO.2、基于NIO的框架Netty等再往上是应用层协议如HTTP、WebSocket这些通常用现成框架处理很少手写。在这棵树里真正需要投入精力的是“传输层特点”和“I/O模型”这两根枝干。前者决定了你处理数据时要考虑粘包、拆包、长连接、心跳等问题后者决定了程序在高并发下的行为表现。HTTP请求这类应用层协议反而因为框架封装得太好不需要你深入了解。先明确这个分界学习效率会高很多。2. 核心细节解析与实操要点2.1 写给写代码的人看的TCP三次握手与四次挥手说到网络编程绕不开TCP协议。但我不打算从教科书角度讲而是从排查问题的角度讲。为什么连接建立需要三次握手因为要确认双方的接收和发送能力都没问题。这对应到代码里就是你调用new Socket(host, port)时操作系统会在内核层面完成三次握手你的程序只是等待结果。如果连接超时要么是服务端没监听要么是防火墙把包丢了要么是IP和端口配置错了。四次挥手则对应连接的关闭。这里有个很实用的点主动关闭连接的一方会进入TIME_WAIT状态持续约2*MSL时间默认大概60秒。如果服务端频繁主动关闭连接你会看到大量TIME_WAIT状态的连接堆积。我遇到过有朋友写了一个简单的HTTP服务器每处理完一个请求就主动关闭Socket结果压测时端口被TIME_WAIT占满新连接建不了。解决思路很简单让客户端主动关闭或者调整系统参数复用连接。这些内容教科书会讲但没做过压测的人根本不知道它会成为线上故障。2.2 BIO模型为什么“慢”阻塞点到底在哪BIOBlocking I/O是Java最传统的网络模型ServerSocket.accept()会阻塞线程InputStream.read()也会阻塞线程。很多人觉得BIO慢其实是误解。单看一次请求的响应速度BIO不一定比NIO慢真正的瓶颈是它阻塞了线程。举个例子你用BIO开一个服务端来了100个并发连接就得有100个线程去处理每个线程默认要占1MB左右的栈内存同时线程上下文切换开销也非常可观。更麻烦的是大部分网络连接并不是一直在传数据。比如一个移动端App和服务端保持长连接可能几十秒才发一个心跳包。但在BIO模型下这条连接也必须占用一个线程来等待读取线程大部分时间都在阻塞状态资源利用率极低。这就是BIO“慢”的真相它不是处理慢而是在连接数上去之后线程资源被无效等待吃光了。理解了这一点你就明白为什么要引入NIO。2.3 最简ServerSocket实现及参数选择先别急着上NIOBIO虽然不适合高并发但作为入门和调试工具非常方便。一个最简的TCP服务端代码核心就几十行。创建ServerSocket后设置一个合理端口然后循环调用accept()获取客户端连接。注意三点第一accept()方法会阻塞当前线程所以必须放到子线程或者使用线程池来处理每个连接第二setSoTimeout()可以用来控制accept()和read()的阻塞超时时间避免线程永久挂死第三setReuseAddress(true)可以在服务端重启时避免“Address already in use”的报错这在开发调试时非常有用。public class SimpleBioServer { public static void main(String[] args) throws IOException { ServerSocket serverSocket new ServerSocket(); serverSocket.setReuseAddress(true); serverSocket.bind(new InetSocketAddress(8080)); System.out.println(server started on 8080); while (true) { Socket socket serverSocket.accept(); // 必须单独处理否则只能处理一个客户端 new Thread(() - handle(socket)).start(); } } private static void handle(Socket socket) { try (BufferedReader in new BufferedReader(new InputStreamReader(socket.getInputStream())); PrintWriter out new PrintWriter(socket.getOutputStream(), true)) { String line; while ((line in.readLine()) ! null) { System.out.println(receive: line); out.println(echo: line); } } catch (IOException e) { e.printStackTrace(); } finally { try { socket.close(); } catch (IOException ignored) {} } } }这段代码能用但千万别直接拿去扛生产流量。因为每来一个连接就new Thread线程数会随着连接数线性增长。这里我习惯用线程池把连接数控制住比如Executors.newFixedThreadPool(200)。即使这样也只是缓解不是根治。明白了BIO的写法之后再去看NIO你会更容易理解它为什么要引入Selector。3. 实操过程与核心环节实现3.1 线程池改造从串行到多线程的坑接上面的例子把new Thread改成线程池后容易踩一个坑如果连接空闲数量超过线程池核心线程数处理任务就会排队。想象一下客户端和服务端建立连接后一直不出声这时又来了一个新的活跃连接处理这个活跃连接的任务可能排在很多空闲连接的任务后面造成响应延迟。所以在线程池方案里要么不给空闲连接设置很长的超时要么把空闲连接及时关闭。还有一种做法是每个连接启动时读取数据的线程就阻塞在read()上这不是任务排队能解决的。所以BIO线程池只适合连接数少、且大多数连接都短命的场景比如内网工具类的一次性请求。如果长连接很多还是老老实实走NIO。我在一个内部管理系统里用过BIO线程池连接数稳定在几十个工作得很好一旦涨到几百上千延迟和CPU占用就明显上来了。3.2 NIO核心组件Buffer、Channel、Selector怎么配合NIO的核心组件就三个Buffer缓冲区、Channel通道、Selector选择器。用个生活类比Channel像一条水管数据在水管里流但不能像流一样直接读写必须把水灌进Buffer这个桶里再处理。Selector则像一个电话接线员它同时盯着很多条电话线哪条线有响动有数据到达就去接哪条线。这样一个线程就能管理成千上万条通道。具体到代码层面一套典型流程是创建ServerSocketChannel并配置为非阻塞注册到Selector上监听OP_ACCEPT事件当事件触发时接受连接并把对应的SocketChannel也注册到同一个Selector上监听OP_READ事件然后在循环里通过selector.select()获取就绪的通道集合逐个处理。整个过程都在一个线程内完成不再为每个连接分配线程。这里有个特别容易被忽略的细节Buffer有四种状态分别是position、limit、capacity还涉及flip、clear、compact等操作。很多人刚写NIO时忘了在读完数据后调用clear()重设Buffer位置导致下一次读不了新数据甚至会读到脏数据。我的建议是刚开始练习时可以把读写Buffer的代码单独抽成方法然后多打日志观察position和limit的变化等完全掌握了再合并写。3.3 用NIO实现一个最简Echo Server写一个最简单的NIO Echo Server核心代码在150行左右。我贴出要点完整代码逻辑是这样主循环里selector.select()拿到IteratorSelectionKey如果是OP_ACCEPT就完成新连接的注册如果是OP_READ就从通道里读数据再写回通道。public class NioEchoServer { public static void main(String[] args) throws IOException { Selector selector Selector.open(); ServerSocketChannel serverChannel ServerSocketChannel.open(); serverChannel.configureBlocking(false); serverChannel.socket().bind(new InetSocketAddress(8080)); serverChannel.register(selector, SelectionKey.OP_ACCEPT); ByteBuffer buffer ByteBuffer.allocate(64); while (true) { selector.select(); IteratorSelectionKey keyIterator selector.selectedKeys().iterator(); while (keyIterator.hasNext()) { SelectionKey key keyIterator.next(); keyIterator.remove(); if (key.isAcceptable()) { SocketChannel client serverChannel.accept(); client.configureBlocking(false); client.register(selector, SelectionKey.OP_READ); } else if (key.isReadable()) { SocketChannel client (SocketChannel) key.channel(); buffer.clear(); int bytesRead client.read(buffer); if (bytesRead -1) { key.cancel(); client.close(); } else { buffer.flip(); client.write(buffer); } } } } } }注意两个细节第一selectedKeys()返回的集合在用完后要remove否则这个Key会一直留在集合里下次select()还会重复处理这是新手最容易崩溃的一个Bug第二如果read()返回-1说明客户端关闭了连接要记得取消Key并关闭通道否则这个无效连接会一直在Selector里挂着白白浪费资源。这段代码虽然简单但包含了NIO的基本骨架后面不管去看Netty源码还是自己封装都是在这个思路上做扩展。3.4 性能对比与选型建议BIO、NIO、Netty到底怎么选直接给结论在连接数不超过几百、并发不高的情况下BIO配合线程池完全够用代码更直观维护成本低。一旦连接数上千或者你有大量长连接需要保持NIO是必然选择。NIO虽然写起来啰嗦但避免了线程膨胀问题。如果你要写生产级的高并发服务我建议直接用Netty因为Netty已经把NIO的复杂细节处理得很好了比如ByteBuf的内存池、断线重连、读写超时、Pipeline处理器这些要是全自己用NIO实现工作量非常大。我用一个简单的表格说明方案线程模型适用场景维护成本推荐指数BIO 线程池每连接一线程小型系统、内部工具低连接数少的场景原生NIOSelector单线程或多线程中等规模长连接高想深入学习时NettyReactor多线程高并发生产环境中绝大多数生产项目当初我在一个物联网项目里用原生NIO实现了几千个设备的长连接代码写得很痛苦光处理空轮询、半包、拆包就花了很多时间。后来换到Netty这些问题的解决方案都是现成的。所以我的建议是如果你是学习者NIO值得好好研究它是理解后面所有框架的基石如果你是做业务直接站在Netty肩膀上更明智。4. 常见问题与排查技巧实录4.1 端口占用、连接超时的典型排查思路我在帮人排查问题时发现非常简单的基础问题反而出现频率最高。比如“端口被占用”报错BindException: Address already in use。最简单的排查就是执行netstat -ano | grep 端口号看是哪个进程占用了端口或者直接用lsof -i:端口。如果是服务端主动断开后短时间内重启报这个错多半是没有设置SO_REUSEADDR加上系统TIME_WAIT状态还没消失。连接超时又分两种connect timed out和read timed out。前者是TCP握手都没成功需要检查网络通不通、防火墙、服务端是否监听、IP端口是否正确。后者是连接建立了但服务端迟迟不返回数据需要去看服务端是否线程阻塞、是否数据库查询卡住、是否发生了死锁。很多人一看到超时就去调参数其实先确认故障层比调参数重要得多。4.2 粘包与拆包TCP的“流”本质才是根源TCP是流式协议消息在TCP层没有天然边界。你调用一次send发送“hello world”接收方可能一次read就拿到全部数据也可能分两次、三次才能拿全。反过来你连续发送两条消息接收方可能一次read就把两条数据一起读到这就是粘包也可能一条消息被拆成多次read才读完这就是拆包。要解决粘包问题我常用的办法有四种固定消息长度简单但浪费空间使用特殊分隔符比如\n或\r\n但业务数据里要避免出现这些字符在消息头里携带长度信息的长度字段法这是业界最常用也最可靠或者使用JSON、Protobuf这类自带长度信息的格式。我个人最推荐的是“长度字段法”因为它的兼容性和扩展性都最好。4.3 半包处理与消息边界的实战经验半包和拆包其实是一码事只是拆包的粒度更细。举个例子我用长度字段法发一条消息4个字节表示长度后跟实际数据。接收方第一次可能只读到长度字段的前2个字节后面数据还没到。这种情况下你以为读取了足够数据实则没有。很多NIO初学者的代码就崩在这直接用一个固定大小的Buffer去接收结果消息长度超过Buffer被强行截断。正确的姿势是把数据积累到一个可扩容的缓冲区里每次读到新数据就检查缓冲区的字节数是否足够解析出一个完整的消息长度字段实际内容。如果不够就继续等待如果够了就切出一个完整消息剩余字节留给下一条消息。这部分代码如果自己写容易出边界Bug所以我特别建议大家用Netty的ByteBuf配合自定义ByteToMessageDecoder框架会自动处理半包累积问题你只需要专注在“如何从字节流中解析出一条完整消息”。4.4 新手最容易踩的5个坑亲测有效第一把Socket流当作“发一条消息收一条消息”的同步请求响应来用。TCP没有消息边界必须自己设计消息格式。第二在NIO的OP_READ事件里读取数据后忘记处理字节数不够的情况直接尝试解析导致解析失败。第三用SetString或者MapString, Socket保存连接时不考虑并发导致多个线程同时操作连接集合。第四关闭连接时只关Socket不关输入输出流或反过来导致资源泄漏。第五把心跳机制当成可选项结果死连接占满资源服务端实际还在运行但客户端早已断网。这里要专门说一下心跳。很多人在开发环境一切正常一到生产环境就发现连接假死客户端进程还在服务端也不报错但数据就是互发不通。本质是中间路由或防火墙清理了空闲连接而两端一无所知。解决方式很简单客户端定期发送心跳包服务端设置空闲超时超过时间没有收到心跳就主动关闭连接。Netty里有个IdleStateHandler专门做这件事比自己写省心很多。4.5 经验心得复杂问题先“简化复现”排查网络问题最高效的方法不是看代码而是先简化复现。把业务逻辑剥离只留下一个最简的客户端和服务端看数据能不能正常收发。如果简化的例子能跑通问题就一定出在业务层或者中间层比如序列化、线程池、代理。如果简化例子也复现了问题那就是底层传输或框架使用方式有问题。我曾经排查过一个诡异的延迟问题简化之后发现是客户端所在的服务器网卡开启了某项节能特性不是Java代码的问题。这种问题如果只盯着代码永远找不到答案。另外多利用系统命令辅助排查ping测网络连通性telnet测端口通不通tcpdump抓包看协议交互。Java包里java.net的API只暴露了一部分信息有时候你觉得代码没问题但实际网络包早就丢了。用抓包工具一看立刻真相大白。掌握了这些排查手段你的网络编程能力才算真正完整。5. 后续可以怎么扩展关于扩展方向我特别建议两点。一是把上面的NIO代码改成多线程Reactor模型一个Boss线程专门负责accept多个Worker线程负责read和write然后对比一下和单线程模型在吞吐量上的差异。二是尝试用Netty重写Echo Server再把自定义协议解析加上体会一下框架帮你解决的问题。不用贪多真正写一遍你之前看过的概念才会变成肌肉记忆。最后再说一个小技巧吧是我在实际项目中养成的习惯网络通信的日志一定要把每条消息的字节数和十六进制内容打出来。调试粘包和拆包时这两项信息几乎能解决90%的问题。不要只打印转成字符串后的内容因为不可见字符会被你忽略。用十六进制看原始字节消息边界到底在哪、哪个字节被吞了一目了然。这个习惯帮我节省了大量排查时间也分享给你。
很多刚接触Java网络编程的朋友一上来就被各种概念砸得头晕Socket、ServerSocket、BIO、NIO、Netty、粘包半包……网上教程要么太浅只给个Echo例子就没了要么太深直接甩源码分析。所以我一直想写一份“精简版”的Java网络编程梳理把最核心的脉络和真正的实战要点挑出来。这份内容是我在多个后端项目里反复用到的经验总结适合刚入门的新手快速建立知识框架也适合写过一些代码但总感觉“糊里糊涂”的读者查漏补缺。先声明这不是一本系统教材而是把真正会决定你项目成败的那几个关键点拉出来讲透。1. 内容整体设计与思路拆解1.1 为什么需要一份“精简版”网络编程指南Java网络编程的内容其实非常庞杂从最底层的TCP/IP协议到JDK自带的Socket、ServerSocket再到NIO、NIO.2最后还有各种封装好的框架。如果按教科书顺序学很多人两个月都走不到能实际写业务的那一步。我见过太多人卡在同一个问题明明把Socket的API背熟了到了真实项目中一听“百万连接”“高并发”又不知道怎么动手。精简版的定位不是省略知识而是先画出主干。主干就三条一是搞清楚TCP连接的本质二是掌握阻塞I/O和非阻塞I/O的区别三是知道在什么场景下该用什么工具。三条主干打通之后你再去读Netty源码、看操作系统网络原理方向都不会跑偏。所谓“精简”是把那些三个月后才用得上的细节暂时往后放。1.2 这份内容适合谁能解决什么问题如果你是刚学完Java基础语法想看看网络编程到底怎么玩这份内容可以帮你快速上手一个能跑通的Socket服务端。如果你已经写过简单的Socket程序但总觉得性能不行、并发一高就崩溃这份内容会把线程模型和NIO的差异讲清楚让你明白问题出在哪。如果你正在做微服务、RPC框架、实时消息推送之类的项目这里关于粘包拆包、消息边界的处理经验可以直接复用。一句话概括看完之后你能独立用Java实现一个能处理多客户端连接的TCP服务端并且知道在什么情况下应该转向NIO或Netty而不是在所有场景里都硬写BIO。1.3 核心知识地图先看树再看叶我建议用一张脑图来建立整体视角但在这里只能用文字描述。整个Java网络编程的知识树大概是这样的最底层是传输层协议我们主要关心TCP和UDP往上是JDK提供的网络API分三类——传统BIO、NIO以及NIO.2、基于NIO的框架Netty等再往上是应用层协议如HTTP、WebSocket这些通常用现成框架处理很少手写。在这棵树里真正需要投入精力的是“传输层特点”和“I/O模型”这两根枝干。前者决定了你处理数据时要考虑粘包、拆包、长连接、心跳等问题后者决定了程序在高并发下的行为表现。HTTP请求这类应用层协议反而因为框架封装得太好不需要你深入了解。先明确这个分界学习效率会高很多。2. 核心细节解析与实操要点2.1 写给写代码的人看的TCP三次握手与四次挥手说到网络编程绕不开TCP协议。但我不打算从教科书角度讲而是从排查问题的角度讲。为什么连接建立需要三次握手因为要确认双方的接收和发送能力都没问题。这对应到代码里就是你调用new Socket(host, port)时操作系统会在内核层面完成三次握手你的程序只是等待结果。如果连接超时要么是服务端没监听要么是防火墙把包丢了要么是IP和端口配置错了。四次挥手则对应连接的关闭。这里有个很实用的点主动关闭连接的一方会进入TIME_WAIT状态持续约2*MSL时间默认大概60秒。如果服务端频繁主动关闭连接你会看到大量TIME_WAIT状态的连接堆积。我遇到过有朋友写了一个简单的HTTP服务器每处理完一个请求就主动关闭Socket结果压测时端口被TIME_WAIT占满新连接建不了。解决思路很简单让客户端主动关闭或者调整系统参数复用连接。这些内容教科书会讲但没做过压测的人根本不知道它会成为线上故障。2.2 BIO模型为什么“慢”阻塞点到底在哪BIOBlocking I/O是Java最传统的网络模型ServerSocket.accept()会阻塞线程InputStream.read()也会阻塞线程。很多人觉得BIO慢其实是误解。单看一次请求的响应速度BIO不一定比NIO慢真正的瓶颈是它阻塞了线程。举个例子你用BIO开一个服务端来了100个并发连接就得有100个线程去处理每个线程默认要占1MB左右的栈内存同时线程上下文切换开销也非常可观。更麻烦的是大部分网络连接并不是一直在传数据。比如一个移动端App和服务端保持长连接可能几十秒才发一个心跳包。但在BIO模型下这条连接也必须占用一个线程来等待读取线程大部分时间都在阻塞状态资源利用率极低。这就是BIO“慢”的真相它不是处理慢而是在连接数上去之后线程资源被无效等待吃光了。理解了这一点你就明白为什么要引入NIO。2.3 最简ServerSocket实现及参数选择先别急着上NIOBIO虽然不适合高并发但作为入门和调试工具非常方便。一个最简的TCP服务端代码核心就几十行。创建ServerSocket后设置一个合理端口然后循环调用accept()获取客户端连接。注意三点第一accept()方法会阻塞当前线程所以必须放到子线程或者使用线程池来处理每个连接第二setSoTimeout()可以用来控制accept()和read()的阻塞超时时间避免线程永久挂死第三setReuseAddress(true)可以在服务端重启时避免“Address already in use”的报错这在开发调试时非常有用。public class SimpleBioServer { public static void main(String[] args) throws IOException { ServerSocket serverSocket new ServerSocket(); serverSocket.setReuseAddress(true); serverSocket.bind(new InetSocketAddress(8080)); System.out.println(server started on 8080); while (true) { Socket socket serverSocket.accept(); // 必须单独处理否则只能处理一个客户端 new Thread(() - handle(socket)).start(); } } private static void handle(Socket socket) { try (BufferedReader in new BufferedReader(new InputStreamReader(socket.getInputStream())); PrintWriter out new PrintWriter(socket.getOutputStream(), true)) { String line; while ((line in.readLine()) ! null) { System.out.println(receive: line); out.println(echo: line); } } catch (IOException e) { e.printStackTrace(); } finally { try { socket.close(); } catch (IOException ignored) {} } } }这段代码能用但千万别直接拿去扛生产流量。因为每来一个连接就new Thread线程数会随着连接数线性增长。这里我习惯用线程池把连接数控制住比如Executors.newFixedThreadPool(200)。即使这样也只是缓解不是根治。明白了BIO的写法之后再去看NIO你会更容易理解它为什么要引入Selector。3. 实操过程与核心环节实现3.1 线程池改造从串行到多线程的坑接上面的例子把new Thread改成线程池后容易踩一个坑如果连接空闲数量超过线程池核心线程数处理任务就会排队。想象一下客户端和服务端建立连接后一直不出声这时又来了一个新的活跃连接处理这个活跃连接的任务可能排在很多空闲连接的任务后面造成响应延迟。所以在线程池方案里要么不给空闲连接设置很长的超时要么把空闲连接及时关闭。还有一种做法是每个连接启动时读取数据的线程就阻塞在read()上这不是任务排队能解决的。所以BIO线程池只适合连接数少、且大多数连接都短命的场景比如内网工具类的一次性请求。如果长连接很多还是老老实实走NIO。我在一个内部管理系统里用过BIO线程池连接数稳定在几十个工作得很好一旦涨到几百上千延迟和CPU占用就明显上来了。3.2 NIO核心组件Buffer、Channel、Selector怎么配合NIO的核心组件就三个Buffer缓冲区、Channel通道、Selector选择器。用个生活类比Channel像一条水管数据在水管里流但不能像流一样直接读写必须把水灌进Buffer这个桶里再处理。Selector则像一个电话接线员它同时盯着很多条电话线哪条线有响动有数据到达就去接哪条线。这样一个线程就能管理成千上万条通道。具体到代码层面一套典型流程是创建ServerSocketChannel并配置为非阻塞注册到Selector上监听OP_ACCEPT事件当事件触发时接受连接并把对应的SocketChannel也注册到同一个Selector上监听OP_READ事件然后在循环里通过selector.select()获取就绪的通道集合逐个处理。整个过程都在一个线程内完成不再为每个连接分配线程。这里有个特别容易被忽略的细节Buffer有四种状态分别是position、limit、capacity还涉及flip、clear、compact等操作。很多人刚写NIO时忘了在读完数据后调用clear()重设Buffer位置导致下一次读不了新数据甚至会读到脏数据。我的建议是刚开始练习时可以把读写Buffer的代码单独抽成方法然后多打日志观察position和limit的变化等完全掌握了再合并写。3.3 用NIO实现一个最简Echo Server写一个最简单的NIO Echo Server核心代码在150行左右。我贴出要点完整代码逻辑是这样主循环里selector.select()拿到IteratorSelectionKey如果是OP_ACCEPT就完成新连接的注册如果是OP_READ就从通道里读数据再写回通道。public class NioEchoServer { public static void main(String[] args) throws IOException { Selector selector Selector.open(); ServerSocketChannel serverChannel ServerSocketChannel.open(); serverChannel.configureBlocking(false); serverChannel.socket().bind(new InetSocketAddress(8080)); serverChannel.register(selector, SelectionKey.OP_ACCEPT); ByteBuffer buffer ByteBuffer.allocate(64); while (true) { selector.select(); IteratorSelectionKey keyIterator selector.selectedKeys().iterator(); while (keyIterator.hasNext()) { SelectionKey key keyIterator.next(); keyIterator.remove(); if (key.isAcceptable()) { SocketChannel client serverChannel.accept(); client.configureBlocking(false); client.register(selector, SelectionKey.OP_READ); } else if (key.isReadable()) { SocketChannel client (SocketChannel) key.channel(); buffer.clear(); int bytesRead client.read(buffer); if (bytesRead -1) { key.cancel(); client.close(); } else { buffer.flip(); client.write(buffer); } } } } } }注意两个细节第一selectedKeys()返回的集合在用完后要remove否则这个Key会一直留在集合里下次select()还会重复处理这是新手最容易崩溃的一个Bug第二如果read()返回-1说明客户端关闭了连接要记得取消Key并关闭通道否则这个无效连接会一直在Selector里挂着白白浪费资源。这段代码虽然简单但包含了NIO的基本骨架后面不管去看Netty源码还是自己封装都是在这个思路上做扩展。3.4 性能对比与选型建议BIO、NIO、Netty到底怎么选直接给结论在连接数不超过几百、并发不高的情况下BIO配合线程池完全够用代码更直观维护成本低。一旦连接数上千或者你有大量长连接需要保持NIO是必然选择。NIO虽然写起来啰嗦但避免了线程膨胀问题。如果你要写生产级的高并发服务我建议直接用Netty因为Netty已经把NIO的复杂细节处理得很好了比如ByteBuf的内存池、断线重连、读写超时、Pipeline处理器这些要是全自己用NIO实现工作量非常大。我用一个简单的表格说明方案线程模型适用场景维护成本推荐指数BIO 线程池每连接一线程小型系统、内部工具低连接数少的场景原生NIOSelector单线程或多线程中等规模长连接高想深入学习时NettyReactor多线程高并发生产环境中绝大多数生产项目当初我在一个物联网项目里用原生NIO实现了几千个设备的长连接代码写得很痛苦光处理空轮询、半包、拆包就花了很多时间。后来换到Netty这些问题的解决方案都是现成的。所以我的建议是如果你是学习者NIO值得好好研究它是理解后面所有框架的基石如果你是做业务直接站在Netty肩膀上更明智。4. 常见问题与排查技巧实录4.1 端口占用、连接超时的典型排查思路我在帮人排查问题时发现非常简单的基础问题反而出现频率最高。比如“端口被占用”报错BindException: Address already in use。最简单的排查就是执行netstat -ano | grep 端口号看是哪个进程占用了端口或者直接用lsof -i:端口。如果是服务端主动断开后短时间内重启报这个错多半是没有设置SO_REUSEADDR加上系统TIME_WAIT状态还没消失。连接超时又分两种connect timed out和read timed out。前者是TCP握手都没成功需要检查网络通不通、防火墙、服务端是否监听、IP端口是否正确。后者是连接建立了但服务端迟迟不返回数据需要去看服务端是否线程阻塞、是否数据库查询卡住、是否发生了死锁。很多人一看到超时就去调参数其实先确认故障层比调参数重要得多。4.2 粘包与拆包TCP的“流”本质才是根源TCP是流式协议消息在TCP层没有天然边界。你调用一次send发送“hello world”接收方可能一次read就拿到全部数据也可能分两次、三次才能拿全。反过来你连续发送两条消息接收方可能一次read就把两条数据一起读到这就是粘包也可能一条消息被拆成多次read才读完这就是拆包。要解决粘包问题我常用的办法有四种固定消息长度简单但浪费空间使用特殊分隔符比如\n或\r\n但业务数据里要避免出现这些字符在消息头里携带长度信息的长度字段法这是业界最常用也最可靠或者使用JSON、Protobuf这类自带长度信息的格式。我个人最推荐的是“长度字段法”因为它的兼容性和扩展性都最好。4.3 半包处理与消息边界的实战经验半包和拆包其实是一码事只是拆包的粒度更细。举个例子我用长度字段法发一条消息4个字节表示长度后跟实际数据。接收方第一次可能只读到长度字段的前2个字节后面数据还没到。这种情况下你以为读取了足够数据实则没有。很多NIO初学者的代码就崩在这直接用一个固定大小的Buffer去接收结果消息长度超过Buffer被强行截断。正确的姿势是把数据积累到一个可扩容的缓冲区里每次读到新数据就检查缓冲区的字节数是否足够解析出一个完整的消息长度字段实际内容。如果不够就继续等待如果够了就切出一个完整消息剩余字节留给下一条消息。这部分代码如果自己写容易出边界Bug所以我特别建议大家用Netty的ByteBuf配合自定义ByteToMessageDecoder框架会自动处理半包累积问题你只需要专注在“如何从字节流中解析出一条完整消息”。4.4 新手最容易踩的5个坑亲测有效第一把Socket流当作“发一条消息收一条消息”的同步请求响应来用。TCP没有消息边界必须自己设计消息格式。第二在NIO的OP_READ事件里读取数据后忘记处理字节数不够的情况直接尝试解析导致解析失败。第三用SetString或者MapString, Socket保存连接时不考虑并发导致多个线程同时操作连接集合。第四关闭连接时只关Socket不关输入输出流或反过来导致资源泄漏。第五把心跳机制当成可选项结果死连接占满资源服务端实际还在运行但客户端早已断网。这里要专门说一下心跳。很多人在开发环境一切正常一到生产环境就发现连接假死客户端进程还在服务端也不报错但数据就是互发不通。本质是中间路由或防火墙清理了空闲连接而两端一无所知。解决方式很简单客户端定期发送心跳包服务端设置空闲超时超过时间没有收到心跳就主动关闭连接。Netty里有个IdleStateHandler专门做这件事比自己写省心很多。4.5 经验心得复杂问题先“简化复现”排查网络问题最高效的方法不是看代码而是先简化复现。把业务逻辑剥离只留下一个最简的客户端和服务端看数据能不能正常收发。如果简化的例子能跑通问题就一定出在业务层或者中间层比如序列化、线程池、代理。如果简化例子也复现了问题那就是底层传输或框架使用方式有问题。我曾经排查过一个诡异的延迟问题简化之后发现是客户端所在的服务器网卡开启了某项节能特性不是Java代码的问题。这种问题如果只盯着代码永远找不到答案。另外多利用系统命令辅助排查ping测网络连通性telnet测端口通不通tcpdump抓包看协议交互。Java包里java.net的API只暴露了一部分信息有时候你觉得代码没问题但实际网络包早就丢了。用抓包工具一看立刻真相大白。掌握了这些排查手段你的网络编程能力才算真正完整。5. 后续可以怎么扩展关于扩展方向我特别建议两点。一是把上面的NIO代码改成多线程Reactor模型一个Boss线程专门负责accept多个Worker线程负责read和write然后对比一下和单线程模型在吞吐量上的差异。二是尝试用Netty重写Echo Server再把自定义协议解析加上体会一下框架帮你解决的问题。不用贪多真正写一遍你之前看过的概念才会变成肌肉记忆。最后再说一个小技巧吧是我在实际项目中养成的习惯网络通信的日志一定要把每条消息的字节数和十六进制内容打出来。调试粘包和拆包时这两项信息几乎能解决90%的问题。不要只打印转成字符串后的内容因为不可见字符会被你忽略。用十六进制看原始字节消息边界到底在哪、哪个字节被吞了一目了然。这个习惯帮我节省了大量排查时间也分享给你。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
