开始
一位朋友在群里问了这样一个问题：
本着乐于助人的想法，我当时给出的回答：
后来我总觉得哪里不对劲。
于是我仔细翻阅了《Java虚拟机规范》和《深入理解Java虚拟机》关于这一部分的内容。
害！发现自己理解的有问题。
因为自己的理解出错而误导了别人，实在是让我万分羞愧！
于是我加了这位朋友的好友，向这位朋友表达了歉意。
这位朋友也非常随和，对此表示理解。
今天讨论的问题就是从这个故事开始的。
final修饰的实例变量
我们先分析一下这个问题：
深入Java虚拟机有一句是ConstantValue属性的作用是通知虚拟机自动为静态变量赋值，只有被static关键字修饰的变量才可以使用这项属性。但为什么private final a = 10也可以被赋值？
我翻阅了《深入理解Java虚拟机》第二版，在第191页，确实有前面那句话
书中说的很清楚，ConstantValue属性的作用是通知虚拟机自动为静态变量赋值。
那就意味着只有static修饰的类变量才会在class文件中对应的字段表加上ConstantValue属性吗？
答案是否定的。
用final修饰的实例变量，编译成class文件的时候，对应的字段表也有可能会加上ConstantValue属性。
注意，我这里用了“可能”这两个字，因为这是有条件的。
哪些情况会有ConstantValue属性呢？
我们写一段代码，列举一下用final修饰的实例变量的几种情况。
然后用javap -verbose命令反编译查看字节码：
我们可以看到，在字段表集合里面有四个字段表：
分表对应着a,b,c,d,e五个实例属性。
他们都带有ACC_PUBLIC(public)和ACC_FINAL(final)的访问标志。
但只有a和b对应的字段表带有ConstantValue属性。
不难得出：
用final修饰不是在构造方法赋值的String类型或者基本类型成员变量，编译成字节码文件时，对应的字段表也会带有ConstantValue属性。
这个结论不和《深入理解Java虚拟机》冲突吗？
于是我翻阅了官网的JVM规范，在4.7.2部分我找到了这样一句话：
书中说的很清楚：
如果field_info（字段表）表示的非静态字段包含了ConstantValue属性，那么这个ConstantValue属性会被JVM虚拟机所忽略。
也就是说，对于非静态字段，就算你编译器加上了ConstantValue属性，JVM也会忽略掉，你加不加结果是一样的。
看完JVM规范里面的说明，再回来看《深入理解Java虚拟机》里面的这句话：
ConstantValue属性的作用是通知虚拟机自动为静态变量赋值，只有被static关键字修饰的类变量才可以使用这项属性。
作者的这句话的前半句没有什么争议，但我觉得后半句的表述的不太明确，容易造成误解。
以我的理解，应该是“只有被static关键字修饰的类变量才可以使用ConstantValue这项属性来进行初始化，否则使用这项属性也会被JVM忽略掉”
好了，我们再回到那位朋友问的问题：
“为什么private final a = 10也可以被赋值？”
首先，这个问题的本身就问的不太准确。
我理解这位朋友真正想问的是“为什么private final a = 10也可以通过ConstantValue属性的形式赋值？”
我觉得这是一个很好的问题。
这位朋友通过实验发现用final修饰的实例变量对应的字段表有ConstantValue属性。
结合《深入理解Java虚拟机》，他认为a是通过ConstantValue属性让虚拟机知道然后为其赋值的。
最后他发现和书中冲突，于是提出了上文的这个问题。
这位朋友的思路有问题吗？我觉得是没有问题的。
不过这样的理解是对的吗？显然是不对的。
因为虚拟机规范是这样规范的。对于非静态字段，ConstantValue属性是不会生效的。
至于为什么要这样设计，功力不够的我暂时无法理解设计者的想法。
那单独用final修饰的实例变量到底是在什么时候赋值的呢？
这个问题也不难回答，看一下字节码就清楚了。
图片可点击放大
通过查看字节码，我们可以看到生成了一个<init>
什么是<init>
我们温习一下这个英语四级短语：appear as
然后，我们一起翻译一下：
在JVM层面上，每一个用Java写的构造方法都表现为实例初始方法，这个方法就是<init>
我们再来看一下putfield这个字节码指令的含义：
为指定的类的实例域赋值的，也就是为实例变量赋值的指令。
知道了<init>方法是什么和putfield的含义后，结合上面的字节码，不难得出:
这些用final修饰实例变量是在实例构造器
static修饰的类变量
上面讲到ConstantValue属性的作用是通知虚拟机为静态变量赋值。
什么是静态变量？static修饰的变量！
那static修饰的变量是什么时候加载的呢？
在这之前，我需要给你把类加载的几个过程大致讲一下：
类的生命周期由7个阶段组成，类加载说的是前5个阶段:
即加载—>验证—>准备—>解析—>初始化。
类的生命周期图
我们简单过一下这几个阶段：
加载：将字节码所代表的静态存储结构转化为方法区的运行时数据结构。
验证：验证字节码格式，确保Class文件的字节流中包含的信息符合当前虚拟机的要求，并且不会危害虚拟机自身的安全。
准备：创建类或者接口的静态字段，并为静态变量设置初始值。
解析：将常量池内的符号引用替换为直接引用。
初始化：执行类构造器<clinit>
方法。
上面出现类构造器<clinit>
JVM 规范这样写道：
说白了，编译器会收集所有静态变量的赋值动作、所有静态代码块，合并产生一个方法，即<clinit>
回到static修饰的变量（类变量），类变量有两种赋值方式可以选择:
使用ConstantValue属性赋值。
在类构造器<clinit>方法中赋值。
目前Oracle公司实现的Javac编译器的选择是：
final+static修饰：使用ConstantValue属性赋值。
仅使用static修饰：在<clinit>方法中赋值。这个方法在类加载的初始化阶段执行。
需要注意点的是，用生成ConstantValue属性来进行初始化，这个变量必须是基本类型或者java.lang.String类型。
对于这一点，我们也可以通过javap -verbose命令反编译验证一下:
为什么呢？
这是因为Class文件格式的常量类型中只有与基本属性和字符串相对应的字面量，所以就算ConstantValue属性想支持别的类型也无能为力。
final+static修饰的常量
上面我们说过，<clinit>
那static+final修饰的常量是在类加载的那一阶段进行的呢？
我们可以看一下JVM规范：
我们可以看到在JVM规范里面，static+final修饰的常量是在初始化阶段执行
咦？网上的博客不都是在类加载的准备阶段会对普通类属性赋初始值，对带有ConstantValue的类属性直接赋值吗？
《深入理解Java虚拟机》也是这样说的啊？
书上是错的吗？不是的，因为《深入理解Java虚拟机》里面讲的具体实现，是基于HotSpot VM讲的。
确确实实，HotSpot VM就是这么干的，我们也可以在openJdk中找到对应的源码：
跟踪源码可以发现HotSpot VM对基本类型或者字符串类型的常量的赋值确实在准备阶段完成了。
但一个很关键的点是，虽然没在初始化阶段赋值，仍然在调用<clinit>方法
外界是不会观察到HotSpot VM提前做了这个初始化赋值的，所以是没问题的。
不过要记住的是：
JVM规范里明确说了正确的初始化时机是在“初始化（Initialization）”阶段。
总结
单独用final修饰的变量也有可能在字节码找到对应的ConstantValue属性，但是会被JVM忽略掉。
final修饰的实例属性，在实例创建的时候才会赋值。
static修饰的类属性，在类加载的准备阶段赋初值，初始化阶段赋值。
static+final修饰的String类型或者基本类型常量，JVM规范建议在初始化阶段赋值，但是HotSpot VM直接在准备阶段就赋值了。
static+final修饰的其他引用类型常量，赋值步骤和第二点的流程是一样的。
还有一点，一定不要把《深入理解Java虚拟机》和《Java虚拟机规范》搞混了。
《Java虚拟机规范》是官方JVM规范文档翻译而来的，所有的JVM实现都要遵从规范，但有强制要求的规范和建议的规范。
《深入理解Java虚拟机》是作者根据自己的理解，结合HotSpot VM的具体实现，为了让读者更容易理解JVM而写的一本书。
写在最后
本人才疏学浅，OpenJdk源码也理解的不够透彻。
为了说清楚文中的一些知识，我翻阅了很多资料。
但是还是有一部分的知识点无法找到权威的资料证明。
不过我尽量都基于官方文档展开分析，如果有认识有差错的地方，欢迎指出！我定会在第一时间修改，不误导别人！
最后，感谢你的阅读！
如果可以，点赞、再看加关注，谢谢你！
文章中涉及测试代码：https://github.com/xiaoyingzhi/blog
JVM Spec Java SE 8Edition：https://docs.oracle.com/javase/specs/jvms/se8/jvms8.pdf
IDEA查看字节码插件：https://plugins.jetbrains.com/plugin/9248-jclasslib-bytecode-viewer
《深入理解Java虚拟机》：各大购书平台都可购买，建议购买第三版。
本文分享自微信公众号 - CoderW（MHXJ_0810）。
如有侵权，请联系 [email protected] 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。