1. 为什么我们需要关注线程安全？

当我在2013年第一次遇到多线程数据错乱问题时，整整三天都在排查一个诡异的数值错误。那是我第一次深刻理解到：在多线程环境下，1+1可能等于3。这个经历让我意识到，线程安全不是教科书上的理论概念，而是每个Java开发者必须掌握的生存技能。

现代Java应用几乎都运行在多核CPU上，默认情况下，一个Java进程至少包含6个线程（主线程、Reference Handler、Finalizer等）。当我们创建线程池时，工作线程数往往设置为CPU核心数的1.5-2倍。这意味着，即使最简单的Spring Boot应用，也可能同时有12个线程在竞争资源。

1.1 线程安全的本质

线程安全问题的根源在于共享数据的"竞态条件"。想象超市收银台：当多个顾客（线程）同时抢购最后一件商品（共享资源），如果没有排队机制（同步控制），就会导致超卖或数据不一致。在Java中，这种竞态条件具体表现为：

1. 原子性破坏：i++操作实际上包含读取、修改、写入三个步骤，多线程环境下可能被中断
2. 可见性问题：线程A修改了变量，线程B可能永远看不到最新值
3. 指令重排序：编译器和处理器优化可能导致代码执行顺序与编写顺序不一致

// 典型的不安全计数器 class UnsafeCounter { private int count = 0; public void increment() { count++; // 非原子操作 } }

1.2 并发问题的代价

在我参与过的一个电商项目中，曾因库存扣减未做同步控制，导致超卖3000多件商品，直接损失超百万。这类问题往往在以下场景爆发：

• 高并发秒杀活动时
• 定时任务集中触发期
• 系统流量突增阶段

更可怕的是，这些问题在测试环境可能完全无法复现，因为线程调度具有不确定性。这就是为什么我们必须掌握各种锁机制——它们就像是多线程世界的交通信号灯。

2. Java锁机制全景图

Java的锁机制发展经历了从粗放到精细的过程。下图展示了主要的锁分类：

2.1 synchronized的深层原理

这个看似简单的关键字，底层实现却非常精妙。当我们在方法或代码块上使用synchronized时：

1. 方法级同步：在字节码中表现为ACC_SYNCHRONIZED标志
2. 代码块同步：通过monitorenter/monitorexit指令实现

每个Java对象都有一个关联的Monitor（管程），包含以下关键字段：

• _owner：持有该监视器的线程
• _EntryList：等待获取锁的线程队列
• _WaitSet：调用wait()后进入的等待集合

public synchronized void method() { // 同步方法 } public void block() { synchronized(this) { // 同步代码块 } }

重要提示：synchronized在JDK1.6后进行了重大优化，引入了锁升级机制（无锁→偏向锁→轻量级锁→重量级锁），这使得在低竞争场景下性能大幅提升。

2.2 ReentrantLock的进阶用法

相比synchronized，ReentrantLock提供了更灵活的控制：

ReentrantLock lock = new ReentrantLock(true); // 公平锁 Condition condition = lock.newCondition(); public void advancedLockUsage() { lock.lock(); try { while (!conditionMet) { condition.await(); // 类似Object.wait() } // 业务逻辑 condition.signalAll(); // 类似Object.notifyAll() } finally { lock.unlock(); // 必须放在finally块 } }

ReentrantLock的独特优势包括：

• 可中断的锁获取：lockInterruptibly()
• 超时获取锁：tryLock(long timeout, TimeUnit unit)
• 多个条件变量：一个锁可以创建多个Condition实例

3. 高并发场景下的锁优化实战

在日均百万PV的系统中，不当的锁使用可能导致性能下降百倍。以下是经过实战检验的优化方案：

3.1 减小锁粒度

错误示范：

public class BigLockMap { private final Map<String, Object> map = new HashMap<>(); private final Object lock = new Object(); public void put(String key, Object value) { synchronized(lock) { // 锁整个map map.put(key, value); } } }

优化方案：

public class SegmentLockMap { private final Map<String, Object>[] segments; public SegmentLockMap(int concurrencyLevel) { segments = new Map[concurrencyLevel]; for (int i = 0; i < segments.length; i++) { segments[i] = new HashMap<>(); } } private Map<String, Object> segmentFor(String key) { return segments[key.hashCode() % segments.length]; } public void put(String key, Object value) { synchronized(segmentFor(key)) { // 只锁单个segment segmentFor(key).put(key, value); } } }

这种分段锁思想正是ConcurrentHashMap的实现原理。在JDK1.7中，它默认使用16个分段；在JDK1.8中则进一步优化为CAS+synchronized。

3.2 读写锁的应用场景

当读操作远多于写操作时，ReentrantReadWriteLock可以大幅提升吞吐量：

public class CachedData { private final ReentrantReadWriteLock rwl = new ReentrantReadWriteLock(); private Object data; private boolean cacheValid; public void processCachedData() { rwl.readLock().lock(); if (!cacheValid) { // 必须在释放读锁前获取写锁 rwl.readLock().unlock(); rwl.writeLock().lock(); try { // 再次检查状态，因为可能有其他线程已经更新了缓存 if (!cacheValid) { data = fetchDataFromDB(); cacheValid = true; } // 降级为读锁 rwl.readLock().lock(); } finally { rwl.writeLock().unlock(); // 释放写锁，保持读锁 } } try { use(data); } finally { rwl.readLock().unlock(); } } }

性能对比：在读写比9:1的场景下，读写锁相比独占锁可提升5-10倍吞吐量

3.3 无锁编程的实践

对于简单操作，原子类往往是最佳选择：

public class AtomicCounter { private final AtomicLong count = new AtomicLong(0); public void increment() { count.incrementAndGet(); // CAS操作 } public long get() { return count.get(); } }

JDK8新增的LongAdder在高竞争环境下表现更优，它采用分段累加思想：

LongAdder adder = new LongAdder(); adder.increment(); // 内部使用Cell[]分散竞争 long sum = adder.sum(); // 合并所有分段值

4. 避免死锁的工程实践

我曾参与排查过一个线上死锁问题：两个线程分别持有A、B锁，又同时尝试获取对方持有的锁。这种问题往往在压测时才会暴露。

4.1 死锁的四个必要条件

1. 互斥条件：资源一次只能被一个线程占用
2. 占有且等待：线程持有资源并等待其他资源
3. 不可抢占：已分配的资源不能被强制剥夺
4. 循环等待：存在线程资源的环形等待链

4.2 诊断与预防方案

诊断工具：

1. jstack：查看线程栈和锁持有情况
2. VisualVM：图形化展示线程状态
3. Arthas：在线诊断工具

预防措施：

1. 锁排序：所有线程按固定顺序获取锁
2. 锁超时：使用tryLock设置超时时间
3. 开放调用：不在持有锁时调用外部方法
4. 使用并发容器：如ConcurrentHashMap

// 锁排序示例 public void transfer(Account from, Account to, int amount) { Account first = from.hashCode() < to.hashCode() ? from : to; Account second = first == from ? to : from; synchronized(first) { synchronized(second) { if (from.balance >= amount) { from.balance -= amount; to.balance += amount; } } } }

5. 线程安全的最佳实践

经过多年实践，我总结了以下黄金法则：

1. 优先使用不可变对象：String、BigDecimal等
2. 缩小同步范围：只锁必要部分
3. 优先使用并发容器：ConcurrentHashMap、CopyOnWriteArrayList
4. 考虑线程封闭：ThreadLocal、局部变量
5. 慎用双重检查锁定：推荐使用Holder模式

// 安全的单例模式 public class Singleton { private Singleton() {} private static class Holder { static final Singleton INSTANCE = new Singleton(); } public static Singleton getInstance() { return Holder.INSTANCE; } }

对于复杂场景，可以考虑更高级的并发模式：

• 生产者-消费者模式（BlockingQueue）
• Fork/Join框架（递归任务分解）
• Actor模型（Akka框架）

在分布式环境下，还需要考虑分布式锁的实现（Redis、Zookeeper等），但这已经超出了JVM内存模型的范畴。记住：没有放之四海而皆准的锁策略，只有最适合具体场景的解决方案。