Java 的 static 变量属于类级别，所有实例及同 JVM 进程中对该类的引用共享同一内存副本；但每次运行一个独立的 main 方法，都启动一个全新的 JVM 进程，因此不同类的 main 方法互不共享静态变量。
java 的 `static` 变量属于类级别，所有实例及同 jvm 进程中对该类的引用共享同一内存副本；但**每次运行一个独立的 `main` 方法，都启动一个全新的 jvm 进程**，因此不同类的 `main` 方法互不共享静态变量。
你遇到的现象——Chocolateee 修改了 Dairy.brandname，但 Chocolate1 仍输出原始值——并非 Java 静态机制失效，而是源于对 Java 执行模型的根本误解：每个以 java ClassName 方式启动的 main 方法，都会创建一个独立的 JVM 实例（进程），拥有完全隔离的类加载器、方法区和静态变量空间。
✅ 正确理解：static 共享的前提是「同一个 JVM 进程 + 同一个类加载器」
在你的代码中：
- 运行
Dairy.main()→ 启动 JVM 进程 #1，加载Dairy.class，初始化brandname = "oompaa..lumpaa..Drinks"； - 运行
Chocolateee.main()→ 启动 JVM 进程 #2，重新加载Dairy.class（新类加载器实例），再次初始化brandname为原始值，再修改为"..Yum Drinks"—— 此修改仅存在于进程 #2； - 运行
Chocolate1.main()→ 启动 JVM 进程 #3，第三次加载Dairy.class，bnameString在类初始化阶段（<clinit></clinit>）就已静态绑定为初始值"oompaa..lumpaa..Drinks"，后续任何外部进程的修改对此进程完全不可见。
? 验证关键点：
Chocolate1中static String bnameString = Dairy.brandname;是编译期静态绑定 + 类加载时一次性求值。JVM 在加载Chocolate1类时，会执行其静态初始化，此时读取的是当前 JVM 进程中Dairy.brandname的当前值（即首次加载时的默认值），而非运行时动态查表。
? 正确演示静态共享：单进程内跨类操作
以下代码在同一个 main 方法中依次调用，才能体现 static 的真正共享性：
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
package drinks;
public class Dairy {
public static String brandname = " oompaa..lumpaa..Drinks";
}
public class Chocolateee {
public static void changeDairyBrandname() {
Dairy.brandname = "..Yum Drinks";
}
}
public class DemoStaticSharing {
public static void main(String[] args) {
// 初始值
System.out.println("Initial: " + Dairy.brandname); // " oompaa..lumpaa..Drinks"
// 修改静态变量
Chocolateee.changeDairyBrandname();
// 同一 JVM 内立即可见
System.out.println("After change: " + Dairy.brandname); // "..Yum Drinks"
// 模拟 Chocolate1 的逻辑（在运行时读取，非静态初始化）
String bnameRuntime = Dairy.brandname;
System.out.println("Runtime read: " + bnameRuntime); // "..Yum Drinks"
}
}
✅ 输出：
Initial: oompaa..lumpaa..Drinks After change: ..Yum Drinks Runtime read: ..Yum Drinks
⚠️ 关键注意事项与避坑指南
| 场景 | 是否共享 | 原因说明 |
|---|---|---|
同一 JVM 进程内（如单个 main 调用多个类方法） |
✅ 完全共享 | 类由同一 ClassLoader 加载，静态变量内存地址唯一 |
不同 JVM 进程（分别运行 java Dairy / java Chocolateee） |
❌ 完全隔离 | 每个进程有独立内存空间、独立类加载器、独立方法区 |
| Web 应用热部署（如 Tomcat 重启） | ❌ 隔离 | 新 WebAppClassLoader 加载新类，旧静态变量随旧类卸载 |
| 微服务多实例（K8s 多 Pod） | ❌ 隔离 | 每个 Pod 是独立 JVM 进程 |
-
不要在静态变量中存储可变上下文：如
RequestContext、ThreadLocal、Connection，极易引发内存泄漏或线程污染； -
常量优先用
public static final：编译期内联，安全高效（如public static final String API_URL = "...";）； -
可变状态务必线程安全：若需计数/缓存，用
AtomicInteger或synchronized块，避免count++竞态； -
单元测试需清理：使用
@AfterEach重置静态变量，防止测试间状态污染。
? 总结：static 不是“全局变量”，而是“类级单例”
Java 的 static 本质是 “一个类在当前类加载器作用域内的唯一数据副本”。它的强大在于轻量、高效、无需依赖框架；它的限制在于作用域严格受限于 JVM 进程与类加载器边界。真正掌握它，不是记住“共享”二字，而是理解 类加载时机、初始化顺序、进程隔离性 这三大底层机制——这正是你调试 Chocolate1 行为时缺失的关键视角。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
