如何修复Java 8 IntStream并行更新外部Map时的IndexOutOfBoundException？

问题分析与解决方案 #

从你描述的情况和代码来看，这个IndexOutOfBoundException大概率不是因为循环的index超出范围（毕竟16264远小于16384），而是两个常见原因导致的：

1. 非线程安全的Map引发并发修改异常

如果你的slotMap是普通的HashMap，那在并行流的多线程环境下执行put操作必然会出问题。HashMap本身不是线程安全的，当多个线程同时修改它的内部结构（比如扩容、链表节点插入）时，会导致内部数据结构混乱，进而抛出各种异常——包括你遇到的IndexOutOfBoundException，此时报错时的index只是刚好触发异常的线程任务，和循环范围本身无关。

解决办法：
把slotMap换成线程安全的ConcurrentHashMap，它专门针对并发场景做了优化，能安全处理多线程下的put操作：

// 初始化时替换为ConcurrentHashMap
Map<String, Integer> slotMap = new ConcurrentHashMap<>();

IntStream.range(0, 16384).parallel().forEach(index -> {
    String slotKey = String.valueOf(index);
    slotMap.put(slotKey, cacheService.getCountOfKeysInSlots(index));
    System.out.println(index);
});

2. cacheService.getCountOfKeysInSlots(index)方法内部存在越界问题

另一种可能是这个业务方法本身的逻辑有漏洞：比如方法内部使用了长度小于16384的数组/集合，当传入的index为16264时，直接超出了容器的访问范围，触发了IndexOutOfBoundException。

排查建议：

• 查看该方法的源码，检查是否有类似array[index]的直接数组访问，确认数组长度是否能覆盖0到16383的所有index；
• 打印异常的完整堆栈信息，看异常触发点是在slotMap.put()还是cacheService.getCountOfKeysInSlots()中，这能直接定位问题根源。

更符合流设计的优化方案

其实并行流的设计初衷更推荐用collect收集结果，而非修改外部可变状态，这种方式无需手动处理线程安全，代码也更简洁：

Map<String, Integer> slotMap = IntStream.range(0, 16384)
    .parallel()
    .boxed()
    .collect(Collectors.toConcurrentMap(
        index -> String.valueOf(index),
        index -> cacheService.getCountOfKeysInSlots(index)
    ));

toConcurrentMap会自动处理并发收集逻辑，从根源避免了外部Map的线程安全问题。

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