// Compile.java
// 编译LamdbaTest1.java和LamdbaTest2.java
import javax.tools.*;
import java.io.File;
public class Compile {
 public static void main(String[] args) {
  String path1 = "/path/to/LamdbaTest1.java";
  String path2 = "/path/to/LamdbaTest2.java";
  JavaCompiler javaCompiler = ToolProvider.getSystemJavaCompiler();
  DiagnosticCollector diagnostics = new DiagnosticCollector();
  StandardJavaFileManager fileManager = javaCompiler.getStandardFileManager(diagnostics, null, null);
  Iterable<"text-align: center">



private static void lambda$main$0();


而换版本 1.8.0_66-b17（旧版本 jdk）之后，lambda 的方法就成了：



private static void lambda$main$1();


多尝试几个文件同时编译，我们就可以发现：对于旧版本的 javac，末尾这个数字是全局递增的，50 个类有 100 个 lambda，那最后一个 lambda 的编号就是 99；而新的版本是每个类重新计数的，和总共多少个类没有关系。
确认了问题之后，接下来就是不断的打断点、重试了。后来发现不同版本的 javac 逻辑确实不同。
首先，查看 jdk 源码可以知道，lambda 的方法名都是：


lambda$<methodname>$<lambdaCount>


代码见 LambdaToMethod.java
不同的地方在于： 新版本的 javac，在处理一个新的类的时候，会保存上一个 lambdaCount，后续再恢复：

而旧版本则没有这个逻辑：

这就说明旧版本的编译器确实是 lambda 全局编号的。
那，问题来了，这个行为是从哪个版本变掉的呢？
对比之后发现这个变更是 jdk8u74-b02 引入的。对应的 bug 是 https://bugs.openjdk.java.net/browse/JDK-8067422，基本上就是每个类内的 lambda 单独编号，确保编译顺序不会影响 lambda 的方法名字。
所以，解决方案很简单，升级编译环境的 jdk 版本就好。
非常巧合的是，前两天为了更好的适配 Docker 运行环境（通俗的讲，就是在容器内获取到 docker 的 cpu 配额，而不是物理机器的 cpu 数量），我找运维添加了一个新的j dk 版本 1.8.0_231-b11，这样只需要直接将编译环境的 jdk 版本切换到 8u231 就行！
推荐使用 Arthas
"external nofollow" href="http://t.tb.cn/2A5CbHWveOXzI7sFakaCw8">http://t.tb.cn/2A5CbHWveOXzI7sFakaCw8 

"external nofollow" href="https://github.com/alibaba/arthas">https://github.com/alibaba/arthas。
Arthas 第二期征文活动火热进行中,欢迎参加征文活动，还有奖品拿哦~点击了解详情。
总结