原创声明：本文系作者原创，谢绝个人、媒体、公众号或网站未经授权转载，违者追究其法律责任。
前言
JDK8 引入了诸多特性，其中属 Lambda 最引入注目。在介绍本文主角之前，有必要先介绍 JDK7 (JSR-292) 引入的 3 个 features：
- MethodHandle
- invokedynamic
- VM Anonymous Class
当前 JDK8 对 Lambda 表达式的解析方案便是依赖于以上特性，我们会依次介绍这三个 feature 及其产生的技术背景。
MethodHandle
MethodHandle 属于 JDK7 新加入的 java.lang.invoke 包，废话不说，我们先上代码看看他最简单的用法：
代码逻辑很简单，随机调用两个都实现了 println(Ljava/lang/String)V 方法的类，代码不需要关心 obj 的值是什么类型，只要实现了 println(Ljava/lang/String;)V 方法就能够被调用。看到这里，你肯定会说这不就是 Java 的反射吗？确实，MethodHandle 和 Reflection 实现的功能有太多相似的地方，都是运行时解析方法调用，但他们之间有着本质的区别：
- MethodHandle 和 Reflection 都可以分派方法调用，但是 MethodHandle 比 Reflection 更强大，它是模拟字节码层次的方法分派。有兴趣的同学可以对比 MethodHandles.Lookup 提供的findStatic、findVirtual、findSpecial三个方法和 Reflection 的反射调用；
- MethodHandle 是结合 invokedynamic 指令一起为动态语言服务的，也就是说MethodHandle （更准确的来说是其设计理念）是服务于所有运行在JVM之上的语言，而 Relection 则只是适用 Java 语言本身。
invokedynamic
invokedynamic 是 JDK7 为了支持动态类型语言而新增的字节码指令，简单的理解，invokedynamic 在字节码层面实现了 MethodHandle 实现的功能。对比之前 Java 字节码所有的方法分派均依赖于单纯的符号引用，即在编译生成的.class字节码文件中，4条方法调用指令（invokevirtual、invokespecial、invokestatic、invokeinterface）后面跟的操作数均为明确的 CONSTANT_Methodref_info 或 CONSTANT_InterfaceMethodref_info 常量池符号引用，这就意味着在编译期就提前把方法调用绑定到了某类型及其子类型，如下图是源码 System.out.println("Hello") 和编译后字节码对比截图：
实现了 println (Ljava/lang/String;)V 方法的类必须是 java/io/PrintStream 的子类，但是对于动态语言来说，编译期间是不关心这个类是什么类型的，于是便新增了 invokedynamic 方法分派指令，该指令所在的位置被称为 "动态调用点"（Dynamic Call Site）。
下面我们简单分析下 invokedynamic 指令。之前提到原有的 4 条方法分配指令 invokevirtual、invokespecial、invokestatic、invokeinterface 的操作数类型是 CONSTANT_Methodref_info 或 CONSTANT_InterfaceMethodref_info，在 invokedynamic 则换成了 CONSTANT_InvokeDynamic_info。我们抛开这些概念上的定义，本质上 invokedynamic 后面跟着三个参数，分别是引导方法（Bootstrap Method）， 调用的方法签名，调用的方法名称；Bootstrap Method 根据方法名称和方法签名返回运行时调用点（Call Site）。回过头看上面MethodHandle的示例代码：
MethodHandles.lookup().findVirtual(obj.getClass(), "println", mt).bindTo(obj);
可以做个不太恰当的对号入座： 引导方法对应 MethodHandles.lookup().findVirtual， 方法签名对应 mt，方法名称对应 println，我们只要记住这两点即可：
Bootstrap Method 由编译器自身指定，包括参数；
Bootstrap Method 职责是返回运行时真正的调用点 Call Site；至于 Call Site 如何产生，JVM 是不关心的，那是 Bootstrap Method 负责去做的，只要符合调用要求就行。
VM Anonymous Class
一般意义上的匿名类本质上和普通类没什么区别，需要 ClassLoader 去加载、字节码安全验证、管理访问权限、链接，类初始化。当然匿名类也并不匿名，它有自己的类名，通过 Class.forName 可以索引到对应的 Class。在动态语言中，单纯为了执行一段代码，却要额外做这么多操作显然是不能忍受的，所以在 JDK7 中引入了 VM Anonymous Class 这一真正意义上的匿名类，不需要 ClassLoader 加载，没有类名，当然也没其他权限管理等操作，这意味着效率更高(不必要的锁操作)、GC 更方便（没有 ClassLoader）；VM Anonymous Class 通过调用 sun.misc.Unsafe.defineAnonymousClass 生成。
Lambda的底层实现
在设计 Lambda 表达式的解析方案时，主要考虑下面两点：
可扩展性，不把解析方案写死在字节码上；
解析 Lambda 表达式后，对字节码文件干扰尽量降到最低，起码保证一定的可读性。
正式基于以上两点考虑， invokedynamic 指令被运用到解析 Lambda 表达式，优势如下：
字节码表示简单，利用 invokedynamic 指令本身的特性（引导方法），把 Lambda 表达式在字节码文件的表示和真正的解析分离；
Lambda 表达式的链接解析发生运行期而非编译期，由 invokedynamic 的引导方法执行，扩展性强。
Lambda 是面向方法接口编程，其实我更多认为是 JDK8 提供的语法糖，因为对非方法引用的 Lambda 表达式，编译器都会为其生成一个方法实现 Lambda 表达式的逻辑，并出现在编译后的字节码文件中。这个方法的生成是 Lambda 表达式解析的关键，为了直观点，我们先看下面两段代码及编译后的字节码表示：
编译类 DelegateService，通过 javap -p 指令查看其字节码如下：
再看另一个类及其字节码：
编译类 EntryTwo, 通过 javap -p 查看字节码如下：
可以看到，编译器为 Lambda 表达式都生成了一个方法，但是细心的同学会发现，虽然都是实现 SampleService 函数式接口，但是最后生成的方法区别很大，不仅 static/ 非 static，而且参数类型都不一样，这是为什么呢？Lambda 表达式的解析分成三个阶段：
- 链接阶段， 负责生成动态调用点；
- 变量捕获，闭包中的变量访问；
- Lambda 表达式调用。
之所以造成上面同一个函数接口生成的方法 (desugaring method) 不一致，是因为变量捕获不一样导致的；
- 最终生成 desugaring method 的参数列表是函数接口方法参数列表加上变量捕获列表；
- 如果在lambda表达式中使用到了enclosing class 实例（比如this, super, 或者其实例变量），那么最终的 desugaring method 则是private 实例方法；否则是private 静态方法。
有兴趣的同学可以写代码验证以上两点。
上面提到了 Lambda 表达式的解析分成三个阶段， 链接阶段由 invokedynamic 指令后面跟随的 Bootstrap Method 引导方法完成，生成动态调用点。我们先来看 Lambda 表达式解析用的最多的一个引导方法 java.lang.invoke.LambdaMetafactory#metaFactory：
该启动方法以及参数都是编译器指定，下面来解释下这几个参数的含义：
caller 参考前面提到的 MethodHandle，lookupClass 指向 enclosing object
invokedName 需要实现的函数式接口方法名
invokedType 变量捕获列表
samMethodType 需要实现的函数式接口方法签名（sam 是 single abstract method ）
implMethod 指向生成的 desugaring method
instantiatedMethodType 对应运行时 sam 的方法签名，运行时签名验证，在非泛型情况下，和samMethodType相同；比如下面代码中，samMethodType是(Ljava/lang/Object)V, instantiatedMethodType则是(Ljava/lang/String)V
引导方法 metaMethod 根据这些参数生成 java.lang.invoke.CallSite 动态调用点对象支持 Lambda 表达式的调用执行。在引导方法中会动态生成一个模板匿名类，查看这个类的字节码可以通过加上 -Djdk.internal.lambda.dumpProxyClasses 参数指定 dump 的目录，该匿名是一个模板类，其特点如下：
实现函数式接口，内部逻辑很简单，调用上面提到的脱糖方法（desugaring method）
生成一个构造方法， 构造方法参数为被捕获参数变量，所有变量存储为类实例变量
如果被捕获参数变量列表不为空， 则会生成一个工厂方法 get$lambad，方法签名和构造方法相同；该工厂方法的作用是避免重复调用asm生成匿名类字节码，提升性能；在下一节的性能分析中会提到这个方法的作用
为了更直观，我们看一个例子，也就是上面第一段代码生成的匿名类：
性能分析
这里对比下 VM Anonymous Class 相对普通的匿名类实现 Lambda 的性能优势，
参考 http://www.oracle.com/technetwork/java/jvmls2013kuksen-2014088.pdf
这是 2013 年官方给出的 Lambda 和普通匿名类的性能对比分析，性能差异主要体现在链接阶段，文章中提到的 Lambda 冷启动和热启动。所谓热启动是包括生成匿名类字节码并生成 class 的过程，热启动是比匿名类稍微差点，对相同 Lambda 表达式来说，热启动过程只发生一次，后面都是调用工厂方法即可，直接调用已有的匿名类称之为冷启动，他的性能接近为匿名类的 100 倍。
总结
以上这些，我们可以做个总结了：
对于非方法引用 Lambda 表达式，编译器都会生成对应的 desugaring method
desugaring method 参数列表是接口方法参数列表加上变量捕获列表
变量捕获由虚拟机提供，是闭包访问变量的基础；闭包变量分为两种，instance-capturing 和 non-instance-capturing，如果在lambda中使用了 enclosing object 实例（比如this, super, 或者其实例变量）,desugaring method 是私有实例方法，否则是私有静态方法
invokedynamic 和 Lambda 的实现并没有因果关系，Lambda 的解析可以不依赖 invokdynamic 指令，之所以采用该指令，考虑到以下两点：
可扩展性强，Lambda 解析方案放在引导方法运行时执行，而不是编译器写在 class 文件中
对 class 文件干扰尽量降到最低，字节码简单，可读性强
引导方法 java.lang.invoke.LambdaMetafactory#metaFactory 动态生成一个虚拟机级别的匿名模板类(VM Anonymous Class)，在该匿名类中定义了和函数接口方法签名相同的方法， 方法体则是调用 desugaring method 方法；比较特殊的是该匿名类是真正意义上的匿名类，不需要 ClassLoader 加载，直接通过sun.misc.Unsafe#defineAnonymousClass 加载，较普通匿名类有以下优点：
效率更高，没有类加载、字节码安全验证、管理访问权限、链接，类初始化等一系列(锁)操作
GC 更友好，不涉及任何 ClassLoader
Lambda 引导方法动态生成一个匿名类字节码，这个匿名类有如下特点：
实现函数式接口，内部逻辑调用脱糖方法（desugaring method）
包含一个构造方法， 构造方法参数为被捕获参数变量，所有变量存储为类实例变量
如果捕获参数变量列表不为空， 则会生成一个工厂方法 get$lambad，方法签名和构造方法相同；该工厂方法的作用是避免重复调用 asm 生成匿名类字节码，提升性能
