多文件上传连接超时异常排查及性能优化技术咨询

3. 为何使用parallelStream仍会随文件数量增加导致响应时间变长？ #

• parallelStream的并行度默认由CPU核心数决定，但你的瓶颈在网络IO和外部服务的并发处理能力，而非CPU计算。就算开启并行流，若RestTemplate底层未配置连接池，每次请求都会新建TCP连接，握手、建立连接的开销会持续叠加；而且外部服务大概率有并发限流机制，同时接收多个请求时会排队处理，单个请求的响应时间会被拉长（比如单文件6秒，4个并发请求可能每个都要等前面的请求处理完，总时间就变成6*5=30秒）。
• 另外，parallelStream依赖共享的ForkJoinPool线程池，若系统中其他任务也在使用这个池，会进一步挤占上传任务的线程资源，导致实际并发度达不到预期，上传速度自然变慢。

1. 可采取的响应速度提升措施 #

• 改用多文件批量上传：将多个文件打包成一个multipart/form-data请求发送，减少HTTP请求的握手、头部等固定开销，这是提升速度最直接的方式。
• 给RestTemplate配置连接池：替换默认的SimpleClientHttpRequestFactory，改用Apache HttpClient或OkHttp作为底层客户端，配置合理的最大连接数、单路由最大连接数，复用TCP连接，避免每次新建连接的耗时。示例代码（HttpClient）：

  HttpComponentsClientHttpRequestFactory factory = new HttpComponentsClientHttpRequestFactory();
  CloseableHttpClient httpClient = HttpClientBuilder.create()
          .setMaxConnTotal(10)
          .setMaxConnPerRoute(5)
          .build();
  factory.setHttpClient(httpClient);
  RestTemplate restTemplate = new RestTemplate(factory);
  

• 自定义并行度或改用CompletableFuture：不要依赖parallelStream的默认并行度，用自定义ForkJoinPool控制并发数，或者用CompletableFuture配合固定大小的线程池，根据外部服务的并发能力设置合理的并发数（比如外部服务允许3个并发请求，就设3个线程），避免过度并发导致外部服务限流。
• 优化文件传输方式：如果当前是将文件编码为Base64再传输，直接传二进制字节流——Base64会让文件体积增加约30%，大幅增加传输时间。
• 压缩文件后上传：对非压缩格式的文件（比如文本、图片）进行压缩，减小传输体积，降低带宽消耗。

2. 避免连接超时异常的措施 #

• 调整超时参数：在RestTemplate的连接池配置中，合理设置连接超时（connectTimeout）、读取超时（readTimeout），比如单文件上传需6秒，读取超时可设为10-15秒；同时设置连接池的连接存活时间，清理无效连接。
• 严格控制并发请求数：根据外部服务的处理能力，限制同时发送的请求数量，避免因请求排队导致超时。比如用固定大小的线程池，核心线程数设为2-3，确保不会超过外部服务的并发上限。
• 添加重试机制：针对连接超时异常，实现幂等的重试逻辑（比如给每个文件加唯一标识，外部服务根据标识去重），避免因临时网络波动导致上传失败。
• 排查外部服务限制：确认外部服务是否有请求频率、并发数或带宽限制，若超出限制会被拒绝或延迟响应，需和服务提供方沟通调整配额。

内容的提问来源于stack exchange，提问作者Queen