1. 为什么文件传输这件事，绕不开Socket
很多人第一次接触网络编程，都是从"传个文件"开始的。听起来简单，但真动手写的时候，问题一个接一个：文件传过去少了几KB、大文件传到一半卡死、中文文件名变成乱码、服务端收到的文件打不开。这些坑我在不同项目里几乎都踩过一遍。
Java的Socket API其实不复杂，核心就是ServerSocket和Socket两个类。但"能用"和"好用"之间隔着一整套工程细节。这篇文章不讲教科书式的API罗列，而是从实际项目出发，把基于TCP的Socket文件传输从最基础的字节流写法，到多线程并发、断点续传、完整性校验，一层层拆开讲清楚。
TCP协议本身是面向连接的可靠传输协议，它保证了数据包的顺序和重传机制。但"TCP可靠"不等于"你的代码可靠"。TCP只保证字节流按序到达，它不知道你发的"一个文件"从哪里开始、到哪里结束。这个边界问题必须由应用层自己解决。这就是为什么很多新手写完代码发现文件传过去多了几个字节或者少了几个字节——因为接收端不知道什么时候该停止读取。
这篇文章适合有Java基础、想搞明白网络文件传输完整实现方案的开发者。不管你是做内网工具、做设备间数据同步，还是单纯想理解Socket编程的本质，下面的内容都能直接拿去用。
2. 最朴素的写法：一次一发一收的阻塞式传输
2.1 服务端与客户端的最小闭环
先看最基础的模型。服务端用ServerSocket监听某个端口，客户端用Socket发起连接。连接建立后，双方通过输入输出流交换数据。
服务端的核心逻辑是这样的：
ServerSocket serverSocket = new ServerSocket(8888); Socket socket = serverSocket.accept(); // 阻塞等待连接 InputStream in = socket.getInputStream(); // 读取数据...客户端对应地：
Socket socket = new Socket("127.0.0.1", 8888); OutputStream out = socket.getOutputStream(); // 写入数据...这个模型里，accept()会阻塞直到有客户端连上来，read()也会阻塞直到有数据可读。对于"传一个文件"这种一次性任务，够用了。
2.2 文件边界的确定：为什么不能直接读到-1
这是第一个大坑。很多人写接收端的时候想当然地写：
byte[] buffer = new byte[1024]; int len; while ((len = in.read(buffer)) != -1) { fos.write(buffer, 0, len); }这段代码在传单个文件、传完就关闭连接的场景下能工作。但一旦你想在同一个连接上做多次交互，或者客户端传完文件后没有立即关闭Socket，接收端就会一直阻塞在read()上，因为它等不到-1。
-1只在对方关闭了输出流（调用了shutdownOutput()或者直接关闭了Socket）时才会返回。所以正确的做法有两种：
第一种，客户端传完文件后调用socket.shutdownOutput()，告诉对方"我发完了"，但连接本身还留着可以接收响应。第二种，在应用层协议里先发送文件长度，接收端按长度精确读取。
我个人的习惯是第二种，因为它更可控，后面做断点续传、多文件传输都靠这个基础。
2.3 先发长度再发内容：一个必须养成的习惯
具体做法是：客户端先发送一个固定长度的头部信息，比如用DataOutputStream的writeLong()发送文件大小，然后再发送文件内容。接收端先用DataInputStream的readLong()读出文件大小，然后循环读取直到读满这么多字节。
// 发送端 DataOutputStream dos = new DataOutputStream(socket.getOutputStream()); dos.writeLong(file.length()); dos.writeUTF(file.getName()); // 然后写文件内容 FileInputStream fis = new FileInputStream(file); byte[] buf = new byte[4096]; int len; while ((len = fis.read(buf)) != -1) { dos.write(buf, 0, len); } dos.flush();// 接收端 DataInputStream dis = new DataInputStream(socket.getInputStream()); long fileSize = dis.readLong(); String fileName = dis.readUTF(); FileOutputStream fos = new FileOutputStream(targetDir + fileName); byte[] buf = new byte[4096]; long remaining = fileSize; while (remaining > 0) { int len = dis.read(buf, 0, (int) Math.min(buf.length, remaining)); if (len == -1) break; fos.write(buf, 0, len); remaining -= len; }注意read(buf, 0, (int) Math.min(buf.length, remaining))这一行。为什么要限制读取长度？因为如果缓冲区是4096字节，但文件只剩100字节没读完，你最多只能读100字节。如果不限制，read()可能会读到下一个文件的数据（如果连接上还有后续数据的话），导致文件内容错乱。
提示：
DataOutputStream的writeUTF()会在字符串前面加两个字节的长度前缀，所以接收端用readUTF()能正确读出。但writeUTF对字符串长度有限制（65535字节），文件名一般够用，但如果是很长的路径就要注意。
3. 大文件传输中的内存与流控问题
3.1 缓冲区大小不是越大越好
我见过有人把缓冲区设成10MB，觉得"一次多读点肯定快"。实际上，缓冲区大小对传输速度的影响存在一个收益递减的临界点。太小（比如128字节）会导致频繁的系统调用，上下文切换开销大；太大（比如10MB）会占用过多内存，而且TCP本身的发送窗口和接收窗口有限，你一次写太多，底层还是要分片发送，反而增加了内存拷贝的次数。
实测下来，4KB到64KB是比较合理的区间。局域网内传大文件，32KB或64KB表现不错；跨网络传输，8KB到16KB更稳妥，因为网络MTU一般在1500字节左右，太大的缓冲区在丢包重传时反而效率低。
这里有个容易忽略的点：BufferedInputStream和BufferedOutputStream的默认缓冲区是8KB。如果你在DataInputStream外面又包了一层BufferedInputStream，实际上有两层缓冲，数据会被拷贝两次。所以要么直接用DataInputStream配合自定义大小的byte数组，要么用BufferedInputStream但把byte数组设小一点。
3.2 发送端的flush时机
OutputStream.write()并不保证数据立即发送出去，它可能还在缓冲区里。flush()强制把缓冲区数据推出去。但每写一次就flush一次是灾难性的——每个小数据包都会触发一次网络发送。
正确的做法是：在循环写文件内容的过程中不flush，等整个文件写完了再flush一次。但这里有个例外：如果你在传超大文件（比如几个GB），中途不flush可能导致发送端缓冲区堆积，内存暴涨。这时候可以每写若干次（比如每写1MB）flush一次，平衡内存和效率。
3.3 接收端的写入策略
接收端写文件时，同样建议用BufferedOutputStream包一层，减少磁盘IO次数。但要注意，BufferedOutputStream的flush()只是把数据推给操作系统的文件系统缓存，并不保证落盘。如果需要确保数据真正写入磁盘（比如断电也不丢），需要调用FileDescriptor.sync()或者用RandomAccessFile的getFD().sync()。当然，大多数场景不需要这么严格。
4. 多客户端并发：从单线程到线程池
4.1 单线程服务端的瓶颈
前面的代码只能同时服务一个客户端。第二个客户端连上来的时候，accept()虽然能返回新的Socket，但处理逻辑还在上一个客户端的循环里，新连接只能排队等着。这在真实场景里完全不可接受。
最简单的改造是每接受一个连接就起一个新线程：
while (true) { Socket socket = serverSocket.accept(); new Thread(() -> handleClient(socket)).start(); }但这样有个问题：如果并发连接数很高（比如几百上千），每个连接一个线程会导致线程数量爆炸，内存占用飙升，上下文切换开销巨大。而且线程的创建和销毁本身也有成本。
4.2 线程池方案的参数怎么定
用ThreadPoolExecutor替代裸线程是更工程化的做法。核心参数需要根据实际场景来定：
| 参数 | 建议值 | 理由 |
|---|---|---|
| corePoolSize | CPU核数×2 | 文件传输是IO密集型任务，线程大部分时间在等网络 |
| maximumPoolSize | 50-200 | 根据服务端内存和预期并发数调整 |
| keepAliveTime | 60秒 | 空闲线程回收时间 |
| workQueue | LinkedBlockingQueue(有界) | 防止任务无限堆积导致OOM |
| 拒绝策略 | CallerRunsPolicy | 队列满时让调用线程自己执行，起到背压作用 |
这里特别说一下队列的选择。如果用无界的LinkedBlockingQueue，当任务生产速度超过消费速度时，队列会无限增长，最终OOM。有界队列配合合适的拒绝策略才是安全的。CallerRunsPolicy的好处是当线程池忙不过来时，accept()所在的线程会自己去处理这个连接，这样accept()就被阻塞了，新的连接进不来，自然形成了背压。
4.3 每个连接的文件隔离
多客户端并发时，每个客户端可能传同名文件。如果都写到同一个目录，会互相覆盖。解决方案有两种：一是为每个连接创建一个独立的临时目录，用UUID命名；二是文件名加上时间戳或客户端标识。我一般用第一种，传完之后再根据业务逻辑决定是否合并或重命名。
另外，每个连接处理完毕后必须关闭Socket和相关的流。用try-with-resources可以确保这一点：
try (Socket socket = serverSocket.accept(); InputStream in = socket.getInputStream(); FileOutputStream fos = new FileOutputStream(...)) { // 处理逻辑 } catch (IOException e) { // 日志记录 }注意ServerSocket本身一般不需要在循环里关闭，它跟着服务端的生命周期走。
5. 传输完整性：怎么确认文件没传坏
5.1 TCP校验和不够用吗
TCP协议头里有校验和字段，但它只能检测传输过程中的比特错误，而且校验和的计算相对简单，对于大文件来说碰撞概率虽然低但并非为零。更重要的是，TCP校验和无法检测应用层的逻辑错误——比如你代码写错了，少读了一段数据，TCP层面是感知不到的。
所以应用层必须自己做完整性校验。最常用的就是MD5或SHA-256。发送端在传文件之前先算出文件的哈希值，把哈希值随文件一起发过去（或者单独发），接收端收到文件后重新计算哈希值，比对一致才算成功。
5.2 哈希值放在哪里传
有两种做法。一种是放在文件内容前面，作为头部的一部分：
dos.writeUTF(fileName); dos.writeLong(file.length()); dos.writeUTF(md5Hex); // 先算好的哈希 // 然后写文件内容另一种是文件传完后，客户端再单独发一个哈希值。两种都可以，但第一种更紧凑，减少了一次交互。不过第一种要求发送端在发送之前就把整个文件读一遍算哈希，对于超大文件来说，这意味着要读两次磁盘（一次算哈希，一次发送）。如果对性能敏感，可以在发送的同时用DigestInputStream边读边算，但这样哈希值只能在发送完之后才知道，就得用第二种方案。
5.3 断点续传的基本思路
断点续传的核心是记录"已经传了多少"。发送端在发送前先问接收端："这个文件你那边已经有多少字节了？"接收端查一下本地临时文件的大小，返回给发送端。发送端从那个偏移量开始继续发送。
这需要协议支持双向通信。简单的做法是：客户端连接后先发一个"查询请求"，带上文件名；服务端检查本地是否有对应的临时文件，返回已接收的字节数；客户端用RandomAccessFile.seek()跳到对应位置开始读，服务端也用RandomAccessFile在对应位置追加写入。
这里有个细节：临时文件的名字要能唯一标识一个传输任务，通常用"文件名.part"或者"文件名.tmp"。传输完成后重命名为正式文件名。如果传输中断，下次连接时检查这个临时文件是否存在及其大小。
6. 那些让我调试到半夜的坑
6.1 中文文件名乱码
DataOutputStream.writeUTF()用的是修改版UTF-8编码，能正确处理中文。但如果你用PrintWriter或者直接写字符串的字节数组，就可能因为平台默认编码不同而乱码。比如Windows默认GBK，Linux默认UTF-8，两边不一致就出问题。
最稳妥的方式是统一用writeUTF()/readUTF()，或者手动指定编码：str.getBytes(StandardCharsets.UTF_8)。千万不要用str.getBytes()不带参数，那个用的是平台默认编码，跨平台必出问题。
6.2 防火墙和端口占用
ServerSocket绑定端口时，如果端口已经被占用，会抛BindException。开发阶段经常遇到"Address already in use"，一般是上一个进程还没完全退出。可以用serverSocket.setReuseAddress(true)来允许端口复用，但要注意这可能导致旧连接的数据混入新连接。
另外，如果服务端和客户端不在同一台机器，服务端所在机器的防火墙必须放行对应端口。这个不是代码问题，但新手经常在这里卡住，以为是代码写错了。
6.3 大文件传输时的内存溢出
如果接收端用ByteArrayOutputStream把整个文件读到内存再写磁盘，传个1GB的文件就会OOM。必须用流式处理，边读边写。同样，发送端也不要把整个文件读成byte数组再发。
还有一个隐蔽的OOM场景：DataInputStream的readFully()方法。它会一直读到填满指定数组为止，如果对方发送的数据不够，它会阻塞等待。如果你不小心用了一个很大的数组，而对方只发了一小部分就断了，这个方法会一直挂着。
6.4 连接超时与读取超时
Socket默认的超时是无限等待。如果网络中断或者对方进程崩溃，你的read()可能永远阻塞。必须设置超时：
socket.setSoTimeout(30000); // 30秒读超时超时后read()会抛SocketTimeoutException，你可以捕获后决定重试还是放弃。注意setSoTimeout影响的是read()操作，不影响connect()。连接超时要在创建Socket时指定：new Socket()然后用connect(address, timeout)。
6.5 半关闭状态的正确处理
调用socket.shutdownOutput()之后，TCP会发送FIN包，对方读到流末尾返回-1。但此时连接并没有完全关闭，你仍然可以从输入流读取数据。这个"半关闭"状态在需要"发完文件后等对方确认"的场景下非常有用。
但要注意，有些防火墙或NAT设备会在检测到半关闭状态后直接断开连接。所以如果跨公网传输，半关闭的可靠性不如应用层协议（先发长度再发内容）来得稳。
7. 一套可以直接用的完整实现框架
7.1 协议设计
综合前面的讨论，我设计一个简单的应用层协议：
| 字段 | 类型 | 说明 |
|---|---|---|
| magic | int | 魔数，用于校验连接合法性 |
| fileName | UTF字符串 | 文件名 |
| fileSize | long | 文件总大小 |
| md5 | UTF字符串 | 文件MD5值 |
| 文件内容 | 字节流 | 按fileSize长度读取 |
客户端连接后先发魔数，服务端校验；然后依次发文件名、大小、MD5；最后发文件内容。服务端按顺序读取，读完后校验MD5，返回一个字节表示成功或失败。
7.2 服务端核心代码结构
public class FileServer { private static final int PORT = 8888; private static final int BUFFER_SIZE = 8192; public static void main(String[] args) throws IOException { ExecutorService pool = new ThreadPoolExecutor( 4, 50, 60L, TimeUnit.SECONDS, new LinkedBlockingQueue<>(100), new ThreadPoolExecutor.CallerRunsPolicy() ); try (ServerSocket serverSocket = new ServerSocket(PORT)) { System.out.println("服务端启动，监听端口：" + PORT); while (true) { Socket socket = serverSocket.accept(); pool.submit(() -> handleClient(socket)); } } } private static void handleClient(Socket socket) { try (Socket s = socket; DataInputStream dis = new DataInputStream( new BufferedInputStream(s.getInputStream())); DataOutputStream dos = new DataOutputStream( new BufferedOutputStream(s.getOutputStream()))) { int magic = dis.readInt(); if (magic != 0xCAFEBABE) { dos.writeByte(0); dos.flush(); return; } String fileName = dis.readUTF(); long fileSize = dis.readLong(); String expectedMd5 = dis.readUTF(); File target = new File("received", fileName); target.getParentFile().mkdirs(); MessageDigest md = MessageDigest.getInstance("MD5"); try (FileOutputStream fos = new FileOutputStream(target); BufferedOutputStream bos = new BufferedOutputStream(fos)) { byte[] buf = new byte[BUFFER_SIZE]; long remaining = fileSize; while (remaining > 0) { int len = dis.read(buf, 0, (int) Math.min(buf.length, remaining)); if (len == -1) throw new IOException("连接提前断开"); bos.write(buf, 0, len); md.update(buf, 0, len); remaining -= len; } } String actualMd5 = bytesToHex(md.digest()); if (actualMd5.equalsIgnoreCase(expectedMd5)) { dos.writeByte(1); } else { dos.writeByte(0); target.delete(); } dos.flush(); } catch (Exception e) { e.printStackTrace(); } } private static String bytesToHex(byte[] bytes) { StringBuilder sb = new StringBuilder(); for (byte b : bytes) { sb.append(String.format("%02x", b)); } return sb.toString(); } }7.3 客户端核心代码结构
public class FileClient { private static final int BUFFER_SIZE = 8192; public static void sendFile(String host, int port, File file) throws IOException { String md5 = calcMd5(file); try (Socket socket = new Socket()) { socket.connect(new InetSocketAddress(host, port), 5000); socket.setSoTimeout(30000); try (DataOutputStream dos = new DataOutputStream( new BufferedOutputStream(socket.getOutputStream())); DataInputStream dis = new DataInputStream( new BufferedInputStream(socket.getInputStream())); FileInputStream fis = new FileInputStream(file)) { dos.writeInt(0xCAFEBABE); dos.writeUTF(file.getName()); dos.writeLong(file.length()); dos.writeUTF(md5); byte[] buf = new byte[BUFFER_SIZE]; int len; while ((len = fis.read(buf)) != -1) { dos.write(buf, 0, len); } dos.flush(); int result = dis.readByte(); if (result == 1) { System.out.println("传输成功"); } else { System.out.println("传输失败，MD5校验不通过"); } } } } private static String calcMd5(File file) throws IOException { try (FileInputStream fis = new FileInputStream(file)) { MessageDigest md = MessageDigest.getInstance("MD5"); byte[] buf = new byte[BUFFER_SIZE]; int len; while ((len = fis.read(buf)) != -1) { md.update(buf, 0, len); } return bytesToHex(md.digest()); } catch (NoSuchAlgorithmException e) { throw new RuntimeException(e); } } private static String bytesToHex(byte[] bytes) { StringBuilder sb = new StringBuilder(); for (byte b : bytes) { sb.append(String.format("%02x", b)); } return sb.toString(); } }7.4 几个关键细节的说明
BufferedInputStream包在DataInputStream外面还是里面？答案是外面。DataInputStream负责解析数据类型，BufferedInputStream负责减少系统调用。所以顺序是new DataInputStream(new BufferedInputStream(socket.getInputStream()))。
dos.flush()的位置很关键。发送完文件内容后必须flush，否则数据可能还在缓冲区里，接收端会一直等。发送完魔数、文件名等头部信息后不需要单独flush，因为后面紧接着写文件内容，最后一起flush就行。但如果服务端在收到头部后需要立即响应（比如返回"可以开始传了"），那就必须flush。
MD5计算在发送端是提前算好的，这意味着大文件要读两遍。如果不想读两遍，可以用DigestInputStream包装FileInputStream，边读边算，但这样MD5值只能在发送完之后才知道，需要改协议为"先发文件再发MD5"。两种方案各有取舍，看具体场景。
8. 性能调优的几个实操方向
8.1 TCP_NODELAY要不要开
socket.setTcpNoDelay(true)会禁用Nagle算法。Nagle算法会把小的数据包合并成大的再发，减少网络上的小包数量。对于文件传输这种大数据量场景，Nagle算法其实是有益的，因为它减少了包的数量。但如果你在传文件的同时还有交互式的控制指令（比如暂停、继续），那Nagle算法会导致控制指令延迟。所以纯文件传输不需要开TCP_NODELAY，混合场景建议开。
8.2 发送缓冲区和接收缓冲区
socket.setSendBufferSize()和socket.setReceiveBufferSize()可以调整TCP层的缓冲区大小。默认值在不同操作系统上不一样，Linux一般是几十KB。对于高带宽延迟积的网络（比如跨地域传输），适当增大缓冲区能提升吞吐量。但这两个参数必须在连接建立之前设置才有效，连接建立后再设会被忽略。
8.3 零拷贝的可行性
Java的FileChannel.transferTo()可以实现零拷贝，数据直接从文件系统缓存送到网络协议栈，不经过用户态。但transferTo需要WritableByteChannel，SocketChannel实现了这个接口。所以理论上可以用FileChannel.transferTo()来发送文件，减少一次内存拷贝。不过transferTo一次能传的数据量有限（一般不超过2GB），大文件需要循环调用。而且它和DataOutputStream的头部协议配合起来比较麻烦，需要先通过普通流发头部，再切换到Channel发内容。实际项目中，除非对性能有极致要求，否则用普通的流式传输就够了。
9. 从单机到跨网络：还需要考虑什么
9.1 NAT超时与心跳
如果客户端和服务端之间隔着NAT设备，长时间没有数据传输的话，NAT映射表项可能会过期，导致连接被断开。文件传输过程中一般数据不断，不会有这个问题。但如果传输完成后连接要保持一段时间，就需要定期发心跳包。心跳包可以是一个字节的特定值，接收端识别后忽略即可。
9.2 传输加密
TCP本身不加密，数据在网络上明文传输。如果传的是敏感文件，需要在应用层加密。最简单的做法是用CipherInputStream和CipherOutputStream包一层，用AES加密。密钥交换可以用非对称加密（如RSA）来协商。不过加密会带来性能开销，对于大文件传输，AES硬件加速下影响不大，但密钥管理是个复杂问题，这里不展开。
9.3 传输进度反馈
用户体验好的工具都会显示进度条。实现方式很简单：发送端每发送一定量的数据（比如每1MB），就在控制台打印一次进度。如果是GUI程序，就更新进度条组件。注意不要在每次循环都更新UI，那样会导致界面卡顿，用计数器控制更新频率。
接收端也可以反馈进度，但需要双向通信。一种做法是接收端每收到一定量数据就回发一个确认，发送端根据确认调整发送速率。这就是简单的滑动窗口流控。不过TCP本身已经有流控了，应用层再做一层通常没必要，除非你有特殊的业务需求。
10. 我在实际项目中的几点体会
Socket文件传输这件事，代码写出来能跑不难，难的是在各种异常情况下都能正确处理。网络断开、对方进程崩溃、磁盘写满、文件名冲突、权限不足——每一种异常都需要有对应的处理逻辑。我现在的习惯是，任何网络操作都必须设超时，任何文件写入都必须检查返回值，任何资源都必须用try-with-resources确保释放。
另外，日志要打够。传输开始、传输结束、传输了多少字节、耗时多久、MD5是否匹配——这些信息在排查问题时非常有用。我遇到过好几次"文件传过去了但打不开"的情况，最后都是靠日志里的MD5比对发现是传输过程中数据被截断了。
最后说一个容易被忽略的点：测试的时候不要只用小文件。小文件传输几乎不会暴露问题，因为数据量小，一次write()就发完了，缓冲区、流控、超时这些问题都触发不了。一定要用大文件（至少几百MB）测试，而且要在网络不稳定的环境下测试，比如用限速工具模拟弱网，或者中途手动断开连接看程序是否能正确处理。这些测试做完，你的代码才算真正可靠。
