Java多线程聚合链接数据：并行流收集结果性能优化咨询

你的问题核心在于同步列表的锁竞争——Collections.synchronizedList给整个列表加了全局锁，每次add操作都需要线程竞争获取锁，而并行流的多线程环境会让这种竞争变得非常激烈，直接拖慢了整体速度。下面是几个高效的优化方案：

方案1：使用并行流原生的收集器（最优选择） #

Java的Collectors工具类专门为并行流设计了高效的收集逻辑，它会为每个线程分配独立的本地容器，最后再合并结果，完全避免了全局锁的竞争。

修改后的代码如下：

import java.util.Objects;
import java.util.stream.Collectors;

// ...

List<String> resultList = Arrays.stream(link)
    .parallel()
    .map(link -> {
        try {
            return doSomeJobWithLink(link);
        } catch (IOException e) {
            e.printStackTrace();
            return null; // 标记异常的结果，后续过滤
        }
    })
    .filter(Objects::nonNull) // 过滤掉异常返回的null
    .collect(Collectors.toList());

resultList.forEach(System.out::println);

如果不需要结果的顺序，还可以使用Collectors.toUnmodifiableList()或者显式指定并发特性，进一步提升性能：

.collect(Collectors.collectingAndThen(
    Collector.of(
        ArrayList::new,
        List::add,
        (left, right) -> { left.addAll(right); return left; },
        Collector.Characteristics.CONCURRENT, Collector.Characteristics.UNORDERED
    ),
    ArrayList::new
));

方案2：用CompletableFuture自定义线程池（适合IO密集型任务） #

如果你的doSomeJobWithLink是IO密集型操作（比如网络请求、文件读取），并行流默认的ForkJoinPool线程数（等于CPU核心数）可能无法充分利用资源——因为IO操作时线程大多处于等待状态。这时用CompletableFuture配合自定义线程池可以更灵活地控制并发数：

import java.util.concurrent.CompletableFuture;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;

// ...

// 线程数可以根据IO密集型任务调整，比如CPU核心数*2或者10（避免线程过多导致上下文切换）
ExecutorService executor = Executors.newFixedThreadPool(Math.min(link.length, 10));

List<CompletableFuture<String>> futures = Arrays.stream(link)
    .map(url -> CompletableFuture.supplyAsync(() -> {
        try {
            return doSomeJobWithLink(url);
        } catch (IOException e) {
            e.printStackTrace();
            return null;
        }
    }, executor))
    .collect(Collectors.toList());

// 等待所有任务完成并收集结果
List<String> resultList = futures.stream()
    .map(CompletableFuture::join) // 非阻塞等待，会抛出未检查异常（如果有的话）
    .filter(Objects::nonNull)
    .collect(Collectors.toList());

executor.shutdown(); // 关闭线程池
resultList.forEach(System.out::println);

这个方案的优势在于：你可以根据任务类型调整线程池大小，IO密集型任务用更多线程能显著提升效率，同时避免了并行流默认池和其他共享任务的冲突。

为什么原来的同步列表方案慢？ #

Collections.synchronizedList的add方法是同步的，意味着每次只有一个线程能执行add操作。当并行流的多个线程同时尝试添加元素时，大部分线程都会处于等待锁的状态，大量的时间浪费在锁竞争上，自然导致耗时从2秒飙升到5-8秒。

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