Java中Lambda表达式的使用：https://www.cnblogs.com/franson-2016/p/5593080.html
java 8新特性lambda表达式优劣浅谈： https://blog.csdn.net/qq_28899635/article/details/53691986
最近学习了lambda表达式的用法，就把自己的小项目中所有用到接口回调的地方全都用上了lambda表达式，代码的确精简了不少，不仅是接口回调处，由于其参数类型推断，还减少了不少import语句。 虽然让代码风格更趋向极简，但是很难说lambda表达式就一定优于传统的接口回调语法。理由如下： 1.接口回调为什么而产生？是因为我们要在代码执行的特定时候，调用方要动态的插入一段代码在调用的方法中间而用。这在事件监听中用的极其广泛，在Android中最典型的例子就是View的点击事件监听。所以说，创建接口，在方法的定义中用到接口的实例作为形式参数，以及在调用方法时把接口的实例作为实际参数传入，并重写接口的方法，这一整套步骤是密不可分的，而lambda表达式并不是利用了一个新的方式实现了上述功能，而仅仅只是把最后一步的使用接口的实例作为实参传入并重写接口方法这一个步骤简写，显然，这就导致了整个过程的不统一，这么说有点抽象，具体来收就是，使用lambda表达式，一直作为重要角色的接口名就变得不可见了，接口内部的抽象方法名也变的不可见了，lambda表达式的使用者仍然需要知道接口名和其接口方法名，但是不用写出来，这就变的有点奇怪，因为你在使用lambda表达式时仍然需要前一个步骤，所以从步骤上来看，lambda表达式让理解变的复杂了，使思维步骤多了一步，而减少的仅仅是表现出来的代码量。 2.类型推断让代码可读性变差，举个例子，Android中的View点击事件监听，需要传入OnClickLinstener接口的实例作为参数，这个接口中仅有一个抽象方法需要重写，这个抽象方法也仅仅只有一个参数，于是代码就变成了如下形式： mImageView.setOnClickListener(v -> { }); 由于抽象方法只有一个参数，所以v也不需要放在括号中，加上类型推断机制，v的类型也可以省去，这样一看，就有些不明所以，我们在这里一看就知道v的类型是View那是因为这是Android自己提供的API，所有Android开发者都烂熟于心，假如说你写了一个这样的代码，让一个完全不了解你的人去看，对方很可能对v的类型懵逼，因为对方刚拿到你的代码，并不知道你的代码这里是想做什么，因此，不去查找这个接口的定义，很难一眼看出来v的类型到底是什么。虽然lambda表达式的参数类型推断是可选的，也就是它允许你写上参数类型，但是既然它提供了推断的功能，我相信使用它的人为了尽可能好的使用它的特性，很多人都会不写参数类型。虽然影响并没有那么大，但大体来收参数类型推断功能确实在一定程度上降低了代码的可读性。 ... 后续：快过了一年了，这几天回过头来看看自己以前写的文章，感觉自己当初理解有限，过了一年许多想法都略显浅薄，不过博客作为记录学习之路上的一种载体，我也本来无意修改旧文章，之前看见通知里有一条评论说：lambda表达式可读性差是个笑话，但不知道为何点开文章却看不到评论。这里就当回复一下吧。 当初并不理解FP，而只是用lambda表达式，强行将lambda表达式使用在了OOP的程序当中，感到可读性变成是自然而然的，因为整个程序都不是函数式的。但自从使用了Kotlin以后，现在如果我重新编写一个程序，我会从一开始就利用函数式的整套思想来编写程序，例如原先的接口回调，我会在一开始就写成高阶函数，然后也会利用其它lamnbda的特性，例如将lambda表达式保存在变量当中传递。除此之外还有很多FP的新概念，如果程序一开始就是这样设计的，并且你使用的语言从一开始就支持函数式编程，例如Kotlin，Scala，那一切都将变得很自然，但是纯粹为了尝试这个新特性而将它强行加入到OOP的程序之中，可读性的降低也会变的自然而然。 ———————————————— 版权声明：本文为CSDN博主「Preacher_Qiao」的原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接及本声明。 原文链接：https://blog.csdn.net/qq_28899635/article/details/53691986
lambda表达式foreach性能分析：https://www.jianshu.com/p/e5e96a7b86ec