本文详解 java 原生 socket 文件传输时内容重复的根本原因——客户端未严格按预发文件长度终止读取循环，导致缓冲区残留数据被重复写入；并提供健壮、无额外依赖的修复方案。
在使用 Java 原生 DataInputStream/DataOutputStream 实现 Socket 文件传输时，一个隐蔽但高频的问题是：接收端文件内容出现重复（如末尾多出前 N 字节）。问题并非源于 ObjectOutputStream 缺失，也不是网络粘包（TCP 本身无消息边界），而在于发送与接收逻辑对“文件结束”的判定不一致。
核心症结在于：InputStream.read(byte[], int, int) 方法在到达流末尾时返回 -1，但当文件大小不能被缓冲区整除时（例如文件长 2050 字节，缓冲区为 1024 字节），最后一次 read() 可能只读取 2 字节，随后 size 仍 > 0，循环继续——此时 read() 再次调用将阻塞或（在非阻塞模式下）返回 -1，但若未检查该返回值就直接 write(buffer, 0, bytes)，就会把上一次读取的旧数据（如前 1024 字节）再次写出，造成重复。
原客户端代码中这一关键缺陷体现在：
while(size > 0 && (bytes = input.read(buffer,0,(int)Math.min(buffer.length, size)))!=-1)
{
out.write(buffer, 0, bytes); // ✅ 正确：用实际读取字节数
out.flush();
size -= bytes;
}看似合理，但问题在于：当 size > 0 但 input.read() 返回 -1（即流已关闭或异常）时，循环条件虽退出，但若服务端未及时关闭连接，客户端可能因网络延迟等原因，在下次迭代前 read() 仍返回 -1，而 bytes 保持上一轮值（如 1024），导致 out.write(buffer, 0, 1024) 写入陈旧数据。更本质的是：size > 0 仅表示“预期还有数据”，不能替代对 read() 返回值的严格校验。
立即学习“Java免费学习笔记（深入）”；
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
✅ 正确做法是：以 read() 返回值为唯一 EOF 判定依据，size 仅用于限制单次读取上限，不参与循环控制。修复后的客户端 sendFile 方法如下：
private void sendFile(String path) {
File file = new File(path);
try (FileInputStream input = new FileInputStream(file);
DataOutputStream out = this.out) { // 复用已有 out，确保流一致性
long fileSize = file.length();
System.out.println("Sending file size: " + fileSize);
out.writeLong(fileSize); // 先发送文件总长度
out.flush();
byte[] buffer = new byte[1024];
int bytesRead;
while ((bytesRead = input.read(buffer)) != -1) { // ✅ 核心：仅靠 read() 返回值判断 EOF
// 优化：避免发送超出剩余长度的数据（可选，提升安全性）
int toWrite = (int) Math.min(bytesRead, fileSize);
out.write(buffer, 0, toWrite);
out.flush();
fileSize -= toWrite;
// 防止 fileSize 为负（理论不应发生，但增强鲁棒性）
if (fileSize < 0) {
throw new IOException("File size mismatch: attempted to write more than declared length");
}
}
System.out.println("File sent successfully.");
} catch (IOException e) {
e.printStackTrace();
}
}服务端 receiveFile 同理需修正循环逻辑，移除 size > 0 的联合判断，仅依赖 in.read() 返回值：
private void receiveFile(String path) {
try (FileOutputStream output = new FileOutputStream(path)) {
long remaining = in.readLong(); // 读取声明的文件长度
System.out.println("Expecting " + remaining + " bytes");
byte[] buffer = new byte[1024];
int bytesRead;
while (remaining > 0 && (bytesRead = in.read(buffer, 0,
(int) Math.min(buffer.length, remaining))) != -1) {
output.write(buffer, 0, bytesRead);
remaining -= bytesRead;
}
// ✅ 关键补充：校验是否完整接收
if (remaining != 0) {
throw new IOException("Incomplete file transfer: expected " +
(remaining + (int)(in.readLong() - remaining)) +
" bytes, but received only " + (int)(in.readLong() - remaining));
}
System.out.println("File received successfully.");
} catch (IOException e) {
e.printStackTrace();
}
}⚠️ 重要注意事项：
- 资源管理：务必使用 try-with-resources 确保 FileInputStream/FileOutputStream 在异常时自动关闭，避免句柄泄漏。
- flush() 调用：DataOutputStream 的 write*() 方法不自动 flush，必须显式调用 flush() 保证数据及时发出（尤其小文件）。
- 缓冲区安全：Math.min(buffer.length, remaining) 防止 read() 尝试读取超过剩余长度，避免潜在越界（尽管 read() 本身安全，但体现严谨性）。
- 服务端健壮性：增加 remaining == 0 校验，若提前读完却仍有数据，应视为协议错误而非静默忽略。
- 字符打印调试：示例中 System.out.print((char)b) 仅用于调试，实际生产环境应避免，因二进制文件含非 UTF-8 字节会抛 StringIndexOutOfBoundsException 或显示乱码。
总结：Socket 文件传输重复的本质，是混淆了“业务层长度声明”与“传输层流状态”。永远以 InputStream.read() 的返回值 -1 作为 EOF 的唯一权威信号，file.length() 仅作预分配和校验用途。此原则适用于所有基于流的协议设计，无需引入 ObjectStream，即可实现简洁、可靠、零依赖的文件传输。
