应优先用 synchronized 块保护临界区而非整个方法，避免过度同步；锁对象须私有不可变；简单操作优先用 AtomicInteger 等原子类；复杂逻辑选 ReentrantLock；volatile 仅保可见性与有序性，不保证原子性。
用 synchronized 块保护临界区，而不是整个方法
方法级同步（synchronized 修饰符加在方法上）容易过度锁住，拖慢并发性能。真正需要保护的只是读写共享变量的那一小段逻辑——也就是临界区。
常见错误是把整个 run() 或业务方法都标为 synchronized，结果多个线程串行执行，失去多线程意义。
- 只对共享变量的读写操作加锁，例如
synchronized(lockObj) { count++; } - 锁对象要私有且不可变，避免被外部误用或泄露；推荐用
private final Object lock = new Object(); - 不要用
this或类对象（MyClass.class）作锁，除非你明确控制全部同步点
优先使用 java.util.concurrent.atomic 包中的原子类
对简单计数、标志位、引用更新这类操作，AtomicInteger、AtomicBoolean、AtomicReference 比手动加锁更轻量、更安全。
它们底层依赖 CPU 的 CAS（Compare-And-Swap）指令，无锁但保证可见性和原子性，避免了死锁和锁竞争开销。
立即学习“Java免费学习笔记（深入）”；
-
count.incrementAndGet()替代synchronized块里的count++ - 注意：原子类只保证单个操作的原子性，复合操作（如“先读再条件更新”）仍需
synchronized或StampedLock - 不支持像
wait()/notify()这类协作机制，别试图在原子类上做线程等待
用 ReentrantLock 替代内置锁，当需要超时、可中断或公平性控制时
synchronized 简单可靠，但功能固定：不可中断、不支持超时、非公平（可能饥饿）。一旦遇到这些需求，就得换 ReentrantLock。
典型场景包括：防止线程无限阻塞、响应中断请求、或确保长等待线程最终能获取锁。
- 必须显式调用
lock.lock()和lock.unlock()，且unlock()要放在finally块中 -
tryLock(long, TimeUnit)可设超时，避免死等；lockInterruptibly()支持中断响应 - 开启公平模式（
new ReentrantLock(true)）会显著降低吞吐量，仅在确实存在饥饿问题时启用
别忽略 volatile 的适用边界：它不解决竞态，只保可见性与有序性
很多开发者误以为加了 volatile 就能安全共享变量，结果依然出现诡异的计算错误。它只保证写操作对其他线程立即可见，并禁止指令重排序，但不保证复合操作的原子性。
比如 volatile int counter; 后的 counter++ 仍是“读-改-写”三步，三个线程同时执行就会丢更新。
- 适合场景：状态标志（
volatile boolean shutdownRequested）、双重检查锁定中的单例引用 - 不适合场景：任何需要“读取后判断再修改”的逻辑，例如
if (count - 配合
AtomicInteger使用时，volatile是多余的——原子类内部已处理好内存语义
volatile 或 AtomicInteger，只要逻辑跨多步，就得回到锁或更高级同步工具。这不是语法问题，而是对“共享状态变更边界”的理解是否到位。 
