线程池通过资源节制、失败隔离与状态收敛支撑分片上传并发调度：手动构造threadpoolexecutor，corepoolsize设为cpu核数×1.5～2，maxpoolsize略高，workqueue用有界linkedblockingqueue，拒绝策略自定义并联动断点续传状态存储。
线程池如何支撑分片上传的并发调度
分片上传本质是多个独立IO任务的并行执行，线程池在这里不是简单“开多线程”，而是承担资源节制、失败隔离与状态收敛三重职责。实际部署中建议选用 ThreadPoolExecutor 手动构造，避免使用 Executors 工厂方法（易导致无界队列堆积或线程爆炸）。核心参数需按上传场景调优：
- corePoolSize：设为 CPU 核数 × 1.5～2，兼顾磁盘 IO 和网络等待；若服务器以 SSD + 千兆网为主，可设为 8～12
- maxPoolSize：略高于 core，例如 core=10 时 max=16，应对突发分片洪峰
- workQueue：用 LinkedBlockingQueue（带容量限制），如 200～500，防内存溢出；禁用无界 SynchronousQueue 或 LinkedBlockingDeque
- RejectedExecutionHandler：必须自定义，例如记录日志 + 返回 HTTP 429，并触发客户端退避重试
断点续传中线程池与进度状态协同的关键设计
断点续传的可靠性不取决于“能不能重试”，而在于“重试前能否精准识别哪些已成功”。线程池本身不存状态，必须与外部存储联动：
- 每个分片上传任务提交前，先查 Redis 或数据库中的 uploaded_chunks:{fileMd5} 集合，过滤掉已存在的 chunkIndex
- 任务执行成功后，用原子操作（如 Redis 的 SADD）写入该集合，并更新整体进度字段 upload_progress:{fileMd5}
- 线程池中的 Worker 线程应封装为 ChunkUploadTask，实现 Runnable 接口，内部持有 fileMd5、chunkIndex、chunkFile、重试次数等上下文，失败时自动递减重试计数并重新提交（限 3 次）
- 禁止在任务中直接操作全局共享变量（如 static Map），所有状态变更走统一存储层
分片合并阶段为何要慎用线程池
合并不是并发友好型操作——它要求严格顺序写入、原子完成、单点校验。若错误地用线程池驱动多个 RandomAccessFile 并发写同一目标文件，极易引发数据错位、覆盖或文件损坏。
- 合并应作为上传流程的终态动作，在所有分片确认收齐后，由一个专用线程（或 Spring @Scheduled 定时扫描任务）串行触发
- 推荐使用 Files.walk() 按 chunkIndex 自然排序遍历临时目录，再用 Files.copy() 追加写入目标文件（配合 StandardOpenOption.APPEND）
- 若需提速，可对每个分片做 CRC32 校验并行化（用 ForkJoinPool.commonPool()），但校验通过后再统一合并，不混合 IO 与计算
- 合并成功后，立即删除临时分片目录，并将最终文件元数据（路径、大小、MD5）落库，同时清空 Redis 中的上传状态键
实战中容易被忽略的线程生命周期管理
大文件上传周期长（可能达数十分钟），线程池若未合理关闭或复用，会导致连接泄漏、句柄耗尽甚至 JVM OOM。
- 不要为每次上传新建线程池；应全局单例复用，按业务域隔离（如 upload-pool、verify-pool、merge-pool）
- 为每个上传会话绑定 MDC（Mapped Diagnostic Context），注入 fileMd5 和 uploadId，使日志可追溯到具体文件
- 上传任务完成后，不调用 shutdownNow()，而是让空闲线程自然超时回收（keepAliveTime 设为 60～120 秒）
- 配合 Spring Boot Actuator 暴露 /actuator/pools 端点，监控 active、queued、completed 任务数，及时发现堆积
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
