java中类变量和实例变量的并发更新需分层选择同步策略：类变量优先用原子类或volatile，慎用synchronized；实例变量按对象粒度锁定，避免锁升级，并注意volatile不能替代synchronized处理复合操作。
Java中类变量（static）和实例变量的并发更新，本质是两类不同作用域共享状态的线程安全问题。类变量被所有实例共享，天然跨线程可见；实例变量则绑定到具体对象，多线程访问同一对象时才构成竞争。同步策略需按变量类型、访问模式和性能要求分层选择，而非一概加锁。
类变量：优先用原子类或volatile，慎用synchronized
类变量因全局唯一，极易成为高竞争热点。直接用int count并靠synchronized方法保护，会严重串行化所有调用。
- 若仅需简单计数、开关标志等——首选
AtomicInteger、AtomicBoolean等原子类。它们基于CAS实现无锁更新，性能高且天然线程安全。 - 若只是布尔状态、初始化完成标记等“写一次、读多次”场景——用
volatile即可保证可见性，但不可用于count++这类复合操作。 - 仅当逻辑复杂（如需多个变量协同更新、条件判断后再写入）时，才考虑
synchronized静态方法或synchronized(ClassName.class)代码块，锁粒度必须严格控制。
实例变量：按对象粒度锁定，避免锁升级
多个线程操作不同实例，互不影响；只有操作同一对象的实例变量时，才需同步。关键在于“锁谁”和“锁多细”。
- 同步实例方法（
public synchronized void update()）等价于synchronized(this)，适合轻量级、低频修改场景。 - 若方法内只有一小段代码涉及共享变量，应改用同步块：
synchronized(this) { /* 只锁关键区 */ }，减少阻塞范围。 - 若对象内部有多个独立状态（如用户余额、积分、等级），可为每个状态分配独立锁对象，实现锁分段，提升并发度。
避免常见陷阱：别混淆变量作用域与线程模型
很多并发问题源于对变量生命周期和线程关系的误判。
- 方法内局部变量永远线程安全，无需同步——它们存于栈帧，天然隔离。
- 静态变量不等于“线程不安全”，但它的共享性放大了竞态风险；实例变量也不等于“自动安全”，只有多线程共用同一对象时才危险。
- 不要用
volatile替代synchronized来保护递增、赋值+校验等非原子操作，它只保可见，不保原子。
进阶建议：结合业务语义选同步机制
技术方案要服务于业务逻辑，而非堆砌工具。
- 高频读、低频写的配置类变量——用
volatile+ 不可变对象（如final Map）组合，读无锁，写时替换整个引用。 - 需要等待条件满足（如库存扣减前检查余量）——用
ReentrantLock配合Condition，比synchronized+wait/notify更可控。 - 跨多个对象协作更新（如转账：A扣款+B入账）——考虑使用事务型设计（如数据库事务）或消息队列解耦，而非强行在内存中加锁。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
