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 能解决共享数据一致性问题，其实它恰恰相反：每个线程持有一份独立副本。适用于“线程内单次使用、避免参数层层传递”的场景，比如数据库连接、用户上下文。
PHP5 和 MySQL 圣经
下载
本书是全面讲述PHP与MySQL的经典之作，书中不但全面介绍了两种技术的核心特性，还讲解了如何高效地结合这两种技术构建健壮的数据驱动的应用程序。本书涵盖了两种技术新版本中出现的最新特性，书中大量实际的示例和深入的分析均来自于作者在这方面多年的专业经验，可用于解决开发者在实际中所面临的各种挑战。
-
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，甚至要不要放弃强一致性改用消息队列解耦。 
