minio分块上传线程池需匹配i/o瓶颈，非越大越好；应以压测为准，从cpu核心数×2起步，配合paralleluploads参数实现文件级与分片级两层并发，并同步调优http连接池、超时及重试机制。
线程池大小要匹配I/O瓶颈，不是越大越好
MinIO分块上传本质是网络I/O密集型操作，CPU占用低但受限于带宽、连接数和服务端处理能力。盲目增大线程池（如设为100）反而会引发HTTP连接池耗尽、TIME_WAIT堆积、MinIO服务端限流或Java应用OOM。实际调优应以压测结果为准：先从CPU核心数×2起步（例如8核机器用16线程），再逐步增加并监控上传吞吐量、失败率和系统资源（尤其是`netstat -an | grep :9000 | wc -l`查看连接数）。当吞吐量不再上升甚至下降时，即为当前环境的最优线程数。
用独立线程池隔离MinIO上传任务
避免与业务线程池混用，防止上传阻塞接口响应。推荐创建专用的`ThreadPoolExecutor`，配置关键参数：
- 核心线程数：设为预估并发上传任务数（如5–20，视文件规模和服务器负载而定）
- 最大线程数：略高于核心数（如核心10 → 最大15），防突发流量但不放任无限制增长
- 拒绝策略：用`CallerRunsPolicy`，让调用线程自己执行任务，起到自然降速作用，比直接抛异常更可控
- 队列类型：选`SynchronousQueue`（无缓冲），配合`CallerRunsPolicy`可有效防止任务积压导致内存飙升
配合SDK的parallelUploads参数协同控制并发粒度
MinIO Java SDK的`putObject`内部已支持分片级并行，通过`.parallelUploads(N)`指定每个文件的分片上传线程数。这与外层线程池形成“两层并发”：
- 外层线程池控制文件级并发（同时上传几个大文件）
- `parallelUploads`控制单文件内部分片级并发（一个GB文件拆成100个part，其中5个part同时上传）
- 二者相乘才是真实并发请求数。例如：外层10线程 × parallelUploads=3 → 理论最高30个HTTP上传请求同时发出
- 建议组合策略：小文件（100MB）设`parallelUploads=3~5`，外层线程池保持适中（如8~12）
连接池与超时必须同步调优
线程池再合理，若HTTP连接没管好，照样卡死。MinIO客户端默认使用OkHttp，需显式配置：
- 连接池大小：`maxIdleConnections`和`maxConnectionAgeMillis`要与线程池规模对齐。例如外层12线程，建议设`maxIdleConnections=20`，避免频繁建连开销
- 超时设置：`readTimeout`和`writeTimeout`建议设为30~60秒（大文件上传本身耗时长），`connectTimeout`设为5秒即可。过短易误判超时，过长则故障恢复慢
- 重试机制：启用SDK内置重试（`.retry(RetryConfig.builder().maxAttempts(3).build())`），但避免与线程池重试叠加，外层不额外捕获重试
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
