Java 中的泛型

泛型是什么

泛型，即“参数化类型”，最熟悉的就是定义方法时有形参，然后调用此方法时传递实参。

引入一个类型变量 T（其他大写字母都可以，不过常用的就是 T，E，K，V 等等），并且用<>括起来，并放在类名的后面。泛型类是允许有多个类型变量的。

按照约定，类型参数名称命名为单个大写字母，以便可以在使用普通类或接口名称时能够容易地区分类型参数。以下是常用的类型参数名称列表：

 E - 元素，主要由 Java 集合(Collections)框架使用。

 K - 键，主要用于表示映射中的键的参数类型。

 V - 值，主要用于表示映射中的值的参数类型。

 N - 数字，主要用于表示数字。

 T - 类型，主要用于表示第一类通用型参数。

 S - 类型，主要用于表示第二类通用类型参数。

 U - 类型，主要用于表示第三类通用类型参数。

 V - 类型，主要用于表示第四个通用类型参数。

泛型类和泛型接口

可以为任何类、接口增加泛型声明

泛型接口与泛型类的定义基本相同。

泛型类和接口的使用

而实现泛型接口的类，有两种实现方法：

1、未传入泛型实参时：

在 new 出类的实例时，需要指定具体类型：

2、传入泛型实参

在 new 出类的实例时，和普通的类没区别。

泛型方法

泛型方法，是在调用方法的时候指明泛型的具体类型 ，泛型方法可以在任何地方和任何场景中使用，包括普通类和泛型类。

为什么我们需要泛型？

通过两段代码我们就可以知道为何我们需要泛型

实际开发中，经常有数值类型求和的需求，例如实现 int 类型的加法,有时候还需要实现 long 类型的求和,如果还需要 double 类型的求和，需要重新在重载一个输入是 double 类型的 add 方法。

所以泛型的好处就是：

 适用于多种数据类型执行相同的代码。

 泛型中的类型在使用时指定，不需要强制类型转换。

虚拟机是如何实现泛型的？

泛型擦除

Java 语言中的泛型，它只在程序源码中存在，在编译后的字节码文件中，就已经替换为原来的原生类型（Raw Type，也称为裸类型）了，并且在相应的地方插入了强制转型代码，因此，对于运行期的 Java 语言来说，ArrayList＜int＞与 ArrayList＜String＞就是同一个类，所以泛型技术实际上是 Java 语言的一颗语法糖，Java 语言中的泛型实现方法称为类型擦除，基于这种方法实现的泛型称为伪泛型。

将一段 Java 代码编译成 Class 文件，然后再用字节码反编译工具进行反编译后，将会发现泛型都不见了，程序又变回了 Java 泛型出现之前的写法，泛型类型都变回了原生类型（因为）。

使用泛型注意事项（小甜点，了解即可，装 B 专用）

上面这段代码是不能被编译的，因为参数 List＜Integer＞和 List＜String＞编译之后都被擦除了，变成了一样的原生类型 List＜E＞，擦除动作导致这两种方法的特征签名变得一模一样（注意在 IDEA 中是不行的，但是 jdk 的编译器是可以，因为 jdk 是根据方法返回值+方法名+参数）。

弱记忆

JVM 版本兼容性问题：JDK1.5 以前，为了确保泛型的兼容性，JVM 除了擦除，其实还是保留了泛型信息(Signature 是其中最重要的一项属性，它的作用就是存储一个方法在字节码层面的特征签名，这个属性中保存的参数类型并不是原生类型，而是包括了参数化类型的信息)----弱记忆

另外，从 Signature 属性的出现我们还可以得出结论，擦除法所谓的擦除，仅仅是对方法的 Code 属性中的字节码进行擦除，实际上元数据中还是保留了泛型信息，这也是我们能通过反射手段取得参数化类型的根本依据。

Stream

什么是 Stream？

Java8 中，Collection 新增了两个流方法，分别是 Stream() 和 parallelStream()。

Java8 中添加了一个新的接口类 Stream，相当于高级版的 Iterator，它可以通过 Lambda 表达式对集合进行大批量数据操作，或者各种非常便利、高效的聚合数据操作。 

为什么要使用 Stream？

在 Java8 之前，我们通常是通过 for 循环或者 Iterator 迭代来重新排序合并数据，又或者通过重新定义 Collections.sorts 的Comparator 方法来实现，这两种方式对于大数据量系统来说，效率并不是很理想。

Stream 的聚合操作与数据库 SQL 的聚合操作 sorted、filter、map 等类似。我们在应用层就可以高效地实现类似数据库 SQL 的聚合操作了，而在数据操作方面，Stream 不仅可以通过串行的方式实现数据操作，还可以通过并行的方式处理大批量数据，提高数据的处理效率。

Stream 使用入门

可以看到，如果实现同样的功能，那么使用循环的方式，代码行数将达到 6 行。

Stream 操作分类

官方将 Stream 中的操作分为两大类：终结操作（Terminal operations）和中间操作（Intermediate operations）。

中间操作会返回一个新的流，一个流可以后面跟随零个或多个中间操作。其目的主要是打开流，做出某种程度的数据映射/过滤，然后会返回一个新的流，交给下一个操作使用。这类操作都是惰性化的（lazy），就是说，仅仅调用到这类方法，并没有真正开始流的遍历。而是在终结操作开始的时候才真正开始执行。

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

终结操作是指返回最终的结果。一个流只能有一个终结操作，当这个操作执行后，这个流就被使用“光”了，无法再被操作。所以这必定这个流的最后一个操作。终结操作的执行才会真正开始流的遍历，并且会生成一个结果。

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

演示案例

见代码 StuWithStream

因为 Stream 操作类型非常多，总结一下常用的：

 map():将流中的元素进行再次加工形成一个新流，流中的每一个元素映射为另外的元素。

 filter(): 返回结果生成新的流中只包含满足筛选条件的数据

 limit()：返回指定数量的元素的流。返回的是 Stream 里前面的 n 个元素。

 skip()：和 limit()相反，将前几个元素跳过（取出）再返回一个流，如果流中的元素小于或者等于 n，就会返回一个空的流。

 sorted()：将流中的元素按照自然排序方式进行排序。

 distinct()：将流中的元素去重之后输出。

 peek()：对流中每个元素执行操作，并返回一个新的流，返回的流还是包含原来流中的元素。

Stream 的底层实现

Stream 操作叠加

一个 Stream 的各个操作是由处理管道组装，并统一完成数据处理的。

我们知道 Stream 有中间操作和终结操作，那么对于一个写好的 Stream 处理代码来说，中间操作是通过 AbstractPipeline 生成了一个中间操作 Sink 链表。

当我们调用终结操作时，会生成一个最终的 ReducingSink，通过这个 ReducingSink 触发之前的中间操作，从最后一个 ReducingSink 开始，递归产生一个 Sink链。如下图所示：

Stream 源码实现（不重要）

stream 方法

因为 names 是 ArrayList 集合，所以 names.stream() 方法将会调用集合类基础接口 Collection 的 Stream 方法。

然后，Stream 方法就会调用 StreamSupport 类的 Stream 方法。

Stream 方法中初始化了一个 ReferencePipeline 的 Head 内部类对象：

filter 方法

再调用 filter，这个方法都是无状态的中间操作，所以执行 filter 时，并没有进行任何的操作，而是分别创建了一个 Stage 来标识用户的每一次操作。

而通常情况下 Stream 的操作又需要一个回调函数，所以一个完整的 Stage 是由数据来源、操作、回调函数组成的三元组来表示。

如下图所示，分别是 ReferencePipeline 的 filter 方法和 map 方法：

max 方法

当 Sink 链表生成完成后，Stream 开始执行，通过 spliterator 迭代集合，执行 Sink 链表中的具体操作。

java8 中的 Spliterator 的 forEachRemaining 会迭代集合，每迭代一次，都会执行一次 filter 操作，如果 filter 操作通过，就会触发 map操作，然后将结果放入到临时数组 object 中，再进行下一次的迭代。完成中间操作后，就会触发终结操作 max。

Stream 的性能

常规数据迭代

 100 的性能对比

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

为什么这样：

1、常规迭代代码简单，越简单的代码执行效率越高。

2、Stream 串行迭代，使用了复杂的设计，导致执行速度偏低。所以是性能最低的。

3、Stream 并行迭代 使用了 Fork-Join 线程池,所以效率比 Stream 串行迭代快，但是对比常规迭代还是要慢（毕竟设计和代码复杂）。

大数据迭代

 一亿的数组性能对比（默认线程池）

为什么这样：

1、Stream 并行迭代 使用了 Fork-Join 线程池, 而线程池线程数为 cpu 的核心数（我的电脑为 12 核），大数据场景下，能够利用多线程机制，所以效率比 Stream 串行迭代快，同时多线程机制切换带来的开销相对来说还不算多，所以对比常规迭代还是要快（虽然设计和代码复杂）。

2、常规迭代代码简单，越简单的代码执行效率越高。

3、Stream 串行迭代，使用了复杂的设计，导致执行速度偏低，所以是性能最低的。

 一亿的数组性能对比（线程池数量=2）

为什么这样：

Stream 并行迭代 使用了 Fork-Join 线程池,大数据场景下，虽然利用多线程机制，但是线程池线程数为 2，所以多个请求争抢着执行任务，想象对请求来说任务是被交替执行完成，所以对比常规迭代还是要慢（虽然用到了多线程技术）。

 一亿的数组性能对比（线程池数量=240）

为什么这样：

Stream 并行迭代 使用了 Fork-Join 线程池, 而线程池线程数为 240，大数据场景下，虽然利用多线程机制，但是线程太多，线程的上下文切换成本过高，所以导致了执行效率反而没有常规迭代快。

如何合理使用 Stream？

我们可以看到：在循环迭代次数较少的情况下，常规的迭代方式性能反而更好；而在大数据循环迭代中， parallelStream（合理的线程池数上）有一定的优势。

但是由于所有使用并行流 parallelStream 的地方都是使用同一个 Fork-Join 线程池，而线程池线程数仅为 cpu 的核心数。

切记，如果对底层不太熟悉的话请不要乱用并行流 parallerStream（尤其是你的服务器核心数比较少的情况下）。