Java多线程安全更新共享数组的正确实践

在多线程环境下操作共享数组，稍有不慎就会踩坑。尤其是在处理类似productExceptSelf这类需要并行计算并更新结果数组的场景时，很多人会遇到一个令人抓狂的问题：线程明明跑起来了，但结果数组却没更新。这背后的根源，往往不是代码逻辑本身错了，而是线程间的数据可见性和实例状态管理出了问题。

我们先来看看你提供的原始代码——Threaded继承自Thread类，但问题出在三个关键点上：静态字段滥用、线程实例状态缺失、缺乏线程同步保障。这三者叠加在一起，让多线程陷入了“看似共享，实则混乱”的困境。

具体问题有这么几个

• 静态字段带来的竞态与可见性风险：Solution.nums和Solution.answer被声明为public static，看似方便共享，但实际上就像把所有鸡蛋放在同一个篮子里，而且篮子还没有盖——尤其是在多个测试用例复用同一个类时，数据污染几乎是必然的。
• 构造函数未传递数据引用：Threaded的构造函数没有接收nums和answer的引用，完全依赖静态字段。问题在于，子线程启动时，主线程可能还没完成对静态字段的赋值——在JVM内存模型下，这没有任何happens-before保证。
• 线程操作的是未初始化或陈旧的引用：因为继承了Thread且没有显式传入任务数据，每个线程实际操作的内存视图，很可能根本不是你想的那一份。
• 用ThreadGroup.activeCount()轮询等待：这种方式既不推荐也不可靠。activeCount()只是估算值，并不保证线程确实已经结束。用它来作主线程的等待条件，就像在迷雾中猜路程。

那么，正确的做法是什么？很简单：消除静态共享，通过构造参数显式传递不可变输入和可变输出引用，再用Thread.join()确保有序完成。下面这个优化后的实现，才是最稳妥的方案：

class Solution {
    public int[] productExceptSelf(int[] nums) {
        if (nums == null || nums.length == 0) return new int[0];
        int[] answer = new int[nums.length];
        Thread[] threads = new Thread[nums.length];
        // 启动每个线程，传入独立副本（nums 不变，answer 可写）
        for (int i = 0; i < nums.length; i++) {
            threads[i] = new Thread(new Threaded(nums, answer, i));
            threads[i].start();
        }
        // ✅ 使用 join() 等待所有线程完成（安全、标准、语义明确）
        try {
            for (Thread t : threads) {
                t.join();
            }
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt(); // 恢复中断状态
            throw new RuntimeException("Thread execution interrupted", e);
        }
        return answer;
    }
}

class Threaded implements Runnable {
    private final int[] nums;   // final + 不可变输入，线程安全
    private final int[] answer; // 共享输出数组，由主线程创建并传入
    private final int index;    // 当前线程负责计算的索引

    Threaded(int[] nums, int[] answer, int index) {
        this.nums = nums;
        this.answer = answer;
        this.index = index;
    }

    @Override
    public void run() {
        answer[index] = computeProductExcludingIndex(nums, index);
    }

    private int computeProductExcludingIndex(int[] arr, int excludeIdx) {
        int product = 1;
        for (int i = 0; i < arr.length; i++) {
            if (i != excludeIdx) {
                product *= arr[i];
            }
        }
        return product;
    }
}

这里有几个关键改进值得展开说说：

• 去静态化：移除所有static字段，从根本上杜绝跨测试用例污染和内存可见性问题。每个线程拿到的都是确定的、专属的数据视图。
• 显式依赖注入：Threaded通过构造函数接收nums（只读）、answer（共享写入）和index（职责隔离）。每个线程的任务分工清清楚楚，数据边界一目了然。
• 使用Runnable + Thread组合：比继承Thread更符合面向对象设计原则，资源复用和测试都更方便。这也是行业内的普遍共识。
• join()替代轮询：t.join()提供强语义保证——当前线程会阻塞直至目标线程终止。不需要猜测activeCount()，不需要“等一会儿”的试错逻辑，代码语义清晰而可靠。
• 异常处理：捕获InterruptedException并恢复中断状态，符合Ja va并发编程的最佳实践。这不是一个可有可无的细节。
• 空值防护：主方法增加了边界检查，提升了整体鲁棒性。

不过话说回来，虽然这个方案解决了线程安全更新的问题，但实话实说——对于productExceptSelf这类O(n)时间复杂度的问题，多线程未必能带来性能提升。现代JVM对单线程遍历的优化已经相当高效，而线程创建/调度的开销在小数组（比如长度小于10⁵）上反而会成为瓶颈。如果追求极致性能，更应该优先考虑空间换时间的前后缀积算法——O(1)额外空间，无锁，纯CPU-bound，这才是正道。

总结一下：本篇文章不仅修复了你遇到的并发缺陷，更重要的是想传达一个工程原则——正确性先于优化。多线程不是银弹，必须建立在清晰的数据契约与严谨的同步语义之上。先跑对，再跑快，这个顺序不能颠倒了。