java变量可见性分访问控制（由private等修饰符决定编译期语法可见性）和运行时值可见性（依赖volatile、final、varhandle及初始化顺序），二者解决不同问题；推荐private+getter/setter封装，volatile用于状态标志，final保障安全发布，varhandle提供更细粒度控制。
Java 变量初始化过程中的可见性控制，核心在于区分“谁能看到变量”和“谁能在什么时候看到变量的正确值”。前者由访问修饰符（private、protected、public、包私有）决定；后者则依赖内存模型机制（如 volatile、final、VarHandle）和初始化顺序（静态块、实例块、构造器）。两者常被混淆，但解决的问题完全不同。
访问修饰符决定“能否访问”，不是“是否可见”
访问修饰符只控制编译期的语法可见性，不保证多线程下运行时的值可见。
- private 字段只能在本类中读写，但若未加同步或 volatile，在其他线程中仍可能看到过期值
- public 字段可被任意类访问，但若未做并发控制，多个线程同时读写会导致数据错乱
- 包私有（无修饰符）字段仅限同包类访问，但同样面临可见性问题——比如子线程修改后主线程看不到最新值
- 推荐做法：一律用 private + getter/setter，把访问控制权收归类内部，便于后续添加同步或校验逻辑
volatile 和 final 是最常用的可见性保障手段
当变量需在多线程间共享且要求及时更新，仅靠访问修饰符远远不够。
- volatile 保证每次读都从主内存获取最新值，每次写都立即刷回主内存，适用于状态标志（如 stop = true）、简单布尔或数值开关
- final 字段在构造器结束前必须完成赋值，JVM 保证其初始化完成后的值对所有线程可见（即“安全发布”），适合配置项、不可变对象引用
- 注意：volatile 不保证复合操作原子性（如 i++），仅用于单次读/写场景
- 替代方案：Java 9+ 的 VarHandle 提供更细粒度的内存语义控制，比 volatile 更轻量，支持更强的排序约束
嵌套类中变量可见性的关键在初始化时机
内部类（尤其是静态内部类、局部内部类）的变量能否被访问、看到什么值，取决于外部类是否已初始化、字段是否已赋值。
- 静态内部类的 static 成员加载时，不会触发外部类初始化；但若外部类 static 字段是编译期常量（static final 基本类型或字符串），会被内联，不触发任何类加载
- 实例内部类依赖外部类实例，创建时外部类字段可能尚未初始化完毕——若在实例块中 new Inner()，而 Inner 引用了外部类中声明在实例块之后的字段，将读到默认值（null/0）
- 局部内部类和匿名类只能捕获 effectively final 的局部变量，本质是复制一份快照，不是实时引用；如需动态更新，可用 AtomicInteger 或自定义 Holder 包装
调试可见性问题的实用技巧
光看代码很难判断实际执行顺序，必须借助可观测手段定位问题根源。
- 在每个静态块、实例块、构造器、内部类字段初始化处插入带类名和序号的日志，例如：System.out.println("[Outer.
] static init") - 配合 JVM 参数 -XX:+TraceClassLoading 查看类加载真实时序
- 对关键共享变量加 volatile 后再测试，若问题消失，基本可确认是可见性缺陷
- 使用 IDE 调试器观察字段值变化，特别注意不同线程栈帧中同一变量的值是否一致
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
