你OUT了吗，for双层循环可以使用stream方式替代

本文已参与「新人创作礼」活动，一起开启掘金创作之路

大家好，我是桐言无忌，当前是不务正业的攻城狮，信奉“实践出真知，生活更简单”，向往自由。 签名.PNG

糟粕代码

java8已经出了Stream流处理方式，但是实际业务开发时，大部分同学还是下意识的去写for双层循环。

陈旧代码

一眼看穿繁华。。。这段代码写法就是典型的for双层循环，我们再细看业务逻辑是判断List<T>所有对象元素中有无重复的，若有重复对象主键，则抛出业务异常。

其实业务场景不复杂，那完全可以使用Stream流处理方式，那么大家还是使用for双层循环的原因是什么呢？是习惯，还是处于性能考虑呢？

做个试验，验证看看。。。

试验场

首先模拟个场景：班级里面的学生，学生与班级的匹配，检查学生是否真正是有班级的。

先模拟学生类和班级类
再搞10W+的学生数量和班级数量，不是怀疑是性能吗？数量小了可不行

搞一个for双层循环方式

// for双层循环的方式
private static void doubleForMethod(List<Student> studentList, List<NoClass> noClassList) {
    // 现在用学生与班级进行匹配，如果是班级号一致，认为这个学生是本班级的
    for (int i = 0; i < studentList.size(); i++) {
        Student student = studentList.get(i);
        for (int j = 0; j < noClassList.size(); j++) {
            NoClass noClass = noClassList.get(j);
            if (student.getClassesId().equals(noClass.getClassId())) {
                // System.out.println("该学生:" + student.getStuId() + "是有班级的");
            }
        }
    }
}
复制代码

再搞一个Stream流方式

private static void streamMethod(List<Student> studentList, List<NoClass> noClassList) {
    // 把班级列表转成map，那么班级id就是唯一的id
    Map<String, NoClass> noClassMap = noClassList.stream().collect(Collectors.toMap(t -> t.getClassId(), t -> t));
    // 现在用学生与班级进行匹配，如果是班级号一致，认为这个学生是本班级的
    studentList.stream().forEach(h -> {
        if (noClassMap.containsKey(h.getClassesId())) {
            // System.out.println("该学生:" + h.getStuId() + "是有班级的");
        }
    });
}
复制代码

运行比较两者耗时情况

最终结果是：

for双层循环方式耗时：80438ms

Stream流方式耗时：80ms

同一个业务场景，二者处理结果相同，但耗时却是云泥之别，令人惊叹。

Stream在背后做了什么？

其实，我也不是很清楚，一起来学习吧。

知识忙去.PNG

如果一上来就了解最底层Stream是怎么实现的，这完全是和自己作对；你丫学《C语言程序设计》的时候，有学for(int i=0;i<n;i++)是怎么完成遍历的吗！

回答，肯定是没有呀。对一个知识的掌握，由浅入深，知其特性再探究原因，如果你非要一上来就看Stream源码，也行。我很期待哦，静静地看你表演。

Stream的分类

了解Stream原理之前，先要知道它的操作分类，因为Stream的操作分类就是实现高效迭代集合的原因之一。

操作分类

官方将 Stream 中的操作分为两大类：中间操作（Intermediate operations）和终结操作（Terminal operations）。中间操作只对操作进行了记录，即只会返回一个流，不会进行计算操作，而终结操作是实现了计算操作。

中间操作又可以分为无状态（Stateless）与有状态（Stateful）操作，前者是指元素的处理不受之前元素的影响，后者是指该操作只有拿到所有元素之后才能继续下去。

终结操作又可以分为短路（Short-circuiting）与非短路（Unshort-circuiting）操作，前者是指遇到某些符合条件的元素就可以得到最终结果，后者是指必须处理完所有元素才能得到最终结果。

我们通常还会将中间操作称为懒操作，也正是由这种懒操作结合终结操作、数据源构成的处理管道（Pipeline），实现了 Stream 的高效。

Stream的特点

数据流从一头获取数据源，在流水线上依次对元素进行操作，当元素通过流水线，便无法再对其进行操作，可以重新在数据源获取一个新的数据流进行操作；
对Collection进行处理，一般会使用 Iterator 遍历器的遍历方式，这是一种外部迭代；

而对于处理Stream，只要申明处理方式，处理过程由流对象自行完成，这是一种内部迭代，对于大量数据的迭代处理中，内部迭代比外部迭代要更加高效；

Stream的性能

那是不是Stream就能完全取代for方式，性能更优呢？也未必。

根据官方效率数据显示：

多核 CPU 服务器配置环境下，对比长度 100 的 int 数组的性能

常规的迭代 <Stream 并行迭代 <Stream 串行迭代

多核 CPU 服务器配置环境下，对比长度 1.00E+8 的 int 数组的性能；

Stream 并行迭代 < 常规的迭代 <Stream 串行迭代

多核 CPU 服务器配置环境下，对比长度 1.00E+8 对象数组过滤分组的性能；

Stream 并行迭代 < 常规的迭代 <Stream 串行迭代

单核 CPU 服务器配置环境下，对比长度 1.00E+8 对象数组过滤分组的性能；

常规的迭代 <Stream 串行迭代 <Stream 并行迭代

建议多使用Stream吧

按官方性能统计来看，使用Stream未必可以使得遍历性能更优，具体的要依赖数据量，即实际应用场景。

不过，在我们平时的业务开发中，我建议还是多使用Stream方式。效率是写代码的考虑因素，但不是绝对因素，随着技术的发展，执行效率一定会随着硬件发展而快速提高；对于写代码的人来说，代码一定要以简洁为原则，损失一点效率，换来的是高可读的代码，我觉得是非常值得的。