lambda表达式是JAVA8中提供的一种新的特性，它支持JAVA也能进行简单的“函数式编程”。它是一个匿名函数，Lambda表达式基于数学中的λ演算得名，直接对应于其中的lambda抽象(lambda abstraction)，是一个匿名函数，即没有函数名的函数。
函数式接口：
这个是理解Lambda表达式的重点，也是产生lambda表达式的“母体”，这里我们引用一个比较容易理解的说法：函数式接口是 一个只有一个抽象方法（不包含object中的方法）的接口。
这个需要说明一点，就是在Java中任何一个对象都来自Object 所有接口中自然会继承自Object中的方法，但在判断是否是函数式接口的时候要排除Object中的方法。
为了支持函数式编程，Java 8引入了Lambda表达式.在Java 8中采用的是内部类来实现Lambda表达式.具体实现代码,可以通过debug看, 同时通过字节码查看工具及反编译工具来验证.
自从lambda表达式成为Java语言的一部分之后，Java集合（Collections）API就面临着大幅变化。而JSR 355（规定了Java lambda表达式的标准）的正式启用更是使得Java集合API变的过时不堪。
尽管我们可以从头实现一个新的集合框架（比如“Collection II”），但取代现有的集合框架是一项非常艰难的工作，因为集合接口渗透了Java生态系统的每个角落，将它们一一换成新类库需要相当长的时间。因此，我们决定采取演化的策略（而非推倒重来）以改进集合API： 为现有的接口（例如Collection，List和Stream）增加扩展方法；
在类库中增加新的流（stream，即java.util.stream.Stream）抽象以便进行聚集（aggregation）操作；
改造现有的类型使之可以提供流视图（stream view）；
改造现有的类型使之可以容易的使用新的编程模式，这样用户就不必抛弃使用以久的类库，例如ArrayList和HashMap
（当然这并不是说集合API会常驻永存，毕竟集合API在设计之初并没有考虑到lambda表达式。我们可能会在未来的JDK中添加一个更现代的集合类库）。
除了上面的改进，还有一项重要工作就是提供更加易用的并行（Parallelism）库。尽管Java平台已经对并行和并发提供了强有力的支持，然而开发者在实际工作（将串行代码并行化）中仍然会碰到很多问题。因此，我们希望Java类库能够既便于编写串行代码也便于编写并行代码，因此我们把编程的重点从具体执行细节（how computation should be formed）转移到抽象执行步骤（what computation should be perfomed）。
对于大多数刚刚接触jdk8的同学来说，应该都会认为lambda表达式其实就是匿名内部类的语法糖(包括我自己，在刚刚接触的时候，也是这样认为的)，但实际上二者还是存在不少差异，其中最主要的两点就是标识性和作用域。首先，内部类在创建表达式时，会确保创建一个拥有唯一标识的新对象，而对于lambda，其计算结果（其实就是一个映射的过程）可能有也可能没有唯一标识，这取决于具体实现。
其次，内部类的声明会创建出一个新的命名作用域，在这个作用域中，this与super指向内部类本身的当前实例；但是lambda恰恰相反，它不会引入任何新的命名环境，这样就避免了内部类名称查找的复杂性，名称查找会导致很多问题，比如想要调用外围实例的方法时却错误的调用了内部类实例的Object方法。
