1. 内容整体设计与思路拆解1.1 JUC到底是什么为什么要专门学它JUC全称是 java.util.concurrent简单说就是Java官方提供的一套并发编程工具包。很多人一开始听到“JUC”这个名字会觉得陌生但它其实早就内置在JDK里了从JDK 1.5开始就伴随着每一个Java开发者。为什么它这么重要因为只要你的系统一旦上了规模就必然面临多线程并发的问题而JUC就是专门解决这类问题的“官方武器库”。我记得刚开始接触并发编程时整个人是晕的。synchronized加锁、线程怎么停、怎么通信、集合类怎么在并发下不报错每个问题都能折腾一整天。后来跟着周阳老师的课程系统过了一遍JUC才慢慢把整个并发知识体系串起来。说句实话JUC这门课不是用来“背”的而是用来“构建并发思维”的。学完之后你再去看线程池、看锁、看各种并发容器脑子里会有一张完整的地图哪个工具解决什么问题底层原理是什么遇到坑该怎么排查。这篇笔记我尽量用“人话”把我自己学习JUC的整个路径、核心知识点、实操案例和踩坑记录分享出来。适合的人群简单说有三类一是刚接触Java并发、被synchronized和线程搞懵的新手二是有一定开发经验但并发知识零散、想系统梳理的中级开发者三是准备面试需要快速掌握并发核心考点的人。不管你是哪一类按这条路径走下来收获应该都不会差。1.2 学习路径规划从锁到工具再到线程池一条主线串到底JUC的内容其实非常庞杂如果不做规划很容易今天看一点Lock明天看一点并发容器过两天又跳去看线程池最后什么都没记住。我自己比较受用的学习路径是把它拆成四条主线第一条是锁机制从synchronized到Lock接口再到ReentrantLock的底层AQS原理第二条是线程通信与协作从wait/notify到Condition、LockSupport再到CountDownLatch这类并发工具第三条是并发安全的数据结构包括CopyOnWriteArrayList、ConcurrentHashMap、BlockingQueue等第四条是线程池和异步编程包括ThreadPoolExecutor、Fork/Join、CompletableFuture。为什么要按这个顺序学因为每一步都是下一步的基础。不懂synchronized的局限你就理解不了为什么需要Lock不懂Lock的lock/unlock手动控制你就理解不了Condition为什么要绑定在锁上不懂这些基础的锁和通信机制后面看并发工具类就像看天书。四条线走完你其实已经具备了一个初级并发工程师的核心能力剩下的就是通过实战去加深理解。周阳老师课程里用大量画图和源码追踪的方式来讲这些内容这一点对我帮助很大。比如AQSAbstractQueuedSynchronizer光看书上几段文字是完全不够的必须看它内部state变量怎么变化、CLH队列怎么入队出队、lock和unlock之间线程状态怎么流转。这些用动图和一步一步的源码断点去跟才能真正入脑。2. 核心细节解析与实操要点2.1 synchronized与Lock的选择从“自动挡”到“手动挡”很多初学者都会问一个问题既然synchronized能用为什么还要折腾Lock我用一个生活化的类比来解释synchronized是“自动挡”你只管开车换挡、离合、油门都交给系统Lock是“手动挡”档位、转速、离合全都要自己控制但换来的是更高的操控灵活度。synchronized的优点很明显使用简单锁的获取和释放由JVM自动管理出现异常也会自动释放锁不存在“死锁”这种因为忘记解锁导致的问题。但它的缺点同样明显比如无法中断一个正在等待锁的线程无法设置等待锁的超时时间也无法实现公平锁或者说是非公平的。在高并发场景下这种“一条道走到黑”的策略有时候会显得笨重。Lock接口则提供了更精细的控制能力。用ReentrantLock我可以lock()加锁、unlock()解锁可以用tryLock(timeout, TimeUnit)设置等待超时可以用lockInterruptibly()让线程在等待锁时响应中断还可以通过构造参数new ReentrantLock(true)实现公平锁。举个例子某次支付系统改造中有一个对账任务需要同时更新两个账户的余额并发高的时候很容易互相持有锁然后等待对方释放形成死锁。当时用的synchronized一旦死锁只能重启服务。后来改成ReentrantLock的tryLock设置2秒超时拿不到锁就直接失败重试死锁问题彻底解决。实际项目中我的建议是如果只是简单的同步代码块synchronized完全够用不需要过度设计如果需要超时控制、可中断、公平性这些高级特性或者需要多个 Condition 做精确唤醒那就用Lock。性能上其实现代JDK对synchronized做了大量优化偏向锁、轻量级锁两者已经没有绝对的高低之分关键看你的业务场景需要什么控制粒度。2.2 volatile、CAS与原子类并发编程的“地基三件套”学JUC绕不开三个底层概念volatile、CASCompare And Swap比较并交换和原子类。这三样东西属于“底层建筑”你用的大部分并发工具其底层机制都源自这里。先说volatile。它的两个核心语义是保证可见性和禁止指令重排序。可见性怎么理解假如有两个线程同时访问一个普通int变量线程A修改了值线程B不一定能立刻看到因为每个线程有自己独立的工作内存缓存。而volatile修饰的变量一旦被修改会立即刷新到主内存并且其他线程读的时候会强制从主内存重新读取。另一个禁止指令重排序简单说就是编译器或CPU不会为了优化而打乱volatile读写的执行顺序这在单例模式的双重检查锁DCL场景中至关重要。再说CAS。CAS是一种硬件级别的原子操作原理就是“比较再交换”只有当内存中的当前值和预期值一致时才把值更新为新值否则就重试。Java里很多原子类如AtomicInteger底层就是用Unsafe类的compareAndSwapInt实现的。CAS的好处是避免了加锁的开销但坏处是会产生ABA问题以及在自旋激烈时CPU开销大。ABA问题简单说就是一个线程把值从A改成B又改回A另一个线程执行CAS时发现值还是A于是认为没有被修改过从而可能产生错误的逻辑判断。解决办法是使用带版本号的AtomicStampedReference。原子类则是基于CASvolatile封装出来的一系列类最常用的有AtomicInteger、AtomicLong、LongAdder等。LongAdder是在AtomicLong基础上优化出来的它把单一热点分散到多个cell上在高并发写多读少的场景下性能远好于AtomicLong。我做过一个简单的压测对比同一场景下8个线程并发累加AtomicLong耗时约1200msLongAdder只需要约300ms差距非常明显。2.3 多线程通信wait/notify、Condition与LockSupport的三代演进线程通信这块很多教材还在讲wait/notify但实际生产中更常用的其实是Condition和LockSupport。这三者的核心区别在我看来是“精准度”和“灵活性”的提升。传统synchronized下的通信只能通过Object的wait和notify实现。问题在于notify是随机唤醒一个等待线程如果唤醒错了对象可能造成死等或无效唤醒。这也是为什么规范都要求用while循环包裹wait判断条件而不是用if。因为线程被唤醒后条件不一定已经满足必须重新检查一遍才能保证安全。在Lock出现后Condition替代了wait/notify。每个Condition相当于一个独立的等待队列你可以创建多个Condition来实现精准唤醒。最经典的案例是生产者消费者模型用一个Condition表示“队列满”再用另一个Condition表示“队列空”。生产者只管等“队列空”的Condition消费者只管等“队列满”的Condition这是wait/notify很难优雅实现的多路等待场景。再后来是LockSupport这是JUC工具类底层最常用的线程阻塞工具。LockSupport.park()和unpark()和wait/notify最大的不同在于它不需要在同步代码块里调用并且unpark可以先于park执行相当于给线程发了一张“许可凭证”。这极大简化了开发者的心智负担很多JUC底层的等待逻辑都基于LockSupport实现。一句话总结理解LockSupport的“许可证”机制你再看AQS的源码会顺畅很多。3. 实操过程与核心环节实现3.1 手写一个生产消费模型用Condition实现精准唤醒这里我给出一个可以直接运行的完整示例这也是我当时练习时的标准写法非常经典。代码要求是一个初始值为0的变量两个线程交替操作一个加1一个减1各操作10次要求最终结果仍为0。import java.util.concurrent.locks.Condition; import java.util.concurrent.locks.Lock; import java.util.concurrent.locks.ReentrantLock; class ShareData { private int number 0; private Lock lock new ReentrantLock(); private Condition condition lock.newCondition(); public void increment() throws InterruptedException { lock.lock(); try { // 多线程判断一定要用while防止虚假唤醒 while (number ! 0) { condition.await(); } number; System.out.println(Thread.currentThread().getName() \t number); condition.signalAll(); } finally { lock.unlock(); } } public void decrement() throws InterruptedException { lock.lock(); try { while (number 0) { condition.await(); } number--; System.out.println(Thread.currentThread().getName() \t number); condition.signalAll(); } finally { lock.unlock(); } } } public class ProdConsumerDemo { public static void main(String[] args) { ShareData shareData new ShareData(); new Thread(() - { for (int i 0; i 10; i) { try { shareData.increment(); } catch (InterruptedException e) { e.printStackTrace(); } } }, Producer).start(); new Thread(() - { for (int i 0; i 10; i) { try { shareData.decrement(); } catch (InterruptedException e) { e.printStackTrace(); } } }, Consumer).start(); } }这里面最重要的一行代码是 while 而不是 if。我用 if 试过一次结果程序最终输出结果不是0而且偶发出现数值超过1的情况。原因就是虚假唤醒线程被唤醒后没有重新检查条件就直接执行了number。所以记住一句话在多线程条件下判断条件用while永远比if安全。那么Condition和synchronized版wait/notify相比优势在哪里如果你只有一对生产者和消费者两者的差别不大。但如果你有多个生产者、多个消费者并且要求“生产者唤醒消费者、消费者唤醒生产者”用notifyAll就会导致“唤醒风暴”大量线程白白消耗时间片。用Condition场景就清晰很多可以设置生产者Condition和消费者Condition互相之间精准定向唤醒效率高一个数量级。3.2 八锁案例从字节码层面理解synchronized锁的八种情况周阳老师的课程里有一个“八锁问题”的经典案例通过8个不同场景的小Demo把synchronized到底锁的是什么讲得明明白白。我自己亲自敲了一遍之后对对象锁、类锁、普通方法、静态方法之间的区别理解上了一个大台阶。简单梳理一下这八种情况的核心结论synchronized修饰普通方法锁的是当前实例对象this。两个线程操作同一个对象时互斥操作不同对象时互不干扰。synchronized修饰静态方法锁的是当前类的Class对象。这个锁是所有实例共享的实例不同也没用照样互斥。普通同步方法和静态同步方法之间锁的对象不同互不排斥可以同时执行。一个类中若一个方法有锁、一个方法没有锁没有锁的方法永远不被阻塞多线程可以同时进入。当一个线程进入一个对象的synchronized方法后其他线程能否访问该对象的其他非同步方法答案是能因为非同步方法不参与锁竞争。同一个对象一个线程先执行A锁方法再执行B锁方法另一个线程想执行B锁方法只能等第一个线程释放A的锁因为synchronized是可重入锁。如果A方法是sleep状态持有锁不释放B方法即便只是普通同步方法也要等待。静态锁和实例锁之间互不干扰最关键的是必须搞清楚锁的“锚点”是谁。我当时踩过一个很隐蔽的坑给两个不同对象实例加锁但方法用了静态同步方法结果两边的锁互相影响排查了很久。后来才意识到静态同步方法锁的是整个Class对象所有实例共享同一把锁并不因为new了两个对象就变成两把锁。3.3 锁的底层从ReentrantLock到AQS源码级追踪如果说JUC是一棵大树那AQS就是这棵树的根。理解了AQSReentrantLock、Semaphore、CountDownLatch这些工具在你眼里就不再是孤立的API而是同一个框架的不同变体。AQS的核心就是一个volatile int类型的state变量加上一个双向链表结构的等待队列。以ReentrantLock为例lock()调用时就是通过CAS尝试把state从0改成1如果成功表示当前线程获得锁持有线程记为当前线程如果失败当前线程会被封装成一个Node节点加入等待队列尾部然后通过LockSupport.park()阻塞自己。而unlock()则把state改回0并唤醒队首等待的一个线程。这里有个计算细节值得注意为什么ReentrantLock支持可重入因为state记录的是重入次数。每次同一个线程再次lock()state就加1每次unlock()state减1只有state减到0时锁才真正释放给其他线程。这也是为什么使用ReentrantLock时必须保证lock和unlock成对出现重入几次就要解锁几次否则state永远到不了0锁就永远释放不了。公平锁和非公平锁的差异在AQS里也很直观。非公平锁一上来就直接去抢state抢不到才排队公平锁则先检查队列里有没有排在前面的线程有的话自己乖乖去队尾排队。从性能上说非公平锁的吞吐量通常高于公平锁因为减少了线程上下文切换但某些需要“先来后到”的强一致场景公平锁更合适。3.4 线程池从参数推导到生产级配置线程池这块是JUC里的重头戏也是面试几乎必问的点。很多人背了七大参数、四种拒绝策略但真正问到底层执行流程就卡壳了。这里我把整个流程画成文字版新任务进来先判断当前运行的线程数是否小于corePoolSize小于则新建核心线程执行大于等于核心线程数就把任务放入阻塞队列如果队列满了再判断当前线程数是否小于maximumPoolSize小于则创建非核心线程救急线程执行如果已经到了最大线程数则执行拒绝策略。这里面最容易被忽视的三个参数是 keepAliveTime、TimeUnit 和三个队列/线程工厂的实现。keepAliveTime指的是非核心线程空闲多久后被回收核心线程默认不回收除非设置了allowCoreThreadTimeOut(true)。TimeUnit就是keepAliveTime的时间单位。而线程工厂ThreadFactory看似简单很多人直接用的默认实现结果线上日志里线程名全是pool-1-thread-1出问题的时候根本定位不到是哪个业务线程在跑。我建议一定自定义线程工厂给线程起一个有业务含义的名字比如pay-center-pool-thread-1排查问题的时候能省不少时间。还有一个非常关键的坑线程池 阻塞队列的搭配选择。绝大多数业务场景推荐 LinkedBlockingQueue无界队列默认大小Integer.MAX_VALUE要慎用因为一旦任务大量堆积队列无限增长可能导致OOM。比较稳妥的方案是用有界队列ArrayBlockingQueue并设置合理的容量再配合CallerRunsPolicy调用者运行拒绝策略线程池满了就让提交任务的线程自己去执行任务。这样既能削峰也不会因为拒绝而丢失任务。再聊聊我们实际项目中的配置思路。一个IO密集型的业务核心线程数通常没有固定公式可套但可以按“CPU核心数 * 2”起步再通过压测逐步调整计算密集型则按“CPU核心数 1”来配置。忌讳的是拍脑袋填一个数就上线后续完全不管。我见过因为核心线程数设得太大高峰期一次性创建了上百个线程直接拖垮数据库连接池的案例。线程池参数必须结合压测、监控数据反复调优而不是“配一次用一辈子”。3.5 CompletableFuture从Future到异步编排的优雅演进异步编程是JUC中非常实用的一块内容。传统Future虽然能拿到异步结果但有个天然缺陷只能阻塞式get()等待或者轮询isDone()判断没有办法在任务完成时主动通知下一个任务继续更别说做多个任务之间的编排。CompletableFuture的出现把Java异步编程带入了“流式编排”时代。它支持回调、串行、并行、组合、异常处理等丰富的操作。举一个生产中的例子订单详情接口需要同时查用户信息、商品信息、物流信息三个查询分别耗时100ms、200ms、150ms如果用传统串行调用总耗时是450ms。用CompletableFuture的allOf()组合三个异步任务并行执行总耗时基本等于最慢那个任务的耗时也就是200ms。这个优化效果立竿见影接口性能直接翻倍。它的核心API其实没多少常用的几个记住就够了runAsync/supplyAsync无返回值/有返回值异步执行、thenApply/thenAccept/thenRun串行转换、消费、执行、thenCombine/ thenAcceptBoth两个任务合并、allOf/anyOf多个任务聚合、exceptionally/handle/whenComplete异常处理。重点提醒一个容易踩的坑使用CompletableFuture时如果没有指定自定义的线程池它会使用默认的ForkJoinPool.commonPool()这个池子被所有CompletableFuture共享一旦某个任务阻塞可能会影响其他所有异步任务。所以涉及IO操作时务必传入自定义线程池做到资源隔离。4. 常见问题与排查技巧实录4.1 死锁排查从现象到jstack命令全记录死锁是我处理最多、也最容易让新手崩溃的问题。典型现象就是程序“卡死”接口一直不返回日志停在那里CPU占用率却只有零点几明显不是计算密集型的忙等。出现这种状况第一反应应该是线程可能都在互相等锁。我处理过一个实际生产事故两个服务间互相调用服务A持有数据库连接池中的连接等待服务B返回结果服务B也在等待服务A释放某个分布式锁结果两边僵持连接池被占满大量请求排队。当时用jstack导出了线程快照日志定位到非常明显Found one Java-level deadlock下面列出了两个线程互相持有的锁以及各自正在等待的锁。整个排查时间也就十分钟比盲猜日志快得多。所以这里强烈建议每个Java开发者都要掌握三个命令的用法jps查看Java进程PID、jstack导出线程栈、jstat监控JVM内存和GC。遇到疑似死锁、线程卡死的问题第一件事就是抓现场——导出线程栈而不是急着重启服务。重启一时爽但问题根本没有被定位下次还会再犯。4.2 并发下的集合安全CopyOnWriteArrayList和ConcurrentHashMap口径解析并发场景下使用集合类是另一个高频踩坑点。ArrayList在并发写时会出现两个经典异常一个是ConcurrentModificationException并发修改异常另一个是数组越界异常HashMap扩容时并发put。很多人第一反应是给整个方法加synchronized但这往往是把性能踩在脚下而且粒度控制不当反而引发新的竞争。标准的解法是用并发容器。读多写少的场景用CopyOnWriteArrayList它的写操作会复制一份新数组、修改后替换引用读取操作不加锁天然支持并发读但写操作的代价较高不适合频繁增删。读多写多、且通过key访问的场景用ConcurrentHashMap它内部采用分段锁/ synchronized CAS 的粒度控制在大并发下性能明显优于给整个Map加锁。我自己在项目里踩过的一个坑是把HashMap直接丢给一个多线程环境用结果线上偶发性出现CPU飙高和死循环。后来排查发现JDK 1.7及之前的HashMap在并发扩容时链表的头插法可能导致环状链表get操作陷入死循环。换成ConcurrentHashMap之后问题彻底消失。所以一个经验规则是多线程环境下不要抱有任何侥幸心理老老实实用并发容器。4.3 ThreadLocal的内存泄漏风险ThreadLocal也是并发编程里一个容易被忽视但又容易出事的类。它的作用是为每个线程保存一份独立的变量副本常用于保存用户登录信息、数据库连接等上下文。但它的底层结构是一个ThreadLocalMapkey是ThreadLocal对象本身一个弱引用value则是强引用。一旦ThreadLocal对象被回收而线程还存活那么value就永远无法被访问却一直占用内存形成内存泄漏。规避的方法其实很简单用完ThreadLocal之后一定要调用remove()方法清除。尤其在使用线程池的场景下线程是复用的如果不清理下一次任务执行时还会读到上一次任务留下的旧值这比内存泄漏更隐藏——它直接导致业务数据串线。我以前在写一个定时任务时用ThreadLocal缓存用户信息明明是A用户的任务日志里却出现了B用户的ID排查了好久才发现是线程池复用了线程ThreadLocal里的值没被清理被下一个任务继续使用了。这个教训至今印象深刻。解决套路很简单ThreadLocal变量尽量声明为static final保证全局只有一份在finally代码块中手动remove();使用线程池时尤其注意任务执行完一定要清上下文。5. 高频考点与实战经验延伸5.1 JMM、可见性与指令重排序一个案例彻底讲透JMMJava Memory ModelJava内存模型是个很容易被忽略、但面试和实际调优中经常涉及的概念。简单理解它定义了一个线程对共享变量进行读写时其他线程什么时候能看到这个修改的规则。JMM规定所有变量存储在主内存中每个线程有自己的工作内存线程对变量的操作必须先把变量从主内存拷贝到自己的工作内存修改后再写回主内存。整个过程可能产生两个问题不可见和乱序。经典的并发编程案例“死循环”就能说明不可见问题public class VisibilityDemo { private static boolean flag true; public static void main(String[] args) throws InterruptedException { new Thread(() - { while (flag) { // 空循环 } System.out.println(线程结束); }).start(); Thread.sleep(100); flag false; System.out.println(flag已被设置为false); } }如果你运行这段代码大概率会出现“flag已被设置为false”打印了但线程始终没有退出。原因是主线程修改了flag但工作线程的flag副本仍然是true线程读不到主线程的修改一直死循环。把flag用volatile修饰后立即生效。指令重排序导致的经典问题则是单例模式的双重检查锁。如果不加volatile在new Singleton()的过程中指令可能被优化为“先赋引用再调用构造函数”另一个线程此时读到非null但尚未构造完成的对象直接使用导致初始化中断。volatile禁止了这个重排序保证了对象的完整性。5.2 分布式场景下的幂等控制与并发安全学完JUC很多人会把目光从单机并发拓展到分布式场景这也是必然趋势。单机的线程安全问题可以靠synchronized、Lock、并发容器解决但一到了多机部署这些本地锁就失效了因为不同JVM之间的线程无法感知彼此。此时就需要引入分布式锁常见方案有Redis分布式锁和Zookeeper分布式锁。用Redis实现分布式锁时最常用的框架是Redisson它封装了加锁、解锁、自动续期的逻辑使用起来比手写SETNXLua脚本要安全得多。一个关键点加锁时必须设置过期时间并且要使用原子操作SET key value EX seconds NX防止加锁后进程宕机导致锁永远不释放。另一个关键点锁的value要唯一比如UUID释放锁时要先判断是不是自己的锁再删除防止因为超时误删了别人的锁。我之前负责过一个库存扣减的接口在扣减前先获取分布式锁扣减后释放。压测时发现锁的粒度太粗导致性能瓶颈。后来优化为分段锁把库存拆分成多个段每个段一个锁请求根据订单号哈希取模落到不同段上并发能力提升了4倍多。这说明无论单机还是分布式锁的粒度设计都非常重要千万不要“一把锁锁全库”。5.3 从JUC看整个Java并发知识体系最后我想分享一个认知层面的总结JUC不是一门孤立的课程它是整个Java并发知识体系的中间枢纽。学JUC之前你需要懂线程的基础知识比如start和run的区别、线程状态流转、sleep和wait的区别等。学JUC的过程中你要掌握锁、CAS、AQS、并发容器、线程池、异步编程这些工具。学完JUC之后你又会自然地过渡到分布式锁、分布式事务、消息队列削峰填谷等更复杂的分布式系统话题。所以学习JUC时我建议打开一个文档随时把学到的知识点画成一张知识地图。比如从“锁”出发可以延伸出悲观锁、乐观锁、自旋锁、可重入锁、公平锁、非公平锁、死锁、分布式锁从“线程池”出发可以延伸到任务队列、拒绝策略、参数调优、监控指标、业务隔离。这样一层层发散你的并发知识才能真正“连成网”而不是“散成沙”。6. 学习资源推荐与效率提升技巧6.1 除了看视频还要做这几件事很多人学JUC的方式是刷视频从头到尾看一遍看完觉得自己都懂了一到笔试面试或者实际开发发现用不出来。原因在于视频教学是“输入型学习”而能力增长需要大量的“输出型学习”。所以光看是不够的我给自己定了三个“额外动作”第一个是每个知识点都亲自写一个Demo哪怕是一个两三行的AtomicInteger自增案例也要亲手跑一遍第二个是把Demo的每个变化都记录下来比如改成多个线程同时执行、改成不同锁、改成不用的容器看看结果有什么不同第三个是去GitHub找一些开源项目的源码来读重点看它们如何设计锁和线程池。如果要推荐学习资源除了周阳老师的《JUC并发编程》课程之外我还会看《Java并发编程的艺术》和《Java并发编程实战》这两本书。课程适合入门和建立知识框架书适合深入原理和查漏补缺。另外强烈建议多看JDK源码尤其是ReentrantLock、AQS、ConcurrentHashMap、ThreadPoolExecutor这几个类看源码是理解并发原理最快的方式。6.2 学习节奏建议与心态调整JUC的内容量其实很大如果抱着“一周学完”的心态大概率会挫败。我个人建议的节奏是第一周先掌握synchronized、Lock、CAS、volatile这些基础概念第二周集中攻克线程池和并发工具类第三周开始结合项目实战和源码阅读把知识内化。整个过程大约需要三到四周的业余时间。学习过程中不要怕“看不懂源码”和“运行结果不符合预期”。遇到奇怪的现象其实是一件好事因为这才是真正理解底层机制的契机。我当时在写生产者消费者模型时怎么也想不通为什么用if会出问题后来看了JVM源码中关于wait被唤醒的机制说明才彻底明白“虚假唤醒”的真实场景。这种自己动手发现的问题往往比课本上反复强调的安全写法记得更牢。7. 写在最后我的实践经验沉淀回头看看整个JUC学习过程我最想跟后来者说的一点是不要被并发编程的复杂度吓倒它本质上就是在解决“多个线程同时访问共享资源时如何保证数据正确且性能可控”的问题。JUC里所有工具都是围绕这个核心问题提供的不同粒度的解决方案。从我自己的项目实践来看真正能让你“从小白到不慌”的不是记住多少API而是建立这三层认知第一层知道某个场景下该用什么工具第二层知道这个工具为什么能解决问题它的底层机制是什么第三层知道它有哪些局限、在什么情况下会失效、如何通过监控和日志快速排查问题。能做到第三层基本就具备解决生产环境并发问题的能力了。最后再分享一个小技巧日常开发中多关注线上监控里的线程数、活跃线程数、阻塞队列深度、锁等待时间和线程池拒绝次数这些指标。很多并发问题其实早有征兆只是前面没有留意。学会看这些指标再配合JUC的理论知识很多潜在隐患都能提前暴露并解决。学并发永远不亏真正用起来才会发现它无处不在。
JUC并发编程核心要点梳理：从锁到线程池的实战指南
1. 内容整体设计与思路拆解1.1 JUC到底是什么为什么要专门学它JUC全称是 java.util.concurrent简单说就是Java官方提供的一套并发编程工具包。很多人一开始听到“JUC”这个名字会觉得陌生但它其实早就内置在JDK里了从JDK 1.5开始就伴随着每一个Java开发者。为什么它这么重要因为只要你的系统一旦上了规模就必然面临多线程并发的问题而JUC就是专门解决这类问题的“官方武器库”。我记得刚开始接触并发编程时整个人是晕的。synchronized加锁、线程怎么停、怎么通信、集合类怎么在并发下不报错每个问题都能折腾一整天。后来跟着周阳老师的课程系统过了一遍JUC才慢慢把整个并发知识体系串起来。说句实话JUC这门课不是用来“背”的而是用来“构建并发思维”的。学完之后你再去看线程池、看锁、看各种并发容器脑子里会有一张完整的地图哪个工具解决什么问题底层原理是什么遇到坑该怎么排查。这篇笔记我尽量用“人话”把我自己学习JUC的整个路径、核心知识点、实操案例和踩坑记录分享出来。适合的人群简单说有三类一是刚接触Java并发、被synchronized和线程搞懵的新手二是有一定开发经验但并发知识零散、想系统梳理的中级开发者三是准备面试需要快速掌握并发核心考点的人。不管你是哪一类按这条路径走下来收获应该都不会差。1.2 学习路径规划从锁到工具再到线程池一条主线串到底JUC的内容其实非常庞杂如果不做规划很容易今天看一点Lock明天看一点并发容器过两天又跳去看线程池最后什么都没记住。我自己比较受用的学习路径是把它拆成四条主线第一条是锁机制从synchronized到Lock接口再到ReentrantLock的底层AQS原理第二条是线程通信与协作从wait/notify到Condition、LockSupport再到CountDownLatch这类并发工具第三条是并发安全的数据结构包括CopyOnWriteArrayList、ConcurrentHashMap、BlockingQueue等第四条是线程池和异步编程包括ThreadPoolExecutor、Fork/Join、CompletableFuture。为什么要按这个顺序学因为每一步都是下一步的基础。不懂synchronized的局限你就理解不了为什么需要Lock不懂Lock的lock/unlock手动控制你就理解不了Condition为什么要绑定在锁上不懂这些基础的锁和通信机制后面看并发工具类就像看天书。四条线走完你其实已经具备了一个初级并发工程师的核心能力剩下的就是通过实战去加深理解。周阳老师课程里用大量画图和源码追踪的方式来讲这些内容这一点对我帮助很大。比如AQSAbstractQueuedSynchronizer光看书上几段文字是完全不够的必须看它内部state变量怎么变化、CLH队列怎么入队出队、lock和unlock之间线程状态怎么流转。这些用动图和一步一步的源码断点去跟才能真正入脑。2. 核心细节解析与实操要点2.1 synchronized与Lock的选择从“自动挡”到“手动挡”很多初学者都会问一个问题既然synchronized能用为什么还要折腾Lock我用一个生活化的类比来解释synchronized是“自动挡”你只管开车换挡、离合、油门都交给系统Lock是“手动挡”档位、转速、离合全都要自己控制但换来的是更高的操控灵活度。synchronized的优点很明显使用简单锁的获取和释放由JVM自动管理出现异常也会自动释放锁不存在“死锁”这种因为忘记解锁导致的问题。但它的缺点同样明显比如无法中断一个正在等待锁的线程无法设置等待锁的超时时间也无法实现公平锁或者说是非公平的。在高并发场景下这种“一条道走到黑”的策略有时候会显得笨重。Lock接口则提供了更精细的控制能力。用ReentrantLock我可以lock()加锁、unlock()解锁可以用tryLock(timeout, TimeUnit)设置等待超时可以用lockInterruptibly()让线程在等待锁时响应中断还可以通过构造参数new ReentrantLock(true)实现公平锁。举个例子某次支付系统改造中有一个对账任务需要同时更新两个账户的余额并发高的时候很容易互相持有锁然后等待对方释放形成死锁。当时用的synchronized一旦死锁只能重启服务。后来改成ReentrantLock的tryLock设置2秒超时拿不到锁就直接失败重试死锁问题彻底解决。实际项目中我的建议是如果只是简单的同步代码块synchronized完全够用不需要过度设计如果需要超时控制、可中断、公平性这些高级特性或者需要多个 Condition 做精确唤醒那就用Lock。性能上其实现代JDK对synchronized做了大量优化偏向锁、轻量级锁两者已经没有绝对的高低之分关键看你的业务场景需要什么控制粒度。2.2 volatile、CAS与原子类并发编程的“地基三件套”学JUC绕不开三个底层概念volatile、CASCompare And Swap比较并交换和原子类。这三样东西属于“底层建筑”你用的大部分并发工具其底层机制都源自这里。先说volatile。它的两个核心语义是保证可见性和禁止指令重排序。可见性怎么理解假如有两个线程同时访问一个普通int变量线程A修改了值线程B不一定能立刻看到因为每个线程有自己独立的工作内存缓存。而volatile修饰的变量一旦被修改会立即刷新到主内存并且其他线程读的时候会强制从主内存重新读取。另一个禁止指令重排序简单说就是编译器或CPU不会为了优化而打乱volatile读写的执行顺序这在单例模式的双重检查锁DCL场景中至关重要。再说CAS。CAS是一种硬件级别的原子操作原理就是“比较再交换”只有当内存中的当前值和预期值一致时才把值更新为新值否则就重试。Java里很多原子类如AtomicInteger底层就是用Unsafe类的compareAndSwapInt实现的。CAS的好处是避免了加锁的开销但坏处是会产生ABA问题以及在自旋激烈时CPU开销大。ABA问题简单说就是一个线程把值从A改成B又改回A另一个线程执行CAS时发现值还是A于是认为没有被修改过从而可能产生错误的逻辑判断。解决办法是使用带版本号的AtomicStampedReference。原子类则是基于CASvolatile封装出来的一系列类最常用的有AtomicInteger、AtomicLong、LongAdder等。LongAdder是在AtomicLong基础上优化出来的它把单一热点分散到多个cell上在高并发写多读少的场景下性能远好于AtomicLong。我做过一个简单的压测对比同一场景下8个线程并发累加AtomicLong耗时约1200msLongAdder只需要约300ms差距非常明显。2.3 多线程通信wait/notify、Condition与LockSupport的三代演进线程通信这块很多教材还在讲wait/notify但实际生产中更常用的其实是Condition和LockSupport。这三者的核心区别在我看来是“精准度”和“灵活性”的提升。传统synchronized下的通信只能通过Object的wait和notify实现。问题在于notify是随机唤醒一个等待线程如果唤醒错了对象可能造成死等或无效唤醒。这也是为什么规范都要求用while循环包裹wait判断条件而不是用if。因为线程被唤醒后条件不一定已经满足必须重新检查一遍才能保证安全。在Lock出现后Condition替代了wait/notify。每个Condition相当于一个独立的等待队列你可以创建多个Condition来实现精准唤醒。最经典的案例是生产者消费者模型用一个Condition表示“队列满”再用另一个Condition表示“队列空”。生产者只管等“队列空”的Condition消费者只管等“队列满”的Condition这是wait/notify很难优雅实现的多路等待场景。再后来是LockSupport这是JUC工具类底层最常用的线程阻塞工具。LockSupport.park()和unpark()和wait/notify最大的不同在于它不需要在同步代码块里调用并且unpark可以先于park执行相当于给线程发了一张“许可凭证”。这极大简化了开发者的心智负担很多JUC底层的等待逻辑都基于LockSupport实现。一句话总结理解LockSupport的“许可证”机制你再看AQS的源码会顺畅很多。3. 实操过程与核心环节实现3.1 手写一个生产消费模型用Condition实现精准唤醒这里我给出一个可以直接运行的完整示例这也是我当时练习时的标准写法非常经典。代码要求是一个初始值为0的变量两个线程交替操作一个加1一个减1各操作10次要求最终结果仍为0。import java.util.concurrent.locks.Condition; import java.util.concurrent.locks.Lock; import java.util.concurrent.locks.ReentrantLock; class ShareData { private int number 0; private Lock lock new ReentrantLock(); private Condition condition lock.newCondition(); public void increment() throws InterruptedException { lock.lock(); try { // 多线程判断一定要用while防止虚假唤醒 while (number ! 0) { condition.await(); } number; System.out.println(Thread.currentThread().getName() \t number); condition.signalAll(); } finally { lock.unlock(); } } public void decrement() throws InterruptedException { lock.lock(); try { while (number 0) { condition.await(); } number--; System.out.println(Thread.currentThread().getName() \t number); condition.signalAll(); } finally { lock.unlock(); } } } public class ProdConsumerDemo { public static void main(String[] args) { ShareData shareData new ShareData(); new Thread(() - { for (int i 0; i 10; i) { try { shareData.increment(); } catch (InterruptedException e) { e.printStackTrace(); } } }, Producer).start(); new Thread(() - { for (int i 0; i 10; i) { try { shareData.decrement(); } catch (InterruptedException e) { e.printStackTrace(); } } }, Consumer).start(); } }这里面最重要的一行代码是 while 而不是 if。我用 if 试过一次结果程序最终输出结果不是0而且偶发出现数值超过1的情况。原因就是虚假唤醒线程被唤醒后没有重新检查条件就直接执行了number。所以记住一句话在多线程条件下判断条件用while永远比if安全。那么Condition和synchronized版wait/notify相比优势在哪里如果你只有一对生产者和消费者两者的差别不大。但如果你有多个生产者、多个消费者并且要求“生产者唤醒消费者、消费者唤醒生产者”用notifyAll就会导致“唤醒风暴”大量线程白白消耗时间片。用Condition场景就清晰很多可以设置生产者Condition和消费者Condition互相之间精准定向唤醒效率高一个数量级。3.2 八锁案例从字节码层面理解synchronized锁的八种情况周阳老师的课程里有一个“八锁问题”的经典案例通过8个不同场景的小Demo把synchronized到底锁的是什么讲得明明白白。我自己亲自敲了一遍之后对对象锁、类锁、普通方法、静态方法之间的区别理解上了一个大台阶。简单梳理一下这八种情况的核心结论synchronized修饰普通方法锁的是当前实例对象this。两个线程操作同一个对象时互斥操作不同对象时互不干扰。synchronized修饰静态方法锁的是当前类的Class对象。这个锁是所有实例共享的实例不同也没用照样互斥。普通同步方法和静态同步方法之间锁的对象不同互不排斥可以同时执行。一个类中若一个方法有锁、一个方法没有锁没有锁的方法永远不被阻塞多线程可以同时进入。当一个线程进入一个对象的synchronized方法后其他线程能否访问该对象的其他非同步方法答案是能因为非同步方法不参与锁竞争。同一个对象一个线程先执行A锁方法再执行B锁方法另一个线程想执行B锁方法只能等第一个线程释放A的锁因为synchronized是可重入锁。如果A方法是sleep状态持有锁不释放B方法即便只是普通同步方法也要等待。静态锁和实例锁之间互不干扰最关键的是必须搞清楚锁的“锚点”是谁。我当时踩过一个很隐蔽的坑给两个不同对象实例加锁但方法用了静态同步方法结果两边的锁互相影响排查了很久。后来才意识到静态同步方法锁的是整个Class对象所有实例共享同一把锁并不因为new了两个对象就变成两把锁。3.3 锁的底层从ReentrantLock到AQS源码级追踪如果说JUC是一棵大树那AQS就是这棵树的根。理解了AQSReentrantLock、Semaphore、CountDownLatch这些工具在你眼里就不再是孤立的API而是同一个框架的不同变体。AQS的核心就是一个volatile int类型的state变量加上一个双向链表结构的等待队列。以ReentrantLock为例lock()调用时就是通过CAS尝试把state从0改成1如果成功表示当前线程获得锁持有线程记为当前线程如果失败当前线程会被封装成一个Node节点加入等待队列尾部然后通过LockSupport.park()阻塞自己。而unlock()则把state改回0并唤醒队首等待的一个线程。这里有个计算细节值得注意为什么ReentrantLock支持可重入因为state记录的是重入次数。每次同一个线程再次lock()state就加1每次unlock()state减1只有state减到0时锁才真正释放给其他线程。这也是为什么使用ReentrantLock时必须保证lock和unlock成对出现重入几次就要解锁几次否则state永远到不了0锁就永远释放不了。公平锁和非公平锁的差异在AQS里也很直观。非公平锁一上来就直接去抢state抢不到才排队公平锁则先检查队列里有没有排在前面的线程有的话自己乖乖去队尾排队。从性能上说非公平锁的吞吐量通常高于公平锁因为减少了线程上下文切换但某些需要“先来后到”的强一致场景公平锁更合适。3.4 线程池从参数推导到生产级配置线程池这块是JUC里的重头戏也是面试几乎必问的点。很多人背了七大参数、四种拒绝策略但真正问到底层执行流程就卡壳了。这里我把整个流程画成文字版新任务进来先判断当前运行的线程数是否小于corePoolSize小于则新建核心线程执行大于等于核心线程数就把任务放入阻塞队列如果队列满了再判断当前线程数是否小于maximumPoolSize小于则创建非核心线程救急线程执行如果已经到了最大线程数则执行拒绝策略。这里面最容易被忽视的三个参数是 keepAliveTime、TimeUnit 和三个队列/线程工厂的实现。keepAliveTime指的是非核心线程空闲多久后被回收核心线程默认不回收除非设置了allowCoreThreadTimeOut(true)。TimeUnit就是keepAliveTime的时间单位。而线程工厂ThreadFactory看似简单很多人直接用的默认实现结果线上日志里线程名全是pool-1-thread-1出问题的时候根本定位不到是哪个业务线程在跑。我建议一定自定义线程工厂给线程起一个有业务含义的名字比如pay-center-pool-thread-1排查问题的时候能省不少时间。还有一个非常关键的坑线程池 阻塞队列的搭配选择。绝大多数业务场景推荐 LinkedBlockingQueue无界队列默认大小Integer.MAX_VALUE要慎用因为一旦任务大量堆积队列无限增长可能导致OOM。比较稳妥的方案是用有界队列ArrayBlockingQueue并设置合理的容量再配合CallerRunsPolicy调用者运行拒绝策略线程池满了就让提交任务的线程自己去执行任务。这样既能削峰也不会因为拒绝而丢失任务。再聊聊我们实际项目中的配置思路。一个IO密集型的业务核心线程数通常没有固定公式可套但可以按“CPU核心数 * 2”起步再通过压测逐步调整计算密集型则按“CPU核心数 1”来配置。忌讳的是拍脑袋填一个数就上线后续完全不管。我见过因为核心线程数设得太大高峰期一次性创建了上百个线程直接拖垮数据库连接池的案例。线程池参数必须结合压测、监控数据反复调优而不是“配一次用一辈子”。3.5 CompletableFuture从Future到异步编排的优雅演进异步编程是JUC中非常实用的一块内容。传统Future虽然能拿到异步结果但有个天然缺陷只能阻塞式get()等待或者轮询isDone()判断没有办法在任务完成时主动通知下一个任务继续更别说做多个任务之间的编排。CompletableFuture的出现把Java异步编程带入了“流式编排”时代。它支持回调、串行、并行、组合、异常处理等丰富的操作。举一个生产中的例子订单详情接口需要同时查用户信息、商品信息、物流信息三个查询分别耗时100ms、200ms、150ms如果用传统串行调用总耗时是450ms。用CompletableFuture的allOf()组合三个异步任务并行执行总耗时基本等于最慢那个任务的耗时也就是200ms。这个优化效果立竿见影接口性能直接翻倍。它的核心API其实没多少常用的几个记住就够了runAsync/supplyAsync无返回值/有返回值异步执行、thenApply/thenAccept/thenRun串行转换、消费、执行、thenCombine/ thenAcceptBoth两个任务合并、allOf/anyOf多个任务聚合、exceptionally/handle/whenComplete异常处理。重点提醒一个容易踩的坑使用CompletableFuture时如果没有指定自定义的线程池它会使用默认的ForkJoinPool.commonPool()这个池子被所有CompletableFuture共享一旦某个任务阻塞可能会影响其他所有异步任务。所以涉及IO操作时务必传入自定义线程池做到资源隔离。4. 常见问题与排查技巧实录4.1 死锁排查从现象到jstack命令全记录死锁是我处理最多、也最容易让新手崩溃的问题。典型现象就是程序“卡死”接口一直不返回日志停在那里CPU占用率却只有零点几明显不是计算密集型的忙等。出现这种状况第一反应应该是线程可能都在互相等锁。我处理过一个实际生产事故两个服务间互相调用服务A持有数据库连接池中的连接等待服务B返回结果服务B也在等待服务A释放某个分布式锁结果两边僵持连接池被占满大量请求排队。当时用jstack导出了线程快照日志定位到非常明显Found one Java-level deadlock下面列出了两个线程互相持有的锁以及各自正在等待的锁。整个排查时间也就十分钟比盲猜日志快得多。所以这里强烈建议每个Java开发者都要掌握三个命令的用法jps查看Java进程PID、jstack导出线程栈、jstat监控JVM内存和GC。遇到疑似死锁、线程卡死的问题第一件事就是抓现场——导出线程栈而不是急着重启服务。重启一时爽但问题根本没有被定位下次还会再犯。4.2 并发下的集合安全CopyOnWriteArrayList和ConcurrentHashMap口径解析并发场景下使用集合类是另一个高频踩坑点。ArrayList在并发写时会出现两个经典异常一个是ConcurrentModificationException并发修改异常另一个是数组越界异常HashMap扩容时并发put。很多人第一反应是给整个方法加synchronized但这往往是把性能踩在脚下而且粒度控制不当反而引发新的竞争。标准的解法是用并发容器。读多写少的场景用CopyOnWriteArrayList它的写操作会复制一份新数组、修改后替换引用读取操作不加锁天然支持并发读但写操作的代价较高不适合频繁增删。读多写多、且通过key访问的场景用ConcurrentHashMap它内部采用分段锁/ synchronized CAS 的粒度控制在大并发下性能明显优于给整个Map加锁。我自己在项目里踩过的一个坑是把HashMap直接丢给一个多线程环境用结果线上偶发性出现CPU飙高和死循环。后来排查发现JDK 1.7及之前的HashMap在并发扩容时链表的头插法可能导致环状链表get操作陷入死循环。换成ConcurrentHashMap之后问题彻底消失。所以一个经验规则是多线程环境下不要抱有任何侥幸心理老老实实用并发容器。4.3 ThreadLocal的内存泄漏风险ThreadLocal也是并发编程里一个容易被忽视但又容易出事的类。它的作用是为每个线程保存一份独立的变量副本常用于保存用户登录信息、数据库连接等上下文。但它的底层结构是一个ThreadLocalMapkey是ThreadLocal对象本身一个弱引用value则是强引用。一旦ThreadLocal对象被回收而线程还存活那么value就永远无法被访问却一直占用内存形成内存泄漏。规避的方法其实很简单用完ThreadLocal之后一定要调用remove()方法清除。尤其在使用线程池的场景下线程是复用的如果不清理下一次任务执行时还会读到上一次任务留下的旧值这比内存泄漏更隐藏——它直接导致业务数据串线。我以前在写一个定时任务时用ThreadLocal缓存用户信息明明是A用户的任务日志里却出现了B用户的ID排查了好久才发现是线程池复用了线程ThreadLocal里的值没被清理被下一个任务继续使用了。这个教训至今印象深刻。解决套路很简单ThreadLocal变量尽量声明为static final保证全局只有一份在finally代码块中手动remove();使用线程池时尤其注意任务执行完一定要清上下文。5. 高频考点与实战经验延伸5.1 JMM、可见性与指令重排序一个案例彻底讲透JMMJava Memory ModelJava内存模型是个很容易被忽略、但面试和实际调优中经常涉及的概念。简单理解它定义了一个线程对共享变量进行读写时其他线程什么时候能看到这个修改的规则。JMM规定所有变量存储在主内存中每个线程有自己的工作内存线程对变量的操作必须先把变量从主内存拷贝到自己的工作内存修改后再写回主内存。整个过程可能产生两个问题不可见和乱序。经典的并发编程案例“死循环”就能说明不可见问题public class VisibilityDemo { private static boolean flag true; public static void main(String[] args) throws InterruptedException { new Thread(() - { while (flag) { // 空循环 } System.out.println(线程结束); }).start(); Thread.sleep(100); flag false; System.out.println(flag已被设置为false); } }如果你运行这段代码大概率会出现“flag已被设置为false”打印了但线程始终没有退出。原因是主线程修改了flag但工作线程的flag副本仍然是true线程读不到主线程的修改一直死循环。把flag用volatile修饰后立即生效。指令重排序导致的经典问题则是单例模式的双重检查锁。如果不加volatile在new Singleton()的过程中指令可能被优化为“先赋引用再调用构造函数”另一个线程此时读到非null但尚未构造完成的对象直接使用导致初始化中断。volatile禁止了这个重排序保证了对象的完整性。5.2 分布式场景下的幂等控制与并发安全学完JUC很多人会把目光从单机并发拓展到分布式场景这也是必然趋势。单机的线程安全问题可以靠synchronized、Lock、并发容器解决但一到了多机部署这些本地锁就失效了因为不同JVM之间的线程无法感知彼此。此时就需要引入分布式锁常见方案有Redis分布式锁和Zookeeper分布式锁。用Redis实现分布式锁时最常用的框架是Redisson它封装了加锁、解锁、自动续期的逻辑使用起来比手写SETNXLua脚本要安全得多。一个关键点加锁时必须设置过期时间并且要使用原子操作SET key value EX seconds NX防止加锁后进程宕机导致锁永远不释放。另一个关键点锁的value要唯一比如UUID释放锁时要先判断是不是自己的锁再删除防止因为超时误删了别人的锁。我之前负责过一个库存扣减的接口在扣减前先获取分布式锁扣减后释放。压测时发现锁的粒度太粗导致性能瓶颈。后来优化为分段锁把库存拆分成多个段每个段一个锁请求根据订单号哈希取模落到不同段上并发能力提升了4倍多。这说明无论单机还是分布式锁的粒度设计都非常重要千万不要“一把锁锁全库”。5.3 从JUC看整个Java并发知识体系最后我想分享一个认知层面的总结JUC不是一门孤立的课程它是整个Java并发知识体系的中间枢纽。学JUC之前你需要懂线程的基础知识比如start和run的区别、线程状态流转、sleep和wait的区别等。学JUC的过程中你要掌握锁、CAS、AQS、并发容器、线程池、异步编程这些工具。学完JUC之后你又会自然地过渡到分布式锁、分布式事务、消息队列削峰填谷等更复杂的分布式系统话题。所以学习JUC时我建议打开一个文档随时把学到的知识点画成一张知识地图。比如从“锁”出发可以延伸出悲观锁、乐观锁、自旋锁、可重入锁、公平锁、非公平锁、死锁、分布式锁从“线程池”出发可以延伸到任务队列、拒绝策略、参数调优、监控指标、业务隔离。这样一层层发散你的并发知识才能真正“连成网”而不是“散成沙”。6. 学习资源推荐与效率提升技巧6.1 除了看视频还要做这几件事很多人学JUC的方式是刷视频从头到尾看一遍看完觉得自己都懂了一到笔试面试或者实际开发发现用不出来。原因在于视频教学是“输入型学习”而能力增长需要大量的“输出型学习”。所以光看是不够的我给自己定了三个“额外动作”第一个是每个知识点都亲自写一个Demo哪怕是一个两三行的AtomicInteger自增案例也要亲手跑一遍第二个是把Demo的每个变化都记录下来比如改成多个线程同时执行、改成不同锁、改成不用的容器看看结果有什么不同第三个是去GitHub找一些开源项目的源码来读重点看它们如何设计锁和线程池。如果要推荐学习资源除了周阳老师的《JUC并发编程》课程之外我还会看《Java并发编程的艺术》和《Java并发编程实战》这两本书。课程适合入门和建立知识框架书适合深入原理和查漏补缺。另外强烈建议多看JDK源码尤其是ReentrantLock、AQS、ConcurrentHashMap、ThreadPoolExecutor这几个类看源码是理解并发原理最快的方式。6.2 学习节奏建议与心态调整JUC的内容量其实很大如果抱着“一周学完”的心态大概率会挫败。我个人建议的节奏是第一周先掌握synchronized、Lock、CAS、volatile这些基础概念第二周集中攻克线程池和并发工具类第三周开始结合项目实战和源码阅读把知识内化。整个过程大约需要三到四周的业余时间。学习过程中不要怕“看不懂源码”和“运行结果不符合预期”。遇到奇怪的现象其实是一件好事因为这才是真正理解底层机制的契机。我当时在写生产者消费者模型时怎么也想不通为什么用if会出问题后来看了JVM源码中关于wait被唤醒的机制说明才彻底明白“虚假唤醒”的真实场景。这种自己动手发现的问题往往比课本上反复强调的安全写法记得更牢。7. 写在最后我的实践经验沉淀回头看看整个JUC学习过程我最想跟后来者说的一点是不要被并发编程的复杂度吓倒它本质上就是在解决“多个线程同时访问共享资源时如何保证数据正确且性能可控”的问题。JUC里所有工具都是围绕这个核心问题提供的不同粒度的解决方案。从我自己的项目实践来看真正能让你“从小白到不慌”的不是记住多少API而是建立这三层认知第一层知道某个场景下该用什么工具第二层知道这个工具为什么能解决问题它的底层机制是什么第三层知道它有哪些局限、在什么情况下会失效、如何通过监控和日志快速排查问题。能做到第三层基本就具备解决生产环境并发问题的能力了。最后再分享一个小技巧日常开发中多关注线上监控里的线程数、活跃线程数、阻塞队列深度、锁等待时间和线程池拒绝次数这些指标。很多并发问题其实早有征兆只是前面没有留意。学会看这些指标再配合JUC的理论知识很多潜在隐患都能提前暴露并解决。学并发永远不亏真正用起来才会发现它无处不在。
