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