17370845950

代码块控制变量作用域，{}内声明的变量仅在该块内可见；普通块限局部作用域，实例块随对象创建执行，静态块类加载时执行一次，同步块只影响锁粒度。

代码块在Java中到底控制什么范围

Java里的代码块（用{}围起来的部分）不光是组织代码的视觉分组，它直接定义变量的可见边界。只要变量在某个{}里用int x = 1;声明，它就只能在这个块内被访问——出了大括号，编译器就报错cannot resolve symbol。

这种限制不是语法糖，而是JVM栈帧分配的体现：每次进入代码块，局部变量表可能新增槽位；退出时这些槽位自动失效。所以哪怕只是写了个空{}，里面声明的变量也活不到外面。

四种常见代码块的实际作用差异

Java里有四种带{}的结构，行为完全不同：

• 普通代码块：方法内部任意位置的{ int tmp = 5; }，仅限该块作用域
• 实例初始化块：类中但不在方法里的{ System.out.println("init"); }，每次new对象时执行，顺序在构造器之前
• 静态初始化块：用static { ... }修饰，类加载时执行且只一次，不能访问实例成员
• 同步代码块：synchronized(obj) { ... }，只影响锁粒度，不改变变量作用域

最容易混淆的是后两者——静态块里不能写this.name，而实例块里可以，但都不能直接调用非静态方法（除非通过对象引用）。

作用域嵌套时的变量遮蔽陷阱

当内层代码块声明了和外层同名的变量，外层变量会被临时“遮蔽”，但不是覆盖或销毁：

int x = 10;
{
    int x = 20; // 编译通过，但警告"local variable hides another local variable"
    System.out.println(x); // 输出20
}
System.out.println(x); // 仍输出10

这种写法合法但危险，尤其在调试时容易误判变量值来源。IDE通常会标黄警告，但JVM不阻止。

更隐蔽的问题是循环内声明变量：

for (int i = 0; i < 3; i++) {
    int val = i * 2;
    System.out.println(val)
;
}
// System.out.println(val); // 编译错误：val cannot be resolved

很多人以为for括号里的i和循环体里的val作用域一样，其实i的作用域是整个for语句（包括条件和更新部分），而val只在花括号内——这是语法层面硬性规定的，不是风格问题。

为什么Lambda表达式里只能访问final或effectively final变量

这其实是代码块作用域规则的延伸。Lambda本质是生成一个函数式接口实现类，捕获的外部变量要被复制到新对象的字段里。如果允许修改非final变量，就会出现堆上对象和栈上原始变量状态不一致的问题。

所以即使没写final，只要变量在初始化后没再赋值（即effectively final），就能在Lambda里用：

String prefix = "log: ";
Runnable r = () -> System.out.println(prefix + "start"); // OK
// prefix = "err: "; // 如果放开这行，上面Lambda会编译失败

这个限制常被误解为“Lambda不能改外部变量”，其实它根本没改外部变量——它只是拿了个快照。真正容易忽略的是：数组引用本身是effectively final，但数组元素可以改，因为修改的是堆内存内容，不是引用本身。