Java中使用不纯函数遍历集合的最佳实践及相关问题

场景说明 #

需要更新类内部的HashMap缓存，拥有一组待处理的键，需对这些键及通过键获取的值应用特定条件。

代码示例1 #

import java.util.ArrayList;
import java.util.HashMap;
import java.util.List;
import java.util.Set;

public class App {

    Set<String> keysToUpdate;
    HashMap<String, List<String>> cache;

    void buildCache(){
        keysToUpdate.stream()
            .filter(k -> true)  // 某些过滤条件
            .forEach(
                key ->{
                    // 此时values列表来自流管道外部
                    List<String> values = cache.computeIfAbsent(key, k -> new ArrayList<>());
                    getValuesforKey(key)
                        .stream()
                        .filter(k -> true) //另一个过滤条件
                        // 引入副作用
                        .forEach(value -> {
                                //一些其他操作，例如记录添加的值，如
                                // log.info("{} value added", value);
                                values.add(value);
                            }
                        );
                }

            );
    }
    private List<String> getValuesforKey(String key) {
        //根据键获取值的方法
        return new ArrayList<>();
    }
}

通常认为此类共享可变操作存在问题，因为执行结果不具有确定性，但在此场景中，已知keysToUpdate无重复键，且不在意执行顺序。现提出以下问题：

1. 是否存在未考虑到的其他隐患？ #

有几个容易忽略的隐患：

• 线程安全风险：HashMap和ArrayList都不是线程安全的，如果后续有其他线程同时读写cache或对应的values列表，会引发并发修改异常、数据丢失或脏读问题，哪怕当前buildCache是单线程执行。
• 维护性问题：流中嵌入副作用操作的可读性差，后续维护者可能误判代码逻辑，比如随意改成并行流，或者修改过滤条件时引入意外的并发问题。
• 原子性缺失：computeIfAbsent是原子操作，但后续对values的add操作不是，若其他线程同时操作同一个key的列表，依然会出现线程安全问题。

2. 若将流并行化，此代码是否安全？ #

完全不安全，核心问题在于：

• HashMap本身不支持并发修改，并行流中多个线程同时调用computeIfAbsent可能触发HashMap的结构修改（如扩容），引发线程安全问题。
• 每个key对应的ArrayList是线程不安全的，并行处理时多个线程同时执行values.add(value)会导致ConcurrentModificationException，或者出现元素丢失、重复的情况。
• 即使keysToUpdate无重复，并行流的执行机制也可能导致对共享资源的并发访问，破坏数据一致性。

3. 若不安全，使用集合的迭代器能否解决问题？（代码示例如下） #

代码示例2的做法（先collect到List再forEach）本质上还是单线程遍历，并没有解决并行化的安全问题。这种方式只是把流的元素提前收集，避免了流管道内部的不确定性，但如果依然启用并行流，HashMap和ArrayList的线程安全问题依然存在。要解决并行安全问题，需要替换线程安全的集合（比如ConcurrentHashMap+CopyOnWriteArrayList），或者在修改共享资源时加锁，单纯用迭代器/提前收集元素无法解决核心的并发问题。

代码示例2 #

import java.util.ArrayList;
import java.util.HashMap;
import java.util.List;
import java.util.Set;
import java.util.stream.Collectors;

public class App {

    Set<String> keysToUpdate;
    HashMap<String, List<String>> cache;

    void buildCache(){
        keysToUpdate.stream()
            .filter(k -> true)// 某些过滤条件
            .collect(Collectors.toList()) // 迭代前先收集
            .forEach(
                key ->{
                    // 此时values列表来自流管道外部
                    List<String> values = cache.computeIfAbsent(key, k -> new ArrayList<>());
                    getValuesforKey(key)
                        .stream()
                        .filter(k -> true) //另一个过滤条件
                        .collect(Collectors.toList()) // 迭代前先收集
                        // 引入副作用
                        .forEach(value -> {
                                //一些其他操作，例如记录添加的值，如
                                // log.info("{} value added", value);
                                values.add(value);
                            }
                        );
                }

            );
    }
    private List<String> getValuesforKey(String key) {
        //根据键获取值的方法
        return new ArrayList<>();
    }
}

4. 或者使用命令式编程是否更合适？ #

在这个场景下，命令式编程确实更合适：

• 逻辑直观清晰：命令式的for循环写法直接体现“遍历键→获取值→更新缓存”的流程，维护者一眼就能理解，不会被流API的抽象层迷惑。
• 更易控制副作用：针对共享缓存的修改逻辑一目了然，后续要加锁、调整顺序或增加校验都更方便。
• 流的设计初衷是无副作用的函数式操作，处理有状态的缓存更新时，命令式写法更贴合场景，避免强行套用流API带来的代码晦涩问题。

5. 流中的共享可变操作在何种场景下是可行的？ #

只有满足以下所有条件时，才可以考虑在流中使用共享可变操作：

• 单线程执行：完全没有并发访问共享资源的可能，避免线程安全问题。
• 副作用范围明确：共享变量仅在当前流操作中被修改，不会被其他代码或线程访问。
• 逻辑简单且可读性不受影响：副作用操作逻辑简单，不会让流的代码变得晦涩难懂，相比命令式写法没有明显劣势。
• 无替代方案：确实无法用collect等无副作用的流操作实现，必须依赖共享可变操作。

比如单线程下统计一个本地计数器，或者单线程下更新一个仅在当前方法内使用的临时集合，这类场景可以勉强使用，但依然建议优先用无副作用的流操作。

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