arthas用的好好的，写个lambda表达式就跪了？该咋解决？
△Hollis, 一个对Coding有着独特追求的人△
这是Hollis的第 278 篇原创分享
作者 l Robert Lu
来源 l Hollis（ID：hollischuang）
作为一个从PHP转Java的人，发现alibaba的arthas很好用。通过arthas的redefine命令，可以像PHP一样，不用重新发布，就可以改变程序行为（前提是不改变类结构，不改变方法签名）。
但是用多了，发现很多时候，我们就改了几行代码，甚至有的时候就添加了一行日志，就无法redefine了。提示
redefine error! java.lang.UnsupportedOperationException: class redefinition failed: attempted to add a method
它提示我们新增加方法，那我们就看看是不是新增加了方法。通过javap来查看定义的方法：
这是老的类：
这是新的类：
对比之后发现，新的类，即本地编译的类，其中的lambda对应的方法名都是lambda$getAllCity$0这样的，最后的编号是从0开始的。
而旧的类，即现在在运行的类，其中的同一个lambda的方法名是lambda$getAllCity$121，最后的编号是一个非常大的数字。
在仔细对比下，发现是jdk的版本问题，不同的jdk版本对与lamdba的处理可能不一致。
具体来说，线上编译的jdk版本是1.8.0_66-b17， 而本地是1.8.0_222-b10，而这两个版本对lambda对应的方法命名是不一样的。
首先，为了调试方便，写一个最小复现用例来看看：
// 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 compilationUnits = fileManager.getJavaFileObjects(
new File(path1),
new File(path2)
);
JavaCompiler.CompilationTask task = javaCompiler.getTask(null, fileManager, diagnostics, null, null,
compilationUnits);
boolean success = task.call();
System.out.println(success);
}
}
//LamdbaTest1.java
public class LamdbaTest1 {
private void test(Runnable runnable) {
runnable.run();
}
private void main() throws Throwable {
test(() -> {
System.out.println(11);
});
}
}
//LamdbaTest2.javapublic class LamdbaTest2 { private void test(Runnable runnable) { runnable.run(); } private void main() throws Throwable { test(() -> { System.out.println(22); }); }}
使用1.8.0_222-b10（新版本jdk）跑完了之后，发现LamdbaTest2中的lambda方法是：
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$
$
不同的地方在于：新版本的javac，在处理一个新的类的时候，会保存上一个lambdaCount，后续再恢复，在当前类，则直接从0开始重新计数：
而旧版本则没有这个逻辑，直接用全局递增的计数器：
这就说明旧版本的编译器确实是lambda全局编号的。
那，问题来了，这个行为是从哪个版本变掉的呢？
对比之后发现这个变更是jdk8u74-b02引入的。对应的bug是https://bugs.openjdk.java.net/browse/JDK-8067422
基本上就是每个类内的lambda单独编号，确保编译顺序不会影响lambda的方法名字。
所以，解决方案很简单，升级编译环境的jdk版本就好。
非常巧合的是，前两天为了更好的适配Docker运行环境（通俗的讲，就是在容器内获取到docker的cpu配额，而不是物理机器的cpu数量），我找运维添加了一个新的jdk版本1.8.0_231-b11，这样只需要直接将编译环境的jdk版本切换到8u231就行了！
Arthas官方正在举办征文活动，如果你有
使用 Arthas 排查过的问题
对 Arthas 进行源码解读
对 Arthas 提出建议
不限，其它与 Arthas 有关的内容
欢迎参加征文活动，还有奖品拿哦~
点击阅读原文接入征文活动地址。
福利时间
GIFT TIME
Arthas 技术社区特意将本次征文活动的一部分礼品（1个阿里云定制雨伞，2个淘公仔，5个解压脑型球）赞助了给到Hollis的读者
本次礼品不需要评论，也不需要转发
采用最公平的抽奖方式。
关注公众号：程序员面试现场
公众号后台回复：征文
即可参与抽奖
往期推荐
漫话：为什么键盘以QWER排列，而不是ABCD？
如何让程序员变得没朋友
平滑从Consul迁移到 Nacos，再也不用担心特朗普发疯了...
直面Java第320期：如何判断一个Java对象能否被回收？
深入并发第013期：拓展synchronized——锁优化
如果你喜欢本文,
请长按二维码，关注 Hollis.
转发至朋友圈，是对我最大的支持。
点个 在看
喜欢是一种感觉
在看是一种支持
↘↘↘