stackoverflow
经过前面的分析，留言中提到的结论是验证不下去了。
但是我已经可以非常明确的知道，肯定是 final 关键字在作怪。
于是，我准备去 stackoverflow 上找一圈，看看会不会有意外发现。
果然，皇天不负有心人，我大概翻了几百个帖子，就在准备放弃的边缘，我翻到了一个让我虎躯一震的帖子。
虎躯一震之后，又是倒吸一口凉气：我的个娘，这是 JVM 的一个 BUG！？
这事先按下不表，我先说说我是怎么在 stackoverflow 里面搜索问题的。
首先，当前的这个情况下，我能确定的关键字就是 Java,final 这两个。
但是我拿着这两个关键字去查的时候，查询出来的结果太多了，翻了几个之后我就发现这无疑是大海捞针。
于是我改变了策略，stackoverflow 上搜索是有 tag 即标签功能的：
如果让我把这个问题划分一个标签，标签无非就是 Java,JVM,JMM,JIT。
于是，我在 java-memory-model 即 JMM 下挖到了一个宝藏：
就是这个宝藏问题，推动了接下来的剧情发展：
我知道你看到这里的时候内心毫无波澜，听到我虎躯一震，甚至还想笑。
但是我看到这个问题的时候，不夸张的说：手都在抖。
因为我知道，在这里，就能解决这个玄学问题了。
而我倒吸一口凉气的原因是：这个问题里面的示例代码竟然和我的代码如出一辙，他代码里面的 Simple 就是对应着我代码里面的 Why。想要验证的问题，那就更是一模一样了。
问题里面的描述是这样说的：
Actually, I know the storing "final" field would not emit any assembly instructions on x86 platform. But why this situation came out? Are there some particular operations I don't know ?
实际上，我知道“final”字段不会在 x86 处理器上发出任何汇编指令。但为什么会出现这种情况？有什么特别的操作我不知道吗？
真相
上面提到的 stackoverflow 问题下面有这样的一个回答，这里面就是玄学背后的科学：
我翻译一下给你看：
老哥，我看到你问题里面的截图了，你查问题的姿势没对。
截图是什么呢？
就是提问者附在问题里面的两个截图：
其中 final case 的截图是这样的：
