1. 从一次线上事故说起为什么“同步”不是小事那天晚上十一点我正打算关电脑突然收到告警核心交易服务的一个接口响应时间从平时的50毫秒飙到了5秒CPU使用率也冲到了90%。紧急登录服务器top命令一看好家伙几十个Java进程线程状态全是BLOCKED堆栈信息指向一个平平无奇的synchronized方法。问题很快定位一个被高频调用的“查询用户积分”方法为了线程安全加了锁但在某个业务高峰场景下这个锁的竞争激烈到让所有线程几乎串行执行服务瞬间被拖垮。那次通宵排查让我彻底明白“同步机制”这四个字远不是教科书里“保证线程安全”那么简单。它像一把双刃剑用好了是秩序的守护者用不好就是性能的绞索。同步机制简单说就是多线程或多进程环境下协调大家对共享资源访问次序的一套规则。没有它你的程序可能会陷入数据错乱、逻辑诡异的境地但滥用它又会让你精心设计的并发程序跑得比单线程还慢。无论是Java里的synchronized和Lock还是操作系统层面的信号量、互斥锁亦或是分布式环境下的ZooKeeper、Redis分布式锁其核心思想一脉相承在混乱的并发世界中建立秩序防止“踩踏”。这篇文章我想和你深入聊聊同步机制。我们不只停留在API怎么用而是拆开揉碎了看锁的本质是什么不同的同步工具比如ReentrantLock和synchronized到底在争抢什么资源为什么有些锁会带来“死锁”这种灾难性后果我们又该如何根据不同的业务场景选择合适的同步策略在安全与性能之间找到那个精妙的平衡点如果你是后端开发者、系统架构师或者任何需要处理并发问题的工程师理解这些底层逻辑将是你写出健壮、高效代码的基石。2. 同步的基石竞态条件、临界区与锁的本质要理解同步必须先搞清楚我们到底在防范什么。核心敌人就是“竞态条件”。想象一个场景你和同事共用一张Excel表格记录部门报销总额。表格当前显示总额是10000元。这时你有一笔300元的报销要录入同时你的同事有一笔500元的报销要录入。理想流程是你先打开表格看到10000加上300得到10300保存同事随后打开看到10300你更新后的加上500得到10800保存。最终总额正确10800元。但如果没有同步现实可能是这样的你们同时打开了表格看到的都是10000元。你计算1000030010300同事计算1000050010500。然后你先保存总额变成10300紧接着同事保存他的10500覆盖了你的10300。最终总额变成了10500元那300元不翼而飞。这就是经典的竞态条件程序的正确性依赖于线程执行时序的巧合。程序中那个“共享的Excel表格”——也就是可能被多个线程同时访问和修改的变量或资源——我们称之为“共享资源”或“临界资源”。而访问这些资源的那段代码比如“读取总额 - 计算新值 - 写回总额”这三行代码就构成了“临界区”。锁就是管理临界区访问的令牌。它的核心工作流程可以概括为申请锁线程进入临界区前尝试获取锁。持有与执行如果锁空闲则获取成功线程独占锁并执行临界区代码。此时其他尝试获取该锁的线程会被阻塞进入等待队列。释放锁线程执行完临界区代码后释放锁让等待队列中的其他线程有机会获取。这个过程保证了同一时刻最多只有一个线程在执行临界区代码从而消除了竞态条件。但请你思考一个问题锁本身作为一个被所有线程争抢的对象它自己是不是一个“共享资源”对它的“获取”和“释放”操作本身是不是也应该是“原子的”这引出了锁实现的最底层依赖硬件提供的原子操作指令比如CASCompare-And-Swap。可以说软件层面眼花缭乱的锁其地基是CPU指令集提供的几个原子操作。注意很多人以为synchronized是基于某个神秘的内核对象。在JVM的HotSpot实现中每个Java对象在内存中都有一个对象头里面包含了用于同步的Mark Word。锁的竞争本质上是对这个Mark Word中特定比特位的CAS操作。理解这一点就能明白为什么Java中任何对象都可以作为锁。3. 从synchronized到LockJava同步工具的演进与抉择Java提供了两大同步工具语言内置的synchronized关键字和java.util.concurrent.locks包下的Lock接口主要是ReentrantLock。它们不是简单的替代关系而是不同设计哲学下的产物。3.1synchronized简单粗暴的“隐式锁”synchronized是Java元老级的同步机制用法简单修饰实例方法锁是当前对象实例this。修饰静态方法锁是当前类的Class对象。修饰代码块需显式指定锁对象如synchronized(lockObj) { ... }。它的优点是语法简洁由JVM负责加锁和解锁不会忘记释放锁即使方法抛出异常锁也会被释放。早期版本中synchronized是重量级锁性能较差需要直接向操作系统申请互斥量涉及用户态到内核态的切换。但经过多年优化如偏向锁、轻量级锁、锁膨胀等在低竞争场景下它的性能已经非常优秀甚至优于ReentrantLock。它的缺点也很明显功能单一等待锁的线程会一直阻塞无法中断也无法设置超时时间。这可能导致“等锁等到天荒地老”的死等。非公平锁默认情况下synchronized是非公平锁。这意味着当锁被释放时任何新来的线程和之前就在等待的线程有同等机会抢到锁。这可能导致“等待队列饥饿”现象。一个锁只有一个等待条件无法实现复杂的通知机制。比如一个阻塞队列生产者需要通知“队列非空”消费者需要通知“队列非满”synchronized配合wait()/notifyAll()只能唤醒所有等待线程不够精确。3.2ReentrantLock功能丰富的“显式锁”ReentrantLock是Lock接口的主要实现它把锁变成了一个显式的对象需要手动lock()和unlock()通常放在try-finally块中确保释放。ReentrantLock lock new ReentrantLock(); lock.lock(); try { // 临界区代码 } finally { lock.unlock(); // 确保锁被释放 }它的核心优势在于灵活性可中断的锁获取lockInterruptibly()方法允许在等待锁的过程中响应中断。超时获取锁tryLock(long time, TimeUnit unit)可以尝试在指定时间内获取锁超时则放弃避免无限等待。公平性可选构造函数传入true可以创建公平锁保证等待时间最长的线程优先获取锁但通常会降低吞吐量。多个条件变量一个ReentrantLock可以关联多个Condition对象。这意味着你可以实现更精细的线程间协作。例如在阻塞队列中可以用notEmpty这个Condition专门唤醒消费者用notFull专门唤醒生产者避免了notifyAll()带来的无效竞争。class BoundedBuffer { final ReentrantLock lock new ReentrantLock(); final Condition notFull lock.newCondition(); // 队列未满条件 final Condition notEmpty lock.newCondition(); // 队列非空条件 // ... 队列实现 public void put(Object x) throws InterruptedException { lock.lock(); try { while (队列已满) { notFull.await(); // 释放锁等待“未满”信号 } // 入队操作 notEmpty.signal(); // 入队后队列肯定非空了唤醒一个消费者 } finally { lock.unlock(); } } }那么如何选择默认选择synchronized如果你的场景简单不需要中断、超时、公平锁或多条件优先使用synchronized。它的代码更简洁由JVM管理不易出错且经过深度优化。需要高级功能时选ReentrantLock当你需要尝试非阻塞地获取锁、可中断的锁等待、超时控制或者需要实现类似“生产者-消费者”这种需要多个等待队列的复杂协作模型时ReentrantLock是更合适的工具。实操心得不要为了炫技而使用ReentrantLock。我见过不少代码明明一个简单的synchronized方法就能搞定却偏要用ReentrantLock结果unlock()忘了写在finally里或者异常处理不当导致锁未释放线上直接死锁。显式锁要求开发者具备更强的责任心。4. 锁的“黑暗面”死锁、活锁与饥饿同步机制带来了秩序也引入了新的风险。其中最臭名昭著的就是死锁。死锁的经典场景是“哲学家就餐问题”五个哲学家围坐每人左右各有一根筷子。哲学家必须同时拿到左右两根筷子才能吃饭。如果所有人同时拿起左边的筷子那么所有人都会永远等待右边的筷子被释放系统僵住。死锁的四个必要条件科赫条件必须同时满足互斥资源一次只能被一个线程占用。占有且等待线程已持有至少一个资源又在等待其他资源。不可剥夺线程已获得的资源在未使用完前不能被强行抢占。循环等待存在一个线程资源的环形等待链T1等T2占有的资源T2等T3占有的...Tn等T1占有的。解决死锁的思路就是打破上述任意一个条件避免“占有且等待”一次性申请所有所需资源All-or-Nothing。比如在转账时同时锁定转出账户和转入账户成功后再操作。这需要更复杂的资源管理逻辑。打破“不可剥夺”允许优先级更高的线程抢占资源。这在数据库死锁检测中常见数据库会选择一个“牺牲者”回滚事务。但在一般编程中实现成本高。破坏“循环等待”对资源进行全局排序要求所有线程按固定顺序如ID从小到大申请锁。这是最常用、最有效的预防策略。// 错误示范可能死锁 public void transfer(Account from, Account to, int amount) { synchronized(from) { synchronized(to) { // 转账操作 } } } // 如果线程A执行 transfer(account1, account2, 100) // 同时线程B执行 transfer(account2, account1, 200) // 就可能发生A锁了account1等account2B锁了account2等account1的死锁。 // 正确做法按固定顺序获取锁 public void transfer(Account from, Account to, int amount) { Account firstLock from.id to.id ? from : to; Account secondLock from.id to.id ? to : from; synchronized(firstLock) { synchronized(secondLock) { // 转账操作 } } }除了死锁还有两种不那么常见但同样棘手的问题活锁线程没有阻塞但在不断重试某个总是失败的操作就像两个人在走廊迎面相遇都礼貌地侧身让路结果又同时挪到了另一边继续挡住对方。解决活锁需要引入随机性如随机等待一段时间或协调机制。饥饿某个线程因为优先级低或锁策略如非公平锁问题长期甚至永远得不到执行机会。使用公平锁可以缓解但会牺牲整体吞吐量。排查死锁的实战工具JVM工具jstack pid可以打印线程堆栈在底部通常会明确提示发现死锁并列出涉及死锁的线程和它们持有的锁、等待的锁。可视化工具JConsole,VisualVM的线程标签页可以直观查看线程状态和死锁检测。5. 超越互斥锁读写锁、乐观锁与无锁编程互斥锁Mutex是一种“悲观”策略它假定冲突很可能发生所以每次访问都上锁。但在很多场景下比如“读多写少”这种策略过于保守。为此衍生出了更高效的同步模型。5.1 读写锁ReadWriteLock典型实现是ReentrantReadWriteLock。它将锁的访问分成了两类读锁共享锁允许多个线程同时持有读锁。只要没有线程持有写锁读锁就可以被任意多个线程获取。写锁排他锁同一时刻只能有一个线程持有写锁。获取写锁时不能有任何读锁或其他写锁存在。这完美契合了“读多写少”的场景如缓存、配置信息。读操作可以完全并发极大提升吞吐量写操作则保持独占保证数据一致性。ReentrantReadWriteLock rwLock new ReentrantReadWriteLock(); ReentrantReadWriteLock.ReadLock readLock rwLock.readLock(); ReentrantReadWriteLock.WriteLock writeLock rwLock.writeLock(); // 读操作 public Data getData(String key) { readLock.lock(); try { return cache.get(key); } finally { readLock.unlock(); } } // 写操作 public void updateData(String key, Data value) { writeLock.lock(); try { cache.put(key, value); } finally { writeLock.unlock(); } }使用读写锁的坑锁降级允许一个持有写锁的线程继续获取读锁然后释放写锁。这样就从写锁降级成了读锁期间数据依然被保护且其他读线程可以并发进来。这是允许且有用的。锁升级不允许不允许一个持有读锁的线程直接尝试获取写锁。因为这可能导致死锁两个线程都持有读锁并都想升级为写锁互相等待对方释放读锁。如果需要升级必须先释放读锁再尝试获取写锁但这中间数据可能已被其他线程修改。5.2 乐观锁与CAS这是一种“乐观”策略它假定冲突很少发生所以先直接修改提交时再检查是否有冲突。核心是CASCompare-And-Swap原子指令。CAS操作包含三个参数内存位置V、预期原值A和新值B。当且仅当V的值等于A时处理器才会用B更新V的值否则不执行更新。无论是否更新都会返回V的旧值。Java中的AtomicInteger、AtomicReference等原子类就是基于CAS实现的。AtomicInteger count new AtomicInteger(0); public void safeIncrement() { int oldValue; int newValue; do { oldValue count.get(); // 读取当前值 newValue oldValue 1; // 计算新值 } while (!count.compareAndSet(oldValue, newValue)); // CAS更新失败则重试 }乐观锁的典型应用场景是数据库更新和版本控制。例如更新一条记录时带上版本号UPDATE table SET value new_value, version version 1 WHERE id #{id} AND version #{old_version};如果返回影响行数为0说明版本号已被其他事务修改本次更新失败需要重试。乐观锁的优缺点优点在低冲突场景下性能远超悲观锁因为它避免了线程挂起和上下文切换的开销。缺点高冲突场景下大量的CAS失败和重试自旋会消耗大量CPU资源性能反而下降。这就是著名的“ABA问题”的变种体现虽然ABA问题本身可通过加版本号或时间戳解决但重试开销是本质问题。5.3 无锁编程这是并发编程的“圣杯”完全避免使用锁通过原子操作主要是CAS和精心设计的无锁数据结构如无锁队列来实现线程安全。java.util.concurrent包中的ConcurrentLinkedQueue就是一个经典的无锁实现。无锁编程极其复杂需要对内存模型Java Memory Model有深刻理解容易出错如ABA问题但能提供最高的伸缩性。对于绝大多数应用开发使用java.util.concurrent包提供的高级并发容器如ConcurrentHashMap、CopyOnWriteArrayList就已足够它们内部已经集成了最优的同步策略。6. 从单机到分布式同步机制的维度跃迁当系统从单机扩展到分布式集群同步问题变得更加复杂。你无法再依赖一个共享的JVM内存中的锁对象。这里的“共享资源”可能是一个数据库表中的某一行或者一个缓存中的某个key。6.1 分布式锁的核心诉求分布式锁需要解决几个在单机环境中不存在的问题互斥性在分布式环境下同一时刻只能有一个客户端获得锁。这是基本要求。安全性锁只能由加锁的客户端释放防止其他客户端误删。避免死锁即使持有锁的客户端崩溃锁也必须在某个时间后自动释放通过锁超时机制。高可用提供锁服务的组件如Redis、ZooKeeper本身需要高可用不能是单点。高性能获取和释放锁的操作需要低延迟。6.2 基于Redis的分布式锁这是最常见、最轻量的实现方案。通常使用SET key value NX PX timeout命令NX表示仅当key不存在时设置PX设置过期时间来原子性地获取锁。SET lock:order_12345 client_uuid NX PX 30000lock:order_12345是锁的键。client_uuid是客户端的唯一标识用于安全释放锁判断是不是自己加的锁。NX保证了互斥性。PX 30000设置了30秒的过期时间防止客户端崩溃导致锁永不释放。释放锁的Lua脚本保证原子性if redis.call(get, KEYS[1]) ARGV[1] then return redis.call(del, KEYS[1]) else return 0 end这个脚本先检查锁的值是否还是自己设置的client_uuid如果是才删除。这避免了误删其他客户端锁的风险。Redis分布式锁的缺陷与Redlock算法 简单的SET NX PX方案在Redis主从架构下存在风险如果客户端在主节点上成功加锁但锁数据还未同步到从节点时主节点宕机从节点升级为主节点后这个锁就“丢失”了其他客户端可能再次获得锁。为此Redis作者提出了Redlock算法其核心思想是向多个通常5个独立的Redis主节点申请锁当从大多数N/21节点上获取锁成功且总耗时小于锁的有效期才算加锁成功。这提高了可靠性但引入了更大的复杂性和性能开销。6.3 基于ZooKeeper的分布式锁ZooKeeper通过其有序临时节点EPHEMERAL_SEQUENTIAL特性可以很优雅地实现分布式锁。所有客户端在指定目录如/locks/my_lock下创建临时有序节点。客户端获取目录下所有子节点并排序。如果自己创建的节点序号最小则获得锁。如果自己不是最小则监听比自己序号小的前一个节点的删除事件。当前一个节点被删除锁被释放自己收到通知重新执行步骤2判断。这种方案的优点是安全性高临时节点在客户端会话结束时自动删除相当于自动释放锁避免了死锁。可避免“惊群效应”每个客户端只监听前一个节点而不是监听根目录当锁释放时只有下一个顺序的客户端被唤醒。天然公平节点顺序决定了获取锁的顺序是公平锁。缺点是性能通常低于基于Redis的实现因为每次操作涉及网络通信和ZooKeeper集群的协调。选型建议追求极致性能能容忍极端情况下少量锁失效选择基于Redis的简单锁或Redlock。适用于秒杀库存扣减等场景即使极偶尔超卖几件也可以通过后续校验弥补。要求强一致性锁必须绝对可靠选择基于ZooKeeper的锁。适用于金融交易、主节点选举等场景。7. 实战中的同步策略模式、陷阱与性能调优理解了各种同步工具最终要落到如何用好它们。下面分享几个实战中的模式和常见陷阱。7.1 同步的范围与粒度锁的粒度越细并发度越高但管理越复杂。这是一个永恒的权衡。粗粒度锁例如直接锁住整个服务对象或整个方法。简单安全但并发性能差。文章开头那个事故就是粗粒度锁的典型恶果。细粒度锁例如在ConcurrentHashMap中内部将数据分成多个段SegmentJava 7或使用更细粒度的synchronizedCASJava 8每个段或每个桶有独立的锁。这样不同线程操作不同的键值对时完全不会冲突。设计原则尽可能缩小临界区。只锁住必须共享的那部分数据和代码。对于可以复制的局部变量先在锁外计算好再在锁内进行最终的赋值操作。7.2 线程封闭与无共享最高效的同步就是不同步。如果能避免共享就彻底不需要锁。有两种常见模式线程封闭将对象限制在单个线程内使用。例如ThreadLocal变量每个线程有自己的副本。再比如在Web服务器中经常每个请求用一个独立的连接对象处理完即销毁。副本Copy-On-Write当需要修改时不直接修改原数据而是创建一份副本在副本上修改修改完成后用一个原子操作将引用指向新副本。CopyOnWriteArrayList就是这种思想的体现。它适用于读多写少且写操作不频繁的场景。7.3 常见的性能陷阱与排查锁竞争热点这是最普遍的瓶颈。使用JProfiler、Async Profiler等工具可以直观看到哪些锁上阻塞的线程最多、时间最长。优化方法缩小锁范围、使用读写锁、使用并发容器、考虑数据分片如按用户ID哈希到不同的锁。在锁内执行耗时操作这是新手常犯的错误。比如在synchronized方法里进行网络IO、复杂计算或调用其他慢方法。这会导致锁被长时间持有其他所有线程干等。务必确保临界区内只包含必须原子化的核心操作其他操作移到锁外。锁的滥用过度同步对本来就是线程安全的类如StringBuffer但建议用StringBuilder或者只读操作加锁。要熟悉JDK中哪些类是线程安全的如Vector,Hashtable哪些不是如ArrayList,HashMap以及并发包java.util.concurrent下更高效的替代品。对象头开销与锁膨胀在32位JVM上一个对象头至少8字节64位JVM上至少12字节。大量使用细粒度锁如为每个小对象加锁会带来不小的内存开销。此外synchronized锁会从偏向锁膨胀为轻量级锁再膨胀为重量级锁这个膨胀过程不可逆且重量级锁性能较差。对于生命周期短、竞争激烈的对象可以考虑使用ReentrantLock或Atomic类。7.4 一个综合案例实现一个简单的令牌桶限流器让我们用学到的知识实现一个线程安全的令牌桶限流器。它常用于API限流控制请求速率。import java.util.concurrent.TimeUnit; import java.util.concurrent.locks.ReentrantLock; public class TokenBucketLimiter { private final long capacity; // 桶容量 private long tokens; // 当前令牌数 private long lastRefillTime; // 上次补充令牌的时间 private final long refillInterval; // 补充间隔纳秒 private final long tokensPerRefill; // 每次补充的令牌数 private final ReentrantLock lock new ReentrantLock(); public TokenBucketLimiter(long capacity, long tokensPerSecond) { this.capacity capacity; this.tokens capacity; // 初始满桶 this.lastRefillTime System.nanoTime(); this.refillInterval TimeUnit.SECONDS.toNanos(1) / tokensPerSecond; this.tokensPerRefill 1; // 我们采用每次补充1个令牌但通过调整间隔来控制速率 // 更常见的实现是固定间隔补充一批令牌这里为简化采用离散补充 } public boolean tryAcquire() { lock.lock(); try { refillTokens(); // 先补充令牌 if (tokens 0) { tokens--; return true; } return false; } finally { lock.unlock(); } } private void refillTokens() { long now System.nanoTime(); long elapsed now - lastRefillTime; // 计算经过了多少个补充周期 long tokensToAdd elapsed / refillInterval; if (tokensToAdd 0) { tokens Math.min(capacity, tokens tokensToAdd); lastRefillTime tokensToAdd * refillInterval; // 注意不是直接等于now避免精度累积误差 } } }这个实现的分析锁的选择使用了ReentrantLock因为tryAcquire是一个简单的非阻塞检查未来如果需要支持带超时的获取可以方便地改用tryLock。临界区tryAcquire方法内的refillTokens()和令牌扣除必须原子化否则可能多个线程同时看到tokens0导致超限。时间处理使用System.nanoTime()获取单调递增的纳秒时间避免系统时钟回拨带来的问题。补充令牌的计算基于经过的时间段是令牌桶算法的标准实现。性能考量每次请求都计算补充在超高QPS下可能成为瓶颈。生产级实现可能会将“补充令牌”作为一个后台任务定期执行或者使用更高效的无锁算法。同步机制是并发编程的脊梁它从最底层的CPU指令到语言层面的关键字和类库再到分布式系统的协调服务构建了一套层次化的秩序体系。没有放之四海而皆准的“最佳同步方案”只有最适合当前场景的权衡。我的经验是在设计和评审代码时多问自己几个问题这段代码真的需要共享吗能不能用线程封闭或副本锁的粒度是不是可以更细这个锁会不会成为热点获取锁的路上有没有可能阻塞想清楚这些问题你就能避开大多数并发陷阱写出既安全又高效的程序。最后记住工具越强大责任越重大。显式锁、分布式锁给了你更多控制权也要求你对它们的生命周期和异常情况有更周全的考虑。