java类变量状态传递需平衡共享与隔离：静态变量+同步控制适用于读多写少场景；threadlocal解决线程内独享状态，须防内存泄漏；消息队列实现跨服务解耦；不可变对象保障高并发安全。
Java类变量在大型系统中传递状态，核心矛盾是“共享”与“隔离”的平衡——既要让必要信息跨线程/模块可见，又要避免竞态、内存泄漏和耦合失控。没有银弹方案，选型取决于数据性质、生命周期、访问模式和系统规模。
静态变量 + 同步控制：简单场景下的可控共享
适用于配置类、计数器、单例服务等读多写少、变更频率低的全局状态。关键不是“能不能用”，而是“怎么锁得恰到好处”。
- 避免直接 public static int；用 private static + synchronized getter/setter 或 AtomicInteger 等原子类
- 写操作少时，优先用 volatile（如开关标志、版本号），它比 synchronized 轻量，但不保证复合操作原子性
- 若需复杂逻辑（如“先查再改”），必须用 synchronized 块或 ReentrantLock，锁粒度尽量小，别锁整个类
ThreadLocal：线程内独享状态的黄金路径
适合请求上下文（如用户ID、事务ID、traceId）、数据库连接、格式化器等“每个线程一份、互不干扰”的场景。大型系统中，它是解耦和避免锁的首选。
- 务必在 finally 块或 try-with-resources 中 remove()，否则在线程池复用下极易内存泄漏
- 不要把它当“全局变量替代品”——它不解决跨线程通信，只解决线程内状态携带
- Spring 的 RequestContextHolder、MyBatis 的 SqlSessionHolder 都是典型 ThreadLocal 应用
消息队列 + 事件驱动：跨服务/模块的状态解耦
当状态需要跨越 JVM 边界（如微服务间）、或涉及异步处理（如日志、通知、补偿），硬共享变量就失效了。此时应转向事件机制。
- 本地事件可用 Spring ApplicationEventPublisher，轻量且无额外依赖
- 分布式场景优先选 Kafka/RocketMQ：生产者发状态变更事件，消费者各自更新本地缓存或触发业务逻辑
- 关键点：事件要幂等，状态最终一致性可接受，避免强实时同步带来的瓶颈
不可变对象 + 函数式传递：高并发下的安全基石
对配置、规则、DTO 等只读数据，放弃“修改变量”，转为“创建新对象”。这是最彻底的线程安全方案，也是响应式编程和现代框架（如 Reactor、Stream）的底层哲学。
- 用 final 字段 + 构造器初始化，禁止 setter；集合用 Collections.unmodifiableList 或 Guava 的 ImmutableXxx
- 状态变更时返回新实例（如 builder 模式），调用方决定是否替换引用
- 虽增加 GC 压力，但在读密集、CPU 密集型服务中，远比锁竞争和缓存一致性开销小
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
