1. 从“并发”到“线程”为什么我们需要管理它们在软件开发尤其是后端服务和高性能计算领域“并发”是一个绕不开的词。你可能听过很多次说它能提升程序效率让CPU不再闲着。但真正上手写代码时很多人会直接掉进一个坑里以为开了线程就等于实现了并发结果程序不仅没变快反而更慢了甚至出现了各种诡异的、难以复现的Bug。这背后的核心往往不是“并发”这个概念本身有问题而是“线程管理”没做好。线程是操作系统能够进行运算调度的最小单位。你可以把它想象成一条流水线上的工人。一个单线程程序就像整个工厂只有一位老师傅他得从头到尾包办所有工序虽然专注但效率上限很明显。多线程程序则是雇佣了一组工人他们可以同时处理不同的任务或者协作处理同一个任务的不同部分理论上能极大提升产能。然而管理工人远比管理一台机器复杂。线程管理就是这套“工人管理系统”。它要解决的核心问题包括招多少工人合适线程创建活来了派给谁任务调度工人之间怎么协作又不打架线程同步活干完了工人是回家还是待命线程生命周期工人闹矛盾了怎么调解死锁、竞态条件这套系统如果设计得不好轻则效率低下线程频繁创建销毁、大量时间花在协调上重则生产停滞死锁、产出废品数据不一致甚至整个车间崩溃程序异常退出。我见过太多项目初期为了快速实现功能直接new Thread()满天飞每个请求都拉一个新线程来处理。在开发机和测试环境请求量小看着挺美。一上生产流量稍微起来线程数量爆炸式增长上下文切换开销吞噬了所有CPU资源内存也被大量线程栈占满服务直接雪崩。这时候再回头补课成本就高多了。所以理解并做好线程管理不是高级优化而是开发现代稳健、高性能应用的基本功。2. 线程池从“即用即弃”到“资源复用”的核心跃迁当你意识到不能无节制地创建线程时线程池ThreadPool就是你第一个需要掌握的工具。它背后的思想是一种典型的“池化”资源管理策略类似于数据库连接池。其核心价值在于复用通过预先创建或按需维持一定数量的线程避免频繁创建和销毁线程带来的巨大开销。2.1 线程池的核心构造参数与工作原理一个标准的线程池以Java的ThreadPoolExecutor为例主要由以下几个核心参数定义理解它们就理解了线程池的行为核心线程数 (corePoolSize)池中长期维持的线程数量即使它们处于空闲状态。除非设置了allowCoreThreadTimeOut否则这些线程不会被回收。这相当于公司的“正式编制”员工。最大线程数 (maximumPoolSize)池中允许存在的最大线程数量。当任务队列满了并且当前线程数小于最大线程数时池会创建新的线程来处理任务。这是“编制”“临时工”的总上限。任务队列 (workQueue)用于存放等待执行任务的阻塞队列。这是协调任务提交速度与线程处理速度的“缓冲区”。常见的队列有无界队列 (如LinkedBlockingQueue)队列可以无限增长。这种情况下maximumPoolSize参数会失效因为新任务永远可以进入队列排队不会触发创建新线程。风险是可能耗尽内存。有界队列 (如ArrayBlockingQueue)队列有固定容量。这是最常用的模式也是线程池策略发挥作用的关键。同步移交队列 (如SynchronousQueue)它不存储元素每个插入操作必须等待另一个线程的移除操作。这意味着如果没有空闲线程新任务提交会失败除非此时还能创建新线程。这要求池有足够大的maximumPoolSize或高效的拒绝策略。线程空闲存活时间 (keepAliveTime)当线程数超过核心线程数时多余的空闲线程在等待新任务时的最长存活时间。超过这个时间这些“临时工”线程将被终止回收。拒绝策略 (RejectedExecutionHandler)当任务队列已满且线程数已达到最大值时对新提交任务的处理策略。常见策略有AbortPolicy默认直接抛出RejectedExecutionException异常。CallerRunsPolicy让调用者线程比如提交任务的HTTP请求线程自己执行这个任务。这是一种简单的反馈机制能减缓任务提交速度。DiscardPolicy默默丢弃这个任务不抛异常。DiscardOldestPolicy丢弃队列中最老的一个任务然后尝试重新提交当前任务。线程池的工作流程可以概括为以下步骤这个流程决定了任务被执行的顺序和方式提交一个新任务。如果当前运行的线程数小于corePoolSize则立即创建新线程运行此任务即使其他核心线程空闲。如果当前运行线程数已达到或超过corePoolSize则将任务放入workQueue排队。如果队列已满且当前线程数小于maximumPoolSize则创建新的“临时”线程来处理任务。如果队列已满且当前线程数已达到maximumPoolSize则根据RejectedExecutionHandler策略拒绝该任务。2.2 参数配置的实战经验与避坑指南配置线程池不是玄学需要结合具体业务场景。这里有一些踩过坑才得出的经验CPU密集型 vs IO密集型这是决定线程数量的首要因素。CPU密集型如视频编码、复杂计算线程数不宜过多通常设置为CPU核心数 1左右。过多的线程会导致频繁的上下文切换反而降低性能。Runtime.getRuntime().availableProcessors()可以获取CPU核心数。IO密集型如网络请求、数据库查询线程可以设置得多一些因为线程大部分时间在等待IOCPU是空闲的。一个经验公式是CPU核心数 * (1 平均等待时间 / 平均计算时间)。在Web服务中这个值可能在几十到几百之间需要通过压测来找到最佳点。队列选择是门艺术不要使用无界队列这是生产环境的一个大忌。它会导致任务无限堆积最终内存溢出OOM。推荐使用有界队列如ArrayBlockingQueue并结合合适的拒绝策略。拒绝策略的选用默认的AbortPolicy在关键业务中可能过于粗暴直接抛异常会影响用户体验。CallerRunsPolicy是一个很好的“降级”选择它能让提交任务的线程也参与工作自然地对上游产生背压Back Pressure提醒上游系统“我这边忙不过来了你慢点发”。对于非核心业务DiscardPolicy或DiscardOldestPolicy也可以考虑但要配合完善的监控和日志知道有任务被丢弃了。给线程起个好名字通过自定义ThreadFactory给线程设置一个有意义的名字如businessName-thread-pool-1。这样在查日志、用jstack分析线程堆栈时你能一眼看出这个线程是干什么的极大提升排查效率。监控是必须的你需要知道线程池的运行状态当前线程数、活跃线程数、历史最大线程数、队列积压任务数、完成任务总数等。Spring Boot的Actuator、或通过ThreadPoolExecutor的getXXX()方法自行采集指标并暴露给监控系统如Prometheus都是必要的操作。3. 线程同步当多个“工人”需要操作同一件“产品”线程池解决了“工人”资源管理的问题但当多个线程工人需要访问或修改同一个共享资源产品时新的问题出现了竞态条件。比如一个经典的银行转账问题账户A有100元账户B有0元。线程1要从A转100给B线程2要从A转50给C。如果两个线程同时读取A的余额都是100然后各自计算并写回最终A的余额可能是-50如果线程2后写入或0如果线程1后写入这显然都是错误的。3.1 锁机制从synchronized到ReentrantLock解决竞态条件的关键是互斥即保证同一时间只有一个线程能进入临界区操作共享资源的代码段。最基础的工具是Java内置的synchronized关键字。synchronized的三种用法修饰实例方法锁是当前对象实例 (this)。修饰静态方法锁是当前类的Class对象。修饰代码块需指定一个对象作为锁。synchronized简单易用JVM会负责加锁和释放锁但它的能力相对单一。java.util.concurrent.locks.ReentrantLock提供了更灵活的锁操作。ReentrantLockvssynchronized核心对比特性synchronizedReentrantLock实现层面JVM原生语法字节码层面实现JDK API层面实现Java代码锁的获取隐式获取和释放进入同步块自动获取退出正常或异常自动释放显式调用lock()和unlock()必须在finally块中释放可中断等待锁时不可中断提供lockInterruptibly()方法可响应中断公平性非公平锁默认可选择公平锁或非公平锁构造参数指定条件变量通过wait(),notify(),notifyAll()与对象监视器配合提供Condition类可以创建多个条件队列实现更精确的线程等待/唤醒尝试获取锁不支持支持tryLock()可设置超时时间避免死等实战选择建议优先考虑synchronized。在大多数情况下它的性能已经足够好尤其是JDK不断优化后且代码简洁不易出错自动释放。当需要可中断的锁获取、超时获取锁、公平锁或者需要多个条件等待队列比如生产者-消费者模型中的“非空”和“非满”两个条件时再使用ReentrantLock。3.2 原子类与volatile轻量级同步武器对于简单的共享变量操作如计数、状态标志使用重量级的锁synchronized或ReentrantLock开销太大。这时java.util.concurrent.atomic包下的原子类是你的首选。原子类如AtomicInteger利用CPU的CASCompare-And-Swap指令实现了无锁化的线程安全更新。它的操作如incrementAndGet(),compareAndSet()是原子的性能远高于锁。它适用于计数器、序列号生成等场景。volatile关键字确保变量的可见性和禁止指令重排序但不保证原子性。可见性当一个线程修改了volatile变量的值新值会立即被刷新到主内存并使得其他线程中该变量的缓存行失效从而强制其他线程读取主内存中的新值。禁止重排序防止JVM和处理器为了优化性能而对指令进行重排序这在实现“双重检查锁定”单例模式时至关重要。注意一个常见的误解是volatile能保证i的原子性。这是错的。i是“读-改-写”三个操作volatile只能保证每次读到的i是最新值但两个线程可能同时读到相同的值然后各自加1写回导致最终结果少加了一次。对于复合操作仍需使用synchronized或原子类。3.3 死锁如何预防、诊断与解除死锁是线程同步中最棘手的问题之一。它发生在两个或多个线程互相等待对方持有的锁导致所有线程都无法继续执行。产生死锁需要四个必要条件缺一不可互斥资源一次只能被一个线程使用。占有且等待线程已持有至少一个资源又在等待其他资源。不可抢占资源只能由持有它的线程主动释放。循环等待存在一个线程等待链每个线程都在等待下一个线程所占有的资源。预防死锁就是破坏上述条件之一破坏“占有且等待”一次性申请所有所需资源AllocateAll。这在实践中往往很难做到容易降低并发度。破坏“不可抢占”使用可响应中断的锁如ReentrantLock.lockInterruptibly()或者设置锁获取超时tryLock(timeout)。这是更实用的方法。破坏“循环等待”对资源进行排序要求所有线程都按相同的顺序申请锁。这是最常用且有效的预防策略。例如规定所有线程必须先申请锁A再申请锁B。这样就不可能发生“线程1持有A等B线程2持有B等A”的循环。诊断死锁当应用卡住怀疑死锁时最直接的工具是jstack。使用jps命令找到Java进程的PID。运行jstack -l pid。在输出的最后jstack工具会明确报告是否发现死锁并打印出相关线程的堆栈信息清晰地显示出每个线程持有什么锁在等待什么锁。4. 线程间协作不仅仅是互斥更是有序配合有些场景下线程之间不是简单的竞争关系而是有明确的先后顺序或条件依赖。比如生产者-消费者模型生产者线程生产数据放入缓冲区消费者线程从缓冲区取出数据消费。当缓冲区空时消费者必须等待当缓冲区满时生产者必须等待。这就需要线程间的协作机制。4.1wait()/notify()机制与Condition接口这是最基础的线程协作API与synchronized配合使用。object.wait()调用此方法的线程会释放持有的对象锁并进入该对象的等待队列直到被其他线程唤醒。object.notify()随机唤醒一个在该对象上等待的线程。object.notifyAll()唤醒所有在该对象上等待的线程。使用它们时必须注意必须在synchronized同步块或方法内调用。wait()调用应放在循环中以防止“虚假唤醒”即线程在没有被notify的情况下被唤醒。标准范式是synchronized (lock) { while (!condition) { // 使用while而不是if lock.wait(); } // ... 执行条件满足后的操作 }ReentrantLock提供的Condition接口将对象监视器的wait/notify机制进行了抽象和增强。一个Lock可以创建多个Condition对象实现更精细的等待/通知。例如在生产者-消费者模型中可以创建两个ConditionnotEmpty和notFull。当缓冲区空时消费者在notEmpty上等待生产者生产后唤醒notEmpty上的线程。当缓冲区满时生产者在notFull上等待消费者消费后唤醒notFull上的线程。这样逻辑更清晰效率也更高。4.2 高级同步工具类CountDownLatch,CyclicBarrier,SemaphoreJUC包提供了一系列更高级的“瑞士军刀”可以简化复杂的同步逻辑。CountDownLatch倒计时闩锁允许一个或多个线程等待其他一组线程完成操作。构造时设定一个计数。await()方法会阻塞直到countDown()被调用足够次数计数减至0。它是一次性的计数归零后无法重置。典型场景主线程等待所有子线程初始化完成后再执行模拟并发测试让所有线程同时开始。// 主线程等待5个线程完成任务 CountDownLatch latch new CountDownLatch(5); for (int i 0; i 5; i) { new Thread(() - { // 执行任务 latch.countDown(); }).start(); } latch.await(); // 主线程在此等待 System.out.println(所有任务完成);CyclicBarrier循环屏障让一组线程互相等待直到所有线程都到达一个公共屏障点然后屏障打开所有线程继续执行并且屏障可以重置后重复使用。构造时指定参与线程数和一个可选的Runnable屏障动作在所有线程到达后由最后一个进入屏障的线程执行。典型场景多阶段计算每个阶段必须所有线程都完成才能进入下一阶段。// 3个线程在屏障处集合然后一起继续 CyclicBarrier barrier new CyclicBarrier(3, () - System.out.println(所有线程已就位)); for (int i 0; i 3; i) { new Thread(() - { // 第一阶段工作 barrier.await(); // 第二阶段工作所有线程都完成第一阶段后才开始 }).start(); }Semaphore信号量用来控制同时访问特定资源的线程数量。它维护了一组“许可证”。线程通过acquire()获取许可证如果无证可用则阻塞通过release()释放许可证。可以用于流量控制如数据库连接池限流。// 只允许3个线程同时访问某资源 Semaphore semaphore new Semaphore(3); new Thread(() - { semaphore.acquire(); try { // 访问受保护的资源 } finally { semaphore.release(); // 务必在finally中释放 } }).start();5. 线程本地存储避免共享的“独享空间”有些数据你希望每个线程都有一份独立的副本互不干扰。最典型的例子是数据库连接、用户会话Session信息、或者一些格式化的工具类如SimpleDateFormat它不是线程安全的。如果把这些对象作为共享变量就需要加锁性能差且容易出错。ThreadLocal正是为解决这个问题而生。它为每个使用该变量的线程都提供一个独立的变量副本每个线程只能访问和修改自己的副本从而避免了线程安全问题。它的原理是在Thread类内部维护了一个ThreadLocalMap以ThreadLocal实例自身作为键以线程的副本数据作为值。使用示例与注意事项private static final ThreadLocalSimpleDateFormat dateFormatHolder ThreadLocal.withInitial(() - new SimpleDateFormat(yyyy-MM-dd HH:mm:ss)); public String formatDate(Date date) { return dateFormatHolder.get().format(date); // 每个线程获取自己独立的SimpleDateFormat实例 }ThreadLocal的内存泄漏风险与正确清理这是使用ThreadLocal最大的坑。由于ThreadLocalMap的键是弱引用WeakReference而值是强引用当ThreadLocal实例被回收外部强引用消失后Map中的键会变成null但值对象依然被线程的强引用链持有导致无法被回收造成内存泄漏尤其是在使用线程池线程长期存活的场景下。正确做法将ThreadLocal变量声明为static final延长其生命周期避免键被回收。每次使用完后必须调用remove()方法清理当前线程的副本值这是最重要的习惯。try { // 使用 ThreadLocal String value threadLocal.get(); // ... 业务逻辑 } finally { threadLocal.remove(); // 务必清理 }6. 现代并发编程模型超越原生线程随着业务复杂度的提升直接操作底层线程和锁的模型显得越来越笨重。响应式编程、协程等更高层次的抽象模型开始流行它们的目标是让开发者更关注业务逻辑而非并发细节。Future与CompletableFuture这是Java对异步编程的初步支持。Future代表一个异步计算的结果但获取结果get()是阻塞的。CompletableFuture在Java 8中被引入它实现了Future和CompletionStage接口提供了强大的异步编程和流式组合能力。你可以方便地将多个异步任务组合起来实现链式调用、聚合结果、异常处理等大大简化了异步代码的编写。Project Loom与虚拟线程这是Java并发领域最令人兴奋的进展之一。传统操作系统线程平台线程重量级创建和切换成本高限制了高并发应用的性能。Loom项目引入了虚拟线程它们是JVM管理的轻量级线程与平台线程是M:N的映射关系。虚拟线程的创建和切换开销极低你可以像使用普通线程一样为每个任务如一个HTTP请求分配一个虚拟线程而无需担心资源耗尽。这本质上将“线程”从一种稀缺的系统资源变成了一种近乎无限的、廉价的编程抽象有望从根本上简化高并发程序的编写。虽然截至我撰写本文时Loom还未正式发布但其预览版已展现出巨大潜力是每个Java开发者需要关注的方向。线程管理是一个从微观锁、原子变量到宏观线程池、并发模型的完整体系。它没有银弹最佳实践总是依赖于具体的业务场景、负载特性和性能要求。扎实地理解这些基础概念和工具建立清晰的并发思维模型再辅以严谨的测试和监控才能构建出真正高效、稳定、可维护的并发程序。从我个人的经验来看在项目初期就确立好线程使用的规范比如统一使用线程池、定义好锁的申请顺序远比在后期性能瓶颈或诡异Bug出现时再去救火要有效得多。
1. 从“并发”到“线程”为什么我们需要管理它们在软件开发尤其是后端服务和高性能计算领域“并发”是一个绕不开的词。你可能听过很多次说它能提升程序效率让CPU不再闲着。但真正上手写代码时很多人会直接掉进一个坑里以为开了线程就等于实现了并发结果程序不仅没变快反而更慢了甚至出现了各种诡异的、难以复现的Bug。这背后的核心往往不是“并发”这个概念本身有问题而是“线程管理”没做好。线程是操作系统能够进行运算调度的最小单位。你可以把它想象成一条流水线上的工人。一个单线程程序就像整个工厂只有一位老师傅他得从头到尾包办所有工序虽然专注但效率上限很明显。多线程程序则是雇佣了一组工人他们可以同时处理不同的任务或者协作处理同一个任务的不同部分理论上能极大提升产能。然而管理工人远比管理一台机器复杂。线程管理就是这套“工人管理系统”。它要解决的核心问题包括招多少工人合适线程创建活来了派给谁任务调度工人之间怎么协作又不打架线程同步活干完了工人是回家还是待命线程生命周期工人闹矛盾了怎么调解死锁、竞态条件这套系统如果设计得不好轻则效率低下线程频繁创建销毁、大量时间花在协调上重则生产停滞死锁、产出废品数据不一致甚至整个车间崩溃程序异常退出。我见过太多项目初期为了快速实现功能直接new Thread()满天飞每个请求都拉一个新线程来处理。在开发机和测试环境请求量小看着挺美。一上生产流量稍微起来线程数量爆炸式增长上下文切换开销吞噬了所有CPU资源内存也被大量线程栈占满服务直接雪崩。这时候再回头补课成本就高多了。所以理解并做好线程管理不是高级优化而是开发现代稳健、高性能应用的基本功。2. 线程池从“即用即弃”到“资源复用”的核心跃迁当你意识到不能无节制地创建线程时线程池ThreadPool就是你第一个需要掌握的工具。它背后的思想是一种典型的“池化”资源管理策略类似于数据库连接池。其核心价值在于复用通过预先创建或按需维持一定数量的线程避免频繁创建和销毁线程带来的巨大开销。2.1 线程池的核心构造参数与工作原理一个标准的线程池以Java的ThreadPoolExecutor为例主要由以下几个核心参数定义理解它们就理解了线程池的行为核心线程数 (corePoolSize)池中长期维持的线程数量即使它们处于空闲状态。除非设置了allowCoreThreadTimeOut否则这些线程不会被回收。这相当于公司的“正式编制”员工。最大线程数 (maximumPoolSize)池中允许存在的最大线程数量。当任务队列满了并且当前线程数小于最大线程数时池会创建新的线程来处理任务。这是“编制”“临时工”的总上限。任务队列 (workQueue)用于存放等待执行任务的阻塞队列。这是协调任务提交速度与线程处理速度的“缓冲区”。常见的队列有无界队列 (如LinkedBlockingQueue)队列可以无限增长。这种情况下maximumPoolSize参数会失效因为新任务永远可以进入队列排队不会触发创建新线程。风险是可能耗尽内存。有界队列 (如ArrayBlockingQueue)队列有固定容量。这是最常用的模式也是线程池策略发挥作用的关键。同步移交队列 (如SynchronousQueue)它不存储元素每个插入操作必须等待另一个线程的移除操作。这意味着如果没有空闲线程新任务提交会失败除非此时还能创建新线程。这要求池有足够大的maximumPoolSize或高效的拒绝策略。线程空闲存活时间 (keepAliveTime)当线程数超过核心线程数时多余的空闲线程在等待新任务时的最长存活时间。超过这个时间这些“临时工”线程将被终止回收。拒绝策略 (RejectedExecutionHandler)当任务队列已满且线程数已达到最大值时对新提交任务的处理策略。常见策略有AbortPolicy默认直接抛出RejectedExecutionException异常。CallerRunsPolicy让调用者线程比如提交任务的HTTP请求线程自己执行这个任务。这是一种简单的反馈机制能减缓任务提交速度。DiscardPolicy默默丢弃这个任务不抛异常。DiscardOldestPolicy丢弃队列中最老的一个任务然后尝试重新提交当前任务。线程池的工作流程可以概括为以下步骤这个流程决定了任务被执行的顺序和方式提交一个新任务。如果当前运行的线程数小于corePoolSize则立即创建新线程运行此任务即使其他核心线程空闲。如果当前运行线程数已达到或超过corePoolSize则将任务放入workQueue排队。如果队列已满且当前线程数小于maximumPoolSize则创建新的“临时”线程来处理任务。如果队列已满且当前线程数已达到maximumPoolSize则根据RejectedExecutionHandler策略拒绝该任务。2.2 参数配置的实战经验与避坑指南配置线程池不是玄学需要结合具体业务场景。这里有一些踩过坑才得出的经验CPU密集型 vs IO密集型这是决定线程数量的首要因素。CPU密集型如视频编码、复杂计算线程数不宜过多通常设置为CPU核心数 1左右。过多的线程会导致频繁的上下文切换反而降低性能。Runtime.getRuntime().availableProcessors()可以获取CPU核心数。IO密集型如网络请求、数据库查询线程可以设置得多一些因为线程大部分时间在等待IOCPU是空闲的。一个经验公式是CPU核心数 * (1 平均等待时间 / 平均计算时间)。在Web服务中这个值可能在几十到几百之间需要通过压测来找到最佳点。队列选择是门艺术不要使用无界队列这是生产环境的一个大忌。它会导致任务无限堆积最终内存溢出OOM。推荐使用有界队列如ArrayBlockingQueue并结合合适的拒绝策略。拒绝策略的选用默认的AbortPolicy在关键业务中可能过于粗暴直接抛异常会影响用户体验。CallerRunsPolicy是一个很好的“降级”选择它能让提交任务的线程也参与工作自然地对上游产生背压Back Pressure提醒上游系统“我这边忙不过来了你慢点发”。对于非核心业务DiscardPolicy或DiscardOldestPolicy也可以考虑但要配合完善的监控和日志知道有任务被丢弃了。给线程起个好名字通过自定义ThreadFactory给线程设置一个有意义的名字如businessName-thread-pool-1。这样在查日志、用jstack分析线程堆栈时你能一眼看出这个线程是干什么的极大提升排查效率。监控是必须的你需要知道线程池的运行状态当前线程数、活跃线程数、历史最大线程数、队列积压任务数、完成任务总数等。Spring Boot的Actuator、或通过ThreadPoolExecutor的getXXX()方法自行采集指标并暴露给监控系统如Prometheus都是必要的操作。3. 线程同步当多个“工人”需要操作同一件“产品”线程池解决了“工人”资源管理的问题但当多个线程工人需要访问或修改同一个共享资源产品时新的问题出现了竞态条件。比如一个经典的银行转账问题账户A有100元账户B有0元。线程1要从A转100给B线程2要从A转50给C。如果两个线程同时读取A的余额都是100然后各自计算并写回最终A的余额可能是-50如果线程2后写入或0如果线程1后写入这显然都是错误的。3.1 锁机制从synchronized到ReentrantLock解决竞态条件的关键是互斥即保证同一时间只有一个线程能进入临界区操作共享资源的代码段。最基础的工具是Java内置的synchronized关键字。synchronized的三种用法修饰实例方法锁是当前对象实例 (this)。修饰静态方法锁是当前类的Class对象。修饰代码块需指定一个对象作为锁。synchronized简单易用JVM会负责加锁和释放锁但它的能力相对单一。java.util.concurrent.locks.ReentrantLock提供了更灵活的锁操作。ReentrantLockvssynchronized核心对比特性synchronizedReentrantLock实现层面JVM原生语法字节码层面实现JDK API层面实现Java代码锁的获取隐式获取和释放进入同步块自动获取退出正常或异常自动释放显式调用lock()和unlock()必须在finally块中释放可中断等待锁时不可中断提供lockInterruptibly()方法可响应中断公平性非公平锁默认可选择公平锁或非公平锁构造参数指定条件变量通过wait(),notify(),notifyAll()与对象监视器配合提供Condition类可以创建多个条件队列实现更精确的线程等待/唤醒尝试获取锁不支持支持tryLock()可设置超时时间避免死等实战选择建议优先考虑synchronized。在大多数情况下它的性能已经足够好尤其是JDK不断优化后且代码简洁不易出错自动释放。当需要可中断的锁获取、超时获取锁、公平锁或者需要多个条件等待队列比如生产者-消费者模型中的“非空”和“非满”两个条件时再使用ReentrantLock。3.2 原子类与volatile轻量级同步武器对于简单的共享变量操作如计数、状态标志使用重量级的锁synchronized或ReentrantLock开销太大。这时java.util.concurrent.atomic包下的原子类是你的首选。原子类如AtomicInteger利用CPU的CASCompare-And-Swap指令实现了无锁化的线程安全更新。它的操作如incrementAndGet(),compareAndSet()是原子的性能远高于锁。它适用于计数器、序列号生成等场景。volatile关键字确保变量的可见性和禁止指令重排序但不保证原子性。可见性当一个线程修改了volatile变量的值新值会立即被刷新到主内存并使得其他线程中该变量的缓存行失效从而强制其他线程读取主内存中的新值。禁止重排序防止JVM和处理器为了优化性能而对指令进行重排序这在实现“双重检查锁定”单例模式时至关重要。注意一个常见的误解是volatile能保证i的原子性。这是错的。i是“读-改-写”三个操作volatile只能保证每次读到的i是最新值但两个线程可能同时读到相同的值然后各自加1写回导致最终结果少加了一次。对于复合操作仍需使用synchronized或原子类。3.3 死锁如何预防、诊断与解除死锁是线程同步中最棘手的问题之一。它发生在两个或多个线程互相等待对方持有的锁导致所有线程都无法继续执行。产生死锁需要四个必要条件缺一不可互斥资源一次只能被一个线程使用。占有且等待线程已持有至少一个资源又在等待其他资源。不可抢占资源只能由持有它的线程主动释放。循环等待存在一个线程等待链每个线程都在等待下一个线程所占有的资源。预防死锁就是破坏上述条件之一破坏“占有且等待”一次性申请所有所需资源AllocateAll。这在实践中往往很难做到容易降低并发度。破坏“不可抢占”使用可响应中断的锁如ReentrantLock.lockInterruptibly()或者设置锁获取超时tryLock(timeout)。这是更实用的方法。破坏“循环等待”对资源进行排序要求所有线程都按相同的顺序申请锁。这是最常用且有效的预防策略。例如规定所有线程必须先申请锁A再申请锁B。这样就不可能发生“线程1持有A等B线程2持有B等A”的循环。诊断死锁当应用卡住怀疑死锁时最直接的工具是jstack。使用jps命令找到Java进程的PID。运行jstack -l pid。在输出的最后jstack工具会明确报告是否发现死锁并打印出相关线程的堆栈信息清晰地显示出每个线程持有什么锁在等待什么锁。4. 线程间协作不仅仅是互斥更是有序配合有些场景下线程之间不是简单的竞争关系而是有明确的先后顺序或条件依赖。比如生产者-消费者模型生产者线程生产数据放入缓冲区消费者线程从缓冲区取出数据消费。当缓冲区空时消费者必须等待当缓冲区满时生产者必须等待。这就需要线程间的协作机制。4.1wait()/notify()机制与Condition接口这是最基础的线程协作API与synchronized配合使用。object.wait()调用此方法的线程会释放持有的对象锁并进入该对象的等待队列直到被其他线程唤醒。object.notify()随机唤醒一个在该对象上等待的线程。object.notifyAll()唤醒所有在该对象上等待的线程。使用它们时必须注意必须在synchronized同步块或方法内调用。wait()调用应放在循环中以防止“虚假唤醒”即线程在没有被notify的情况下被唤醒。标准范式是synchronized (lock) { while (!condition) { // 使用while而不是if lock.wait(); } // ... 执行条件满足后的操作 }ReentrantLock提供的Condition接口将对象监视器的wait/notify机制进行了抽象和增强。一个Lock可以创建多个Condition对象实现更精细的等待/通知。例如在生产者-消费者模型中可以创建两个ConditionnotEmpty和notFull。当缓冲区空时消费者在notEmpty上等待生产者生产后唤醒notEmpty上的线程。当缓冲区满时生产者在notFull上等待消费者消费后唤醒notFull上的线程。这样逻辑更清晰效率也更高。4.2 高级同步工具类CountDownLatch,CyclicBarrier,SemaphoreJUC包提供了一系列更高级的“瑞士军刀”可以简化复杂的同步逻辑。CountDownLatch倒计时闩锁允许一个或多个线程等待其他一组线程完成操作。构造时设定一个计数。await()方法会阻塞直到countDown()被调用足够次数计数减至0。它是一次性的计数归零后无法重置。典型场景主线程等待所有子线程初始化完成后再执行模拟并发测试让所有线程同时开始。// 主线程等待5个线程完成任务 CountDownLatch latch new CountDownLatch(5); for (int i 0; i 5; i) { new Thread(() - { // 执行任务 latch.countDown(); }).start(); } latch.await(); // 主线程在此等待 System.out.println(所有任务完成);CyclicBarrier循环屏障让一组线程互相等待直到所有线程都到达一个公共屏障点然后屏障打开所有线程继续执行并且屏障可以重置后重复使用。构造时指定参与线程数和一个可选的Runnable屏障动作在所有线程到达后由最后一个进入屏障的线程执行。典型场景多阶段计算每个阶段必须所有线程都完成才能进入下一阶段。// 3个线程在屏障处集合然后一起继续 CyclicBarrier barrier new CyclicBarrier(3, () - System.out.println(所有线程已就位)); for (int i 0; i 3; i) { new Thread(() - { // 第一阶段工作 barrier.await(); // 第二阶段工作所有线程都完成第一阶段后才开始 }).start(); }Semaphore信号量用来控制同时访问特定资源的线程数量。它维护了一组“许可证”。线程通过acquire()获取许可证如果无证可用则阻塞通过release()释放许可证。可以用于流量控制如数据库连接池限流。// 只允许3个线程同时访问某资源 Semaphore semaphore new Semaphore(3); new Thread(() - { semaphore.acquire(); try { // 访问受保护的资源 } finally { semaphore.release(); // 务必在finally中释放 } }).start();5. 线程本地存储避免共享的“独享空间”有些数据你希望每个线程都有一份独立的副本互不干扰。最典型的例子是数据库连接、用户会话Session信息、或者一些格式化的工具类如SimpleDateFormat它不是线程安全的。如果把这些对象作为共享变量就需要加锁性能差且容易出错。ThreadLocal正是为解决这个问题而生。它为每个使用该变量的线程都提供一个独立的变量副本每个线程只能访问和修改自己的副本从而避免了线程安全问题。它的原理是在Thread类内部维护了一个ThreadLocalMap以ThreadLocal实例自身作为键以线程的副本数据作为值。使用示例与注意事项private static final ThreadLocalSimpleDateFormat dateFormatHolder ThreadLocal.withInitial(() - new SimpleDateFormat(yyyy-MM-dd HH:mm:ss)); public String formatDate(Date date) { return dateFormatHolder.get().format(date); // 每个线程获取自己独立的SimpleDateFormat实例 }ThreadLocal的内存泄漏风险与正确清理这是使用ThreadLocal最大的坑。由于ThreadLocalMap的键是弱引用WeakReference而值是强引用当ThreadLocal实例被回收外部强引用消失后Map中的键会变成null但值对象依然被线程的强引用链持有导致无法被回收造成内存泄漏尤其是在使用线程池线程长期存活的场景下。正确做法将ThreadLocal变量声明为static final延长其生命周期避免键被回收。每次使用完后必须调用remove()方法清理当前线程的副本值这是最重要的习惯。try { // 使用 ThreadLocal String value threadLocal.get(); // ... 业务逻辑 } finally { threadLocal.remove(); // 务必清理 }6. 现代并发编程模型超越原生线程随着业务复杂度的提升直接操作底层线程和锁的模型显得越来越笨重。响应式编程、协程等更高层次的抽象模型开始流行它们的目标是让开发者更关注业务逻辑而非并发细节。Future与CompletableFuture这是Java对异步编程的初步支持。Future代表一个异步计算的结果但获取结果get()是阻塞的。CompletableFuture在Java 8中被引入它实现了Future和CompletionStage接口提供了强大的异步编程和流式组合能力。你可以方便地将多个异步任务组合起来实现链式调用、聚合结果、异常处理等大大简化了异步代码的编写。Project Loom与虚拟线程这是Java并发领域最令人兴奋的进展之一。传统操作系统线程平台线程重量级创建和切换成本高限制了高并发应用的性能。Loom项目引入了虚拟线程它们是JVM管理的轻量级线程与平台线程是M:N的映射关系。虚拟线程的创建和切换开销极低你可以像使用普通线程一样为每个任务如一个HTTP请求分配一个虚拟线程而无需担心资源耗尽。这本质上将“线程”从一种稀缺的系统资源变成了一种近乎无限的、廉价的编程抽象有望从根本上简化高并发程序的编写。虽然截至我撰写本文时Loom还未正式发布但其预览版已展现出巨大潜力是每个Java开发者需要关注的方向。线程管理是一个从微观锁、原子变量到宏观线程池、并发模型的完整体系。它没有银弹最佳实践总是依赖于具体的业务场景、负载特性和性能要求。扎实地理解这些基础概念和工具建立清晰的并发思维模型再辅以严谨的测试和监控才能构建出真正高效、稳定、可维护的并发程序。从我个人的经验来看在项目初期就确立好线程使用的规范比如统一使用线程池、定义好锁的申请顺序远比在后期性能瓶颈或诡异Bug出现时再去救火要有效得多。
)
