Java变量的可见性与作用域本质是编译期约束与运行时内存布局共同作用的结果：局部变量存于栈帧、无默认值、出块即销毁；实例变量内嵌堆中对象、有默认值、随对象生命周期存在；静态变量驻留方法区、类加载即初始化、所有实例共享；多线程下共享变量需通过volatile或锁保障主内存同步。
Java变量的可见性与作用域，本质是编译期约束与运行时内存布局共同作用的结果。理解它不能只靠“能用/不能用”的表层规则，而要看到栈帧分配、堆内存归属、类加载时机这些底层机制如何协同决定一个变量“在哪里存”“被谁看到”“何时释放”。
局部变量：栈帧私有，无默认值，出块即销毁
方法内声明的变量（含形参、for/if块中定义的变量）全部分配在当前线程的Java栈中，每个方法调用对应一个独立栈帧。该帧内的局部变量表只对该帧可见，其他栈帧完全无法访问——这是JVM线程隔离的底层保障。
- 必须显式初始化才能读取，因为栈内存不自动清零；未赋值就使用会触发编译错误（javac在字节码校验阶段拦截），而非运行时异常
- 嵌套块中的变量（如if{}里声明的int x）生命周期严格绑定该块的执行：字节码中对应
astore/iload指令仅在块内有效，超出范围则指令非法 - 同名变量遮蔽（shadowing）是编译器符号解析行为：当查找
count时，从当前栈帧的局部变量表开始查，查不到才向上找实例变量——这与内存无关，纯属编译期名字绑定
实例变量：堆中对象附属，随对象生命周期存在
每个对象在堆内存中占据一块连续空间，实例变量作为对象状态的一部分，直接内嵌在该对象的内存布局里（紧跟对象头之后）。不同对象的同名实例变量物理地址完全不同，互不影响。
- 默认初始化发生在对象创建时（
new指令触发）：JVM在堆上分配内存后，会将数值类型字段置0、引用类型置null、boolean置false——这是堆内存清零操作，非编译器插入赋值语句 -
this的本质是指向当前对象堆内存首地址的引用，因此this.count实际是通过偏移量访问堆中固定位置的数据，与局部变量的栈地址访问方式截然不同 - 垃圾回收器（GC）决定其销毁时机：只有当对象不可达时，整个对象连同其所有实例变量才可能被回收，不存在“变量单独释放”的概念
静态变量：方法区常驻，类加载即初始化
静态变量存储在方法区（JDK8+为元空间），属于类元数据的一部分。类加载的“准备阶段”就为其分配内存并设默认值，“初始化阶段”再执行static {}或字段赋值语句。
立即学习“Java免费学习笔记（深入）”；
- 所有实例共享同一份数据：无论创建多少个对象，静态变量在内存中只有一个副本，修改立即对所有实例可见——这是通过类对象（Class instance）全局唯一性保证的
- 可通过
ClassName.field直接访问，无需对象实例，因为JVM在类加载时已将该字段地址注册到运行时常量池，解析过程不依赖堆对象 -
static final基本类型会被JVM内联优化：编译期就替换为字面量，运行时不占用方法区内存；但引用类型（如static final List）仍需在方法区分配空间并初始化
多线程下的可见性：主内存与工作内存的同步鸿沟
变量的“可见性问题”专指共享变量（实例变量、静态变量）在多线程环境中的读写一致性。JVM规范要求每个线程拥有自己的工作内存（缓存），而变量原始值存于主内存（堆/方法区）。线程间不直接通信，必须通过主内存中转。
- 普通变量无同步保障：线程A修改后可能长期滞留在工作内存，线程B读到的是过期副本——这是JMM允许的合法重排序
-
volatile强制刷新：写操作后立即将值刷回主内存，读操作前强制从主内存重载，但不保证原子性 - 锁机制（
synchronized/ReentrantLock）提供“全内存屏障”：加锁时清空工作内存，解锁时将变更刷回主内存，同时确保临界区代码不被重排序
