我怀疑这是IDEA的BUG,但是我翻遍全网没找到证据!

你好呀,我是歪歪。

前几天有朋友给我发来这样的一个截图:

他说他不理解,为什么这样不报错。

我说我也不理解,把一个 boolean 类型赋值给 int 类型,怎么会不报错呢,并接着追问他:这个代码截图是哪里来的?

他说是 Lombok 的 @Data 注解自动生成的。

巧了,对于 Lombok 我之前有一点点了解,所以听到这个的答案的那一瞬间,电光火石之间我仿佛明白了点什么东西:因为 Lombok 是利用字节码增强的技术,直接操作字节码文件的,难道它可以直接绕过变量类型不匹配的问题?

但是很快又转念一想,不可能啊:这玩意要是都能绕过,Java 还玩个毛线啊。

于是我决定研究一下,最后发现这事儿其实很简单:就是 idea 的一个 bug。

复现

Lombok 插件我本来也再用,所以我很快就在本地复现了一波。

源文件是这样的,我只是加了 @Data 注解:

经过 Maven install 编译之后的 class 文件是这样的:

可以看到 @Data 注解帮我们干了非常多的事情:生成了无参构造函数、name 字段的 get/set 方法、 equals 方法、toStrong 方法还有 hashCode 方法。

其实你点到 @Data 注解的源码里面去,它也给你说明了,这就是一个复合注解:

因此,真正生成 hashCode 方法的注解,应该是 @EqualsAndHashCode 才对。

所以,为了排除干扰项,方便我聚焦到 hashCode 方法上,我把 @Data 注解替换为 @EqualsAndHashCode:

结果还是一样的,只是默认生成的方法少了很多,而且我也不关心那些方法。

现在,也眼见为实了,为啥这里的 hashCode 方法里面的第一行代码是这样的呢:

int PRIME = true;

直觉告诉我,这里肯定有障眼法。

我首先想到了另一个反编译的工具,jd-gui,就它:

果然,把 class 文件拖到 jd-gui 里面之后,hashCode 方法是这样的:

是数字 59,而不是 true 了。

但是这个 PRIME 变量,看起来在 hashCode 方法里面也没有用呢,这个问题不着急,先抛出来放在这里,等下再说。

另外,我还想到了直接查看字节码的方法:

可以看到这样看到的 hashCode 方法的第一个命令用的整型入栈指令 bipush 数字 59。

经过 jd-gui 和字节码的验证,我有理由怀疑在 idea 里面显示 int PRIME = true 绝!对!是!BUG!

开心,又发现 BUG 了,素材这不就来了吗。

当时我开心极了,就和下面这个小朋友的表情是一样一样的。

线索

于是我在网上找了一圈,没有找到任何这方面的资料,没有一点点收获。内心的 OS 是:“啊,一定是我的姿势不对,再来一次。”

扩大了搜索范围,又找了一圈。

“怎么还是没有什么线索呢,没道理啊!不行,一定是有蛛丝马迹的。”

于是又又找一圈。

“嗯,确实是没有什么线索。浪费我几小时,垃圾,就这样吧。”

我穷尽我的毕生所学,在网上翻了个底朝天,确实没有找到关于 idea 为什么会在这里显示 int PRIME = true 这样的一行代码。

我找到的唯一有相关度的问题是这个:

https://stackoverflow.com/questions/70824467/lombok-hashcode-1-why-good-2-why-no-compile-error/70824612#70824612

在这个问题里面,提问的哥们说,为什么他看到了 int result = true 这样的代码,且没有编译错误?

和我看到的有点相似,但是又不是完全一样。我发现他的 Test 类是无参的,而我自己的做测试的 UserInfo 是有一个 name 参数的。

于是我也搞了个无参的看了一下:

我这里是没有问题的,显示的是 int result = 1

然后有人问是不是因为你这个 Test 类没有字段呀,搞几个字段看看。

当他加了两个字段之后,编译后的 class 文件就和我看到的是一样的了:

但是这个问题下面只有这一个有效回答:

这个回答的哥们说:你看到 hashCode 方法是这样的,可能是因为你用的生成字节码的工具的一个问题。

在你用的工具的内部,布尔值 true 和 false 分别用 1 和 0 表示。

一些字节码反编译器盲目地将 0 翻译成 false,将 1 翻译成 true,这可能就是你遇到的情况。

这个哥们想表达的意思也是:这是工具的 BUG。

虽然我总是觉得差点意思,先不说差在哪儿了吧,按下不表,我们先接着看。

在这个回答里面,还提到了 lombok 的一个特性 delombok,我想先说说这个:

delombok

这是个啥东西呢?

给你说个场景,假设你喜欢用 Lombok 的注解,于是你在你对外提供的 api 包里面使用了相关的注解。

但是引用你 api 包的同学,他并不喜欢 Lombok 注解,也没有做过相关依赖和配置,那你提供过去 api 包别人肯定用不了。

那么怎么办呢?

delombok 就派上用场了。

可以直接生成已经解析过 lombok 注解的 java 源代码。

官网上关于这块的描述是这样的:

https://projectlombok.org/features/delombok

换句话说,也就是你可以利用它看到 lombok 给你生成的 java 文件是长什么样的。

我带你瞅一眼是啥样的。

从官网上的描述可以看到 delombok 有很多不同的打开方式:

对我们而言,最简单的方案就是直接用 maven plugin 了。

https://github.com/awhitford/lombok.maven

直接把这一坨配置贴到项目的 pom.xml 里面就行了。

但是需要注意的是,这个配置下面还有一段话,开头第一句就很重要:

Place the java source code with lombok annotations in src/main/lombok (instead of src/main/java).

将带有 lombok 注解的 java 源代码放在 src/main/lombok 路径下,而不是 src/main/java 里面。

所以,我创建了一个 lombok 文件夹,并且把这 UserInfo.java 文件移动到了里面。

然后执行 maven 的 install 操作,可以看到 target/generated-sources/delombok 路径下多了一个 UserInfo.java 文件:

这个文件就是经过 delombok 插件处理之后的 java 文件,可以在遇到对方没有使用 lombok 插件的情况下,直接放到 api 里面提供出去。

然后我们瞅一眼这个文件。我拿到这个文件主要还是想看看它 hashCode 方法到底是怎么样的:

看到没有,hashCode 方法里面的 int PRIME = true 没有了,取而代之的是 final int PRIME = 59

这已经是 java 文件了,要是这地方还是 true 的话,那么妥妥的编译错误:

而且通过 delombok 生成的源码,也解答了我之前的一个疑问:

看 class 文件的时候,感觉 PRIME 这个变量没有使用过呢,那么它的意义是什么呢?

但是看 delombok 编译后得到的 java 文件,我知道了,PRIME 其实是用到了的:

那么为啥 PRIME 变成了 true 呢?

望着 delombok 生成的源码,我突然眼前一亮,好家伙,你看这是什么:

这是 final 类型的局部变量。

注意:是!final!类!型!

为了更好的引出下面我想说的概率,我先给你写一个非常简单的东西:

看到了吗,why 和 mx 都变成 true 了,相当于把 test 方法直接修改为这样了:

public int test() {
return 3;
}

给你看看字节码可能更加直观一点:

左边是不加 final,右边是加了 final。

可以看到,加了 final 之后完全都没有访问局部变量的 iload 操作了。

这东西叫什么?

这就是“常量折叠”。

有幸很久之前看到过 JVM 大佬R大对于这个现象的解读,当时觉得很有趣,所以有点印象。

当看到 final int PRIME = 59 的时候,一下就点燃了回忆。

于是去找到了之前看的链接:

https://www.zhihu.com/question/21762917/answer/19239387

在R大的回答中,有这么一小段,我给你截图看看:

同时,给你看看 constant variable 这个东西在 Java 语言规范里面的定义:

A variable of primitive type or type String, that is final and initialized with a compile-time constant expression , is called a constant variable.

一个基本类型或 String 类型的变量,如果是被 final 修饰的,在编译时的就完成了初始化,这就被称为 constant variable(常量变量)。

所以 final int PRIME = 59 里面的 PRIME 就是一个常量变量。

这里既然提到了 String,那我也给你举个例子:

你看 test2 方法,用了 final,最终的 class 文件中,直接就是 return 了拼接完成后的字符串。

为什么呢?

别问,问就是规定。

https://docs.oracle.com/javase/specs/jls/se7/html/jls-15.html#jls-15.28

我只是在这里给你指个路,有兴趣的可以自己去翻一翻。

另外,也再一次实锤了 class 文件下面这样的显示,确实是 idea 的 BUG,和 lombok 完全没有任何关系,因为我这里根本就没有用 lombok:

同时,关于上面这个问题在 lombok 的 github 里面也有相关的讨论:

https://github.com/projectlombok/lombok/issues/523

提问者说:这个 PRIME 变量看起来像是没啥用的代码呢,因为在这个局部方法中都没有被使用过。

官方的回答是:老哥,我怀疑你看到的是 javac 的一个优化。如果你看一下 delombok 生成的代码,你会看到 PRIME 这个玩意是在被使用。应该是 javac 在对这个常量进行了内联的操作。

为什么是 59

我们再次把目光聚焦到 delombok 生成的 hashCode 方法:

为什么这里用了 59 呢,hashCode 里面的因子不应该是无脑使用 31 吗?

我觉得这里是有故事的,于是我又浅挖了一下。

我挖线索的思路是这样的。

首先我先找到 59 这个数是怎么来的,它肯定是来自于 lombok 的某个文件中。

然后我把 lombok 的源码拉下来,查看对应文件中针对这个值的提交或者说变化。正常情况下,这种魔法值不会是无缘无故的来的,提交代码的时候大概率会针对为什么取这个值进行一个说明。

我只要找到那段说明即可。

首先,我根据 @EqualsAndHashCode 调用的地方,找到了这个类:

lombok.javac.handlers.HandleEqualsAndHashCode

然后在这个类里面,可以看到我们熟悉的 “PRIME”:

接着,搜索这个关键词,我找到了这个地方:

这里的这个方法,就是 59 的来源:

lombok.core.handlers.HandlerUtil#primeForHashcode

第一步就算完成了,接着就要去看看 lombok 里面 HandlerUtil 这个类的提交记录了:

结果很顺利,这个类的第二次提交的 commit 信息就在说为什么没有用 31。

从 commit 信息看,之前应该用的就是 31,而用这个数的原因是因为《Effective Java》推荐使用。但是根据 issue#625 里面的观点来说,也许 277 是一个比较好的值。

从提交的代码也可以看出,之前确实是使用的 31,而且是直接写死的:

在这次的提交里面,修改为了 277 并提到了 HandlerUtil 的一个常量中:

但是,这样不是我想要找的 59 呀,于是接着找。

很快,就找到了 277 到 59 的这一次变更:

同时也指向了 issue#625。

等我哼着小曲唱着歌,准备到 issue#625 里面一探究竟的时候,傻眼了:

https://github.com/projectlombok/lombok/issues/625

issue#625 说的事儿根本和 hashCode 没有任何关系呀。

而且这个问题是 2015 年 7 月 15 日才提出来的,但是代码可是在 2014 年 1 月就提交了。

所以 lombok 的 issues 肯定是丢失了很大一部分,导致现在我对不上号了。

这行为,属于在代码里面下毒了,我就是一个中毒的人。

事情看起来就像是走进了死胡同。

但是很快,就峰回路转了,因为我的小脑壳里面闪过了另外一个可能有答案的地方,那就是 changelog:

https://projectlombok.org/changelog

果然,在 changelog 里面,我发现了新的线索 issue#660:

打开 issue#660 一看,嗯,这次应该是没走错路了:

https://github.com/projectlombok/lombok/issues/660

在这个 issues 里面首先 Maaartinus 老哥给出了一段代码,然后他解释说:

在我的例子中,如果 lombok 生成的 hashCode 方法使用 31 这个因子,对于 256 个生成的对象,只有 64 个唯一的哈希值,也就是说会产生非常多的碰撞。

但是如果 lombok 使用一个更好的因子,这个数字会增加到 144,相对好一点。

而且几乎任何奇数都可以。使用 31 是少数糟糕的选择之一。

官方看到后,很快就给了回复:

看了老哥的程序,我觉得老哥说的有道理啊。之前我用 31 也完全是因为《Effective Java》里面是这样建议的,没有考虑太多。

另外,我决定使用 277 这个数字来替代 31,作为新的因子。

为什么是 277 呢?

别问,问就是它很 lucky!

277 is the lucky winner

那么最后为什么又从 277 修改为 59 呢?

因为使用 227 这样一个“巨大 ”的因子,会有大概 1-2% 的性能损失。所以需要换一个数字。

最终决定就选 59 了,虽然也没有说具体原因:

但是结合 changelog 来看,我有理由猜测原因之一是要选一个小于 127 的数,因为 -128 到 127 在 Integer 的缓存范围内:

IDEA

说起 IDEA 的 BUG,我早年间可是踩过一次印象深刻的 “BUG”。

以前在调试 ConcurrentLinkedQueue 这个东西的,直接把心态给玩崩了。

你有可能会碰到的一个巨坑,比如我们的测试代码是这样的:

public class Test {

public static void main(String[] args) {
ConcurrentLinkedQueue<Object> queue = new ConcurrentLinkedQueue<>();
queue.offer(new Object());
}
}

非常简单,在队列里面添加一个元素。

由于初始化的情况下 head=tail=new Node(null):

所以在 add 方法被调用之后的链表结构里面的 item 指向应该是这样的:

我们在 offer 方法里面加入几个输出语句:

执行之后的日志是这样的:

为什么最后一行输出,【offer之后】输出的日志不是 null->@723279cf 呢?

因为这个方法里面会调用 first 方法,获取真正的头节点,即 item 不为 null 的节点:

到这里都一切正常。但是,当你用 debug 模式操作的时候就不太一样了:

头节点的 item 不为 null 了!而头节点的下一个节点为 null,所以抛出空指针异常。

单线程的情况下代码直接运行的结果和 Debug 运行的结果不一致!这不是遇到鬼了吗。

我在网上查了一圈,发现遇到鬼的网友还不少。

最终找到了这个地方:

https://stackoverflow.com/questions/55889152/why-my-object-has-been-changed-by-intellij-ideas-debugger-soundlessly

这个哥们遇到的问题和我们一模一样:

这个问题下面只有一个回答:

你知道回答这个问题的哥们是谁吗?

IDEA 的产品经理,献上我的 respect。

最后的解决方案就是关闭 IDEA 的这两个配置:

因为 IDEA 在 Debug 模式下会主动的帮我们调用一次 toString 方法,而 toString 方法里面,会去调用迭代器。

而 CLQ 的迭代器,会触发 first 方法,这个里面和之前说的,会修改 head 元素:

一切,都真相大白了。

而这篇文章里面的问题:

我有理由确定就是 IDEA 的问题,但是也没有找到像是这一小节里面的问题的权威人士的认证。

所以我前面说的差点意思,就是这个意思。

— 本文首发于公众号why技术。

商匡云商
Logo
注册新帐户
对比商品
  • 合计 (0)
对比
0
购物车