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

　　糟粕代码
　　java8已经出了Stream流处理方式，但是实际业务开发时，大部分同学还是下意识的去写for双层循环。
　　一眼看穿繁华这段代码写法就是典型的for双层循环，我们再细看业务逻辑是判断List所有对象元素中有无重复的，若有重复对象主键，则抛出业务异常。
　　其实业务场景不复杂，那完全可以使用Stream流处理方式，那么大家还是使用for双层循环的原因是什么呢？是习惯，还是处于性能考虑呢？
　　做个试验，验证看看试验场
　　首先模拟个场景：班级里面的学生，学生与班级的匹配，检查学生是否真正是有班级的。先模拟学生类和班级类
　　再搞10W的学生数量和班级数量，不是怀疑是性能吗？数量小了可不行
　　搞一个for双层循环方式for双层循环的方式privatestaticvoiddoubleForMethod（ListStudentstudentList，ListNoClassnoClassList）｛现在用学生与班级进行匹配，如果是班级号一致，认为这个学生是本班级的for（inti0；istudentList。size（）；i）｛StudentstudentstudentList。get（i）；for（intj0；jnoClassList。size（）；j）｛NoClassnoClassnoClassList。get（j）；if（student。getClassesId（）。equals（noClass。getClassId（）））｛System。out。println（该学生：student。getStuId（）是有班级的）；｝｝｝｝
　　再搞一个Stream流方式privatestaticvoidstreamMethod（ListStudentstudentList，ListNoClassnoClassList）｛把班级列表转成map，那么班级id就是唯一的idMapString，NoClassnoClassMapnoClassList。stream（）。collect（Collectors。toMap（tt。getClassId（），tt））；现在用学生与班级进行匹配，如果是班级号一致，认为这个学生是本班级的studentList。stream（）。forEach（h｛if（noClassMap。containsKey（h。getClassesId（）））｛System。out。println（该学生：h。getStuId（）是有班级的）；｝｝）；｝运行比较两者耗时情况
　　最终结果是：for双层循环方式耗时：80438msStream流方式耗时：80ms
　　同一个业务场景，二者处理结果相同，但耗时却是云泥之别，令人惊叹。Stream在背后做了什么？
　　其实，我也不是很清楚，一起来学习吧。
　　如果一上来就了解最底层Stream是怎么实现的，这完全是和自己作对；你丫学《C语言程序设计》的时候，有学for（inti0；i）是怎么完成遍历的吗！
　　回答，肯定是没有呀。对一个知识的掌握，由浅入深，知其特性再探究原因，如果你非要一上来就看Stream源码，也行。我很期待哦，静静地看你表演。
　　Stream的分类
　　了解Stream原理之前，先要知道它的操作分类，因为Stream的操作分类就是实现高效迭代集合的原因之一。
　　官方将Stream中的操作分为两大类：中间操作（Intermediateoperations）和终结操作（Terminaloperations）。中间操作只对操作进行了记录，即只会返回一个流，不会进行计算操作，而终结操作是实现了计算操作。
　　中间操作又可以分为无状态（Stateless）与有状态（Stateful）操作，前者是指元素的处理不受之前元素的影响，后者是指该操作只有拿到所有元素之后才能继续下去。
　　终结操作又可以分为短路（Shortcircuiting）与非短路（Unshortcircuiting）操作，前者是指遇到某些符合条件的元素就可以得到最终结果，后者是指必须处理完所有元素才能得到最终结果。
　　我们通常还会将中间操作称为懒操作，也正是由这种懒操作结合终结操作、数据源构成的处理管道（Pipeline），实现了Stream的高效。Stream的特点数据流从一头获取数据源，在流水线上依次对元素进行操作，当元素通过流水线，便无法再对其进行操作，可以重新在数据源获取一个新的数据流进行操作；对Collection进行处理，一般会使用Iterator遍历器的遍历方式，这是一种外部迭代；而对于处理Stream，只要申明处理方式，处理过程由流对象自行完成，这是一种内部迭代，对于大量数据的迭代处理中，内部迭代比外部迭代要更加高效；Stream的性能
　　那是不是Stream就能完全取代for方式，性能更优呢？也未必。
　　根据官方效率数据显示：
　　多核CPU服务器配置环境下，对比长度100的int数组的性能常规的迭代Stream并行迭代Stream串行迭代多核CPU服务器配置环境下，对比长度1。00E8的int数组的性能；Stream并行迭代常规的迭代Stream串行迭代多核CPU服务器配置环境下，对比长度1。00E8对象数组过滤分组的性能；Stream并行迭代常规的迭代Stream串行迭代单核CPU服务器配置环境下，对比长度1。00E8对象数组过滤分组的性能；常规的迭代Stream串行迭代Stream并行迭代建议多使用Stream吧
　　按官方性能统计来看，使用Stream未必可以使得遍历性能更优，具体的要依赖数据量，即实际应用场景。
　　不过，在我们平时的业务开发中，我建议还是多使用Stream方式。效率是写代码的考虑因素，但不是绝对因素，随着技术的发展，执行效率一定会随着硬件发展而快速提高；对于写代码的人来说，代码一定要以简洁为原则，损失一点效率，换来的是高可读的代码，我觉得是非常值得的。
　　作者：桐言无忌
　　链接：https：juejin。cnpost7057694629474336775