大文件IO应使用专用有界线程池，corePoolSize设为平均并发数（如5～8），maximumPoolSize依系统文件描述符限制设定（如120），配ArrayBlockingQueue(800)与CallerRunsPolicy。
大文件IO（如读写GB级文件、网络流传输、数据库BLOB操作）属于典型的阻塞型IO任务，线程一旦调用FileInputStream.read()或BufferedOutputStream.write()等方法，就会挂起等待磁盘或系统缓冲区就绪。用默认线程池处理这类任务极易导致线程耗尽、任务堆积、响应停滞——不是慢，是卡死。
核心配置原则：线程数看IO并发量，不看CPU核数
大文件IO的瓶颈不在CPU，而在磁盘吞吐、内存缓冲、文件句柄和系统I/O调度能力。此时线程池大小应匹配「同时打开的大文件流数量」和「系统能稳定支撑的并发IO操作数」，而非CPU核心数。
- corePoolSize建议设为预期平均并发大文件任务数（例如：平均同时处理3个500MB上传+2个导出下载 → 设为5～8）
- maximumPoolSize需结合系统限制设定：Linux默认
ulimit -n通常为1024，每个大文件流至少占用1个文件描述符；若max设为200，意味着最多支持约150个活跃大文件操作（留余量给日志、网络连接等） - 不要盲目设高（如500+），否则触发频繁GC、上下文切换激增，反而吞吐下降
必须用有界队列 + 显式拒绝策略
无界队列（如new LinkedBlockingQueue()无参构造）是大文件IO场景的“定时炸弹”：任务持续提交→队列无限增长→堆内存缓慢膨胀→Full GC频发→服务假死。
- 首选
ArrayBlockingQueue(500)或LinkedBlockingQueue(1000)，容量根据业务峰值预估（例如每秒最多接收20个大文件请求，超时30秒，则队列≥600） - 拒绝策略必须启用兜底逻辑：
CallerRunsPolicy可让上游降速，避免雪崩；更推荐自定义策略：记录告警+返回“排队中”响应+写入本地磁盘缓冲队列异步重试 - 禁用
AbortPolicy（静默失败）和DiscardOldestPolicy（丢旧任务易丢关键文件）
配套关键优化：避免单任务拖垮整个池
一个大文件读取卡住10秒，不该让整条线程闲置10秒。需从代码层配合线程池：
- 设置IO超时：用
FileChannel.transferTo()替代循环read/write；对网络文件使用带timeout的HttpURLConnection.setConnectTimeout() - 分块处理：将1GB文件切为10MB分片，每个分片作为独立任务提交，失败可重试局部，不阻塞全局
- 资源强释放：确保
try-with-resources包裹所有流，配合finalizer或Cleaner防范泄漏；大文件任务结束后主动调用System.gc()非必须，但可显式ByteBuffer.clear()释放直接内存 - 隔离部署：大文件IO线程池必须与HTTP处理、定时任务、数据库查询等线程池物理隔离，防止相互拖累
示例配置（生产可用）
以下为适配大文件IO的ThreadPoolExecutor显式构造方式，避开Executors工厂陷阱：
int cpu = Runtime.getRuntime().availableProcessors();
ThreadPoolExecutor ioPool = new ThreadPoolExecutor(
8, // core: 支持平均8路并发大文件
120, // max: 预留弹性，不超过ulimit-n/2
30L, TimeUnit.SECONDS, // 空闲线程30秒后回收
new ArrayBlockingQueue<>(800), // 有界队列，防OOM
new ThreadFactoryBuilder()
.setNameFormat("bigfile-io-%d")
.setDaemon(true)
.build(),
new ThreadPoolExecutor.CallerRunsPolicy() // 调用方执行，自然限流
);
