Java 多线程深入思考

前言学多线程的真正本质绝大多数开发者学习多线程只停留在背 API、背锁的区别、背线程池参数属于表层八股。 真正的 Java 多线程体系从头到尾只解决一个核心问题在多线程并发、CPU 高速切换、指令优化重排的前提下如何保证共享数据安全、同时最大化程序执行性能。所有多线程知识点、所有并发 BUG、所有高并发优化全部围绕线程调度、线程安全、线程管理三大体系展开没有任何例外。一、进程与线程 底层本质深度辨析1. 进程操作系统资源分配的最小单位进程是程序的一次运行实例操作系统会为每一个进程独立分配资源 独立虚拟内存、独立堆空间、文件句柄、网络资源、独立 CPU 时间片。进程之间完全物理隔离一个进程崩溃不会影响其他进程。 进程通信成本极高只能通过管道、Socket、共享内存、消息队列实现开销巨大。2. 线程CPU 调度执行的最小单位线程隶属于进程一个进程至少包含一个主线程。 线程共享进程所有资源堆内存、方法区、静态变量、全局资源。 线程私有资源虚拟机栈、本地方法栈、程序计数器。正因为线程共享堆内存才出现了多线程数据竞争、线程不安全问题。3. 多线程提速的底层真相误区线程越多程序越快。 真相CPU 密集型任务计算、逻辑运算 CPU 核心数有限线程过多会触发频繁上下文切换消耗大量 CPU 资源效率大幅下降。 最优线程数 CPU 核心数。IO 密集型任务数据库、网络、文件读写 线程大量时间处于阻塞等待状态不占用 CPU。 可以设置大量线程充分利用 CPU 空闲时间。多线程提速的本质消除 CPU 空闲最大化压榨 CPU 利用率而不是并行执行。二、并发不安全三大根源JVM 和 CPU 的底层优化导致单线程完全正常的代码多线程全部不安全。1. 可见性问题CPU 缓存架构导致现代 CPU 存在多级缓存每个线程拥有独立的工作缓存。线程修改变量只会先修改自己的缓存不会立刻刷新主内存其他线程读取的依旧是旧的主内存数据造成一个线程修改值其他线程永远感知不到。 解决方案volatile、synchronized、Lock。2. 原子性问题CPU 时间片切换导致原子性一个操作要么全部执行完毕要么不执行不可中断。Java 中很多简单操作不具备原子性最典型i 分为三步从内存读取值寄存器 1写回主内存CPU 可能在三步之间任意切换线程导致数据覆盖、数据丢失。 解决方案synchronized、ReentrantLock、Atomic 原子类CAS。3. 有序性问题JVM/CPU 指令重排优化为提升执行效率JVM 和 CPU 会打乱代码执行顺序不影响单线程结果。多线程环境下重排会导致逻辑错乱经典 DCL 空指针问题。 解决方案volatile 禁止重排、锁保证串行执行。终极总结volatile解决可见性、有序性不支持原子性synchronized / Lock解决可见性、原子性、有序性全部问题三、Volatile 彻底深度解析1. 两大核心作用保证内存可见性修改立即刷新主内存其他线程实时读取最新值禁止指令重排序保障代码执行顺序和书写顺序一致2. 致命短板完全不保证原子性复合操作、自增、累加、多变量依赖操作依旧线程不安全。3. 工业级唯一使用场景只有两个线程启停标记位实时感知状态变更DCL 懒汉单例禁止指令重排避免半初始化对象溢出4. 绝对不能用的场景计数、累加、统计、共享变量更新。四、锁体系深度对比Synchronized VS ReentrantLock1. Synchronized 隐式锁底层由 JVM 原生 C 实现自动加锁、自动释放锁无需手动干预不会死锁遗漏拥有锁升级机制偏向锁 → 轻量级锁 → 重量级锁 无竞争偏向、轻微竞争自旋、高竞争阻塞性能自适应不可中断线程阻塞后无法被唤醒默认非公平锁2. ReentrantLock 显式锁JDK 纯 Java 代码实现基于 AQS手动加锁、手动解锁必须 finally 释放可中断、可超时避免死锁永久阻塞可自选公平 / 非公平模式支持Condition 精准唤醒替代粗糙的 wait/notify3. 最终选型结论JDK1.6 之后 synchronized 经过锁升级优化性能完全不输 Lock简单同步、低并发场景优先 synchronized简洁、安全高并发、细粒度控制、可中断、精准唤醒优先 ReentrantLock五、AQS 并发底层基石AQSAbstractQueuedSynchronizer是 Java 所有锁、并发工具的底层父类。 ReentrantLock、CountDownLatch、Semaphore、CyclicBarrier 全部基于 AQS。AQS 三大核心要素state 状态变量int 类型全局变量0无锁状态1已加锁大于 1锁重入次数CLH 双向阻塞队列抢锁失败的线程封装为节点入队阻塞等待唤醒。两种工作模式独占模式同一时间只有一个线程抢到锁ReentrantLock共享模式多线程可同时获取资源CountDownLatch、Semaphore六、线程通信机制深度解析1. wait / notify / notifyAll必须在 synchronized 锁内部调用wait()释放锁、阻塞等待notify ()随机唤醒一个等待线程notifyAll ()唤醒全部等待线程经典面试区别sleep waitsleep线程休眠、不释放锁、属于线程方法wait线程等待、释放锁、属于 Object 方法2. Condition 精准通信Lock 锁配套的等待唤醒机制相比 wait/notify 优势巨大可以创建多个条件队列精准唤醒指定线程不会无效唤醒、浪费 CPU3. 三大并发工具类CountDownLatch一次性计数器一个线程等待多个线程执行完毕不可复用CyclicBarrier循环栅栏多个线程互相等待全部到位后统一执行可循环复用Semaphore信号量控制最大并发数量用于限流、资源抢占七、线程池完整深度解析1. 为什么禁止手动 new Thread线程创建销毁是重量级操作频繁创建严重损耗性能无限制创建线程会导致线程数量溢出引发 OOM、CPU 满载线程分散无法统一管理、监控、调优2. 线程池五大核心参数核心线程数常驻线程不会被回收最大线程数线程池能容纳的最大线程总量空闲存活时间非核心线程空闲超时自动回收阻塞队列存放等待任务拒绝策略任务爆满后的兜底策略3. 线程池完整执行流程任务提交核心线程数未满 → 创建核心线程执行任务核心线程已满 → 任务进入阻塞队列排队队列已满 → 创建非核心线程执行任务线程数达到最大值 → 触发拒绝策略4. 四种拒绝策略AbortPolicy直接抛异常默认CallerRunsPolicy交给主线程执行DiscardOldestPolicy丢弃队列最久未执行任务DiscardPolicy直接丢弃当前新任务5. 阿里开发强制规范禁止使用 Executors 快捷创建线程池原因FixedThreadPool、SingleThreadPool无界队列任务堆积 OOMCachedThreadPool无上限线程无限创建线程 OOM 生产必须手动 new ThreadPoolExecutor自定义参数。八、Java 线程安全完整解决方案体系从最优到最差性能逐级递减1. 无状态设计最优类中无成员变量、无共享变量只有局部变量。 Controller、Service、工具类天然线程安全。2. 不可变设计final 修饰、不可变类String、Integer数据一旦赋值不可修改彻底杜绝竞争。3. 局部变量方法内定义的变量存在线程私有栈空间线程隔离绝对安全。4. 线程隔离ThreadLocal不为共享变量加锁直接给每个线程分配独立副本彻底规避竞争。 用于存储用户上下文、登录信息、事务 ID。5. 并发容器JUC 自带线程安全容器 ConcurrentHashMap、CopyOnWriteArrayList、CopyOnWriteArraySet6. 锁机制synchronized、ReentrantLock牺牲性能换取数据一致性。九、ThreadLocal 深度坑点解析核心定位ThreadLocal 不解决并发安全它直接规避并发竞争。通过线程私有数据实现数据隔离。致命坑点内存泄漏ThreadLocal 底层keyThreadLocal 对象弱引用value存储的数据强引用当 ThreadLocal 对象被回收后key 为 null 但线程存活时value 强引用永远无法释放造成内存泄漏。强制规范使用完 ThreadLocal必须手动 remove ()清空副本数据。十、高频面试灵魂问答1. 多线程不安全的根本原因CPU 缓存可见性、指令重排有序性、操作不原子性三大底层问题共同导致。2. synchronized 和 volatile 核心区别volatile 仅解决可见性、有序性不保证原子性 synchronized 独占锁保证原子性、可见性、有序性全部特性。3. sleep 和 wait 核心区别sleep 不释放锁、不释放资源 wait 主动释放锁进入等待队列。4. 为什么生产禁止 Executors封装参数存在严重缺陷无界队列、无限线程会引发 OOM生产不可控。5. ConcurrentHashMap 如何保证线程安全JDK1.8数组 链表 红黑树结合CAS synchronized 锁定桶节点细粒度锁高并发性能极强。6. 并发最高性能方案是什么无共享、无状态、数据隔离不加锁的并发永远最快。十一、终极多线程思维总结多线程不是为了快是为了最大化利用 CPU 资源所有并发 BUG根源全部来自共享变量的多线程竞争解决并发的优先级无状态 数据隔离 不可变 加锁锁是性能损耗的兜底方案绝对不是首选方案工程开发中线程池是唯一合法的线程创建方式多线程编程的核心尽量规避竞争迫不得已才控制竞争