1. 项目概述从“并发恐慌”到“并发掌控”如果你在面试中被问到“如何处理高并发”或者在实际项目中看到日志里一堆ConcurrentModificationException心里咯噔一下那说明你正站在JUCJava Util Concurrent这座宝藏的门口。这不是什么高深莫测的黑魔法而是每个处理过稍微有点流量系统的Java开发者迟早要面对、也必须掌握的核心技能集。我见过太多团队业务逻辑写得飞起一到并发场景就靠加synchronized和无限增大线程池来硬扛结果就是系统在流量稍大时响应缓慢甚至直接宕机深夜报警电话响个不停。所谓的“高并发”拆开看就是两件事一是“高”指单位时间内大量的请求二是“并发”指这些请求看起来是同时处理的。JUC包提供的一系列工具就是帮我们安全、高效地管理这种“同时”把不可控的混乱变成有序的协作。从简单的ReentrantLock替代synchronized到复杂的ConcurrentHashMap、ThreadPoolExecutor再到协调多线程步调的CountDownLatch、CyclicBarrier每一件工具都是为了解决特定的并发难题而生。掌握它们意味着你能从被动地处理并发bug转变为主动地设计并发架构这是中级程序员向资深迈进的关键一步。这篇文章我会结合我趟过的坑和积累的经验带你深入JUC的核心部分不止于API调用更聚焦于设计思维和问题排查。2. 核心工具解析锁、容器与原子类当我们谈论JUC时首先面对的就是这三驾马车锁机制、并发容器和原子变量。它们是构建线程安全大厦的基石。2.1 锁的进化从synchronized到ReentrantLocksynchronized是Java原生的关键字简单粗暴在大多数场景下也够用。但它的问题在于“笨重”和“不可控”锁的获取和释放由JVM管理我们无法中断一个正在等待锁的线程也无法尝试获取锁拿不到就死等更无法设置公平性。// synchronized 典型用法 public synchronized void transfer(Account from, Account to, int amount) { // ... 转账逻辑 }而ReentrantLock作为JUC提供的显式锁带来了更多的灵活性。它的“可重入”特性与synchronized一致即同一个线程可以多次获取同一把锁。但其核心优势在于高级功能尝试非阻塞获取锁tryLock()方法允许我们尝试获取锁如果获取失败立即返回false而不是傻等。这在死锁恢复、避免长时间等待的场景非常有用。可中断的锁等待lockInterruptibly()方法允许在等待锁的过程中响应中断为线程管理提供了更细粒度的控制。公平锁与非公平锁构造函数中可以指定是否创建公平锁。公平锁保证等待时间最长的线程优先获取锁避免了“饥饿”现象但会带来更大的性能开销因为需要维护一个队列。非公平锁则允许“插队”吞吐量通常更高也是默认选项。条件变量Condition这是ReentrantLock相比synchronized最强大的特性之一。一个锁可以关联多个Condition对象实现更精确的线程等待/通知机制典型应用就是实现一个阻塞队列。import java.util.concurrent.locks.ReentrantLock; import java.util.concurrent.locks.Condition; public class BoundedBuffer { final ReentrantLock lock new ReentrantLock(); final Condition notFull lock.newCondition(); // 条件不满 final Condition notEmpty lock.newCondition(); // 条件不空 final Object[] items new Object[100]; int putptr, takeptr, count; public void put(Object x) throws InterruptedException { lock.lock(); try { while (count items.length) // 缓冲区满等待“不满”条件 notFull.await(); items[putptr] x; if (putptr items.length) putptr 0; count; notEmpty.signal(); // 放入一个元素后通知“不空”条件 } finally { lock.unlock(); // 务必在finally块中释放锁 } } public Object take() throws InterruptedException { lock.lock(); try { while (count 0) // 缓冲区空等待“不空”条件 notEmpty.await(); Object x items[takeptr]; if (takeptr items.length) takeptr 0; --count; notFull.signal(); // 取走一个元素后通知“不满”条件 return x; } finally { lock.unlock(); } } }注意使用ReentrantLock必须手动在finally块中调用unlock()释放锁否则会导致锁泄漏其他线程永远无法获取该锁。这是与synchronized最大的使用区别也更容易出错。选择建议在不需要ReentrantLock的高级功能可中断、尝试锁、公平锁、条件变量时优先使用synchronized。因为synchronized由JVM优化语法简洁不易出错。当你需要更复杂的线程协作或者需要尝试获取锁、避免死锁时再考虑ReentrantLock。2.2 并发容器告别Collections.synchronizedXXX早期我们常用Collections.synchronizedList(new ArrayList())来包装一个同步的列表。这种方式实现的是粗粒度的锁每次读写操作都会锁住整个容器性能很差。JUC提供了一套真正的并发容器其核心思想是“锁分段”或“无锁算法”极大提升了并发访问效率。ConcurrentHashMap这是最著名的并发容器。在Java 7及之前它采用分段锁Segment将数据分成一段一段的每段配一把锁这样不同段的数据操作就可以并行。在Java 8及之后它进行了大规模重构底层利用synchronized和CASCompare-And-Swap操作来锁住单个链表头或红黑树根节点并发度更高。ConcurrentHashMapString, Integer map new ConcurrentHashMap(); // 线程安全的put但无法保证整个“检查-执行”过程的原子性 map.put(key, 1); // 使用computeIfAbsent实现原子性的“如果不存在则计算并放入” map.computeIfAbsent(key, k - expensiveCalculation(k));computeIfAbsent是一个非常重要的方法。假设你需要根据一个key加载配置如果多个线程同时调用使用putIfAbsent可能会计算多次而computeIfAbsent能保证对于同一个key传入的映射函数只被执行一次。这在实现本地缓存时非常有用。CopyOnWriteArrayList/CopyOnWriteArraySet写时复制容器。顾名思义当需要修改容器内容增、删、改时并不直接在原数组上操作而是将原数组复制一份在新数组上进行修改修改完成后再将容器的引用指向新数组。这种方式的优点是读操作完全无锁速度极快。缺点是写操作开销大需要复制且数据具有最终一致性读线程可能读到旧数据。适用场景读多写少且数据量不大的情况。比如监听器列表、只读或很少修改的配置快照。CopyOnWriteArrayListString listenerList new CopyOnWriteArrayList(); // 添加监听器写操作会复制数组 listenerList.add(newListener); // 遍历通知所有监听器读操作无锁安全 for (String listener : listenerList) { notifyListener(listener); }ConcurrentLinkedQueue一个基于链接节点的无界、线程安全、非阻塞的FIFO队列。它使用CAS操作实现入队和出队性能在高并发下非常好。但它不支持阻塞操作即队列为空时取元素会返回null如果需要阻塞应使用BlockingQueue接口的实现类如LinkedBlockingQueue或ArrayBlockingQueue。2.3 原子类无锁化的计数器与状态标记java.util.concurrent.atomic包下的原子类是实现无锁Lock-Free编程的基础。它们利用CPU底层的CAS指令保证对一个变量的更新操作是原子的且通常比使用锁的性能更高。最常用的是AtomicInteger、AtomicLong和AtomicReference。AtomicInteger counter new AtomicInteger(0); // 线程安全的递增 int newValue counter.incrementAndGet(); // 相当于 i int oldValue counter.getAndIncrement(); // 相当于 i // CAS操作如果当前值是1就更新为2 boolean success counter.compareAndSet(1, 2);核心方法compareAndSetCAS这是原子类的灵魂。它接受两个参数“期望值”和“新值”。如果原子变量当前的值等于“期望值”那么就将其更新为“新值”并返回true否则什么都不做返回false。这个操作是原子的。典型应用场景计数器如接口访问次数、在线人数统计。状态标志位控制某个流程只能执行一次如初始化。实现非阻塞算法如无锁栈、无锁队列。实操心得原子类虽然高效但并非万能。对于复杂的复合操作例如“读取-修改-写入”中修改依赖于读取的值单纯使用原子类可能仍需配合循环CAS逻辑会变复杂。此时如果竞争不激烈使用锁如synchronized代码会更清晰。高竞争下可以考虑LongAdderJava 8引入它在高并发统计求和场景下性能远优于AtomicLong因为它内部采用了分段累加的思想。3. 线程池精讲告别new Thread()直接new Thread()创建线程然后start()在简单的demo里没问题但在生产环境是灾难。线程的创建和销毁开销很大无限制创建会导致资源耗尽。线程池的核心思想是复用已创建的线程管理线程的生命周期。3.1 ThreadPoolExecutor七大参数剖析Executors工厂类提供了一些快捷方法如newFixedThreadPool,newCachedThreadPool但在大厂规范中通常要求直接使用ThreadPoolExecutor构造函数来创建线程池以便更精确地控制其行为。这涉及到七个核心参数public ThreadPoolExecutor(int corePoolSize, int maximumPoolSize, long keepAliveTime, TimeUnit unit, BlockingQueueRunnable workQueue, ThreadFactory threadFactory, RejectedExecutionHandler handler)corePoolSize核心线程数线程池中长期存活的线程数量即使它们空闲。除非设置了allowCoreThreadTimeOut。maximumPoolSize最大线程数线程池允许创建的最大线程数量。keepAliveTime unit线程空闲时间当线程数超过核心线程数时多余的空闲线程在等待新任务时的最长存活时间超时将被回收。workQueue工作队列用于存放提交但尚未被执行的任务的阻塞队列。这是线程池调优的关键。threadFactory线程工厂用于创建新线程。可以在这里设置线程名、优先级、守护线程状态等便于监控和排查问题。RejectedExecutionHandler拒绝策略当线程池已关闭或队列已满且线程数达到最大值时对新提交任务的处理策略。3.2 任务提交与执行流程理解下面这个流程是合理配置参数的前提提交一个任务。如果当前运行的线程数 corePoolSize则立即创建新线程来执行该任务即使有空闲核心线程。如果当前运行的线程数 corePoolSize则尝试将任务放入工作队列。如果队列未满任务入队成功等待空闲线程来执行。如果队列已满则检查当前线程数是否 maximumPoolSize。如果小于则创建新的非核心线程来执行该任务。如果已达到maximumPoolSize则触发拒绝策略。关键点任务不是先入队而是先尝试创建核心线程核心线程满了才入队队列满了才创建非核心线程。这个顺序很重要。3.3 工作队列与拒绝策略选型工作队列BlockingQueue常见类型SynchronousQueue一个不存储元素的队列。每个插入操作必须等待另一个线程的移除操作。Executors.newCachedThreadPool使用它。这意味着提交任务时如果没有空闲线程就会立即创建新线程。适用于任务短小、快速的场景但可能创建大量线程。LinkedBlockingQueue基于链表的无界队列除非构造时指定容量。Executors.newFixedThreadPool使用它。由于队列可以无限增长任务永远不会被拒绝直到内存耗尽因此maximumPoolSize参数会失效。适用于任务量平稳需要缓冲的场景。ArrayBlockingQueue基于数组的有界队列。这是最常用的队列类型可以防止资源耗尽。需要合理设置队列大小。拒绝策略RejectedExecutionHandler常见类型AbortPolicy默认直接抛出RejectedExecutionException异常。CallerRunsPolicy由调用者线程提交任务的线程自己来执行这个任务。这提供了一个简单的反馈机制会降低任务提交速度。DiscardPolicy默默丢弃这个任务不抛异常。DiscardOldestPolicy丢弃队列里最老的一个任务即队列头部的任务然后尝试重新提交当前任务。配置实战建议 对于CPU密集型任务如计算、处理线程数不宜过多通常设置为CPU核心数 1队列可用有界ArrayBlockingQueue。对于IO密集型任务如网络请求、数据库操作线程数可以设置得多一些例如CPU核心数 * 2或更高队列也可适当大一些。监控线程池的运行状态队列大小、活跃线程数、完成任务数等是必不可少的。4. 同步辅助工具控制多线程的步调JUC提供了几个强大的工具类用于协调多个线程之间的执行顺序它们比简单的wait()/notify()更易用、更安全。4.1 CountDownLatch多线程任务汇合CountDownLatch像一个倒计数器构造时设定一个初始值count。线程调用await()方法会阻塞直到其他线程调用countDown()将计数器减到0。它常用于让一个主线程等待多个子线程完成初始化或者让多个子线程等待一个主线程发出开始指令。// 场景主线程等待所有数据加载完成后再继续 public class DataLoader { public static void main(String[] args) throws InterruptedException { int taskCount 3; CountDownLatch latch new CountDownLatch(taskCount); ExecutorService executor Executors.newFixedThreadPool(taskCount); for (int i 0; i taskCount; i) { executor.submit(() - { try { // 模拟加载数据 loadData(); } finally { latch.countDown(); // 无论如何任务结束必须减1 } }); } latch.await(); // 主线程在此等待直到计数器归零 System.out.println(所有数据加载完成开始处理...); executor.shutdown(); } }注意countDown()必须放在finally块中执行确保即使任务异常计数器也能递减避免主线程永远等待。4.2 CyclicBarrier线程集体栅栏CyclicBarrier让一组线程互相等待直到所有线程都到达一个公共的屏障点然后所有线程再同时继续执行。与CountDownLatch一次性使用不同CyclicBarrier的计数器可以重置cyclic意为循环因此可以重复使用。它还可以在到达屏障点时执行一个预定义的Runnable任务由最后一个到达屏障的线程执行。// 场景多线程分阶段计算每阶段需同步 public class MatrixSolver { private final int workerCount; private final CyclicBarrier barrier; private final double[][] matrix; class Worker implements Runnable { private final int myRow; Worker(int row) { myRow row; } public void run() { try { while (!done()) { // 未计算完成 processRow(myRow); // 处理自己负责的行 barrier.await(); // 等待其他所有行处理完 // 屏障打开后可以开始下一轮迭代如交换数据 } } catch (Exception e) { Thread.currentThread().interrupt(); } } } public void solve() { ExecutorService exec Executors.newFixedThreadPool(workerCount); for (int i 0; i workerCount; i) exec.execute(new Worker(i)); exec.shutdown(); } }4.3 Semaphore控制并发访问的许可证Semaphore信号量用来控制同时访问特定资源的线程数量。它维护了一组“许可证”线程需要先获取许可证才能执行执行完后释放许可证。这常用于流量控制比如数据库连接池。// 场景控制最多10个线程同时访问某个资源 public class ConnectionPool { private final Semaphore available new Semaphore(10); // 10个许可证 private final SetConnection pool new HashSet(); public Connection getConnection() throws InterruptedException { available.acquire(); // 获取一个许可证如果没有则阻塞 Connection conn null; synchronized (pool) { conn pool.iterator().next(); pool.remove(conn); } return new ConnectionProxy(conn, available); // 代理在close时释放许可证 } private static class ConnectionProxy extends Connection { private final Connection realConn; private final Semaphore semaphore; // ... 重写close方法调用 semaphore.release(); } }区别总结CountDownLatch一个线程或多个等待其他一组线程完成。一次性不可重置。CyclicBarrier一组线程互相等待到达屏障后一起继续。可循环使用。Semaphore控制同时访问资源的线程数量类似于“令牌桶”。5. Future与异步编程获取线程的执行结果Runnable的run()方法没有返回值。如果我们想在线程执行完毕后得到一个结果就需要用到Callable和Future。CallableV类似于Runnable但它的call()方法有返回值并且可以抛出受检异常。FutureV代表一个异步计算的结果。它提供了检查计算是否完成、等待计算完成、以及获取计算结果的方法。ExecutorService executor Executors.newSingleThreadExecutor(); // 提交Callable任务返回一个Future对象 FutureInteger future executor.submit(() - { Thread.sleep(1000); return 42; }); // 在需要结果的地方可以尝试获取 try { // get()会阻塞直到计算完成 Integer result future.get(); // 也可以设置超时时间避免无限等待 // Integer result future.get(2, TimeUnit.SECONDS); System.out.println(计算结果: result); } catch (InterruptedException | ExecutionException e) { e.printStackTrace(); // 处理计算过程中抛出的异常 } finally { executor.shutdown(); }5.1 CompletableFuture更强大的异步编程Future的模式是“提交任务 - 获取结果”但多个异步任务之间的组合例如A任务完成后触发B任务或者等待所有任务完成写起来很麻烦。Java 8引入的CompletableFuture完美解决了这个问题它实现了Future和CompletionStage接口提供了丰富的API来组合异步操作。核心能力显式完成可以手动设置CompletableFuture的结果complete。链式调用可以将多个异步操作串联或并联起来。异常处理提供了专门的异常处理方法。// 示例异步查询用户信息然后异步查询订单最后合并结果 public CompletableFutureUserInfo getUserInfoAsync(String userId) { return CompletableFuture.supplyAsync(() - userService.getUser(userId), executor); } public CompletableFutureListOrder getOrdersAsync(String userId) { return CompletableFuture.supplyAsync(() - orderService.getOrders(userId), executor); } // 组合两个异步任务 public CompletableFutureUserProfile getUserProfile(String userId) { CompletableFutureUserInfo userFuture getUserInfoAsync(userId); CompletableFutureListOrder ordersFuture getOrdersAsync(userId); // thenCombine: 当两个Future都完成时用BiFunction合并结果 return userFuture.thenCombine(ordersFuture, (user, orders) - { UserProfile profile new UserProfile(); profile.setUser(user); profile.setOrders(orders); return profile; }); } // 使用 getUserProfile(123).thenAccept(profile - { // 异步处理最终结果 System.out.println(profile); }).exceptionally(ex - { // 统一处理整个链路上的异常 System.err.println(获取用户画像失败: ex.getMessage()); return null; });CompletableFuture的方法非常丰富如thenApply转换结果、thenCompose扁平化类似flatMap、allOf/anyOf等待所有/任意一个完成等。它让异步编程的代码变得声明式、清晰是处理复杂异步流程的利器。6. 常见问题与排查技巧实录理论懂了工具也会用了但在实际生产环境中并发问题往往以各种诡异的形式出现。下面是我总结的几个典型问题和排查思路。6.1 死锁的识别与预防死锁是指两个或以上的线程互相持有对方需要的资源导致它们都无法继续执行。经典的死锁条件有四个互斥、持有并等待、不可剥夺、循环等待。排查最直接的方法是使用jstack命令获取线程转储Thread Dump。在输出中搜索“deadlock”关键词或者查看线程状态为BLOCKED的并分析其持有的锁和等待的锁通常能很快定位循环等待链。预防策略避免嵌套锁尽量只获取一把锁。如果必须获取多把锁确保所有线程都以相同的顺序获取锁。这是打破“循环等待”条件最有效的方法。使用尝试锁用ReentrantLock.tryLock()或带超时的tryLock(long time, TimeUnit unit)。获取不到锁时释放自己已持有的锁回退并重试。锁粗化与细化不要过度拆分锁的范围细化这可能导致频繁获取释放锁增加死锁概率也不要过度扩大锁的范围粗化这会降低并发度。需要根据业务场景权衡。6.2 线程池配置不当引发的故障问题一任务堆积导致内存溢出OOM现象使用LinkedBlockingQueue这类无界队列且任务生产速度持续大于消费速度队列会无限增长最终耗尽堆内存。解决使用有界队列如ArrayBlockingQueue并配合合理的拒绝策略如CallerRunsPolicy让生产者降速。问题二核心线程数设置过小响应变慢现象CPU密集型任务核心线程数设得很大如100但服务器CPU核心只有8个。大量线程争抢CPU上下文切换开销巨大整体吞吐量反而下降。解决根据任务类型CPU/IO密集型合理设置核心线程数。使用监控工具如Micrometer, Prometheus Grafana观察线程池活跃线程数、队列大小等指标动态调整。问题三线程泄露现象线程池中的线程执行任务后没有正确释放或者任务本身是个无限循环。解决确保提交给线程池的任务逻辑完整能够正常结束。对于需要长时间运行的任务考虑使用ScheduledThreadPoolExecutor并妥善处理异常。6.3 volatile关键字与内存可见性volatile是轻量级的同步机制。它保证了两件事可见性当一个线程修改了volatile变量的值新值会立即被刷新到主内存并且其他线程中该变量的缓存会失效从而强制它们去主内存读取新值。禁止指令重排序防止JVM和处理器为了优化性能而对指令进行重排序这在单例模式的双重检查锁定DCL中至关重要。但它不保证原子性。常见的误区是以为volatile int i; i;是线程安全的。实际上i是“读-改-写”三个操作volatile只能保证每次读到的都是最新值但多个线程可能同时读到相同的值然后各自加一写回导致最终结果小于预期。适用场景状态标志位如volatile boolean shutdownRequested;。一次性安全发布如DCL单例模式中的实例引用。6.4 ConcurrentModificationException的根源这个异常常出现在使用迭代器遍历集合的同时另一个线程修改了集合的结构增、删。即使是在单线程中用for-each循环遍历ArrayList时直接调用remove方法也会抛出此异常。解决方案使用并发容器如遍历ConcurrentHashMap时其迭代器是“弱一致性”的允许在迭代过程中修改不会抛异常。遍历时加锁在遍历集合的代码块前后加锁使用synchronized或ReentrantLock确保遍历期间集合不被修改。复制快照在遍历前将集合内容复制到一个新数组中如list.toArray(new String[0])然后遍历这个快照。适用于集合不大的情况。使用CopyOnWriteArrayList如前所述它专门为这种“读多写少”的遍历场景设计。并发编程的调试和排查除了依靠日志和线程转储更需要在设计阶段就保持清晰。尽量缩小同步代码块的范围优先使用不可变对象明确共享变量的访问边界这些良好的习惯比任何事后工具都更有效。每一次线上并发问题的解决都是对这套知识体系的一次淬炼积累下来的经验就是你在面对下一个“高并发”需求时那份从容和自信的来源。