final修饰基本类型时，变量与值的绑定在编译期固化，字节码禁止任何赋值指令，声明或构造器中必须且仅能初始化一次，反射也无法修改。

final修饰基本数据类型时，“不可变”不是靠运行时检查，而是编译期就封死赋值路径。JVM把这类变量当作“一次性绑定”，一旦初始化完成，变量名和那个具体数值的关联关系就被固化在字节码里。

值被直接固化在栈帧中

基本类型变量（如int、boolean、char）的值存在栈上。final修饰后，JVM不允许在后续任何地方生成对该变量的putfield或istore指令（针对局部变量）。也就是说，字节码层面压根没有“改值”的操作空间。

• 声明即赋值：final int x = 5; → 编译后x直接作为常量参与计算（比如x + 3可能被优化成8）
• 构造器中赋值：final int id; 必须在构造方法结束前写this.id = 100;，否则编译失败
• 没有“延迟初始化”余地：实例初始化块、静态块也必须覆盖所有分支，确保每条执行路径都赋值一次

编译器强制拦截所有非法写入

你写的x = 20;不会等到运行时报错——javac在语法分析阶段就标记为错误，直接拒绝生成class文件。

• 报错信息明确：cannot assign a value to final variable 'x'
• 连自增运算符x++、复合赋值x += 1都不允许，因为它们本质都是赋值操作
• 反射也不能绕过：Field.set()对final基本类型字段会抛IllegalAccessException

和“不可变对象”有本质区别

这里锁定的是“变量与值的绑定”，不是内存里的某个状态。它不涉及对象头、锁或可见性保障，也不影响多线程读取一致性（final基本类型字段在构造完毕后对其他线程天然可见，这是JMM的保证，但机制独立于“值不可变”本身）。

• 不是靠同步或volatile实现，而是语言规范+编译约束共同作用的结果
• 哪怕把final int改成static final，底层仍是同一套绑定逻辑，只是存储位置从栈/堆移到方法区常量池
• 这种锁定是单向的：你可以读无数次，但写零次——连“写一次再读”都不被允许