简介这份资源面向具备一定Java基础的开发者与网络编程学习者聚焦服务端与客户端之间的文件传输场景帮助理解Socket通信在实际项目中的落地方式。包内共9个文件以3个java源码与3个class编译文件为核心另含project工程配置、prefs偏好设置与classpath路径文件整体约9KB属于可直接导入IDE运行的轻量级示例工程。内容围绕ServerSocket监听端口、accept建立连接、输入输出流读写文件等关键环节展开并涉及缓冲区优化、文件大小预发送、传输进度跟踪以及try-catch-finally异常处理与流关闭等细节同时提及NIO与线程池在并发性能上的改进思路。已有679人学习下载适合希望快速掌握Java文件传输实现、对照源码理解通信流程并积累排错经验的读者参考。1. 从一次文件传输翻车说起Java Socket 到底能扛住多大的文件上周帮一个做物联网设备管理的朋友排查问题他们的网关程序需要把设备采集的日志文件回传到中心服务器用的是 Java 原生 Socket 写的传输模块。小文件几十 KB跑得好好的一上 200MB 的固件包就出问题——客户端显示发送完成服务端收到的文件却只有前几 MB后面全是空的。抓包一看客户端write完直接close服务端还在慢悠悠地readTCP 缓冲区里剩下的数据全被 RST 掉了。这个场景太典型了。Java Socket 编程做文件传输入门门槛低到令人发指——ServerSocket加Socket两个流对接就完事。但真放到生产环境传大文件缓冲区大小、粘包处理、进度反馈、断点续传、并发连接管理每一个点都能让你加班到凌晨。今天要拆的这份资源就是一套完整的 Java 服务端与客户端文件传输实现覆盖从最基础的字节流对拷到多文件并发传输的完整链路。它适合两类人刚学完 Java IO 想找个能跑通的实战项目练手的新手以及需要快速搭一个内网文件同步工具、不想引入 Netty 这类重框架的工程师。下面我按实际复现的顺序把这份资源里的关键实现和踩过的坑一个个拆开讲。2. 先跑通再优化最简 C/S 传输模型的代码骨架与参数调优2.1 服务端监听与客户端连接从 ServerSocket 到三次握手任何 Socket 文件传输的起点都是建立连接。服务端用ServerSocket绑定端口后进入accept()阻塞等待客户端用new Socket(host, port)发起连接。这一步看起来简单但有两个参数直接决定后续传输的稳定性。第一个是ServerSocket的 backlog 参数。它控制的是已完成三次握手但还没被accept()取走的连接队列长度。默认值在不同操作系统上不一样Linux 通常是 50。如果你预期有大量客户端同时连接这个值设小了多余的连接会被内核直接拒绝客户端收到Connection refused。常见做法是设成 128 或 256配合操作系统的somaxconn参数一起调。第二个是Socket的setSoTimeout()。它设置的是读操作的阻塞超时时间单位毫秒。不设的话read()会一直阻塞到有数据或连接断开。在文件传输场景里如果客户端发送中途崩溃服务端会永远卡在read()上线程泄漏。我一般会设 3000030 秒超时后抛SocketTimeoutException在 catch 块里清理资源。// 服务端绑定端口并设置连接队列长度 ServerSocket serverSocket new ServerSocket(); serverSocket.setReuseAddress(true); // 避免 TIME_WAIT 状态导致端口占用 serverSocket.bind(new InetSocketAddress(8888), 128); // backlog 128 while (true) { Socket socket serverSocket.accept(); // 阻塞等待客户端连接 socket.setSoTimeout(30000); // 读超时 30 秒防止死等 // 交给线程池处理避免阻塞主线程 executor.submit(() - handleClient(socket)); }setReuseAddress(true)这行值得单独说。TCP 连接关闭后主动关闭方会进入TIME_WAIT状态持续 2MSL通常 60 秒。如果服务端重启时端口还处于这个状态bind()会直接抛BindException: Address already in use。加上这行内核允许复用处于TIME_WAIT的地址重启就不会翻车。客户端这边连接超时用new Socket()的无参构造加connect(SocketAddress, timeout)来控制比直接new Socket(host, port)更可控后者用的是操作系统默认超时可能长达几分钟。// 客户端带超时控制的连接 Socket socket new Socket(); socket.connect(new InetSocketAddress(192.168.1.100, 8888), 5000); // 连接超时 5 秒 socket.setSoTimeout(30000);2.2 字节流对拷缓冲区大小为什么 8KB 是个分水岭连接建立后核心就是InputStream和OutputStream的对拷。最朴素的写法是一个字节一个字节地读写但每次read()和write()都是一次系统调用传 100MB 文件就是上亿次系统调用CPU 全耗在内核态和用户态的切换上。正确做法是用缓冲区批量读写。缓冲区大小怎么选我实测过 1KB、4KB、8KB、16KB、32KB、64KB 几档在千兆内网环境下8KB 以下性能下降明显8KB 到 64KB 之间差距不大超过 64KB 反而因为内存拷贝开销增加而略有下降。8KB 刚好是一个内存页的大小也是大多数操作系统默认的管道缓冲区大小属于“不会错”的选择。// 服务端接收文件的标准写法 public void receiveFile(Socket socket, String savePath) throws IOException { File targetFile new File(savePath); try (InputStream in socket.getInputStream(); BufferedOutputStream out new BufferedOutputStream( new FileOutputStream(targetFile))) { byte[] buffer new byte[8192]; // 8KB 缓冲区 int bytesRead; long totalRead 0; while ((bytesRead in.read(buffer)) ! -1) { out.write(buffer, 0, bytesRead); totalRead bytesRead; } out.flush(); // 确保缓冲区数据全部落盘 System.out.println(接收完成总字节数 totalRead); } }这里有个细节in.read(buffer)返回 -1 表示对端关闭了输出流。但如果你在客户端用的是socket.shutdownOutput()而不是socket.close()服务端能正常读到 -1同时客户端还能继续通过输入流接收服务端的响应。这个半关闭机制在多文件传输场景里非常关键后面会展开。BufferedOutputStream这层包装也值得说。FileOutputStream的write是直接调操作系统的写文件接口每次写 8KB 就是一次系统调用。加上BufferedOutputStream后数据先写到内存缓冲区默认 8KB满了再一次性刷到磁盘减少了系统调用次数。但注意最后必须flush()否则缓冲区里残留的数据会丢。2.3 文件元信息传递文件名和大小怎么告诉对端上面的代码只传了文件内容服务端不知道文件叫什么名字也不知道该存成什么格式。所以实际传输时需要先发一段“文件头”包含文件名和文件大小再发文件内容。常见做法是自定义一个简单的协议先发文件名的字节数组长度4 字节 int再发文件名本身然后发文件大小8 字节 long最后发文件内容。服务端按同样的顺序读。// 客户端发送文件元信息 内容 public void sendFile(Socket socket, File file) throws IOException { try (DataOutputStream dos new DataOutputStream( new BufferedOutputStream(socket.getOutputStream())); FileInputStream fis new FileInputStream(file)) { // 1. 发送文件名 byte[] nameBytes file.getName().getBytes(StandardCharsets.UTF_8); dos.writeInt(nameBytes.length); // 先写文件名长度 dos.write(nameBytes); // 再写文件名 // 2. 发送文件大小 dos.writeLong(file.length()); // 3. 发送文件内容 byte[] buffer new byte[8192]; int bytesRead; while ((bytesRead fis.read(buffer)) ! -1) { dos.write(buffer, 0, bytesRead); } dos.flush(); socket.shutdownOutput(); // 半关闭告诉服务端数据发完了 } }服务端对应的读取逻辑// 服务端解析元信息并接收文件 public void receiveFileWithMeta(Socket socket, String saveDir) throws IOException { try (DataInputStream dis new DataInputStream( new BufferedInputStream(socket.getInputStream()))) { // 1. 读文件名 int nameLen dis.readInt(); byte[] nameBytes new byte[nameLen]; dis.readFully(nameBytes); String fileName new String(nameBytes, StandardCharsets.UTF_8); // 2. 读文件大小 long fileSize dis.readLong(); // 3. 读文件内容 File targetFile new File(saveDir, fileName); try (BufferedOutputStream bos new BufferedOutputStream( new FileOutputStream(targetFile))) { byte[] buffer new byte[8192]; long remaining fileSize; while (remaining 0) { int toRead (int) Math.min(buffer.length, remaining); int read dis.read(buffer, 0, toRead); if (read -1) break; bos.write(buffer, 0, read); remaining - read; } } } }注意服务端这里用的是dis.readFully(nameBytes)而不是dis.read(nameBytes)。readFully会保证读满整个数组而read可能只读了一部分就返回。在网络传输中数据是分片到达的read返回部分数据是常态用readFully能省掉手动循环的麻烦。文件内容的读取则用remaining计数确保不会多读也不会少读这在连续传输多个文件时尤其重要——多读一个字节下一个文件的元信息解析就会全乱套。3. 多文件与并发传输线程池、半关闭和粘包的处理3.1 一个连接传多个文件半关闭与循环读取的配合单文件传输跑通后下一个需求往往是“一次连接传多个文件”。这时候不能每传一个文件就关一次 Socket那样频繁的三次握手和四次挥手开销太大。正确做法是在同一个连接上循环传输每个文件传完后不关连接只发一个结束标记。但这里有个坑服务端怎么知道当前文件传完了如果靠read()返回 -1那意味着客户端关闭了输出流后续就没法再传了。所以需要自定义一个结束标记比如在文件内容发完后再发一个长度为 0 的文件名writeInt(0)服务端读到文件名长度为 0 就认为本轮传输结束。// 客户端循环发送多个文件 public void sendMultipleFiles(Socket socket, ListFile files) throws IOException { try (DataOutputStream dos new DataOutputStream( new BufferedOutputStream(socket.getOutputStream()))) { for (File file : files) { byte[] nameBytes file.getName().getBytes(StandardCharsets.UTF_8); dos.writeInt(nameBytes.length); dos.write(nameBytes); dos.writeLong(file.length()); try (FileInputStream fis new FileInputStream(file)) { byte[] buffer new byte[8192]; int bytesRead; while ((bytesRead fis.read(buffer)) ! -1) { dos.write(buffer, 0, bytesRead); } } } dos.writeInt(0); // 结束标记文件名长度为 0 dos.flush(); socket.shutdownOutput(); } }服务端循环读取直到读到长度为 0 的文件名// 服务端循环接收多个文件 public void receiveMultipleFiles(Socket socket, String saveDir) throws IOException { try (DataInputStream dis new DataInputStream( new BufferedInputStream(socket.getInputStream()))) { while (true) { int nameLen dis.readInt(); if (nameLen 0) break; // 结束标记 byte[] nameBytes new byte[nameLen]; dis.readFully(nameBytes); String fileName new String(nameBytes, StandardCharsets.UTF_8); long fileSize dis.readLong(); File targetFile new File(saveDir, fileName); try (BufferedOutputStream bos new BufferedOutputStream( new FileOutputStream(targetFile))) { byte[] buffer new byte[8192]; long remaining fileSize; while (remaining 0) { int toRead (int) Math.min(buffer.length, remaining); int read dis.read(buffer, 0, toRead); if (read -1) break; bos.write(buffer, 0, read); remaining - read; } } System.out.println(已接收 fileName); } } }这个模式的关键在于DataInputStream和DataOutputStream保证了 int、long 这些基本类型的字节序一致都是大端序不会出现服务端读出来的文件名长度是个负数这种玄学问题。另外BufferedInputStream和BufferedOutputStream的包装不能省否则每次readInt()都是一次系统调用性能会惨不忍睹。3.2 多客户端并发线程池参数怎么配才不炸服务端要同时处理多个客户端的连接最直接的做法是每个accept()到一个连接就起一个新线程。但线程数量不受控100 个客户端同时连进来就是 100 个线程内存和上下文切换开销会把机器拖垮。用线程池是标准解法。核心线程数、最大线程数、队列容量这三个参数怎么配取决于你的业务特征。文件传输属于 IO 密集型任务线程大部分时间在等网络数据CPU 占用低。所以线程数可以适当多一些经验公式是CPU 核心数 * 2起步。// 服务端线程池处理并发连接 int cpuCores Runtime.getRuntime().availableProcessors(); ThreadPoolExecutor executor new ThreadPoolExecutor( cpuCores * 2, // 核心线程数 cpuCores * 4, // 最大线程数 60L, TimeUnit.SECONDS, // 空闲线程存活时间 new LinkedBlockingQueue(200), // 任务队列容量 new ThreadPoolExecutor.CallerRunsPolicy() // 拒绝策略 ); while (true) { Socket socket serverSocket.accept(); executor.submit(() - { try { receiveMultipleFiles(socket, /data/received); } catch (IOException e) { System.err.println(传输失败 e.getMessage()); } finally { try { socket.close(); } catch (IOException ignored) {} } }); }拒绝策略选CallerRunsPolicy是有意为之。当队列满了、线程数也到上限时这个策略会让提交任务的线程也就是主线程自己去执行任务而不是抛异常丢弃。效果是主线程被占住无法继续accept()新连接形成一种自然的背压——客户端连接会堆积在操作系统的 backlog 队列里而不是被服务端直接拒绝。对于文件传输这种不能丢数据的场景这比AbortPolicy直接抛RejectedExecutionException要温和得多。3.3 传输进度与断点续传的雏形大文件传输时客户端和服务端都需要知道进度。最简单的做法是在循环里累计已传输字节数定期打印百分比。但要注意System.out.println本身有 IO 开销每读 8KB 就打印一次会明显拖慢速度。我一般每传 1MB 或每 5% 打印一次。// 客户端带进度反馈的发送 long totalSent 0; long lastPrint 0; while ((bytesRead fis.read(buffer)) ! -1) { dos.write(buffer, 0, bytesRead); totalSent bytesRead; if (totalSent - lastPrint 1024 * 1024) { // 每 1MB 打印一次 System.out.printf(已发送%.1f%%%n, totalSent * 100.0 / fileSize); lastPrint totalSent; } }断点续传的完整实现需要服务端记录已接收的字节数客户端重连后从该偏移量继续发送。核心是客户端在发送前先问服务端“这个文件你已经收了多少”服务端返回一个 long 值客户端用FileInputStream.skip(offset)跳过已发送部分。这份资源里给出了基础框架但没做校验和验证实际生产环境还需要加 MD5 或 SHA-256 校验确保续传后的文件完整。4. 避坑指南文件传输中最容易翻车的五个点4.1 现象小文件正常大文件传一半就断原因客户端write完直接close没有等对端确认。TCP 的close会触发四次挥手但如果发送缓冲区里还有数据没发出去close会导致内核发送 RST 包接收端缓冲区里的数据被丢弃。解决发送完成后先flush()再shutdownOutput()等对端读完返回 -1 后再关闭 Socket。或者用socket.setSoLinger(true, timeout)让close阻塞到数据发完或超时。4.2 现象服务端收到的文件名是乱码原因客户端和服务端用的字符集不一致。客户端用系统默认字符集编码文件名服务端用另一种字符集解码。Windows 中文版默认 GBKLinux 默认 UTF-8跨平台传输必乱。解决两端强制指定StandardCharsets.UTF_8不要用file.getName().getBytes()这种依赖默认字符集的写法。4.3 现象传完一个文件后第二个文件的元信息解析错位原因第一个文件的内容没有精确读完。比如文件大小是 10000 字节但服务端循环里用了while ((read dis.read(buffer)) ! -1)结果多读了下个文件的头部数据。解决用remaining计数精确控制读取字节数确保不多读一个字节。这是多文件传输里最容易翻车的地方血泪经验。4.4 现象并发连接数一高服务端就报 OutOfMemoryError原因每个连接起一个线程线程栈默认 1MB1000 个连接就是 1GB 内存。加上每个连接的缓冲区内存直接爆掉。解决用线程池限制最大线程数或者改用 NIO 的Selector模型。如果坚持用 BIO把线程栈大小调小-Xss256k同时控制最大连接数。4.5 现象传输速度远低于网卡带宽原因缓冲区太小导致系统调用频繁或者BufferedInputStream/BufferedOutputStream没加每次read/write都是直接操作文件描述符。解决缓冲区设 8KB 到 32KB加上 Buffered 包装。另外检查是否在循环里做了flush()每次flush都会强制系统调用应该只在最后刷一次。5. 进阶技巧用零拷贝和 NIO 把传输速度再提一档传统 BIO 的文件传输数据要从磁盘读到内核缓冲区再从内核缓冲区拷贝到用户缓冲区Java 的 byte[]然后从用户缓冲区拷贝到 Socket 发送缓冲区最后从发送缓冲区拷贝到网卡。四次拷贝两次系统调用。Java NIO 提供了FileChannel.transferTo()和transferFrom()底层依赖操作系统的sendfile系统调用数据直接从磁盘文件描述符传到 Socket 文件描述符不经过用户态。这就是所谓的零拷贝。// 服务端用 FileChannel 零拷贝接收文件 public void receiveFileZeroCopy(SocketChannel channel, String savePath) throws IOException { try (FileChannel fileChannel FileChannel.open( Paths.get(savePath), StandardOpenOption.CREATE, StandardOpenOption.WRITE)) { ByteBuffer buffer ByteBuffer.allocateDirect(8192); // 直接缓冲区 while (channel.read(buffer) ! -1) { buffer.flip(); // 切换为读模式 while (buffer.hasRemaining()) { fileChannel.write(buffer); } buffer.clear(); // 清空准备下次读 } } }allocateDirect分配的是堆外内存不受 GC 管理但创建和销毁成本高适合长期复用的场景。flip()和clear()的配合是 NIO 的经典模式写数据前clear读数据前flip读完再clear。搞反了就会出现“读了 0 字节”或者“BufferOverflowException”这类问题。实测在千兆内网传 1GB 文件传统 BIO 加 8KB 缓冲区大约 110MB/sNIO 零拷贝能到 118MB/s 左右差距不算大因为千兆网卡本身就是瓶颈。但在万兆网卡或者本地回环测试时零拷贝的优势会非常明显能到 2GB/s 以上。另一个技巧是压缩传输。如果传的是文本日志或 JSON 文件压缩率通常能到 5:1 甚至 10:1。在客户端用GZIPOutputStream包一层服务端用GZIPInputStream解压网络传输时间大幅缩短代价是两端各多一次压缩和解压的 CPU 开销。内网带宽充足时没必要跨机房或公网传输时非常值得。从那以后我每次写 Socket 文件传输都会先问自己三个问题文件多大、网络多快、要不要断点续传。这三个答案决定了缓冲区大小、是否压缩、以及要不要上 NIO。希望帮到你。本文还有配套的精品资源点击获取