synchronized块保护共享变量最直接，需锁最小临界区并用私有锁对象；volatile仅保可见性不保原子性；AtomicInteger等并发工具更高效；ThreadLocal实现线程隔离而非共享。
用 synchronized 块保护共享变量最直接
当多个线程读写同一个对象字段（如 counter++）时，非原子操作会导致数据丢失。加 synchronized 是最基础且可控的方案，关键不是锁整个方法，而是锁最小临界区。
- 优先用私有锁对象（
private final Object lock = new Object();），避免锁this或类对象引发意外竞争 - 不要在同步块里调用外部可变对象的方法（比如
list.sort(...)），可能造成锁升级或死锁 -
synchronized无法解决“先检查后执行”（check-then-act）问题，例如if (list.isEmpty()) list.add(x);需整体包裹
private int counter = 0;
private final Object lock = new Object();
public void increment() {
synchronized (lock) {
counter++; // 这才是原子的
}
}
java.util.concurrent 包里的工具类更高效
对计数、队列、Map 等常见结构，JDK 提供了无锁或分段锁实现，性能远高于粗粒度 synchronized，且语义清晰。
-
AtomicInteger适合简单状态计数，但注意getAndIncrement()和incrementAndGet()返回值不同 -
ConcurrentHashMap不允许null作为 key 或 value，否则抛NullPointerException -
CopyOnWriteArrayList适合读多写少场景，但每次写都复制数组，写频繁时内存和 GC 压力大
private AtomicInteger counter = new AtomicInteger(0);
private ConcurrentHashMap<String, String> cache = new ConcurrentHashMap<>();
public void addCache(String key, String value) {
cache.putIfAbsent(key, value); // 原子性保证，无需额外同步
}
ThreadLocal 不是共享，而是“伪共享”隔离
很多人误以为 ThreadLocal 能解决共享数据一致性问题，其实它恰恰相反：每个线程持有一份独立副本。适用于“线程内单次使用、避免参数层层传递”的场景，比如数据库连接、用户上下文。
Java Maven Common
下载
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
-
ThreadLocal变量不清理会导致内存泄漏（尤其在线程池中），务必在 finally 块或使用 try-with-resources 风格调用remove() - 不能用于跨线程传递数据；子线程不会自动继承父线程的
ThreadLocal值，需显式用InheritableThreadLocal - 它的
set()和get()操作本身是线程安全的，但内部对象（如SimpleDateFormat）仍需自行保证线程安全
private static final ThreadLocal<SimpleDateFormat> formatter =
ThreadLocal.withInitial(() -> new SimpleDateFormat("yyyy-MM-dd"));
public String formatDate(Date date) {
try {
return formatter.get().format(date);
} finally {
// formatter.remove(); // 忘记这句，在线程复用时可能污染后续请求
}
}
volatile 仅保证可见性，不保证原子性
volatile 关键字常被误当作“轻量级同步”，但它只做两件事：禁止指令重排序 + 强制每次读写都走主内存。对复合操作（如 i++）完全无效。
立即学习“Java免费学习笔记（深入）”；
- 适用场景很窄：布尔开关标志（
running = false）、一次性发布（如单例双重检查中的 instance 字段） - 不能替代
synchronized或原子类，volatile int counter依然会因竞态导致结果错误 - 在 Java 5+ 中语义已明确，但低版本 JVM 行为不可靠，慎用于老环境
private volatile boolean shutdownRequested = false;
public void shutdown() {
shutdownRequested = true; // ✅ 安全：单纯写入
}
public void doWork() {
while (!shutdownRequested) { // ✅ 安全：单纯读取
// ...
}
}
真正难的是识别哪些状态必须强一致、哪些可以最终一致。比如缓存更新失败是否允许短暂脏读，日志计数是否允许丢失几条——这些业务语义决定了该用 ReentrantLock 还是 StampedLock，甚至要不要放弃强一致性改用消息队列解耦。 
