简介面向Java网络编程初学者的一份Socket字节流传输示例解析内容聚焦基于TCP/IP协议的Socket通信与字节流处理帮助读者理解服务端如何监听端口、接收客户端数据并将其转换为十六进制字符串输出。资源以PDF形式提供全文共1个文件大小仅38KB方便移动端或电脑端随时查阅适合快速学习与复习。该资料已吸引2629人学习查看。文档以TalkServer4Byte服务端实现为主线涵盖ServerSocket初始化、accept阻塞等待连接、BufferedInputStream与DataInputStream装饰流的使用、逐字节读取与bytesToHexString方法转换、finally块中关闭Socket等关键环节同时扩展了客户端类的简单写法便于对照实践。通过阅读这份解析读者可掌握Java网络编程中字节流收发的核心思路为后续处理文本、图像及其他二进制数据打下基础。1. 一段老示例里的 Java socket 字节流能跑通但藏着四个隐患Java socket 字节流传输的示例网上能翻出一大堆但像这份把服务端、客户端、hex 转换完整凑齐的并不多。它来自一个 2016 年的教学样例服务端监听 5020 端口用 DataInputStream 逐字节读取客户端发来的数据转成十六进制字符串打印客户端从 System.in 读一个字节、发一个字节。对刚接触 Java 网络编程的人它最直接的价值是把 ServerSocket、accept、装饰流、资源关闭这条完整链路串起来拿来当 java 面试前复习 socket 编程的知识点也很合适。但我要先给你交个底这段代码在真实网络环境下跑半包粘包、available() 判断边界、异常被吞掉、finally 空指针这几点大概率会让你翻车。它适合当入门脚手架不适合直接搬进生产。2. 先看底层监听端口、阻塞 accept 与两层装饰流的分工2.1 ServerSocket 初始化与 accept 的阻塞语义new ServerSocket(port)这行代码做了两件事把 5020 端口绑定到本机网络接口然后让内核进入监听状态。一旦绑定成功后续到这个端口的 TCP 连接请求都会由操作系统转交给这个进程如果端口已经被别的进程占着构造函数会直接抛java.net.BindException。原示例里 catch 块是空实现异常信息一个字都不打这是我在第 5 章要重点说的第一个坑。accept()是阻塞方法调用线程会在那里挂起直到有客户端完成 TCP 握手。它返回的 Socket 是这条连接专用的通信端点负责实际的读写而 ServerSocket 本身不参与 IO只负责接客。示例里while (true)每 accept 一次就处理一个连接处理完 close再回到 accept 等下一个。这是最朴素的单线程连接模型——一个连接处理期间后面的连接全部在 accept 队列里排队。端口选型上5020 落在 1024-49151 的注册端口区间避开了 1024 以下需要特权的端口也没有撞上 3306、8080 这类常用服务端口教学演示是合理的。实际项目里我会把端口挪到配置文件或启动参数里不然换个环境就得改代码重编译。绑定端口前先用netstat -ano | findstr 5020Windows或lsof -i:5020Linux/macOS确认一下有没有被占用能省掉后面一堆排查时间。2.2 BufferedInputStream 与 DataInputStream 叠用的分工服务端拿到 Socket 之后先调用socket.getInputStream()拿原始网络流再叠两层装饰流。这个层级关系值得画清楚层级类在这份代码里的职责1SocketInputStream直接从 TCP 接收缓冲区取字节2BufferedInputStream默认 8KB 缓冲区减少系统调用次数3DataInputStream提供 readByte、readInt、readFully 等便捷方法4业务代码把字节转 hex 字符串并打印BufferedInputStream的价值在于底层网络流每次 read 都可能触发一次系统调用套上缓冲层后底层一次性多读一些字节放进内存上层再按需取用吞吐会好一些。DataInputStream在这里主要用到read(byte[])这个方法的语义是尽力读取 1 到数组长度个字节返回实际读取的字节数读到流末尾返回 -1。注意它不保证一定读满数组——这正是后面所有边界问题的源头。示例里数组长度是 1一次最多读一个字节所以不存在读不满的问题代码在该场景下是自洽的只是效率确实低。2.3 逐字节读取与 0xFF为什么要转成十六进制网络调试时最直观的做法是把字节流按 hex 输出一个字节对应两位十六进制比如 0x41 就是大写字母 A。bytesToHexString里的int v src[i] 0xFF是 Java 网络编程的必考点byte 在 Java 里是有符号的范围 -128 到 127直接拿负数去调Integer.toHexString会因为符号扩展输出ffffff80这样的 8 位长串和 0xFF 做与运算后强制回到 0-255 的无符号视角才能得到干净的两位80。这一步不做你的 hex 打印全是乱的。示例一次读一个字节是逐字节转 hex的教学姿态不是性能姿态。如果数据量大ret 这种字符串拼接会产生大量中间对象应该改成 StringBuilder 追加这个我放到第 4 章改造时一起处理。3. 服务端与客户端逐行拆解这份代码可以直接抄3.1 TalkServer4Byte接受连接、逐字节读取与 doSomething完整代码如下我保留原始逻辑只把两处空 catch 补上了异常输出方便你跑的时候看到问题package com.yuan.socket; import java.io.*; import java.net.*; public class TalkServer4Byte { private ServerSocket server; private int port 5020; public TalkServer4Byte() { try { server new ServerSocket(port); } catch (IOException e) { e.printStackTrace(); // 端口被占用时至少能看到 BindException } } public void talk() { System.out.println(monitor port: port); Socket socket null; while (true) { try { socket server.accept(); // 阻塞等待客户端连接 System.out.println(client: socket.getRemoteSocketAddress()); DataInputStream dis new DataInputStream( new BufferedInputStream(socket.getInputStream())); byte[] bytes new byte[1]; // 一次只读一个字节 String ret ; while (dis.read(bytes) ! -1) { ret bytesToHexString(bytes) ; if (dis.available() 0) { // 原示例用可读字节数判断请求结束 doSomething(ret); } } } catch (IOException e) { e.printStackTrace(); } finally { try { socket.close(); } catch (IOException e) { e.printStackTrace(); } } } } public static void doSomething(String ret) { System.out.println(ret); } public static String bytesToHexString(byte[] src) { StringBuilder stringBuilder new StringBuilder(); if (src null || src.length 0) { return null; } for (int i 0; i src.length; i) { int v src[i] 0xFF; // 转无符号视角 String hv Integer.toHexString(v); if (hv.length() 2) { stringBuilder.append(0); } stringBuilder.append(hv); } return stringBuilder.toString(); } public static void main(String[] args) { new TalkServer4Byte().talk(); } }几个关键点server.accept()阻塞直到有客户端进来返回的 socket 就代表这条连接socket.getRemoteSocketAddress()打印的是客户端 IP 和端口排障时很有用dis.read(bytes) ! -1的退出条件是客户端关闭连接或网络断开返回 -1 表示 EOF。dis.available() 0是这份示例最值得怀疑的一行我在第 4 章专门拆。doSomething(ret)是 static 方法这里只负责打印实际项目里这一行应该换成你的业务逻辑比如解析协议头、写数据库、转发消息。另外注意doSomething 处理完后ret 没有被清空多个请求的 hex 会一直累积拼接这是原示例的顺手 bug改造时记得在这里ret 。最后提醒一句finally 块里socket.close()有个隐藏的 NPE 风险accept 抛异常时 socket 还是 null具体在 5.4 节展开。3.2 TalkClient4ByteSystem.in 到 DataOutputStream 的发送链路客户端代码比服务端短但有两个细节非常容易误读package com.yuan.socket; import java.io.*; import java.net.*; public class TalkClient4Byte { private Socket socket; private SocketAddress address; public TalkClient4Byte() { try { socket new Socket(); address new InetSocketAddress(127.0.0.1, 5020); socket.connect(address, 1000); // 连接超时 1000 毫秒 } catch (IOException e) { e.printStackTrace(); } } public void talk() { try { InputStream in new DataInputStream(System.in); // 标准输入 byte[] b new byte[1]; DataOutputStream dos new DataOutputStream(socket.getOutputStream()); while (-1 ! in.read(b)) { // 阻塞读CtrlD/CtrlZ 才 EOF dos.write(b); // 一个字节一个字节往 TCP 栈里写 } dos.flush(); dos.close(); } catch (IOException e) { e.printStackTrace(); } finally { try { socket.close(); } catch (IOException e) { } } } public static void main(String[] args) { new TalkClient4Byte().talk(); } }new Socket()先创建未连接 socket再connect(address, 1000)第二个参数是连接超时毫秒数超时会抛SocketTimeoutException。in.read(b)从标准输入阻塞读取正常交互下不会自己返回 -1需要 CtrlDUnix或 CtrlZ 回车Windows结束输入循环才会退出然后执行后面的 flush 和 close。这里纠正一个容易误判的点DataOutputStream本身不维护缓冲区它直接往底层 SocketOutputStream 写所以dos.write(b)之后数据已经进入内核 TCP 发送队列并不会因为 flush 在循环外就一直攒着不发。真正影响你交互体验的是 Nagle 算法对小包的合并——一个字节一个字节地 write前一个包的 ACK 没回来之前后面的小包会被内核压在缓冲区里一段时间。这个在 5.3 节细说。另外System.in本来就有read(byte[])方法包一层 DataInputStream 没有实际增益原示例里变量名还起成os容易让人误以为是输出流我改成in了。3.3 两套 hex 转换方法哪个该留哪个是冗余原代码里有两个高度相似的方法bytesToHexString(byte[] src)转小写 hexBytesHexString(byte[] b)转大写 hex。逻辑核心都是b[i] 0xFF再Integer.toHexString唯一的区别就是大小写。实际使用保留一个就够两个都留纯属代码冗余还容易让人困惑到底调哪个。我建议保留bytesToHexString因为这个方法原代码里已经用 StringBuilder 做了拼接优化原版确实如此而BytesHexString用的还是String加法显得不太走心。调试打印场景小写 hex 足够可读如果你对接的下游系统要求大写再在toUpperCase()上做一次转换没必要维护两套方法。4. 半包、粘包与 available()这段示例里最值得警惕的边界4.1 TCP 是字节流不是消息流TCP 协议给你的是一个可靠的、有序的字节管道它不负责维护哪几个字节算一条消息。你连续 write 两次各 4 字节对端 read 可能一次拿到 8 个字节也可能第一次拿到 5 个、第二次拿到 3 个。前者叫粘包后者叫半包。这是字节流协议的本性不是 bug。原示例里客户端按字节 write服务端按字节 read粒度都是 1恰好躲过了这类问题。但一旦把byte[1]换成byte[1024]或者客户端一次 write 几百字节问题立刻暴露。初学者最容易犯的错就是把 read 的返回值当成一条完整消息实际上 read 返回的只是本次从接收缓冲区取到的字节数和消息边界没有对应关系。4.2 available() 0 是玄学不是边界available()返回的是当前在不阻塞的情况下还能读到多少字节的估算值。它是内核接收缓冲区的一个瞬时快照跟你的业务消息边界没有任何关系。对端发送 100 字节这 100 字节可能被网络拆成 6040 两段到达服务端读完前 60 个字节后如果恰好available()为 0代码就会把只有 60 字节的半条消息当成完整请求处理。反过来对端连续 write 两次两次数据又挤在同一时刻到达available()在中间不会归零两个消息就粘成一条了。为什么这份示例跑起来大多正常因为客户端从控制台按字节读、按字节写整个会话的数据量通常就几个字节又是在本地回环上跑拆包概率极低。这是场景运气带来的假象不是边界设计正确。我做 socket 排障这几年见过太多线上神秘乱码、丢数据排查到最后都是这一行available()惹的祸。记住一个结论网络程序千万不要依赖available()判断一个请求结束能不用就不用。4.3 最小改造用长度前缀确认一个完整请求最省事的消息边界方案是长度前缀发送方在内容前面写 4 字节整数表示正文长度接收方先readInt()拿到长度再用readFully()读满整个正文。readInt()在没读满 4 字节之前会一直阻塞readFully()同理这就天然解决了半包问题——数据不够就继续等数据多了就把多出来的留给下一帧解析。服务端核心读取逻辑改成这样DataInputStream dis new DataInputStream(new BufferedInputStream(socket.getInputStream())); while (true) { int len; try { len dis.readInt(); // 读不到 4 字节会阻塞连接关闭抛 EOFException } catch (EOFException e) { break; // 对端正常关闭连接 } if (len 0 || len 1024 * 1024) { System.out.println(illegal frame length: len); break; // 防御脏数据或恶意长度 } byte[] body new byte[len]; dis.readFully(body); // 阻塞到读满 len 个字节 System.out.println(bytesToHexString(body)); }几个参数说明readInt()按大端序读 4 字节Java 和绝大多数语言一致跨语言通信不用操心字节序问题长度上限 1MB 是防御手段防止对端发一个0x7FFFFFFF的长度值把你的内存直接打爆EOFException 在 TCP 层面就是对方断开连接当正常退出处理即可。这个改造保留了原示例按请求打印的意图同时把半包、粘包问题一起解决是我在这个场景下最推荐的最小改动方案。5. 常见问题与避坑跑通这个示例时我最想提前知道的五件事这一章是我照着原样代码跑完再结合平时排查 socket 问题的血泪经验攒出来的。五条记录按现象 → 原因 → 解决展开照着排查能省不少时间。5.1 端口被占用BindException 被空 catch 静默吞掉现象启动服务端控制台干干净净没有报错进程直接退出像是压根没启动。用netstat -ano | findstr 5020一看端口已经被某个残留进程占着或者上次运行的程序还处在 TIME_WAIT 状态。原因new ServerSocket(port)失败抛BindException但原示例 catch 块是空实现异常信息被吞得干干净净你连为什么退出的都不知道。解决排查层面Windows 用netstat -ano | findstr 5020找到占用 PID再taskkill /PID pid /FLinux/macOS 用lsof -i:5020。代码层面至少把catch (IOException e) {}改成e.printStackTrace()生产环境换日志框架。如果服务端口不固定可以new ServerSocket(0)让内核分配空闲端口再用server.getLocalPort()打印出来给客户端连接这是自动化测试里常见的做法。5.2 中文输入被拆散字节流不关心编码边界全靠自己定现象客户端输入中文服务端打印的 hex 是e4 b8 ad三个字节而且这三个字节可能被拆成好几段触发了多次 doSomething想还原成文本阅读直接乱码。原因字节流层面完全正常——UTF-8 编码下中本来就是 3 个字节。问题出在示例按字节读取、用available()找边界3 个字节很容易被切到不同请求里。这是字节流协议不关心编码语义的自然结果不是编码损坏。解决调试看 hex 是对的要还原文本必须自己约定编码通常用 UTF-8并在读完整帧之后统一new String(body, StandardCharsets.UTF_8)。这和第 4 章的长度前缀改造是配套的——先有消息帧才能谈字符串解码。编码这件事越早约定越好否则后面每加一个对接方就多一次返工。5.3 逐字节发送与 Nagle 合并控制台输入总是一坨一坨地到达现象客户端每敲一个字符服务端却半天没反应过一会儿突然一次性输出一串。交互体验非常差。原因客户端一个字节一个字节地 write触发了 Nagle 算法的小包合并——前一个小包的 ACK 没回来之前后续小包被内核攒着不发。DataOutputStream本身没有缓冲flush 在这里只是把调用往底层透传起不到立即发送的作用。解决交互场景下在连接建立后加一行socket.setTcpNoDelay(true)关闭 Nagle 合并让每个小包尽快出去同时把标准输入读取改成BufferedReader.readLine()按行发送并每行 flush既能减少包的碎片化也让控制台交互更自然。注意setTcpNoDelay要在连接建立后立刻设置不要在发送过程中反复切换。5.4 accept 异常时 finally 空指针服务端静默退出现象客户端在握手阶段网络抖动服务端突然整个进程退出控制台只看到一条 IOException紧跟一条 NullPointerException。这个 NPE 还不是 catch (IOException) 能接住的它一路冒到 main循环彻底死掉。原因看 finally 块里的socket.close()socket 变量在外层声明accept 抛异常时它还是 null对 null 调 close() 当然 NPE。原示例吞掉所有异常的做法让这个问题更难发现你只看到进程莫名消失。解决两个层面。第一层finally里判空if (socket ! null) { socket.close(); }。第二层accept 失败打日志后应该continue让 while 循环继续接下一个连接而不是让一个异常搞死整个监听服务。资源关闭代码必须能容忍对象还没被赋值的场景这条规则我在写任何 close 逻辑时都会默认遵守。5.5 available() 边界失效粘包后的脏数据现象客户端一次发送一整行文本服务端打印出来的请求要么是半截要么把两次发送合并成一条输出内容和真实消息对不上。原因第 4 章已经说透——TCP 没有消息边界available()只能反映当前缓冲区的瞬时可读量不代表业务边界。本地回环测试可能糊弄过去一旦走公网、走高并发必现。解决换长度前缀帧代码直接用第 4.3 节的实现。另外记得把 doSomething 处理后的字符串容器清空原示例ret在打印后没有重置连续请求会越拼越长这个问题在改造帧读取时一起改掉。处理完每一帧后该清的状态清干净这是网络编程的基本素养。6. 验证与进阶把示例改造成能扛多连接的小框架6.1 先用 nc 和一段测试代码验证服务端行为原版服务端跑起来后不想写客户端也能验证。启动服务端另一个终端执行printf AB | nc 127.0.0.1 5020printf发送的是 ASCII 码 A 和 B 两个字节原版服务端会打印出41 42。这个测试有个附加价值多跑几次你会发现AB 两个字节有时被当成一个请求有时被拆成两个正好直观复现第 4.2 节的粘包问题。如果你已经把服务端改成 4.3 的长度前缀帧验证脚本也要跟着升级。用下面这段 Java 代码发一帧带长度头的数据try (Socket s new Socket(127.0.0.1, 5020); DataOutputStream dos new DataOutputStream(s.getOutputStream())) { byte[] payload hello.getBytes(StandardCharsets.UTF_8); dos.writeInt(payload.length); // 4 字节长度前缀 dos.write(payload); dos.flush(); }writeInt必须和readInt用同样的大端序Java 默认一致所以这里不用额外配置字节序。发送成功后服务端应打印68656c6c6f。6.2 线程池改造多客户端不再互相阻塞原模型最明显的缺陷是单线程一个连接不关闭后面所有连接都在 accept 队列里排队。教学可以但你要做多客户端通信最常见的改造方向是线程池版本的 Thread-Per-ConnectionExecutorService pool Executors.newCachedThreadPool(); while (true) { Socket socket server.accept(); pool.submit(() - handle(socket)); // handle 里放一帧的读取与业务逻辑 }newCachedThreadPool会为短连接创建新线程空闲 60 秒回收适合连接频繁但活跃时间短的场景。如果客户端是长连接建议newFixedThreadPool(n)限制并发线程数否则连接数一多线程数会被直接带飞。handle 方法内部的异常要 catch 全——线程池里一个任务抛异常不会杀掉池子但会导致这条连接的后续资源释放不了了finally 里关 socket 的代码一定不能省。6.3 三行检查清单每个连接处理前都该想的三个问题不要小看这份 2016 年的老示例它把 socket 编程的骨架完整摆了出来监听、接受连接、读字节、转 hex、关资源。真正让你在真实环境翻车的从来不是 API 不会调而是消息边界没定、异常路径静默、发送策略没考虑这三类细节。从那以后我每次写 socket都强制自己过一遍三个检查点一消息边界靠什么确定是长度前缀、分隔符还是定长帧二异常路径打不打日志资源关闭能不能容忍 null三数据有没有真正离开进程该 flush 的流 flush 了没有Nagle 算法会不会影响交互延迟。这套检查习惯救了我很多次希望你也能用上希望帮到你。本文还有配套的精品资源点击获取