优先用 synchronized 块而非方法，以控制锁粒度；ReentrantLock 适用于需超时、中断或公平锁等场景；Vector 等已过时，推荐 ConcurrentHashMap 或 CopyOnWriteArrayList；AtomicInteger 基于 CAS 实现无锁原子操作。
用 synchronized 块还是方法？看锁粒度和可读性
直接加在方法上最省事，但容易锁过宽。比如一个类有多个不相关的临界资源，全用 synchronized 实例方法，会强制串行访问，哪怕操作的是不同字段。
更稳妥的做法是显式用 synchronized(this) 或 synchronized(shareLockObj) 块，只包住真正需要保护的代码段。尤其当锁对象是静态资源时，必须用类锁：synchronized(MyClass.class)，否则实例锁互不影响。
常见错误：在 getter/setter 上盲目加 synchronized，而实际业务中读多写少，这时更适合用 volatile（仅适用于简单赋值+无依赖读写）或 java.util.concurrent 中的原子类。
ReentrantLock 比 synchronized 多出什么？别为炫技而用
ReentrantLock 提供了超时获取、可中断等待、公平锁选择、以及绑定多个 Condition 实例的能力——这些是 synchronized 做不到的。
立即学习“Java免费学习笔记（深入）”；
但代价是必须手动 lock() 和 unlock()，且 unlock() 必须放在 finally 块里，否则可能永久持锁。典型写法：
lock.lock();
try {
// 临界区
} finally {
lock.unlock();
}
如果只是简单互斥，synchronized 更简洁、JVM 层面优化更好；只有明确需要上述高级特性时，才换用 ReentrantLock。
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
哪些集合类天生线程安全？别把 ArrayList 当 Vector 用
Vector 和 Stack 是历史遗留类，所有方法都同步，但性能差、API 过时，不推荐新代码使用。
现代替代方案分两类：
- 读多写少 → 用
Collections.synchronizedList(new ArrayList())，但注意：迭代仍需手动同步，否则抛ConcurrentModificationException - 高并发读写 → 直接用
CopyOnWriteArrayList（适合读远多于写的场景）或ConcurrentHashMap（比Hashtable更细粒度、支持高并发读）
误用 ArrayList 在多线程下 add/remove，大概率出现数据丢失或数组越界异常，不是“偶尔出错”，而是必然不安全。
为什么 AtomicInteger 不需要锁？它的 CAS 底层怎么工作
AtomicInteger 的自增（incrementAndGet()）本质是 CPU 级的 CAS（Compare-And-Swap）指令：先读当前值，再尝试用新值替换，仅当内存值未变时才成功；失败则重试。整个过程无锁、无阻塞。
它适用场景很明确：单变量、无依赖的原子操作。例如计数器、序列号生成。但不能用于复合逻辑，比如“先读再判断再写”——这种必须用锁或 StampedLock 等机制。
注意：CAS 在高竞争下会频繁重试，导致 CPU 浪费；极端情况下，不如直接上锁来得稳定。
真正难的不是选哪个工具，而是判断“哪段逻辑才算一个不可分割的操作”。很多线程安全问题，根源在于对业务语义的原子性理解错了，而不是同步语法没写对。
