Java列表映射优化咨询：循环与Optional+Lambda的性能对比及NPE规避

嘿，我来帮你梳理下这个问题～你现在的需求是在列表操作中避免空指针异常（NPE），同时纠结要不要用Lambda+Optional替代现有嵌套循环，还要兼顾性能对吧？咱们一步步来拆解：

现有代码的优缺点 #

你的嵌套循环写法其实性能是很不错的——因为它是直接的迭代操作，没有额外的包装或抽象开销，JVM能很好地优化这种代码。但缺点也很明显：大量的空判断让代码显得臃肿，可读性和可维护性差一点，尤其是嵌套层级多了之后容易出错。

用Lambda+Optional优化的方案 #

我们可以结合Java Stream API和Optional来简化代码，同时完全避免NPE。先给你看优化后的代码：

优化版本1（兼容原实体类） #

import java.util.*;
import java.util.stream.Collectors;

public class MyClass {
    public static void main(String args[]) {
        List<MyObject> objList = getList();
        
        List<String> descList = Optional.ofNullable(objList)
                // 如果objList为null，用空列表替代，避免后续stream空指针
                .orElse(Collections.emptyList())
                .stream()
                // 过滤data非空且不为空串的MyObject
                .filter(o -> o.getData() != null && !o.getData().isEmpty())
                // 取出子列表objList
                .map(MyObject::getObjList)
                // 过滤子列表为null的情况
                .filter(Objects::nonNull)
                // 扁平化子列表，把多个List<MySecondObject>合并成一个流
                .flatMap(List::stream)
                // 过滤desc非空且不为空串的MySecondObject
                .filter(s -> s.getDesc() != null && !s.getDesc().isEmpty())
                // 收集结果到List
                .collect(Collectors.toList());
    }
}

优化版本2（推荐：实体类做防御性编程） #

如果能修改MyObject类，让getObjList()返回空列表而非null，代码会更简洁：

class MyObject {
    // ... 原有属性
    
    public List<MySecondObject> getObjList() {
        // 防御性编程：返回空列表代替null
        return objList == null ? Collections.emptyList() : objList;
    }
}

此时业务代码可以去掉子列表的空判断：

List<String> descList = Optional.ofNullable(objList)
        .orElse(Collections.emptyList())
        .stream()
        .filter(o -> o.getData() != null && !o.getData().isEmpty())
        .flatMap(o -> o.getObjList().stream())
        .filter(s -> s.getDesc() != null && !s.getDesc().isEmpty())
        .collect(Collectors.toList());

性能对比：哪种更快？ #

这是你最关心的点，结论是：

• 大多数业务场景下，两者性能几乎无差异：Stream API在JVM经过JIT编译后，会被优化成接近普通循环的字节码，尤其是在数据量不大的时候，你根本感知不到区别。
• 极端性能敏感场景（百万级以上数据）：普通嵌套循环可能会略胜一筹，因为它没有Stream的抽象层开销。但这种差异非常小，除非你有严格的性能指标要求，否则可读性的提升更值得优先考虑。

最终建议 #

• 如果你的团队熟悉Stream API，优先选择Lambda+Optional的方案：代码更简洁、可读性更高，且性能足够满足绝大多数场景。
• 如果是极端性能敏感的场景，或者团队对Stream不熟悉，保留现有循环也没问题，但建议给实体类加上防御性编程（返回空列表而非null），减少空判断的冗余代码。

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