为何Java ExecutorService多线程实现性能低于单线程实现？

1. 存在明确的逻辑bug：futures列表从未清空 #

你将futures列表的初始化放在了while循环外侧，第一轮循环会往列表中添加199个行处理任务，第二轮循环会继续在原有列表基础上追加199个任务，循环100轮后列表里会堆积19900个Future对象。后续遍历执行f.get()时，你会把所有历史轮次早已执行完成的任务全部遍历等待一遍，平白增加了巨量无意义的遍历开销，运行轮数越多这个损耗越大。

2. 任务粒度过细，线程调度开销远大于计算收益 #

200*200规格的棋盘总共仅4万个格子，你按行拆分出199个任务，每个任务仅处理200个格子的生命游戏逻辑，计算耗时在百纳秒级别，但线程池提交任务、操作系统调度线程、Future同步等待的开销在微秒级，调度成本是计算成本的几十上百倍，跑得比单线程慢是必然结果。

3. 任务拆分逻辑与线程池能力不匹配 #

你配置的线程池大小为CPU核心数，但拆分出的任务数是核心数的几十倍，大量短生命周期任务在线程池中排队、触发频繁的线程上下文切换，CPU会把大量时间耗费在线程调度上，而非实际的棋盘状态计算。同时按行拆分任务时，相邻行的内存地址距离极近，多线程访问很容易触发CPU缓存伪共享问题，进一步拉低缓存命中率——单线程运行时反而可以顺利利用CPU L1/L2缓存的高速访问优势，自然表现更好。

• 先修复基础逻辑bug：把futures列表的初始化移到while循环内部，每轮迭代新建空列表存储当前轮次的任务，不要堆积历史任务。
• 粗化任务粒度：不要按行拆分任务，直接对齐线程池的核心数拆分，例如8核CPU就拆成8个任务，每个任务负责连续25行（200/8）的计算，把线程调度的开销占比压到1%以下。
• 遵循康威生命游戏的计算规则：计算下一代状态时必须基于上一代的完整快照，不能边计算边修改原棋盘，否则多线程下会读到半更新的状态，导致计算结果错误。可以准备两个二维数组，一个存当前代状态、一个存下一代状态，所有计算任务只读当前代数组，仅写入自己负责的下一代数组分片，完全避免线程间读写竞争，不需要加任何锁。
• 可以用CountDownLatch代替Future列表做同步：不需要每个任务都返回冗余的Integer值，每轮初始化一个计数器等于任务数的CountDownLatch，任务执行完就调用countDown()，主线程仅需调用一次await()即可等待所有任务完成，比遍历大量Future对象的开销更低。

优化后的核心逻辑参考：

public void processTask() {
    int threadNum = Runtime.getRuntime().availableProcessors();
    int sliceSize = board.length / threadNum;
    // 下一代状态数组，和当前代数组分离避免读写冲突
    boolean[][] nextBoard = new boolean[board.length][board[0].length];

    for (int round = 0; round < count; round++) {
        CountDownLatch latch = new CountDownLatch(threadNum);
        // 按CPU核心数拆分为少量大粒度任务
        for (int t = 0; t < threadNum; t++) {
            int startRow = t * sliceSize;
            int endRow = (t == threadNum - 1) ? board.length : (t + 1) * sliceSize;
            threadPool.submit(() -> {
                try {
                    for (int k = startRow; k < endRow; k++) {
                        for (int l = 0; l < board[0].length; l++) {
                            // 此处实现生命游戏规则：只读board数组，只写入nextBoard[k][l]
                        }
                    }
                } finally {
                    latch.countDown();
                }
            });
        }

        try {
            latch.await();
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
            return;
        }
        // 交换两个数组引用，下一轮直接基于刚算完的状态继续计算
        boolean[][] temp = board;
        board = nextBoard;
        nextBoard = temp;
    }
    threadPool.shutdown();
}

额外说明：200200的棋盘本身计算量极小，就算完成上述优化，多线程版本也未必比单线程快，核心数较少的设备上单线程反而更优。多线程从来不是性能银弹，只有当单个任务的计算量足够大、线程调度开销占比足够低的时候，多线程才能带来明确的性能收益。如果把棋盘规格提升到20002000甚至更大，再使用上述多线程方案，就能看到非常明显的性能提升。

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