面试官拆解四个同步：从入门到精通的避坑指南

看了一堆教程还是不会写项目？别急，问题往往出在基础概念没吃透。很多开发者觉得“四个同步”只是背个名词，直到面试被问懵，或者上线后数据错乱才后悔。这篇文章带你从入门到精通，彻底搞懂这四个核心机制，让你下次面试稳如老狗。

考点梳理：面试官到底在问什么

在Java并发编程中，“四个同步”通常指synchronized、ReentrantLock、CountDownLatch、CyclicBarrier。虽然名字里都有“同步”，但它们的底层逻辑、适用场景和API设计哲学截然不同。

面试官问这个，不是在考你背诵定义，而是在考察你对并发控制粒度和线程协作模式的理解。很多候选人只答得出“它们都能让线程等待”，却分不清“独占锁”和“栅栏同步”的本质区别。一旦深入追问“为什么这里用Latch不用Barrier”，或者“synchronized的锁升级过程”，立马露馅。

你需要明确，这四个工具分别解决了并发编程中的三大核心问题：互斥访问（防止脏读脏写）、线程等待（主线程等待子线程）、线程协作（多个线程同时等待某个时间点）。搞清楚这一点，你就已经超过了60%的竞争者。

标准答法：结构化表达是关键

面试回答要有条理，建议采用“定义+底层原理+适用场景+优缺点”的四段式结构。

1. synchronized 这是Java关键字级别的同步机制。早期JDK 1.5之前，它是唯一的选择。现在它的底层实现已经优化为偏向锁、轻量级锁、重量级锁的渐进式升级。

核心点：JVM内置支持，无需手动释放，适合短临界区。
痛点：不可中断，无法公平调度，性能在高竞争下下降明显。

2. ReentrantLock 这是java.util.concurrent包下的显式锁。它提供了比synchronized更丰富的功能，比如可中断的获取锁、公平锁、条件变量（Condition）。

核心点：API灵活，支持超时，适合复杂业务逻辑。
痛点：必须手动unlock，如果忘记释放会导致死锁，性能略低于优化后的synchronized。

3. CountDownLatch 这是一个一次性屏障。它允许一个或多个线程等待其他线程完成一组操作。

核心点：count只能减不能增，用完即废。
场景：主线程等待N个子任务全部完成，比如并行加载多个数据源。

4. CyclicBarrier 这是一个可复用的屏障。它让一组线程全部到达某个屏障点，然后才能继续执行。

核心点：可重置，支持在屏障点执行额外任务。
场景：多线程分阶段计算，比如多轮迭代训练，每轮结束后需要汇总结果。

记忆技巧： synchronized是“傻瓜式”互斥，ReentrantLock是“全能型”互斥，CountDownLatch是“单向等待”，CyclicBarrier是“双向会合”。

代码实现：别只看不练，手敲才有感觉

光说不练假把式。下面这段代码模拟了一个典型的并发场景：4个线程并行计算数据，计算完成后，主线程汇总结果。 这里我们对比使用CountDownLatch和CyclicBarrier的区别。

import java.util.concurrent.*;
import java.util.concurrent.atomic.AtomicInteger;public class SyncDemo {private static final int THREAD_COUNT = 4;private static final ExecutorService executor = Executors.newFixedThreadPool(THREAD_COUNT);public static void main(String[] args) throws InterruptedException, BrokenBarrierException {System.out.println("=== 测试 CountDownLatch: 主线程等待子线程 ===");testCountDownLatch();System.out.println("\n=== 测试 CyclicBarrier: 子线程之间等待 ===");testCyclicBarrier();executor.shutdown();}// 场景1：主线程等待所有子线程完成private static void testCountDownLatch() throws InterruptedException {CountDownLatch latch = new CountDownLatch(THREAD_COUNT);long startTime = System.currentTimeMillis();for (int i = 1; i <= THREAD_COUNT; i++) {final int taskId = i;executor.submit(() -> {try {System.out.println(Thread.currentThread().getName() + " 开始处理任务 " + taskId);Thread.sleep((long)(Math.random() * 1000)); // 模拟耗时操作System.out.println(Thread.currentThread().getName() + " 完成任务 " + taskId);} catch (InterruptedException e) {Thread.currentThread().interrupt();} finally {latch.countDown(); // 关键：减少计数}});}// 主线程阻塞，直到计数为0latch.await();long endTime = System.currentTimeMillis();System.out.println("所有任务完成，总耗时: " + (endTime - startTime) + "ms");}// 场景2：所有子线程互相等待，都完成后一起执行下一阶段private static void testCyclicBarrier() throws BrokenBarrierException, InterruptedException {AtomicInteger phase = new AtomicInteger(0);CyclicBarrier barrier = new CyclicBarrier(THREAD_COUNT, () -> {// 当所有线程到达屏障时，执行这个Runnablephase.incrementAndGet();System.out.println(">>> 第 " + phase.get() + " 轮所有线程就绪，开始下一阶段 <<<");});for (int i = 1; i <= THREAD_COUNT; i++) {final int taskId = i;executor.submit(() -> {try {// 阶段1System.out.println(Thread.currentThread().getName() + " 阶段1: 处理数据 " + taskId);Thread.sleep((long)(Math.random() * 500));// 等待其他线程都完成阶段1barrier.await();// 阶段2 (只有所有线程都通过屏障后才会执行)System.out.println(Thread.currentThread().getName() + " 阶段2: 汇总结果 " + taskId);Thread.sleep((long)(Math.random() * 500));// 如果还有阶段3，可以继续 barrier.await()} catch (InterruptedException | BrokenBarrierException e) {Thread.currentThread().interrupt();}});}// 等待线程池任务完成Thread.sleep(2000);}
}

逐行解析关键点：

CountDownLatch的finally块：注意代码中latch.countDown()放在finally里。这是生产环境的最佳实践。如果任务执行中抛出异常，如果不放在finally，计数永远不会减到0，主线程将永久阻塞，导致线程池耗尽。
CyclicBarrier的Runnable参数：构造函数中的第二个参数是一个回调函数。它只在所有线程调用await()后执行一次。这在需要“同步点”执行额外逻辑（如打印日志、重置状态）时非常有用。
异常处理：CyclicBarrier.await()会抛出BrokenBarrierException。如果某个线程在等待时被中断或超时，屏障会“破损”，其他等待线程会立即抛出异常。这是与CountDownLatch的重要区别，后者一个线程异常不影响其他线程继续等待。

追问与延伸：高阶玩家的战场

面试官满意你的基础回答后，通常会追问以下三个高频问题。

追问1：synchronized和ReentrantLock在性能上有区别吗？ 答：在低竞争环境下，JDK 6之后的synchronized通过锁升级优化，性能与ReentrantLock相当。但在高竞争环境下，ReentrantLock由于可以设置公平锁和可中断获取，避免了线程无限期等待，性能表现更可控。此外，ReentrantLock的lock()和unlock()是用户空间代码，而synchronized依赖JVM内置指令，后者在简单场景下开销更小。

追问2：为什么CountDownLatch不能重置，而CyclicBarrier可以？ 答：这是设计意图决定的。CountDownLatch通常用于一次性的启动或关闭信号，比如服务器启动时等待所有模块初始化完成。这种场景下，重置没有意义，反而容易引发状态不一致。而CyclicBarrier常用于循环迭代算法，如蒙特卡洛模拟、多轮机器学习训练，每轮都需要所有线程同步，因此必须支持复用。

追问3：如果线程在await()时抛出了业务异常，该怎么办？ 答：对于CountDownLatch，必须在finally中调用countDown()，确保计数归零。对于CyclicBarrier，如果某个线程抛出异常，屏障会被破坏，其他线程也会收到BrokenBarrierException。此时需要捕获异常并决定是重新创建Barrier还是终止任务。在实际项目中，建议使用CompletableFuture或ForkJoinPool来替代这种复杂的同步逻辑，它们提供了更好的异常传播机制。

避坑指南：

不要混用锁：不要在一个线程用synchronized，另一个线程用ReentrantLock保护同一资源，这会导致死锁或数据不一致。
注意超时：CountDownLatch和CyclicBarrier的await()都有带超时的版本。生产环境务必使用超时版本，防止因某个线程卡死导致整个应用阻塞。
官方文档参考：建议查阅Java SE 17官方文档中的java.util.concurrent章节，里面详细描述了各个类的线程安全性保证和边界条件，这是最权威的参考。