写了几年的Java业务代码，发现每天基本不是在各种牛逼的框架下搬砖，就是在if/else、for、BeanUtils.copy里浪费青春（请原谅我的直接）。是不是可以可以转变一下思路，既然接触不到或者是还没能力去触碰那些让你虎躯一震的代码，那可不可以从Java最基础的代码入手，搞懂那些以前很多时候只知道结果（有些甚至都答不上来），却不知道具体原因的代码，致以提高自身的水平呢？这就是为什么写这边文章的原因。（PS：以上全部都是我胡说八道的，其实我是被一个问题搞懵逼了）。
废话不多说，直接上代码：
这段代码我乍一看，两个都是true啊，都应该指向"hello world"这个字符串的在常量池中的地址啊，这有啥难的啊，自己跑了下代码，啪啪啪的脸都被打肿了（大家可以鄙视我一下）：
这是咋回事啊，经过我一番百度，最多的回答：Java 中宏变量/宏替换指的是在编译期某些变量能够直接被其本身的值所替换，编译到.class文件中，因此，编译后的.class文件中已经不存在此变量了。final修饰符修饰的变量在由于其本身的特性，在编译期就能直接确定其值，且此值不可变，不过要注意，只有在编译期间能确切知道final变量值的情况下，编译器才会进行这样的优化。不知道大家明白了不，我是没弄清楚，直到偶然间窥得大道之真言：可以通过查看class文件的字节码，查看Java在编译期间到底做了什么事情来搞明白这个流程，OK，那就来试一下吧：
先来编译一下这个测试类：javac -verbose FinalTest.java
注意倒数第三行，突然间乱入了StringBuilder，明明我的代码里面只有String啊，这说明肯定有个地方用到了它，在什么地方呢？我们继续看：Javap -verbose FinalTest.class(只截取了部分)
到此不知道大家看明白了没有，反正我是再一次的懵逼了，这是啥啊，是人看的吗？那换一种看法吧，在IDEA中安装ASM ByteCode插件，用那个去看看，如下图：
这么看是不是清楚多了？在编译期间，第9行被final修饰的变量b直接被替换成了"hello "，11行的d也相应的变成"hello world"，所以a==d是true没问题；而在第12行，也就是给e赋值的时候，居然是new了一个StringBuilder，接着用append做字符串的连接操作，最后调用toString方法，他们各自指向的物理内存地址是不一样的，所以a==e是false，是不是有种豁然开朗的感觉？有时候解决问题就是这么简单！
既然是关于.class文件字节码的，那我们来看看字节码文件到底是啥样的：
这。。。，啥玩意儿，关于.class文件的理解，我将会在下一篇再介绍，你以为我要结束了吗，太天真了，刚好借着这个机会我们来看看this这个关键字，还是借助之前的那个测试类吧，先看看构造方法：
默认的构造方法没有任何参数，但是在编译的时候，编译器居然帮我们做了一些幕后工作，它暗自把“所操作对象的引用”作为第一个参数传递给了方法，当然这些我们是无感知的，那是不是构造方法自己本身特殊呢，我们再写一个普通方法验证一下：
经过编译器编译之后的字节码：
再一次验证了之前的话，编译器真是为我们操碎了心啊！
以后遇到让你百思不得其解的代码时，从这个角度来看一看问题，说不定就柳暗花明又一村了！！！
