代码块控制变量作用域，{}内声明的变量仅在该块内可见；普通块限局部作用域，实例块随对象创建执行，静态块类加载时执行一次，同步块只影响锁粒度。
代码块在Java中到底控制什么范围
Java里的代码块（用{}围起来的部分）不光是组织代码的视觉分组，它直接定义变量的可见边界。只要变量在某个{}里用int x = 1;声明，它就只能在这个块内被访问——出了大括号，编译器就报错cannot resolve symbol。
这种限制不是语法糖，而是JVM栈帧分配的体现：每次进入代码块，局部变量表可能新增槽位；退出时这些槽位自动失效。所以哪怕只是写了个空{}，里面声明的变量也活不到外面。
四种常见代码块的实际作用差异
Java里有四种带{}的结构，行为完全不同：
-
普通代码块：方法内部任意位置的
{ int tmp = 5; }，仅限该块作用域 -
实例初始化块：类中但不在方法里的
{ System.out.println("init"); }，每次new对象时执行，顺序在构造器之前 -
静态初始化块：用
static { ... }修饰，类加载时执行且只一次，不能访问实例成员 -
同步代码块：
synchronized(obj) { ... }，只影响锁粒度，不改变变量作用域
最容易混淆的是后两者——静态块里不能写this.name，而实例块里可以，但都不能直接调用非静态方法（除非通过对象引用）。
立即学习“Java免费学习笔记（深入）”；
作用域嵌套时的变量遮蔽陷阱
当内层代码块声明了和外层同名的变量，外层变量会被临时“遮蔽”，但不是覆盖或销毁：
int x = 10;
{
int x = 20; // 编译通过，但警告"local variable hides another local variable"
System.out.println(x); // 输出20
}
System.out.println(x); // 仍输出10
这种写法合法但危险，尤其在调试时容易误判变量值来源。IDE通常会标黄警告，但JVM不阻止。
在整本书中我们所涉及许多的Flex框架源码，但为了简洁，我们不总是显示所指的代码。当你阅读这本书时，要求你打开Flex Builder，或能够访问Flex3框架的源码，跟随着我们所讨论源码是怎么工作及为什么这样做。 如果你跟着阅读源码，请注意，我们经常跳过功能或者具体的代码，以便我们可以对应当前的主题。这样能防止我们远离当前的主题，主要是讲解代码的微妙之处。这并不是说那些代码的作用不重要，而是那些代码处理特别的案例，防止潜在的错误或在生命周期的后面来处理，只是我们当前没有讨论它。有需要的朋友可以下载看看
更隐蔽的问题是循环内声明变量：
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，但数组元素可以改，因为修改的是堆内存内容，不是引用本身。
