Java多线程共享变量冲突应优先用AtomicInteger等原子类处理单变量读改写操作，其次精准synchronized临界区、volatile状态通知、ThreadLocal隔离或不可变对象，根本上减少共享。
Java 中解决多线程同时修改共享变量引发的冲突，核心是保障操作的原子性、可见性、有序性。不能一概加锁，而要按场景选最轻量、最匹配的方案。
用原子类替代基础变量（推荐优先尝试）
适用于单变量的“读-改-写”类操作，比如计数器、开关标志、状态码等。
- 把
private static int count = 0;换成private static AtomicInteger count = new AtomicInteger(0); - 用
count.incrementAndGet()替代count++，底层靠 CPU 的 CAS 指令，无锁且线程安全 - 注意：不支持跨多个变量的复合逻辑（如“查余额→扣款→记日志”），这种仍需同步控制
精准使用 synchronized 控制临界区
不是锁整个方法，而是只包裹真正读写共享变量的那几行代码，减少阻塞范围。
- 静态变量建议用
synchronized (MyClass.class)，避免用this或新建对象作锁 - 锁对象必须私有且 final，例如：
private final Object lock = new Object(); - 嵌套加锁时固定顺序（如先锁 A 再锁 B），否则容易死锁
volatile 仅用于简单状态通知
它能保证变量修改对其他线程立即可见，并禁止指令重排序，但不保证原子性。
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
立即学习“Java免费学习笔记（深入）”；
- 适合：
private static volatile boolean running = true;这类纯开关、初始化完成标志 - 不适合：
count++、list.add()、任何含“读-改-写”的操作 - 可配合 double-checked locking 使用，但不能单独承担数据一致性责任
彻底消除共享：ThreadLocal 或实例化
很多问题其实源于不该共享却用了 static。先问一句：“它非得被所有线程共用吗？”
-
ThreadLocal为每个线程提供独立副本，适合用户上下文、格式化器、事务 ID 等场景 - 把 static 变量改为普通成员变量，交由 Spring 等容器管理生命周期，通过依赖注入传递
- 不可变对象（final 字段 + 无修改方法）也天然线程安全，适合配置类、DTO 等只读结构
不复杂但容易忽略：加锁只是手段，不是目的。优先考虑“能不能不共享”，其次才是“怎么安全地共享”。
