1. JUC类库的初步认识与核心设计思路1.1 JUC到底在解决什么问题在Java并发编程里几乎每个团队都会遇到同一个问题到底用synchronized还是用JUC我早年写并发代码的时候第一反应就是synchronized加锁。但随着系统并发量上来各种问题就暴露了——锁粒度不好控制、无法超时、等待不能中断、高竞争场景下性能衰减明显。JUC这套工具集本质上就是为了解决这些痛点而设计的。JUCjava.util.concurrent包从JDK 5开始进入标准库经过JDK 8、JDK 17等多个版本的演进已经构建出一个非常完整的并发编程工具箱。它并不是要完全取代synchronized而是提供更细粒度、更灵活的手段。在日常开发中最常见的几类需求——限流、等待多个任务完成、并行任务调度、安全的数据共享——都能在JUC里找到对应的解决方案。JUC的核心价值是把并发控制从“锁住对象”提升到了“协调工具”和“调度框架”的层面。举一个实际场景你要跑一批定时任务比如每小时同步一次数据。如果任务执行时间超过一小时就会遇到重入问题。用传统的定时器配合synchronized很容易出现锁等待甚至任务堆积。但用JUC的线程池调度既可以让任务在超时后自动跳过也可以让队列有界防止任务无限堆积。这套设计显然更贴近真实业务。从线程安全的角度来说JUC还自带一批并发容器。虽然Vector、Hashtable也算线程安全但它们的线程安全完全靠方法级synchronized实现在高竞争下性能衰减很明显。JUC提供的ConcurrentHashMap在并发读写上做了大量优化它的锁粒度是“桶级”而不是“全表级”。打个比方这就好比把整栋大楼唯一的闸门换成了每个房间独立的门禁并发效率自然就上去了。1.2 JUC的整体分类与核心组件JUC按职责可以分成几大类线程池与执行器框架ExecutorService、ThreadPoolExecutor、ForkJoinPool等、同步工具CountDownLatch、CyclicBarrier、Semaphore、Phaser等、并发容器ConcurrentHashMap、CopyOnWriteArrayList、ConcurrentLinkedQueue等、原子类AtomicInteger、AtomicLong、LongAdder等以及底层同步框架AQSAbstractQueuedSynchronizer。这几类分别对应着并发编程的几个核心问题线程池解决的是“线程怎么创建、怎么复用、怎么调度”同步工具解决的是“多线程之间怎么协作、怎么互相等待”并发容器解决的是“数据在并发环境里怎么安全存储和访问”原子类解决的是“无锁情况下怎么做数值累加和更新”AQS则是整个JUC同步类的底层支撑理解了AQS就理解了JUC大半的同步工具我见过很多开发者能流利背出这些类的名字但真到业务里就只敢用Executors.newFixedThreadPool。这种“只知API、不懂原理”的做法在并发环境下特别容易出事故。后续内容里我会逐一拆解每个类的使用场景、关键参数和坑点尽量让你读完能在实际项目中用对、用稳。2. 线程池并发世界的“调度中枢”2.1 核心线程池类解析ThreadPoolExecutor、ExecutorsThreadPoolExecutor是JUC线程池的核心实现。一个ThreadPoolExecutor实例本质上就是一个有界任务队列加一组工作线程。线程数量、队列类型、拒绝策略共同决定了线程池的行为。我在项目落地时几乎不会直接用Executors工具类而是手动new一个ThreadPoolExecutor因为Executors默认的参数在很多场景下有隐患。最典型的例子是newFixedThreadPool和newSingleThreadExecutor它们的任务队列默认是LinkedBlockingQueue容量无上限。一旦任务提交速度超过消费速度队列会一直增长最后把内存吃满。手动创建线程池时我会把参数划分成三组来考虑。核心线程数corePoolSize、最大线程数maximumPoolSize、空闲线程存活时间keepAliveTime是一组控制线程规模任务队列BlockingQueue单独是一组控制任务的排队策略拒绝策略RejectedExecutionHandler是最后一组控制系统过载时的行为。线程数的估算有两条实用路径。如果是CPU密集型任务核心线程数一般设置为CPU核数加1如果是IO密集型任务可以设置为核心线程数的两倍甚至更多因为线程大部分时间在等待IO。这个经验公式对新手起步够用但真实项目里还得结合压测数据调整尤其是数据库连接池、外部服务调用这些潜在瓶颈线程数不能只看公式。队列的选择同样重要。ArrayBlockingQueue是有界队列能限制内存占用但满了以后会触发拒绝策略LinkedBlockingQueue如果不给容量就是无界队列虽然任务不会丢但内存风险很大SynchronousQueue不存储任务直接把任务交给线程适合任务量不大但要求即时处理的场景PriorityBlockingQueue则适合有优先级要求的任务。拒绝策略有四种AbortPolicy默认直接抛异常、CallerRunsPolicy让提交线程自己执行任务、DiscardPolicy静默丢弃、DiscardOldestPolicy丢弃最老的任务。在企业系统里我一般用自定义的拒绝策略——记录日志并存库方便事后排查而不会直接使用DiscardPolicy这种静默丢弃的方式因为出问题的时候连个痕迹都没有。2.2 线程池参数选择与避坑指南线程池配置没有“一条公式走天下”的说法但有几个实战经验可以分享。第一个坑核心线程数设得太小任务排队严重。我曾经处理过一个线上订单消息处理慢的故障线程池核心线程数4最大线程数8队列容量1000。当时流量突增每个任务处理又涉及一次数据库操作耗时大约80ms。消息积压得越来越严重但线程池却没有创建更多线程因为核心线程都忙着队列还没满。直到队列满了才会创建新线程但此时已经是半小时后的事了。后来我把队列改成有界且容量调小核心线程数提高到处理能力的80%效果立竿见影。第二个坑没有设置allowCoreThreadTimeOut。默认情况下核心线程是常驻的。但有些场景流量有明显的波峰波谷比如每天晚上十二点后几乎没有任务。如果核心线程也一直保留就浪费了系统资源。设置allowCoreThreadTimeOut(true)后核心线程的空闲时间超过keepAliveTime也会被回收线程数能降到0等下一波流量来了再创建线程。这个设置对节省内存和CPU资源很有用特别是跑在容器里的应用CPU和内存都要精打细算。第三个坑过度依赖线程池却忽略了任务的真实耗时。可以用一个简单公式来估算线程池容量设任务平均耗时为T毫秒要求每秒处理量为Q那么线程数大致等于T乘以Q再除以1000。比如任务平均耗时50ms目标QPS是1000理论上需要的线程数大概是50。但这个计算没有考虑CPU核数上限所以实际落地时还是要在压测环境里验证。线程池的监控也是一个很多人忽略的点。ThreadPoolExecutor自带getPoolSize、getActiveCount、getQueueSize这些方法但真正线上环境里我更建议维护一套基于定时采集的任务每隔几秒把线程池状态打到日志或监控系统里。队列堆积数、拒绝次数、活跃线程数这三个指标能快速定位瓶颈。3. 同步工具类让线程“步调一致”3.1 CountDownLatch、CyclicBarrier、Semaphore实战开发中最常遇到的同步工具就是这三个。CountDownLatch像一个倒计时计数器用来让一个或多个线程等待其他线程完成一系列操作。典型场景是主线程启动多个子任务等所有子任务完成后再汇总结果。它的实现非常简单构造时传一个计数器值count每次调用countDown()计数器值减一当值变成0时await()方法就会返回。一个实际例子做批量报表导出时需要并发调用三个外部数据源然后合并数据。我会新建一个CountDownLatch(3)三个线程分别查询数据各自完成后调用countDown()主线程调用await()等待。需要注意的点是await()可以加超时参数await(5, TimeUnit.SECONDS)如果五秒没等到计数器归零就继续往下走避免主线程被无限卡死。CyclicBarrier是另一种栅栏机制。和CountDownLatch的区别在于CyclicBarrier可以让一组线程互相等待直到所有线程都到达同一个点然后同时继续执行。我常用它来做数据分段处理。比如将一个大数组拆成4段每段由不同线程计算每个线程算完后调用barrier.await()等4个线程都到了再统一进入下一阶段。CyclicBarrier的“循环”特性是指它可以复用——这轮用完重置后下一轮还能接着用。Semaphore是信号量它更接近“流量控制”。Semaphore初始化N个许可acquire()获取许可release()释放许可。常见应用场景除了限流还有控制对某类资源的并发访问数。比如外部接口只允许10个并发请求可以用Semaphore(10)来控制。需要快速失败的场景可以用tryAcquire()拿不到许可就直接返回false而不是一直阻塞等待。3.2 同步工具类的选择对比与原理这三个同步工具在实际工作中经常被混用很多人分不清。我的口诀是CountDownLatch等结果CyclicBarrier等伙伴Semaphore控数量。等结果强调的是“主线等待子任务完成”等伙伴强调的是“一组任务一起到达某个状态之后才继续”控数量是“限制同时访问资源的线程数”。原理上CountDownLatch基于AQS实现它其实是一个共享锁的特殊用法。每次countDown对应一次释放而await相当于获取一个共享锁。CyclicBarrier底层用的是ReentrantLock加Condition它会维护一个count变量每个线程到达后count减一如果没到0就调用condition.await()进入等待最后一个线程到达时唤醒所有等待线程并重置计数。Semaphore也是基于AQS的共享模式用state字段代表剩余的许可数。工具类核心机制是否可复用主要场景超时支持CountDownLatch计数器递减不可复用主线程等待多任务完成await支持超时CyclicBarrier栅栏等待可循环使用多线程分阶段协同await支持超时Semaphore许可数量可动态release资源访问限流tryAcquire支持超时很多人有一个误区以为CountDownLatch也可以复用甚至想手动重置计数器。实际上它没有提供重置方法如果想重复使用就应该改成CyclicBarrier或者直接用AtomicInteger自己实现。这一点实战中非常关键我见过不止一次有人为了“重用”CountDownLatch去反射改内部字段最后搞得线上代码一团糟。4. 并发容器数据安全与性能并重4.1 ConcurrentHashMap与CopyOnWriteArrayList在JUC包出现之前Java里线程安全的Map选择是Hashtable或者用Collections.synchronizedMap包装。这两种方案本质上都是对每个方法加全局锁线程竞争激烈时性能很差。ConcurrentHashMap在JDK 7用分段锁降低竞争粒度JDK 8改成了CAS加synchronized对每个桶进行并发控制。读操作用CAS和volatile保证可见性写操作加桶级别的小锁这意味着不同线程操作不同桶时几乎不会互相阻塞。ConcurrentHashMap的用法和HashMap几乎一致但它不保证复合操作的原子性。举个例子map.putIfAbsent是原子的但“先判断存在再操作”的组合就不是原子操作。如果需要这样的复合原子操作建议看看ConcurrentHashMap提供的compute、merge方法它们能保证在锁内执行整个函数。我用merge做累加计算比较多比如统计点击量map.merge(key, 1, Integer::sum)比先get再put的方式要安全得多。CopyOnWriteArrayList是另一个很有代表性的容器。它靠“写时复制”实现线程安全每次修改add、set、remove都会创建一份新的底层数组然后替换原数组的引用。因为创建副本需要成本所以它特别适合“读多写少”的场景。典型的例子是配置列表、监听器列表、路由规则列表。如果是频繁写入的场景用CopyOnWriteArrayList就很不划算每次写都复制整个数组内存和GC都会受到影响。有一个项目里我用它存动态配置项读的次数极多、几乎不写效果很好但如果每分钟要更新上千次就不能这么干了。4.2 队列与并发集合的实战选择JUC包里还有一批并发队列比较常用的有ConcurrentLinkedQueue、ArrayBlockingQueue、LinkedBlockingQueue和DelayQueue。ConcurrentLinkedQueue是无限长度的无锁队列适合并发生产者消费者场景ArrayBlockingQueue和LinkedBlockingQueue经常配合线程池使用前者有界后者默认无界。BlockingQueue的核心魅力在于它提供了阻塞方法put和take。put在队列满时阻塞take在队列空时阻塞。生产者和消费者模式用BlockingQueue实现天然就很优雅不需要自己写wait/notify。我在业务系统里用ArrayBlockingQueue做订单流水异步落库生产者只是put任务消费者线程组poll处理解耦效果很好。从稳定性角度看凡是涉及队列的地方我都会考虑“背压”机制。如果队列是无界的而消费者处理速度跟不上队列会不断膨胀最终导致内存溢出。所以设计消费者模型时第一个问题不是“用什么队列”而是“队列必须要有多大的上限”。有时候哪怕直接丢弃任务也比内存崩溃好——这也就是我会在架构设计里用“有界队列加合理拒绝策略”的根本原因。5. 原子类与AQS框架无锁方案的底层逻辑5.1 AtomicInteger、LongAdder与CAS机制原子类位于java.util.concurrent.atomic包它们利用CASCompare And Swap实现了无锁的线程安全更新。CAS的操作逻辑是比较当前值是否等于预期值如果相等就把值更新成新值否则不做操作。这个操作是CPU指令级别的原子操作不需要加锁。AtomicInteger的典型用途是并发计数。比如统计接口调用次数用incrementAndGet方法在高并发下也能保证准确。不过在高竞争场景下CAS存在一个“自旋”问题多个线程同时争抢同一个变量失败的线程会不断重试浪费CPU。LongAdder就是专门解决这个问题的它内部维护了一个基础值和一个Cell数组每个线程更新时会把负载分散到不同的cell上最后调用sum()时再汇总。高并发计数场景下LongAdder的性能比AtomicInteger更好。需要注意的坑是CAS的ABA问题。假设一个变量初始值为A线程1和线程2都读到A线程1想把A改成B线程2先把A改成C再改回A。线程1做CAS时发现值还是A就认为没变过结果就更新了。虽然最终值可能没错但中间过程被覆盖了。解决办法是使用AtomicStampedReference它额外维护一个版本号。5.2 AQS核心原理与ReentrantLock实战AQSAbstractQueuedSynchronizer是JUC中几乎所有同步类的地基。ReentrantLock、Semaphore、CountDownLatch、ReentrantReadWriteLock全基于AQS。AQS的核心是一个volatile int state变量加上一个FIFO等待队列。state可以表示锁状态0表示未持有1表示持有也可以表示剩余许可数还可以表示计数器的剩余值。每个同步类都对state的含义做了自己的定义。ReentrantLock的公平锁和非公平锁区别很多面试官会问。非公平锁在尝试加锁时会直接CAS尝试把state从0改成1如果成功就拿到锁根本不管队列里有没有人已经在等待。公平锁则严格按队列顺序新来的线程必须排队。非公平锁的性能高一些因为减少了线程唤醒和切换的开销但可能出现“线程饥饿”的问题。在业务开发中我默认用非公平锁只有在明确需要保证任务执行顺序的场景才使用公平锁。ReentrantLock比synchronized强的地方在于可中断、可超时、可多个Condition。尤其是Condition可以在同一个锁上实现多路等待。比如一个阻塞队列消费线程需要等待“队列非空”生产线程需要等待“队列非满”这两个等待条件如果用synchronized就只能用notifyAll唤醒所有线程浪费严重。而用Condition的话一个lock创建两个Condition分别管理生产者和消费者的等待效率高很多。再提一个容易被忽略的细节tryLock的用法。tryLock(500, TimeUnit.MILLISECONDS)如果拿不到锁会返回false这时可以选择走别的逻辑而不是傻等。这种场景在分布式任务抢占时特别有用。我曾在一个JVM内同时跑多个定时任务用ReentrantLock配合tryLock实现节点内的串行控制即使任务异常中断锁也会在超时后自动释放不会造成长时间阻塞。6. 高频坑点与实战经验速查6.1 高并发环境下最容易被踩的五个坑第一个坑提交任务给线程池后没有拿Future。很多新手学完ExecutorService就喜欢executor.submit(new Runnable())跑完就完事。但submit返回的Future对象如果不接收任务执行异常就会被吞掉。我多次在线上看到任务悄悄失败、日志里却没有异常的案例。处理方法是至少用Future.get()捕获ExecutionException或者在任务里自己try/catch并记录日志。第二个坑synchronized和JUC锁混用时死锁。锁的嵌套顺序必须一致否则必然产生死锁。比如线程A先拿锁1再拿锁2线程B先拿锁2再拿锁1两边同时跑起来就互相等待。解决方案是规定全局锁顺序或者用tryLock超时来规避。第三个坑使用ThreadLocal不当导致内存泄漏。在高并发的线程池环境里如果线程池线程的ThreadLocal值没有清理虽然线程本身还在但关联的数据会一直驻留最终触发OOM。特别是用了线程池时ThreadLocal变量在任务结束后一定要调用remove。第四个坑CountDownLatch计数和实际任务数不一致。如果某次循环里满足条件提前continue导致countDown没有执行主线程就会一直等待。这种问题在代码评审阶段很难发现我建议所有await都加上超时参数宁可超时后走降级逻辑也不要被无限卡死。第五个坑把无界队列当成默认选项。很多框架默认配置就是无界队列一旦出现突发流量队列越堆越高内存告警。处理思路是尽量使用有界队列并配套合理的拒绝策略。6.2 高频面试问题自查清单最后整理一下我平时面试别人时常用的高频问题。这既是面试指南也是检验自己JUC理解程度的自查清单。JUC包下有哪些类按功能分类说明。ThreadPoolExecutor核心参数有哪些分别控制什么Executors.newFixedThreadPool和手动创建ThreadPoolExecutor的区别是什么CountDownLatch和CyclicBarrier的区别是什么Semaphore的使用场景是什么ConcurrentHashMap在JDK 7和JDK 8的实现区别CAS的原理和ABA问题怎么解决AQS的核心是什么它的state变量有什么作用ReentrantLock公平锁和非公平锁的实现区别原子类AtomicInteger和LongAdder分别适合什么场景这一套问题如果全都能讲清楚原理和场景JUC就基本吃透了。我自己面试时也更喜欢听候选人结合项目实际案例去讲而不是背书式地抛概念。毕竟并发编程这东西纸上谈兵和真正在线上跑过完全是两种体验。
