Java 中的并发同步，本质上是一个作用域问题。类变量与实例变量虽然都面临多线程读写，但它们的共享范围截然不同——类变量属于全局层级，所有实例均可访问；实例变量则绑定到具体对象，仅当多个线程同时操作同一个对象时才会引发竞争。因此，同步策略不应“一刀切”地加锁，而需根据变量类型、访问模式及性能要求进行分层选择。下面将关键要点逐一展开。
首先来看类变量。由于全局唯一，它极易成为高并发场景下的热点。如果直接用 int count 加上 synchronized 方法保护，相当于把所有调用串行化，性能会急剧下降。更优的做法是：
- 若仅涉及简单计数或开关标志，优先选用
AtomicInteger、AtomicBoolean等原子类，它们基于 CAS 无锁更新，性能出色且天然线程安全。 - 若只是布尔状态、初始化完成标记这类“写一次、读多次”的场景，使用
volatile即可保证可见性，但需注意它不能用于count++等复合操作。 - 只有当逻辑复杂到需要多个变量协同更新、或需要条件判断后才能写入时，才应使用
synchronized静态方法或synchronized(ClassName.class)代码块，且务必控制好锁粒度，避免锁住整个类。
实例变量：按对象粒度锁定，避免锁升级
当多个线程操作不同的实例时，彼此互不影响；只有操作同一个对象的实例变量时才需要同步。因此关键只有两点：锁定谁，以及锁的粒度有多细。
- 同步实例方法（
public synchronized void update()）等价于synchronized(this)，适合轻量级、低频修改的场景。 - 如果方法中只有一小段代码涉及共享变量，应使用同步块：
synchronized(this) { /* 仅锁关键区域 */ }，以缩小阻塞范围。 - 若对象内部包含多个独立状态（如用户余额、积分、等级），可为每个状态分配独立的锁对象，实现锁分段，从而显著提升并发度。
避免常见陷阱：别混淆变量作用域与线程模型
许多并发问题都源于对变量生命周期和线程关系的判断失误。以下是一些老生常谈但极易踩坑的点：
- 方法内的局部变量始终是线程安全的，无需同步——它们存在于栈帧中，每个线程拥有独立的副本，天然隔离。
- 静态变量并不等同于“线程不安全”，但其全局共享性放大了竞态风险；实例变量也不等于“自动安全”，只有多线程共用同一对象时才存在危险。
- 切勿用
volatile替代synchronized来保护递增、赋值加校验等非原子操作，因为 volatile 仅保证可见性，不保证原子性。
进阶建议：结合业务语义选择同步机制
技术方案最终要服务于业务逻辑，而非为了炫技而堆砌工具。
- 若变量属于高频读取、低频写入的配置类，可采用
volatile加不可变对象（如final Map）的组合，读取时无锁，写入时整体替换引用。 - 若需要等待条件满足（如库存扣减前先检查余量），使用
ReentrantLock搭配Condition，比synchronized加wait/notify更灵活可控。 - 如果涉及跨多个对象的协作更新（如转账：A 扣款 + B 入账），则应考虑事务型设计（如数据库事务）或消息队列来解耦，而非强行在内存中加锁。
