Java8 源码阅读之——Stream

** 写在前面的话:本人作为一枚纯技术爱好者,一直喜欢利用闲暇写一点自己研究的收获和体会。虽然力求谨慎,但个人见解难免会有有失偏颇的时候,还望各位读者批评指正! **

Stream的继承关系

要想吃透Stream的设计,最好还是从它的UML设计图开始。通过上图我们可以看到,貌似BaseStream是作为核心流操作的规范存在,那么我们就先以它为切入点开始剖析整个Stream的体系。

AutoCloseable接口

但在BaseStream之上仍然有一个AutoCloseable接口,虽然这个接口很简单,但我们还是先看一下吧。

This construction ensures prompt release, avoiding resource exhaustion exceptions and errors that may otherwise occur.

这段截取自该接口的注释,大致意思就是这个结构保证了资源的及时释放,避免发生资源枯竭带来的异常。

Stream顾名思义“流”,这个流可能来自文件、网络I/O……所以JDK在顶层定义了这样一个接口,规定了流的实现类在资源使用完成或者遇到异常的时候及时释放资源,避免发生资源枯竭。

所以这个接口也只声明了一个方法: void close() throws Exception 也就是关闭流操作。

BaseStream 接口

现在正式开始介绍BaseStream,我们先来大致看一下它都定义了哪些规范。

Iterator<T> iterator()

定义了每个Stream都需要提供返回一个迭代子对象的方法。

Spliterator<T> spliterator()

和iterator() 方法类似,但返回的对象是Spliterator而不是Iterator。Spliterator可以将元素分割成多份,分别交于不于的线程去遍历,以提高效率。

使用Iterator的时候,我们可以顺序地遍历容器中的元素,使用Spliterator的时候,我们可以将元素分割成多份,分别交于不于的线程去遍历,以提高效率。

boolean isParallel()

判断该流是不是并行执行。

S sequential()

返回一个串行流,如果该流本身就是串行的,则返回他本身。

S parallel()

返回一个并行流,如果该流本身就是并行的,则返回他本身。

S unordered()

返回一个无序流,如果该流本身就是无序的,则返回他本身。

S onClose(Runnable closeHandler)

返回一个带着关闭处理的流。closeHandler线程将在调用close()方法时执行。

乍一看定义的方法很多,但实际上只有三类。第一类是iterator() 和 spliterator()操作提供了遍历元素的方法。

第二类是 sequential()、parallel()、unordered()对流进行转化,返回一个指定的流。

第三类就是对关闭流方法的处理。

总结来讲,BaseStream并没有对具体流的操作做任何说明,只是规定了三种流的形式和提供了两种遍历流的方式——单线程、多线程两种遍历方式。

最后再提一下关于BaseStream这个接口的定义: interface BaseStream<T, S extends BaseStream<T, S>>这个定义方式也是很奇特——泛型的第二个参数必须是自己的子类。

看了JDK关于T和S的解释,T是指定stream元素的类型,S是stream的实现类。

看完也就理解了,它使用S规定了创建流的类型,而这个接口有4个方法会返回指定流,所以才需要规定流的类型必须是BaseStream的实现类。

Stream 接口

实际上BaseStream并没有定义任何与具体流的操作,所以我们只能把目光转向它的子接口。 BaseStream 接口下面有4个继承接口和一个抽象类,之所以选Stream接口是因为从命名上来看IntStream、LongStream、DoubleStream与是作为特殊数据特殊处理的Stream而存在的,所以我们姑且可以先看Stream接口。

这篇文章的目的是拆解分析整个Java8 Stream体系,过多介绍某个接口或实现类的方法并没有太大的意义,所以挑了几个比较具有代表性的方法。

Stream<T> filter(Predicate<? super T> predicate)

该方法接收一个lambda表达式(Predicate类型)过滤出符合条件的元素,并返回一个新流。

<R> Stream<R> map(Function<? super T, ? extends R> mapper)

该方法接收一个lambda表达式(Function类型)过滤出符合条件的元素,并返回一个新流。

T reduce(T identity, BinaryOperator<T> accumulator)

该方法接收一个lambda表达式(BiFunction类型)过滤出符合条件的元素,并返回结果。

void forEach(Consumer<? super T> action)

和以上方法类似,传入一个lambda表达式(Consumer类型),遍历流,无返回值。

这些接口看着差别很大,但仔细研究一下就会发现,他们都是传入一个Lambda表达式,这个表达式会对流的元素进行一定操作,只是返回值有差异而已。filter、map是返回一个新流,reduce是返回结果,forEach是对元素遍历。

对比于List接口定义的一些抽象——get、set、add、remove……,我们可以发现传统的Collection的关注点在元素,而Stream的关注点在于函数,更确切的讲是对数据的计算。所以我们认为Stream的出现是对Collection的一种补充。

一些新的概念

JDK的作者有一个很好的习惯,就是在重要的接口定义上会有非常详细的注释。Stream也不例外,一个简单的Stream有着100多行的注释。

随着对注释的解读,我发现作为对Collection的补充,Stream不仅有着很便捷的语法,对大数据量的处理也有更高的效率,以下是本人对一些比较重要的特点的一些总结。

  • 关于stream的操作,大体可以划分为两类—— intermediate operationsterminal operation

    这两者有什么区别呢?

    intermediate operations 按照原文的解释就是: which transform a stream into an other stream, such as Stream#filter(Predicate) 意思就是一个stream处理以后返回的是一个新的stream那么就称之为intermediate operations

相对的 terminal operation 对应的操作就是那些产生了一定结果或者其他影响的操作,例如: Stream#count()} 或者 Stream#forEach(Consumer)}

为什么JDK会把stream的操作区分为以上两种形式呢?原因他们也给了解释: Streams are lazy; computation on the source data is only performed when the terminal operation is initiated, and source elements are consumed only as needed.

Streams 是懒加载的,仅在启动terminal操作时才执行源数据的计算,并且仅根据需要消耗源元素。

  • Stream与Collection的本质区别

    根据JDK作者的解释,虽然他们之间有着很多相似的地方,但他们设计的目标是不一样的。

    集合主要关注的是管理和访问他们的元素,相比之下,流不直接访问或操纵元素提供了一种手段,而是关注对流进行聚合等计算操作。

    当然了,流也提供了 iterator()和spliterator() 两个方法对流进行遍历。

总结:

  • 关于Java8 Stream的引入是对原先Collection的一个扩展。

  • Java8之前的Collection,例如List、Map等更关注对单个元素的操作,更适用于的访问、修改。还有一个很重要的特性就是一旦对象被创建,那么Collection将直接占用相应的堆内存。

  • 而Stream则不同,它使用"流"的概念,注重对数据的过滤、聚合等操作,但并不修改数据源本身。而且还有一个很重要的特性就是Stream只有在使用到的时候才会加入内存,并且仅根据需要消耗源元素。所以,流式计算更适合于大数据量的过滤、统计等操作。

  • 最后夹带一点私货,看了JDK关于接口的设计,真的是非常有收获,当我看到BaseStream这个接口的时候,下意识以为这个接口至少会定义一些流的基本操作,但是实际上它仅仅规定了流的方向——迭代子遍历,串行、并行以及他们之间的转化,而真正对于流的操作则是放到了Stream接口里。** 阅读源码最大的好处不是知道怎么去用这些方法,而是学习他们怎么去设计这些接口、管理他们之间的复杂关系(所以我才从UML入手)。 **这也是我孜孜不倦的原因,共勉!

*** To be continue……***

** 关于文章开头UML图中的XXXPipeline也是非常重要且优雅的设计,我会在下一章揭开它的神秘面纱。**

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 204,684评论 6 478
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 87,143评论 2 381
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 151,214评论 0 337
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,788评论 1 277
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,796评论 5 368
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,665评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 38,027评论 3 399
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,679评论 0 258
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 41,346评论 1 299
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,664评论 2 321
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,766评论 1 331
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,412评论 4 321
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 39,015评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,974评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,203评论 1 260
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 45,073评论 2 350
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,501评论 2 343

推荐阅读更多精彩内容

  • Spring Cloud为开发人员提供了快速构建分布式系统中一些常见模式的工具(例如配置管理,服务发现,断路器,智...
    卡卡罗2017阅读 134,596评论 18 139
  • Java8 in action 没有共享的可变数据,将方法和函数即代码传递给其他方法的能力就是我们平常所说的函数式...
    铁牛很铁阅读 1,213评论 1 2
  • Jav8中,在核心类库中引入了新的概念,流(Stream)。流使得程序媛们得以站在更高的抽象层次上对集合进行操作。...
    仁昌居士阅读 3,619评论 0 6
  • 1. Java基础部分 基础部分的顺序:基本语法,类相关的语法,内部类的语法,继承相关的语法,异常的语法,线程的语...
    子非鱼_t_阅读 31,573评论 18 399
  • 某年某月某日 意外和你相识 并不深刻 某年某月某日 看了你一眼 无关心动 怎知日子一久 你就三三两两懒懒幽幽 停在我心上
    与闲言阅读 413评论 0 0