应锁具体资源而非整个方法，避免无关操作串行化；如转账时按对象哈希码顺序加锁，防止死锁并提升并发性。
用 synchronized 锁住临界区，但别锁整个方法
直接在方法上加 synchronized 会让所有调用串行化，哪怕操作的是不同对象或无关字段。比如一个 Account 类里有 balance 和 lastLoginTime，只改余额时不该阻塞登录时间更新。
更合理的做法是锁具体资源：
public void transfer(Account from, Account to, BigDecimal amount) {
// 按 hashcode 顺序加锁，避免死锁
Object lock1 = from.hashCode() < to.hashCode() ? from : to;
Object lock2 = from.hashCode() < to.hashCode() ? to : from;
synchronized (lock1) {
synchronized (lock2) {
from.withdraw(amount);
to.deposit(amount);
}
}
}
- 不要用
this或类锁（Account.class）做账户间转账锁，极易引发死锁 - 多个共享变量需同时修改时，必须保证所有线程按相同顺序获取锁
-
synchronized块比同步方法粒度更细，吞吐量通常高 2–5 倍（视竞争强度而定）
优先用 java.util.concurrent 包里的线程安全类型
不是所有共享状态都适合加锁。计数器、累加器、队列这些高频场景，AtomicInteger、LongAdder、ConcurrentHashMap 已经做了底层优化，比手写锁更轻量、更可靠。
-
AtomicInteger适用于简单整数增减，如请求计数：counter.incrementAndGet() -
LongAdder在高并发写+低频读场景下比AtomicLong快 3–10 倍（内部分段累加） -
ConcurrentHashMap的computeIfAbsent()是线程安全的初始化入口，别在外部再套synchronized - 避免把
ArrayList包一层Collections.synchronizedList()后就认为遍历安全——迭代过程仍可能抛ConcurrentModificationException
用 ThreadLocal 隔离线程内状态，但记得 remove()
当每个线程需要自己独占一份变量（比如数据库连接、用户上下文、格式化器），ThreadLocal 是最自然的选择。但它不自动清理，线程复用（如线程池）时会引发内存泄漏或脏数据。
立即学习“Java免费学习笔记（深入）”；
- Web 应用中，每次请求结束前必须调用
threadLocal.remove()，不能只靠set(null) - 不要把大对象（如
StringBuilder或缓存 Map）长期存在ThreadLocal中 - 继承
InheritableThreadLocal要谨慎：子线程会复制父线程值，但多数线程池不支持该行为，容易误以为“传递成功”
别依赖“看起来不会并发”的代码逻辑
比如一个单例类里有个未加锁的布尔标记 isInitialized，配合双重检查创建资源，却忘了用 volatile 声明它。JVM 可能重排序指令，导致其他线程看到已赋值但未初始化完成的对象。
-
volatile不保证原子性，但能禁止指令重排 + 强制内存可见性，适用于状态标志、一次性初始化 -
final字段在构造器内完成赋值后，对所有线程天然可见，适合配置类、不可变 DTO - 即使只读集合（如
Arrays.asList(...)）也不是线程安全的——底层仍是普通数组，没有同步机制
并发问题往往在压测或高峰时段才暴露，且难以复现。真正安全的设计不是靠“应该没问题”，而是明确每处共享变量的访问契约：谁写、谁读、是否需要同步、失效边界在哪。
