Java类变量（static变量）仅在单个JVM内共享，多实例部署时各进程拥有独立副本，互不感知；应改用Redis、Nacos等外部服务实现跨节点一致性。
Java 类变量（即 static 变量）在单个 JVM 内确实全局共享，但在多实例部署场景下——比如 Spring Boot 多进程、Kubernetes 多 Pod、Docker 多容器或同一台机器启多个端口——它完全不共享。这不是 bug，而是 JVM 隔离机制的必然结果。
类变量的真实作用域：仅限当前 JVM
static 变量随类加载而初始化，存于元空间（JDK 8+），整个 JVM 中只有一份。但“整个 JVM”≠“整个系统”。只要启动多个应用进程，哪怕在同一台机器上跑 8080 和 8081 两个端口，它们就是两个独立 JVM，各自有：
- 独立的类加载器
- 独立的内存空间
- 独立的 static 变量副本
例如，一个 public static int counter = 0;，在 8080 实例里自增 5 次，值为 5；8081 实例里自增 3 次，值为 3——两者互不可见，也绝不会叠加成 8。
跨类共享有效，跨进程共享无效
static 变量天然支持跨实例、跨类共享，前提是这些类运行在同一个 JVM 中：
立即学习“Java免费学习笔记（深入）”；
- ClassA 和 ClassB 同属一个 Spring Boot 应用？可以共用
Config.API_TIMEOUT - 订单服务和用户服务部署在不同 JVM（哪怕代码完全一样）？各自的
Config.API_TIMEOUT完全独立，改一个不影响另一个 - 同项目中多个 Service 类调用同一个
CacheUtil.CACHE_MAP？只要没重启，所有 Bean 共享同一份 ConcurrentHashMap
最容易误用的三类场景
以下写法在单机开发时看似正常，上线集群后立刻失效：
-
内存缓存滥用：用
private static final Map<String, User> CACHE = new ConcurrentHashMap<>()做用户缓存——只存在本节点，其他节点查不到，也无法通知更新 -
开关硬编码：
public static boolean FEATURE_X_ENABLED = true——想灰度开关？必须逐台重启，无法动态生效 -
计数器裸用：
private static long totalRequests = 0——集群总请求数 = 单机数 × 每节点计数值，毫无统计意义
真正可用的替代方案
需要跨实例共享状态，必须引入外部一致存储：
- 高频读写 + 强一致性 → 用 Redis（支持原子操作、过期、发布订阅）
- 配置类数据 → 接入 Nacos / Apollo 等配置中心，支持实时推送与灰度发布
- 分布式限流 → 改用 Redis + Lua 或 Sentinel，而非基于 static 的令牌桶
- 唯一 ID 或序列号 → 使用雪花算法（依赖时间+机器ID）或数据库自增+步长分段
如果只是单 JVM 内协调（如模块间传参、统一开关、轻量池化），static 仍是简洁高效的选择——关键要清楚它的边界在哪里。
