Java实现TB级文件高速传输：分片并发与断点续传实战

自从上次在内网拷了快一天还没传完一个几百GB的文件夹，我就一直琢磨换条路子。场景很常见：两台服务器在同一个局域网，想搬一个1TB左右的数据目录，里面有大量视频、模型文件、日志压缩包，单个文件大小从几KB到几个GB不等。最开始尝试共享文件夹直接拖，中途一次网络波动，进度归零；换FTP，断点续传功能有但目录结构处理麻烦，并发更别指望；找了找rsync，在Windows上又是另一套折腾。最后决定自己写一个Java工具，用分片并发加断点续传来解决，实测下来把千兆带宽基本跑满，中断了也能从上次的位置接着走。这篇文章就完整梳理一下这个方案的思路、协议设计、核心代码和我在实际踩坑中摸出来的经验。

1. 方案选型与整体设计

1.1 为什么我把现成工具都换掉了

先盘一下那几类现成方案的痛点。

共享文件夹（比如SMB/CIFS）最大的问题是“要么全有，要么全无”。大目录复制过程中一旦断掉，Windows往往只会标记失败，已经拷走的零散文件倒是还在，可到底哪些文件完整、哪些缺了一半，没有一个可靠的清单。文件夹里成千上万个文件，你想“跳过已有文件”都不行，因为复制工具对“文件是否相同”的判断经常只看文件名和大小，两个大小相同的错误文件会被直接跳过。这个方案在文件量少、网络极稳的场合够用，但放到TB级目录上就是折磨。

FTP本身支持断点续传，REST命令可以告诉服务端从偏移量继续写文件。但只解决“单个文件续传”，没有解决“批量目录并发”。1TB目录里有几万个文件的话，用FTP逐个传，要么串行速度慢，要么自己写一个多FTP会话并发管理器，工作量和自己写一个分片协议差不了多少。另外很多FTP服务器在大连接数下会主动断开空闲连接，遇到高峰期网络拥塞，连接一断，重新建立会话、重新定位偏移量，这些逻辑全要你手工兜底。

rsync是Linux生态的常青树，增量同步很牛，但它是为文件级别同步设计的，不是为“单个超大文件的并发续传”设计的。一个20GB的单文件断了，rsync重新校验整个文件的时间也不短；更麻烦的是Windows下原生支持并不好，要么上模拟环境，要么用第三方封装，内部机制的不可控性让人难受。

还有一个容易被忽略的问题：这些工具都没有一个统一的“进度视图”。我想知道“现在传了百分之多少”“哪些文件已经校验通过”“剩余时间大概多少”，它们做不到。我需要的不是一个“复制粘贴”动作，而是一个能监控、能中断、能恢复、能并发调度的传输系统。

1.2 分片、断点、并发：这套方案的基本工作原理

这个方案的核心一句话概括：把大文件切成固定大小的小块，每一块当作一条独立消息传过去，传成功的块记录到状态清单里，下次启动时跳过清单里已经完成的块，只传剩下的。

举个例子。一个1024MB的文件，分片大小设为128MB，那就切成8个片子。每个片子都有唯一的序号（0到7）。接收端收到1号片子，就把它写到目标文件的偏移量128MB位置，同时把“1号分片已完成”写入状态记录。如果第5个片子传一半时网络断了，状态记录里只有0到4是COMPLETE，5是IN_TRANSFER或PENDING，6和7是PENDING。重启程序后，发送端读到状态记录，看到0到4已经完成，直接从5开始传。整个流程不需要重新扫描那个1024MB文件的内容，连可传输数据的总量都直接在启动时计算出来。

分片以后，并发也变得简单。发送端维护一个待发送分片队列，多个工作线程从队列里取分片，各自开Socket连接传给接收端。接收端按照分片序号计算文件偏移位置，用FileChannel的position方法跳到对应位置写入。这样多个分片虽然到达顺序是乱的，但每个分片都落在自己的区域，彼此不干扰。

TB级数据里通常包含海量小文件。我的做法是把“文件夹传输”也抽象成一个个“分片”。目录结构先序列化成元数据发送过去，接收端提前建好目录；然后小文件不需要单独分片，而是把多个小文件打包成一个逻辑分片（比如打包到64MB一个包）发送，接收端拆包后按相对路径写盘。这样既避免了几万个小文件的连接建立开销，也让“文件夹”整体变成了同样可以断点续传的任务。大文件单独切分，小文件打包切分，两者统一纳入同一个分片调度框架。

1.3 技术选型：纯Java Socket还是Netty

一开始我就不打算引入重型框架，原因很直接：这个工具只需要部署在两台机器上，目标是解决一次性的迁移任务，做成一个能double-click跑起来的Jar比什么都重要。纯JDK的Socket、ServerSocket、FileChannel足够支撑这个场景。

Java的标准库处理TCP通信有一层封装好的Socket/ServerSocket，只要保证发送的数据能区分边界、能确认到达，写起来并不复杂。传输过程中最担心的粘包/半包问题，也可以通过“先读取4字节长度头，再读取长度字节体”的方式解决，这是业内通用的LengthFieldBasedFrameDecoder思路，算最基础的解法。纯JDK不需要引第三方依赖，也不需要考虑Netty版本兼容、性能调优这些周边成本。

但我会把另一条路讲清楚：如果数据规模继续膨胀，比如到了几十TB，或者要求传输机有更好的CPU/内存利用率和更低的延迟，那直接换Netty更合适。Netty内置了lengthFieldBasedFrameDecoder、内存池、零拷贝相关API，线程模型也比自己写的线程池更精细。后来我封装这个工具时，把协议层和网络传输层解耦，就是为了以后可以把Socket实现整体替换成Netty实现，业务代码不动。

2. 核心细节拆解：协议、分片、状态与并发

2.1 分片大小的选择与文件切分实现

分片大小不是拍脑袋定的，它受几个因素约束：内存占用、磁盘IO、重传粒度、校验开销。

如果分片设成64MB，一个数据包就这么大，发送端读文件时需要准备一个64MB的byte数组吗？不一定，我们可以用FileChannel读取一小段一小段循环写入网络流，但接收端在写文件时也是循环写；可一旦需要做MD5校验，你得先接收完整一个分片再算校验值，这时必须把分片数据放在内存里或者临时磁盘缓冲。如果选择把分片完整缓存到内存，64MB × 4个并发连接就是256MB，在8GB内存的机器上还扛得住；如果分片设成512MB，同样并发下内存就可能吃紧。因此我最终把默认值设为128MB，性能测试时内存占用大约稳定在1.5GB左右（8线程并发），对一台传输服务器来说可以接受。

从TCP窗口和磁盘IO的角度看，分片太小时会放大“每个分片都要进行状态写入、校验、ACK”的固定开销。实测下来，32MB分片在千兆局域网中速度稳定在95~105MB/s，128MB分片能到110MB/s左右，512MB分片反而因为内存压力和重组时的GC波动掉回100MB/s以下。所以对千兆局域网，128MB是一个不错的甜点值。

切分逻辑本身非常简单，但要处理好最后一块不等于标准大小的情况：

java复制public class FileSplitter {
    private final long chunkSize;

    public List<ChunkDescriptor> split(Path filePath, Path rootPath) throws IOException {
        long fileSize = Files.size(filePath);
        long chunkCount = (fileSize + chunkSize - 1) / chunkSize;
        List<ChunkDescriptor> chunks = new ArrayList<>();
        String relativePath = rootPath.relativize(filePath).toString();
        // 注意：Windows路径分隔符需要统一替换成 /
        relativePath = relativePath.replace('\\', '/');
        for (int i = 0; i < chunkCount; i++) {
            long start = (long) i * chunkSize;
            long length = Math.min(chunkSize, fileSize - start);
            chunks.add(new ChunkDescriptor(i, relativePath, start, length));
        }
        return chunks;
    }
}

代码里其实是按整个文件切，不需要真正把文件切开。每个分片通过“文件相对路径 + 起始偏移 + 长度”三个字段描述。发送端读取时，用FileChannel.open(path)把position定位到start位置，再读length个字节。接收端重组时，也是打开目标文件，把position定位到对应位置写。整个传输过程中没有一次性的全文件内存复制，所有IO都走文件通道。

2.2 断点续传的状态记录与恢复逻辑

状态记录是断点续传的“账本”，它必须回答这几个问题：要传哪些文件？每个文件分成多少片？每个分片的当前状态是什么？是否传完了？

我设计的状态文件是一个JSON文件，传输前后都放在接收端机器上的一个隐藏目录里，比如.transfer-state/task.json。结构大致长这样：

json复制{
  "taskId": "20240512-0930-a1b2c3",
  "rootPath": "video_dataset",
  "totalBytes": 1099511627776,
  "totalChunks": 8586,
  "files": [
    {
      "path": "videos/scene_001.mp4",
      "size": 272629760,
      "chunks": [
        {"seq": 0, "status": "COMPLETE", "offset": 0, "length": 134217728, "md5": "..."},
        {"seq": 1, "status": "COMPLETE", "offset": 134217728, "length": 134217728, "md5": "..."},
        {"seq": 2, "status": "IN_TRANSFER", "offset": 268435456, "length": 4194304, "md5": ""}
      ]
    }
  ]
}

状态枚举我坚持只用四个：PENDING（未开始）、IN_TRANSFER（传输中）、COMPLETE（已完成）、FAILED（失败）。其中IN_TRANSFER在程序异常退出后会被视为未完成，启动时自动重置为PENDING。为什么不能把IN_TRANSFER直接当作已完成？因为“正在传”不等于“数据完整落地”，如果程序刚好在发送完网络包、还没写状态文件的间隙挂了，接收端磁盘上可能已经有半截分片数据。稳妥的做法是接收端每写完整一个分片并校验通过后，才更新这个分片状态为COMPLETE，并且这个状态更新应该先落盘，再给发送端回ACK。这一点顺序不能反，我在早期版本里先回ACK再更新状态，就出现过接收端已经回ACK但状态没写进JSON，发送端认为完成、接收端实际没记录的矛盾。后来统一成“先落状态，再回ACK”，问题不再出现。

断点恢复的流程也不复杂。程序启动时先读任务目录下的状态文件。如果任务不存在，就进入“新任务初始化”流程：发送端扫描整个文件夹生成文件清单，接收端创建目录结构，然后开始调度。如果任务存在，就加载所有分片状态，把COMPLETE的滤掉，把IN_TRANSFER重置为PENDING，然后把PENDING和FAILED的分片塞回待发送队列，从该队列开始继续执行。整个过程对用户来说就是重新执行一遍启动命令，无需额外指定“续传”或者“覆盖”。

2.3 传输协议帧设计：怎么处理粘包和半包

局域网TCP传输最大的坑之一就是流式传输没有天然的消息边界。两个分片前后脚发出，接收方可能一次性读到两片的数据；相反，一个分片可能被拆成好几个TCP包，接收方一次read只读到一小段。为了避免业务层错乱，我设计了一个非常简单的帧格式：

这个帧头里最关键的是数据长度。接收端每次先读固定长度的帧头（4+1+1+8+8+4=26字节），然后根据数据长度读取数据体。为了让这个流程稳定，我封装了一个readFully方法，目标就是把指定长度的字节读满为止：

java复制public static byte[] readFully(InputStream in, int len) throws IOException {
    byte[] buffer = new byte[len];
    int offset = 0;
    while (offset < len) {
        int r = in.read(buffer, offset, len - offset);
        if (r == -1) {
            throw new EOFException("连接被对端关闭");
        }
        offset += r;
    }
    return buffer;
}

帧头里的通道ID很重要：一个发送端可以开启多个并发连接，每连接传输不同的分片。接收端拿到数据体后，不关心它来自哪个Socket连接，只需要检查分片序列号，用FileChannel写文件时定位offset即可。

ACK/NACK走了同一个帧结构，只是消息类型不同。发送端发完一个数据分片后，会等待对应分片序列号的ACK。如果收到NACK，说明接收端校验失败，发送端要重传这个分片。如果等待超过5秒没收到任何回复，发送端也认为分片丢失，主动重传。这里要控制重传次数，连续重传5次仍然失败就把这个分片状态置为FAILED，并暂停整个任务向用户报告。

心跳机制主要用来检测死连接。平时数据传输忙时不发心跳，空闲超过10秒就发送端发一个心跳帧，接收端收到后原样回复。发送端连续3个心跳超时，就关闭这条连接并重新建立。

2.4 并发调度与写入策略：多线程不打架的秘诀

启动时，发送端会准备一个ConcurrentLinkedQueue，把所有待发送分片描述符塞进去。然后创建固定数量的工作线程，我默认取CPU核数的一到两倍，但绝不能盲目翻倍。因为每个线程独占一条TCP连接，线程太多会让连接数暴涨，Linux下临时端口和文件描述符容易告急；线程太少又跑不满千兆带宽。我在24核的服务器上测试过，12个线程就能打满千兆，16线程差不多，再涨到32线程时反而因为Context Switch增多速度略降。最终我把线程数做成可配置参数，默认值为12。

接收端每个连接也需要一个线程来读取和处理。接收端用的线程池大小可以比发送端大一点，因为接收端处理工作除了网络IO还有文件写入和MD5计算。MD5计算比较耗CPU，如果接收端机器性能偏弱，这个线程池会成为瓶颈。一个折中方案是把MD5校验从接收线程移到独立的校验线程池，接收线程把完整分片数据放到内存缓冲区，校验线程取走并写文件。但由于一个128MB分片在内存里要占128MB，多开校验线程会增大内存压力，所以刚开始做的时候还是让接收线程自己校验，等真的出现接收端CPU瓶颈再拆。

写入目标文件时用RandomAccessFile或FileChannel都是可以的，核心是每次写都带分片偏移量。我用的是：

java复制try (FileChannel fileChannel = FileChannel.open(targetPath,
        StandardOpenOption.CREATE, StandardOpenOption.WRITE)) {
    fileChannel.position(chunk.getOffset());
    ByteBuffer buffer = ByteBuffer.wrap(chunkData);
    while (buffer.hasRemaining()) {
        fileChannel.write(buffer);
    }
    fileChannel.force(true);
}

fileChannel.force(true)会把文件数据和元数据刷到磁盘，代价是性能会明显下降，但对断点续传的可靠性至关重要。因为如果不force，操作系统可能把数据留在page cache，这时候程序认为传输完成，但当系统掉电时数据就没了。全速传输场景下，每写完一个分片force一次，实测速度会从110MB/s降到90MB/s左右，可靠性换性能，我认为值得。如果接受“极端断电后需要重传最后若干个分片”的风险，可以把force改成每隔几个分片调用一次。

并发写入同一文件时，不同的FileChannel对象定位到不同位置写，操作系统能保证在同一个文件的不同区域并发写是安全的，因为写操作是带偏移的。但如果同时写同一区域的同一位置，后写的会覆盖先写的，必须避免。我们的分片调度保证每个分片有唯一偏移区间，同一偏移区间只会被调度到一条连接的任务中，所以不会发生覆盖。

3. 完整实操实现：从启动到跑满带宽

3.1 项目结构与环境准备

我用的是JDK 8的语法，所有代码只依赖核心库，方便在两台服务器上直接运行。项目结构如下：

code复制fast-transfer/
├── pom.xml
└── src/main/java
    └── com/example/transfer/
        ├── FastTransferMain.java       // 主入口，命令行解析
        ├── model/
        │   ├── ChunkDescriptor.java
        │   ├── FileDescriptor.java
        │   └── TransferTask.java
        ├── protocol/
        │   ├── ProtocolCodec.java      // 帧编码解码
        │   └── MessageType.java
        ├── sender/
        │   ├── SenderServer.java       // 服务端，等待接收端连接
        │   ├── ChunkDispatcher.java    // 分片调度器
        │   └── ChunkSender.java        // 单分片发送线程
        ├── receiver/
        │   ├── ReceiverClient.java     // 接收端，主动连接发送端
        │   ├── ChunkReceiver.java      // 分片接收处理
        │   └── FileMerger.java         // 按偏移写入合并
        └── state/
            ├── StateStore.java         // 状态JSON读写
            └── StateStatus.java

前提条件：两端都装JDK 8以上，网络互通，防火墙放行指定的TCP端口。整个工具不需要服务器权限，普通用户即可运行，唯一的要求是目标目录所在磁盘剩余空间要大于源数据总量。

3.2 发送端实现：扫描、切分、调度与重传

发送端启动后做的事情可以拆成五步：解析命令行参数、扫描源目录生成文件清单、初始化状态、启动ServerSocket监听、创建调度线程池发送分片。

主入口代码如下，命令行写得很直白：

java复制public static void main(String[] args) throws Exception {
    Config config = Config.parse(args);
    if (config.isSender()) {
        SenderServer server = new SenderServer(config);
        server.start();
        server.await();
    } else {
        ReceiverClient client = new ReceiverClient(config);
        client.start();
        client.await();
    }
}

实际用起来是两行命令：

bash复制# 接收端运行（先启动）
java -jar fast-transfer.jar receiver --dir /data/receive --listen-port 9527

# 发送端运行
java -jar fast-transfer.jar sender --dir /data/video_dataset --host 192.168.1.20 --port 9527

这里的设计是发送端主动连接接收端，因为实际场景中发送端往往是临时发起迁移的人，接收端机器IP固定。这个模式也方便接收端作为“服务端”接收来自多个发送端的连接。

SenderServer启动后会开启一个控制服务。第一个连接进来时，发送端把任务元数据（所有文件清单和分片描述）发给接收端，其中最关键的是分片总数和总字节数，接收端用它初始化状态文件和计算进度。之后发送端的工作线程会从队列中不断取待发送分片，建立新的数据连接发送。为了避免频繁创建连接，我让每个工作线程在启动时建立一条长连接，完成一个分片后继续从队列取下一个分片，直到队列为空再关闭连接。长连接可以有效避免每个分片都要经历三次握手和四次挥手，在大规模分片场景下对性能提升相当明显。

分片发送的核心方法长这样：

java复制public void sendChunk(ChunkDescriptor chunk) throws Exception {
    byte[] data = readChunkData(chunk);
    ProtocolFrame frame = ProtocolFrame.buildDataFrame(
            channelId, chunk.getSeq(), data, md5(data));
    sendFrame(frame);
    ProtocolFrame ack = waitAck(chunk.getSeq(), ACK_TIMEOUT_MS);
    if (ack == null || ack.getMessageType() != MessageType.ACK) {
        throw new RetryableException("ack timeout, seq=" + chunk.getSeq());
    }
}

读取分片数据时要特别留意：不能一次性把整个分片读入一个byte[]再发送，因为128MB的byte数组在堆里是很重的。我的readChunkData内部会使用文件通道和一个8KB的临时缓冲区循环读写到OutputStream，然后把整个分片数据组合成ProtocolFrame的数据体。实际上这个过程中还是会产生一个128MB的byte[]作为帧体，因为MD5计算需要看到全部分片数据。想省内存，就要牺牲一次校验或使用增量哈希，我用的是后者：在读取分片数据时边读边更新MessageDigest，等整个分片传输完毕后，把“数据长度+MD5”先发出去，然后再把分片内容循环发送。也就是说协议数据被拆成一个“传输头”和一个“原始体”，发送端发完头之后继续发原始体；接收端先收头，再收原始体。这样的话发送端不需要为整个分片申请大缓冲区。接收端那边还是需要把某个分片的数据攒满才能算MD5，但它可以直接把数据边收边写入一个临时分片文件，等文件收满后再对整个临时文件计算校验和，这样接收端也不需要128MB的byte数组。这个设计帮我避免了大对象频繁创建带来的GC压力，我强烈建议在TB级传输中采用“流式校验”而非整块内存校验。

3.3 接收端实现：状态落地、偏移写入与合并

接收端比发送端多一个任务：维护所有分片状态。我在接收端单独开一个状态管理组件StateStore，它的所有写操作都是同步的，做到一个分片的状态只能被一个线程修改。

接收端启动时，先加载或创建状态文件。如果创建新任务，接收端从控制连接读取发送端传来的文件清单，遍历所有文件，初始化每个文件的分片状态为PENDING。随后进入接收循环，等待每个连接上的数据帧。收到数据帧后，先判断分片序号，然后向对应文件写入数据，写完调用StateStore.markComplete，最后回ACK。

关键代码如下：

java复制public void handleDataFrame(ProtocolFrame frame) throws Exception {
    long seq = frame.getSequence();
    ChunkDescriptor chunk = stateStore.getChunk(seq);
    if (chunk.getStatus() == StateStatus.COMPLETE) {
        sendAck(seq);
        return;
    }

    // 把数据写入目标文件的对应偏移
    writeToFile(chunk.getPath(), chunk.getOffset(), frame.getData());

    byte[] md5 = md5FileChunk(chunk.getPath(), chunk.getOffset(), chunk.getLength());
    if (MessageDigest.isEqual(md5, frame.getDigest())) {
        stateStore.markComplete(seq);
        sendAck(seq);
    } else {
        sendNack(seq);
    }
}

这里有一个细节：如果状态已经是COMPLETE，但发送端又重复发来了同一个分片（可能是ACK在网络中丢失导致发送端重传），接收端应当直接回ACK而不是重新写文件。这种幂等处理保证了重传不会破坏已存在的数据。

接收端写完数据后，并没有做一次“单独的文件合并收尾”。因为从一开始就是直接往最终目标文件的偏移位置写的，所有分片到位后，文件自然就是完整的。唯一需要做的合并工作是针对目录结构里的那些打包小文件分片：一个逻辑分片里包含多个小文件，接收端写完这个逻辑分片后，需要调用解包方法，按元数据里的相对路径把各个小文件写到对应位置。

把整个逻辑分片写入临时文件再解包，磁盘占用会临时增加一个分片大小，然后解包完成后删除临时文件。这个临时空间在TB级任务中的峰值大概是128MB，可以接受。

3.4 断点恢复全过程演示

以我的实测环境为例。发送端目录/data/video_dataset总大小约1.2TB，接收端目录/data/receive备用。先启动接收端，再启动发送端，能看到日志滚动输出分片完成情况。传到第4382个分片时，我手动中断发送端进程模拟网络崩溃。

重启发送端和接收端，两者都会读取状态文件。接收端日志显示“Loaded existing task, completed chunks: 4382, pending chunks: 1024”。所以它不会重新初始化任务，而是直接等发送端继续调度。发送端也读到了同样的状态，把PENDING和IN_TRANSFER的分片重新加入队列。传输继续从第4382片后面的片段开始，而不是从头来。最终全部完成后，接收端状态文件里所有分片都是COMPLETE，两边文件的MD5逐一比对一致。

整个恢复过程的关键在于：发送端和接收端必须使用同一个任务ID。我让任务ID由发送端在首次启动时生成，随后通过控制连接发给接收端，接收端把它写入状态文件。恢复时，接收端先上报自己的任务ID，发送端检查是否与本地一致。不一致则拒绝续传，避免把两个不同任务的状态混在一起。

3.5 参数调优与一组实测数据

我把实测数据放在一张表里，前提是两台普通服务器通过千兆交换机直连，源目录是一个混合数据集，包含约28000个文件。

千兆局域网的理论上限约112MB/s（1000Mbps/8），在启用分片并发后能跑到110MB/s，基本可以认为网络协议开销之外已经被榨干。如果换成万兆网络，瓶颈会很快转移到磁盘IO和MD5计算上，那时候就需要考虑用多块磁盘做目标目录条带化，或者用SHA-256代替MD5（但更慢），也可以引入零拷贝。

Socket层面有两个参数值得一提。发送端Socket开启TCP_NODELAY，禁用Nagle算法，避免因小包聚合造成延迟偏高：

java复制socket.setTcpNoDelay(true);
socket.setSoTimeout(5000);
socket.setSendBufferSize(4 * 1024 * 1024);
socket.setReceiveBufferSize(4 * 1024 * 1024);

发送缓冲区设到4MB，可以让大分片发送时内核缓冲更充裕，但不要设太大，否则在带宽不足时反而会因为缓冲堆积导致发送延迟与RTO计算偏差。

4. 常见问题与排查技巧实录

4.1 传输中断后无法续传，重新启动又从头开始

这个问题百分之九十出在状态文件没有正确加载。排查顺序如下：

先看接收端目录下有没有生成.transfer-state/task.json。如果没有，说明接收端第一次启动时没有收到任务元数据，或者写入状态文件失败。此时需要检查接收端是否有写权限、磁盘空间是否足够。

再看发送端日志是否显示“taskId mismatch”。状态文件的加载要求两端任务ID一致。如果接收端的状态文件是上一次任务的残留，而发送端是新任务，就会报这个错。解决方法是给任务加自定义名称，比如按日期和目录名拼一个taskId，或者每次新任务前先清空接收端的旧状态目录。

最后确认一下代码里状态更新顺序。如果要重构成自己维护状态，一定要遵守“先标记IN_TRANSFER或PENDING，再发送分片；发送并校验成功后，只更新COMPLETE，不更新其他中间态”。

4.2 收到的分片数据出现错乱，文件MD5对不上

错乱通常来自三个地方：粘包半包处理不正确、字节序不一致、以及并发写文件时位置写错。

粘包半包的解法就是前面讲的readFully，但还有一个容易忽略的点：发送端如果分组构造帧头，接收端可能一次读到了“帧头A+部分帧体B”混在一起的数据。如果接收端盲目先读26字节当作帧头，就会把帧体当成下一帧的帧头。所以必须严格按数据长度循环读取，并在读完数据体后再处理下一个帧头，我在接收循环里保证了这一点。

字节序问题主要出现在跨语言实现里。我的协议帧里所有int/long都固定用大端序。Java的DataOutputStream.writeInt默认就是大端，DataInputStream.readInt也是大端，只要两端都用Java就没问题。但如果你把发送端或接收端换成C++/Python，就别忘了统一字节序。Python端可以用struct.pack(">I", value)表示大端无符号整数。

并发写文件时位置写错的场景，常见于发送端调度器把同一个分片序号分配给了两个工作线程。比如一次失败重传中，原始发送线程还在等ACK，而调度器已经把这个分片重新入队，第二个线程也把它发出去了。接收端会收到两个相同序列号的分片，但内容完全一样，所以不会出错，只会多传一次。真正危险的是两个不同的分片序号由于计算偏移错误映射到了同一文件区间，导致相互覆盖。因此分片序号、起始偏移、长度这三者的映射关系在切分阶段就必须唯一且稳定。代码里我是从文件元数据直接计算，不用任何动态分配。

4.3 传超过2GB的文件时偏移量变成了负数

这个问题其实是Java老生常谈。如果你用int类型存储offset，任何超过2GB的位置都会变成负数。我的分片描述里，chunk.getOffset()返回long，FileChannel.position(long)也接受long。如果框架底层不小心把long强转int，大文件必炸。排查时可以打印分片元数据，看是否出现负数偏移。Java的Arrays类或ByteBuffer类型转换时也容易踩这个坑，建议全局搜索所有涉及位置值的变量类型，确保是long。

4.4 目录结构里的中文文件名显示乱码

文件名字符串通过网络传输后乱码，是因为字符编码不统一。我在协议里统一规定文件名字段采用UTF-8编码，发送端在写入帧体前显式调用getBytes(StandardCharsets.UTF_8)，接收端用new String(data, StandardCharsets.UTF_8)还原。只要不依赖平台默认字符集，这个问题就能避免。另一个容易踩的坑是Windows的路径分隔符，我前面代码里已经做了replace('\','/')，接收端在创建文件时再用File.separatorChar或Paths.get来还原。

4.5 连接被对端重置，但进程还在

这种情况多见于接收端线程出现未捕获异常后异常结束，连接被操作系统回收。排查接收端日志，看看是不是在写文件时抛出了FileSystemException（比如磁盘空间不足、权限被改）。还有可能是防火墙或系统安全策略杀掉了长连接。建议在接收端用无操作系统的环境变量禁用安全策略，如果内网安全策略严格，则需要把TCP端口加白名单，并让应用层心跳频率高于防火墙空闲连接老化时间，比如防火墙30分钟断开空闲连接，心跳就10分钟一次。

我在排查此类问题时，常用一个“终极大法”：降低并发到1，分片大小降到16MB，如果问题消失，说明是多连接并发触发了什么问题；如果问题依旧，说明是单条连接链路本身出问题，优先检查防火墙和路由器MTU。

4.6 磁盘可用空间足够但写入失败

这通常不是真的空间不足，而是目标目录所在文件系统满了inode。在Linux下，如果目录里有很多小文件，但每个分片写入时又会创建临时文件，inode可能被占满。我遇到过接收端创建了几万个临时文件后inode耗尽，即使磁盘还有几百GB也写不进去。排查命令是df -i，处理方式是减少临时文件数量，或者把临时分片目录放在独立文件系统上。后来我们改为“边收边写入最终位置”，不再创建临时分片文件，这个问题就基本不出现了。

5. 优化方向：从百兆到万兆，以及变成可运维的服务

5.1 用零拷贝把FileChannel.transferTo用起来

JDK NIO里有一个容易被忽略的API：FileChannel.transferTo(long position, long count, WritableByteChannel target)。它在Linux上底层会尝试使用sendfile系统调用，数据直接从内核文件页缓存发到Socket缓冲区，无需拷贝到用户态。这一下能省掉内核和用户内存之间的一次大块内存复制，对万兆网络场景提升明显。

但要注意，transferTo对并发连接的支持仍然依赖FileChannel和SocketChannel，纯Socket的OutputStream无法直接用。如果基于NIO改造，需要把接收端的SocketChannel作为WritableByteChannel传入。JDK8以下在Windows上transferTo的优化有限，Linux效果好。我们实测在一个万兆场景试过，使用transferTo后CPU占用率明显下降，但速度提升不如预期，因为磁盘IO仍是瓶颈。

5.2 从“裸Socket”换成Netty

如果项目需要长期维护，我建议尽早把底层的Socket链路替换成Netty。Netty的LengthFieldBasedFrameDecoder可以自动解决粘包半包问题，ByteBuf使用池化内存减少GC，而且支持将FileRegion用于零拷贝文件发送。线程模型上，Netty的EventLoop天然适合处理高并发连接，不需要自己管理阻塞线程。

我之所以没在一开始就上Netty，是为了让这个工具保持零依赖，方便一次性脚本化运行。但如果把传输工具做成公司内部的数据迁移平台，多任务并发、客户端断线重连、Web界面展示进度，这些需求会让自定义Socket的维护成本高得很快。Netty在这种场景下能省很多事。

5.3 进度管理与Web界面

TB级任务通常要跑几个小时，没有进度视图很难交代。我们的状态文件本身就包含了所有分片状态，做一个定时扫描就能得到精确的字节级进度。最简单的实现是新增一个HTTP端口，任意浏览器访问http://receiver-ip:8085/progress就能看到JSON，里面是：

json复制{
  "totalChunks": 8586,
  "completedChunks": 4382,
  "totalBytes": 1099511627776,
  "completedBytes": 561476468736,
  "percent": 51.1,
  "speedMBps": 108.5,
  "remainingSeconds": 4732
}

进度模块不参与传输逻辑，只是StateStore的只读视图，所以不会影响稳定性。如果再扩展，可以在这个接口上增加暂停、取消、限速等控制指令。

5.4 限速与带宽控制

内网传输虽然带宽大，但不是所有环境都能独占带宽。如果一边要传数据一边还有业务在跑，为了防止传输占用全部带宽导致线上服务抖动，需要给传输工具加限速。最简单的令牌桶限速器可以放在发送端：每个工作线程在发送分片数据前，从共享令牌桶中获取对应字节数的令牌，没令牌就等待。令牌桶的填充速度就是目标速率，比如设为80MB/s。

java复制public class SpeedLimiter {
    private final double maxBytesPerSecond;
    private double tokens;
    private long lastRefillTime;

    public synchronized void acquire(int bytes) throws InterruptedException {
        refill();
        while (tokens < bytes) {
            long sleepNanos = (long) ((bytes - tokens) / maxBytesPerSecond * 1e9);
            Thread.sleep(Math.min(sleepNanos / 1000000, 100));
            refill();
        }
        tokens -= bytes;
    }

    private void refill() {
        long now = System.nanoTime();
        tokens = Math.min(maxBytesPerSecond,
                tokens + (now - lastRefillTime) * maxBytesPerSecond / 1e9);
        lastRefillTime = now;
    }
}

注意不要在每个字节循环内调用acquire，应该在每读一次大块数据（比如256KB）后调用一次，减少同步开销。

最后再分享一点我的实际体会

这个工具从写第一行代码到能稳定跑完1TB数据，中间大概迭代了三四个版本。最初我只实现了单文件分片续传，后来发现真正的问题不是大文件而是整目录的小文件太多，于是加了“小文件打包分片”。最初我用每个分片都先写临时文件再合并，结果磁盘占用翻倍被运维直接喊停，改成按偏移写最终文件后才真正能用在生产环境。最初我把MD5计算放在内存里，跑一会儿GC就严重，改成流式校验之后才消停。这一路踩下来最大的感受是，TB级传输的难点从来不是“能不能传”，而是“断了能不能无损地接着传”“传的过程中内存和磁盘扛不扛得住”“出了问题时能不能明确知道是哪一分片出了问题”。一套可靠的状态记录加上严格的消息应答，比任何花哨的协议栈都管用。如果你也要做类似的事，建议先把断点续传的状态模型画清楚，再写网络代码，顺序不能反。