JUC并发编程核心解析：线程安全、锁机制与并发容器实战

一说到多线程绕不开的就是JUC。JUC是java.util.concurrent的缩写说白了就是Java官方提供的一套专门解决并发问题的工具包。很多人把它当成面试里的“八股文”考点背了一堆概念什么AQS、CAS、ConcurrentHashMap结果一到线上出了并发问题还是两眼一抹黑。这篇内容我会站在实操角度把JUC里跟“线程安全”强相关的核心机制、底层原理、常见坑点全部拆开揉碎讲清楚。不管你是刚接触Java并发的初学者还是写过一两年业务代码但从来没系统梳理过并发安全的开发这篇都比较适合。你能搞清楚三件事多线程到底为什么会不安全JUC是怎么解决这些问题的以及真正遇到线程安全问题时该怎么定位和修复。全文不堆砌术语尽量用大白话把原理讲透最后附上我实际排查问题时的经验。1. 先从“为什么”说起线程安全问题的根源在哪里很多初学者有个误区觉得线程安全就是“加锁”只要加了锁就万事大吉。实际上锁只是解决手段你得先明白问题是怎么产生的才能在合适的场景选对合适的工具。1.1 三个罪魁祸首原子性、可见性、有序性线程安全问题归根结底就是三个根源其他所有概念、工具、面试题都是围绕这三个点展开的。原子性这个词听起来高大上其实就是一个操作不能被中途打断。比如经典的i看起来是一行代码但编译成字节码之后是三条指令先读取 i 的值然后加1最后写回去。假设线程A正在执行过程中线程B也来执行两个线程同时读写同一个变量最后的结果就会丢失更新。这就是没有原子性导致的。可见性指的是一个线程修改了共享变量另一个线程能不能立刻看到。由于CPU缓存和JIT编译优化的存在线程A改了变量数据可能还停留在CPU缓存或者寄存器里线程B读到的还是旧值。这就是典型的内存不可见问题。有序性是为了提高性能编译器和CPU会对指令进行重排。在单线程下重排不影响最终结果但在多线程下重排可能导致一个线程的“代码顺序”在另一个线程眼里是乱序的。经典的例子就是单例模式的“双重检查锁”如果没有特殊的指令屏障可能创建出半个对象。1.2 一句话理解JUC它不是“银弹”而是一整套解决方案很多资料把JUC吹得天花乱坠好像用了JUC就彻底安全了。我实际用下来最大的体会是JUC不是银弹它是一整套针对不同并发场景的解决方案。你面对的并发场景无非就几类多个线程抢同一个资源锁多个线程各自独立干活最后汇总CountDownLatch、CyclicBarrier多个线程共享一个容器并发集合多个线程排队执行任务线程池、BlockingQueue。JUC把这几类场景都封装成了现成的工具让你不用每次从零写锁、写队列、写线程池。但前提是你要分得清场景知道什么情况下该用AQS什么情况下用CAS什么情况下老老实实用synchronized。后面我会逐个讲清楚。2. 核心细节解析JUC的几个扛把子组件JUC这个包的内容非常多但真正在业务代码里高频出现、面试也经常问的就是我下面要讲的这五个方向。理解了它们JUC的安全问题基本就掌握一半了。2.1 synchronized到底经历了什么从重量级锁到锁升级synchronized是Java最古老的同步手段JUC里的Lock很多思路其实是它的“改良版”但synchronized自身也一直在进化。在JDK 1.6之前synchronized确实是个“重量级锁”因为它本质上是依赖操作系统的互斥量来实现的线程一旦被阻塞就要从用户态切换到内核态这个切换开销非常昂贵。但JDK 1.6之后官方对synchronized做了大量优化引入了偏向锁、轻量级锁、重量级锁的锁升级机制。我在实际工作中观察很多资深开发仍然坚持用synchronized因为它够简单而且大部分业务场景下的锁竞争并没有那么激烈锁升级机制已经能够应付。你用Lock确实能在高竞争下获得更好的性能但代价是要手动释放锁写不好就容易死锁。这里有个需要特别注意的坑synchronized在异常发生时会自动释放锁而Lock不会。所以你用Lock的时候一定要在finally块里执行unlock这一步我见过太多人忘了写导致线上通配符全部卡死。2.2 显式锁Lock可中断、可超时、可公平Lock是JUC里最核心的锁接口最常用的实现是ReentrantLock。它比synchronized强在三个地方可中断、可超时、可公平。先说可中断。synchronized一旦进入阻塞你就没法打断它只能等持锁线程自己释放。但ReentrantLock提供了lockInterruptibly()方法当线程在等待锁的过程中被interrupt()打断时会立刻抛InterruptedException。这个能力在处理某些故障场景的时候非常有用比如一个线程卡住锁不放手至少你有办法把它“叫醒”。再说可超时。tryLock(timeout, TimeUnit)可以在指定时间内获取锁拿不到就直接放弃返回false。这比无限期等下去要安全得多。最后说可公平。synchronized是非公平锁新来的线程可以和排队的线程抢锁这可能导致饥饿。ReentrantLock可以设置公平性参数公平锁会让先等待的线程先拿到锁。但公平锁开销更大吞吐量更低我实测下来业务上不太建议你开公平锁除非你的业务对公平性有硬性要求。注意Lock和synchronized二选一即可不要同一个方法里混用。混用的后果是锁互不相认根本起不到互斥效果。2.3 volatile轻量级的“可见性”方案volatile可能是被误解最多的关键字。很多人认为volatile能保证原子性这完全是错的。volatile的两个核心能力是保证可见性、禁止指令重排。它适用于一个线程写、多个线程读的场景。比如你写一个后台线程循环执行任务开关变量用volatile修饰主线程修改这个变量来停止后台线程这个场景就是volatile的经典用法。但在i这种复合操作下volatile是没用的。因为它管不了“读-改-写”这个过程的原子性。你要是真的用volatile去修饰计数器并发的线程照样会丢更新。所以记住一条铁律volatile只能解决可见性和有序性不能解决原子性。2.4 CAS与AQS无锁方案和同步器的基石CAS全称是Compare And Swap中文叫比较并交换。这是一个CPU级别的原子指令JUC里很多并发工具都在底层用它来实现线程安全。CAS的原理非常朴素它有三个操作数内存值V、旧的预期值A、要修改的新值B。只有内存值等于预期值A的时候才把V改成B否则就什么都不做或者重新读取再重试。这个过程是原子的不会被线程切换打断。CAS最大的优点是无锁线程不用阻塞所以没有上下文切换开销。但CAS也有两个很麻烦的缺点一是ABA问题就是变量从A变成B再变回ACAS会认为它没有被修改过二是自旋消耗CPU高并发下CAS失败率很高线程会一直循环重试白白烧掉CPU。AQSAbstractQueuedSynchronizer则是JUC里所有锁和同步器ReentrantLock、CountDownLatch、Semaphore等的底层框架。它的核心思想是维护一个volatile的state变量和一个FIFO的CLH线程等待队列。线程获取锁就是通过CAS把state从0改成1获取不到就进入队列挂起。理解了state的状态流转你就理解了JUC锁的一半底层原理。3. 实操过程与核心环节实现写一个安全的并发计数器光讲概念不过瘾我直接带大家实操一个经典案例多线程并发累加一个计数器的值。这是考验线程安全的基础也是面试时经常让你手写的题。我先强调一点实际开发中几乎不会有人真的手写计数器但这个案例把“不安全→安全”的演进过程完整地展示出来了理解了它你就知道了线程安全到底是围绕什么展开的。3.1 第一步复现不安全场景先用最简单的代码模拟100个线程每个线程对共享变量执行1万次累加。代码如下public class CounterDemo { private int count 0; public void increment() { count; } public int getCount() { return count; } public static void main(String[] args) throws InterruptedException { CounterDemo demo new CounterDemo(); CountDownLatch latch new CountDownLatch(100); for (int i 0; i 100; i) { new Thread(() - { for (int j 0; j 10000; j) { demo.increment(); } latch.countDown(); }).start(); } latch.await(); System.out.println(最终结果: demo.getCount()); } }正常情况下你期望的结果是100万而且代码本身没有语法错误。我实测运行多次结果经常是92万、96万、98万不等每次都不一样但很少能跑到100万。原理我前面说过了就是count不是原子操作多个线程同时读到了旧值然后写回旧值1互相覆盖。3.2 第二步尝试三种修复方案第一种最简单直接把synchronized加到increment方法上public synchronized void increment() { count; }这样每次只有一个线程能进入方法结果必然变成100万。这个方案我推荐给刚接触并发的同学简单、可靠、不容易出错。第二种是用ReentrantLockprivate final Lock lock new ReentrantLock(); public void increment() { lock.lock(); try { count; } finally { lock.unlock(); } }注意看我在unlock的外面包了finally这是铁律。不管业务逻辑有没有抛异常锁都必须释放否则其他线程会永久卡死。第三种是用AtomicInteger走CAS无锁路线private AtomicInteger count new AtomicInteger(); public void increment() { count.incrementAndGet(); }AtomicInteger就相当于把int包装了一层内部用CAS保证自增操作的原子性。这种方案性能最好而且代码很简洁。注意普通业务代码里如果只是计数器累加推荐直接用AtomicInteger不需要为了这点事上锁。锁的重度大于CASCAS的重度大于无锁。3.3 第三步引入并发容器处理更复杂的场景计数器只是最基础的场景更常见的需求是多个线程并发读写同一个容器。先看一个反面教材很多同学喜欢在单线程环境下用HashMap然后到了多线程环境里直接把HashMap换成HashTable以此“保证线程安全”。HashTable确实是线程安全的因为它的每个方法都上了synchronized但这意味着所有线程串行化读和写并发越高性能越差。更好的方案是ConcurrentHashMap。它在JDK 1.8之后放弃了分段锁的旧设计改成了CAS synchronized只对单个桶位加锁读操作完全不加锁所以并发读性能非常好。MapString, Integer counterMap new ConcurrentHashMap(); // 多线程下安全地累加某个key的值 counterMap.compute(orderCount, (key, value) - value null ? 1 : value 1);注意这个误区ConcurrentHashMap只保证单个方法的线程安全不保证复合操作的原子性。比如“先get判断再put”这种逻辑如果不在外面加锁照样会出问题。ConcurrentHashMap提供了compute和merge这类原子方法来解决这种场景建议优先使用。3.4 线程池多线程场景下的“资源池化”实际业务里你不会无脑new Thread而是用线程池来管理线程。线程池的好处是复用线程、控制并发数、避免频繁创建销毁线程带来的开销。JUC里核心的线程池实现是ThreadPoolExecutor它有七个参数我用自己的话翻译一下corePoolSize核心线程数即使空闲也会保留的线程数量。maximumPoolSize最大线程数超过这个数字的任务必须排队或丢弃。keepAliveTime非核心线程空闲多久后被回收。unit空闲时间单位。workQueue任务队列当线程数达到核心线程数时新任务会进入队列。threadFactory线程工厂给线程起名字方便排查问题。handler拒绝策略队列和最大线程数都满了之后怎么处理新任务。我踩过的坑是很多人喜欢用Executors.newFixedThreadPool去创建线程池这种方式虽然方便但它的队列是无界的LinkedBlockingQueue意味着任务可以无限排队极端情况下会造成OOM内存溢出。阿里规约里也建议不要用Executors提供的快捷方法而是直接new ThreadPoolExecutor把队列长度、拒绝策略都显式配置这样更可控。举个例子我习惯用有界队列加CallerRunsPolicy拒绝策略ThreadPoolExecutor executor new ThreadPoolExecutor( 4, // 核心线程数 8, // 最大线程数 60, TimeUnit.SECONDS, // 空闲回收时间 new ArrayBlockingQueue(100), // 有界队列最多排100个任务 new ThreadFactoryBuilder().setNameFormat(biz-thread-%d).build(), new ThreadPoolExecutor.CallerRunsPolicy() );CallerRunsPolicy的意思是如果任务满了就让提交任务的线程自己来执行这个任务。这比直接丢弃任务要安全得多至少保证了任务不会丢失并且天然带了流量降级的效果。4. 常见问题与排查技巧实录再扎实的理论到了线上也可能出问题。我把实际开发中遇到的典型多线程安全问题和排查手段整理成了速查内容遇到类似情况可以直接参考。4.1 问题速查表问题现象可能原因排查方向解决思路计数结果比预期小共享变量自增操作不具备原子性检查是否使用Atomic类或加锁改用AtomicInteger或加锁线程A改了数据线程B看不到变量没有可见性保证检查是否被CPU缓存所致加volatile或使用锁程序卡死请求无响应死锁或锁未释放抓线程快照定位锁顺序检查unlock队列任务积压内存飙升无界队列导致OOM查看线程池队列大小改用有界队列设置拒绝策略数据库重复插入判断和插入非原子操作查看代码是否先查再插加分布式锁或唯一索引兜底4.2 死锁排查实战我遇到过一次死锁事故场景是两个线程各自持有一把锁又想获取对方的锁。表面上看代码没什么毛病但线上跑了一段时间就开始卡死。排查死锁我推荐直接抓线程快照。先用jps -l找到Java进程ID然后执行jstack pidJVM会把所有线程的状态打印出来。如果你看到Found one Java-level deadlock这段日志后面跟着两个线程互相等待的信息那基本就是死锁实锤了。jstack输出的信息里还会很清楚地告诉你Thread-0持有lockA等lockBThread-1持有lockB等lockA。看到这个顺着代码去找抢锁的顺序把两把锁的获取顺序调成一致就能解决。4.3 线上问题定位思路还有一个高频问题线上系统变慢但CPU使用率居高不下。这种我一般分两步查。第一步用top -H -p pid查到CPU占用高的线程ID把十进制的线程ID转成十六进制然后用jstack pid | grep -A 20 十六进制线程ID看这个线程在跑什么代码。如果发现大量线程卡在同一个锁的阻塞队列里那就是锁竞争太激烈可以考虑用读写锁等更细粒度的锁。第二步是看线程池指标。线程池的活跃线程数、队列积压量都是判断系统健康状况的关键指标。我习惯在代码里对线程池做监控埋点定期打印活跃线程数、队列长度、已完成任务数这样出了问题能快速定位是哪个线程池扛不住流量了。4.4 面试中怎么答多线程安全问题既然这些关键词里反复出现“JUC面试题”我就多聊一句面试的角度。面试官问多线程安全问题本质上是在考察两件事你懂不懂底层原理你有没有真实踩坑经验。懂原理要能顺着“原子性、可见性、有序性”往下讲能说出来volatile不能保证原子性CAS有ABA问题AQS是用volatile 队列实现的。有经验要能用具体的案例说明你遇到过什么问题、怎么定位的、为什么选择某个方案。干巴巴背概念是没有区分度的但如果你能把你用jstack查死锁的经历讲清楚同时把ConcurrentHashMap和HashTable的性能差异说透面试官基本就能判断你有真东西。最后分享一点我的个人体会写了这么多其实很核心的一句话就是线程安全不是靠某一个工具一劳永逸的而是要建立一套判断的思路。我现在的习惯是写任何一段多线程代码前先问自己三个问题共享变量是什么哪些操作涉及读改写多个线程之间是竞争关系还是协作关系。想清楚这三个问题再决定是加锁、用CAS还是用并发容器基本不会跑偏。平时我也建议多跟线上的数据打交道生产环境遇到一次诡异的并发问题比看十篇理论文章都管用。你不需要一开始就搞懂JUC里所有类的源码但至少把synchronized、ReentrantLock、volatile、ConcurrentHashMap、ThreadPoolExecutor这五个常用的东西彻底吃透。它们覆盖了绝大多数业务并发场景搞定了这里你再去看其他并发组件都会显得轻松很多。