当前位置:

首页 > 编程开发 > JUC并发工具类使用教程与案例解析

JUC并发工具类使用教程与案例解析

JUC并发工具类解决了传统并发编程中synchronized和wait()/notify()的粒度粗、灵活性差、易出错等问题,1.提供ReentrantLock实现更细粒度的锁控制,支持tryLock、lockInterruptibly等特性;2.通过ExecutorService线程池高效管理线程资源,降低创建销毁开销;3.使用Atomic系列原子类实现无锁线程安全操作;4.利用CountDownLatch、CyclicBarrier、Semaphore等同步器协调复杂线程协作;5.引入Conditio

本文目录

    JUC并发工具类解决了传统并发编程中synchronized和wait()/notify()的粒度粗、灵活性差、易出错等问题,1.提供ReentrantLock实现更细粒度的锁控制,支持tryLock、lockInterruptibly等特性;2.通过ExecutorService线程池高效管理线程资源,降低创建销毁开销;3.使用Atomic系列原子类实现无锁线程安全操作;4.利用CountDownLatch、CyclicBarrier、Semaphore等同步器协调复杂线程协作;5.引入Condition替代wait/notify,支持多条件队列;6.提供ConcurrentHashMap等高性能并发集合减少锁竞争,相比传统机制在高并发场景下具备更高的灵活性与性能。

    JUC并发工具类详细使用教程与案例解析

    JUC并发工具类是Java在多线程编程领域提供的一系列强大组件,它们极大地简化了复杂并发场景的开发,帮助我们更安全、高效地管理线程协作与数据共享,有效避免了传统同步机制的诸多限制和陷阱。理解并恰当运用这些工具,是构建高性能、健壮并发应用的关键所在。

    JUC并发工具类详细使用教程与案例解析

    解决方案

    JUC并发工具类详细使用教程与案例解析

    要深入掌握JUC并发工具类,核心在于理解其设计哲学——将并发编程中常见的模式和问题抽象化为易于使用的类库。这包括:通过显式锁(如ReentrantLock)提供比synchronized更细粒度的控制和更丰富的功能;利用线程池(ExecutorService)高效管理线程资源,避免频繁创建销毁的开销;使用原子类(Atomic系列)实现无锁的线程安全操作;以及通过各种同步器(如CountDownLatch、CyclicBarrier、Semaphore)协调线程间的复杂协作。实际应用中,关键是根据具体的业务需求和并发模式,选择最合适的JUC工具,而不是一概而论。

    为什么我们需要JUC,它解决了哪些传统并发编程的痛点?

    JUC并发工具类详细使用教程与案例解析

    说实话,刚开始接触Java并发,我们最先学到的多半是synchronized关键字和wait()/notify()。它们确实能解决一些基本的同步问题,但在面对更复杂的场景时,就显得有些力不从心了。比如,synchronized是块级别的锁,一旦进入同步块,整个对象就被锁住了,粒度比较粗,在高并发下可能导致性能瓶颈。它还不支持尝试获取锁(tryLock)、中断等待锁(lockInterruptibly),以及超时获取锁这些灵活的操作。

    再看wait()和notify(),它们的用法也挺讲究,必须配合synchronized使用,而且容易出现“虚假唤醒”(Spurious Wakeups)的问题,或者因为忘记notify()而导致线程永久等待。更头疼的是,如果需要多个条件来唤醒不同的线程组,wait()/notify()就显得非常笨拙,你可能得写一大堆条件判断。

    JUC的出现,正是为了解决这些痛点。它提供了一套更高级、更灵活、性能更好的并发工具。例如,ReentrantLock提供了非阻塞获取锁、可中断获取锁、以及超时获取锁的能力,这在处理死锁或提高响应性方面非常有用。而Condition对象则完美替代了wait()/notify(),它允许一个锁关联多个条件队列,极大地简化了复杂条件下的线程协作。此外,JUC还引入了非阻塞算法(通过Atomic类实现),以及高效的并发集合类(如ConcurrentHashMap),它们在很多场景下比传统的Collections.synchronizedMap性能要好得多,因为它们减少了锁的竞争。

    ReentrantLock与Synchronized:我该如何选择与应用?

    这是个老生常谈的问题,但确实是理解JUC绕不开的一环。简单来说,synchronized是Java语言层面的关键字,由JVM隐式管理锁的获取和释放,用起来非常简洁,不容易出错(比如忘记释放锁)。它的性能在JDK后续版本中也得到了大幅优化,在低竞争或中等竞争的场景下,性能可能不比ReentrantLock差多少,甚至更好。JVM会对其进行偏向锁、轻量级锁等优化。

    public class SynchronizedExample {
        private int count = 0;
    
        public synchronized void increment() {
            count++;
        }
    
        public int getCount() {
            return count;
        }
    }

    而ReentrantLock是JUC包下的一个类,它提供了更细粒度的控制。最大的区别在于,ReentrantLock需要我们手动调用lock()和unlock()方法来获取和释放锁。这意味着你必须非常小心地在finally块中释放锁,否则一旦代码抛出异常,锁就永远不会被释放,这会直接导致死锁。

    import java.util.concurrent.locks.ReentrantLock;
    
    public class ReentrantLockExample {
        private final ReentrantLock lock = new ReentrantLock();
        private int count = 0;
    
        public void increment() {
            lock.lock(); // 获取锁
            try {
                count++;
            } finally {
                lock.unlock(); // 确保在finally块中释放锁
            }
        }
    
        public int getCount() {
            return count;
        }
    
        public void tryIncrement() {
            if (lock.tryLock()) { // 尝试获取锁,不阻塞
                try {
                    count++;
                    System.out.println(Thread.currentThread().getName() + " incremented count.");
                } finally {
                    lock.unlock();
                }
            } else {
                System.out.println(Thread.currentThread().getName() + " failed to acquire lock.");
            }
        }
    }

    那么,何时选择ReentrantLock呢?

    1. 需要非阻塞地获取锁:tryLock()方法可以在不阻塞当前线程的情况下尝试获取锁。
    2. 需要可中断地获取锁:lockInterruptibly()方法允许在等待锁的过程中响应中断。
    3. 需要多个条件变量:ReentrantLock可以通过newCondition()创建多个Condition对象,实现更复杂的线程间协作。
    4. 需要公平锁:ReentrantLock可以构造为公平锁(new ReentrantLock(true)),它会尝试将锁授予等待时间最长的线程,而synchronized是非公平的。

    如果你只是需要一个简单的互斥锁,并且对锁的控制粒度没有特殊要求,那么synchronized通常是更简洁、更安全的选择。如果你需要更高级的锁特性,或者在某些高竞争场景下需要极致的性能调优,那么ReentrantLock会是更好的工具。

    ExecutorService线程池:构建高效并发应用的核心利器

    直接管理线程(即每次任务来就new Thread())是低效且危险的。线程的创建和销毁都有不小的开销,而且无限制地创建线程可能耗尽系统资源,导致OOM(OutOfMemoryError)甚至系统崩溃。ExecutorService正是为了解决这些问题而生的。它提供了一个框架,用于管理和复用线程,将任务的提交与任务的执行解耦。

    使用线程池的好处显而易见:

    • 降低资源消耗:通过复用已存在的线程,减少线程创建和销毁的开销。
    • 提高响应速度:任务到达时,可以直接从池中获取线程执行,无需等待线程创建。
    • 提高可管理性:可以对线程池进行统一的调优、监控和管理,比如限制并发线程的数量。

    ExecutorService是java.util.concurrent.Executor接口的扩展,提供了生命周期管理和提交Callable和Runnable任务的方法。通常,我们会通过Executors工厂类来创建不同类型的线程池:

    • newFixedThreadPool(int nThreads):创建固定大小的线程池。当提交的任务多于线程数时,多余的任务会在队列中等待。
    • newCachedThreadPool():创建一个可缓存的线程池。如果线程池中有空闲线程,则复用;如果没有,则创建新线程。空闲线程在一定时间后会被回收。
    • newSingleThreadExecutor():创建一个单线程的线程池。它会保证所有任务都按照提交顺序执行。
    • newScheduledThreadPool(int corePoolSize):创建一个支持定时及周期性任务执行的线程池。

    当然,更高级的用法是直接构造ThreadPoolExecutor,这样可以完全自定义线程池的各项参数,包括核心线程数、最大线程数、空闲线程存活时间、任务队列、线程工厂以及拒绝策略等。这在生产环境中进行性能调优时非常关键。

    import java.util.concurrent.ExecutorService;
    import java.util.concurrent.Executors;
    import java.util.concurrent.TimeUnit;
    
    public class ExecutorServiceExample {
    
        public static void main(String[] args) {
            // 创建一个固定大小为3的线程池
            ExecutorService executor = Executors.newFixedThreadPool(3);
    
            for (int i = 0; i < 10; i++) {
                final int taskId = i;
                executor.submit(() -> {
                    System.out.println("Executing task " + taskId + " by " + Thread.currentThread().getName());
                    try {
                        Thread.sleep(1000); // 模拟任务执行时间
                    } catch (InterruptedException e) {
                        Thread.currentThread().interrupt();
                        System.out.println("Task " + taskId + " was interrupted.");
                    }
                });
            }
    
            // 关闭线程池,不再接受新任务,但会执行已提交的任务
            executor.shutdown();
            try {
                // 等待所有任务执行完毕,最多等待10秒
                if (!executor.awaitTermination(10, TimeUnit.SECONDS)) {
                    System.err.println("Pool did not terminate in time. Forcibly shutting down.");
                    executor.shutdownNow(); // 立即关闭,尝试中断正在执行的任务
                }
            } catch (InterruptedException e) {
                executor.shutdownNow();
                Thread.currentThread().interrupt();
            }
            System.out.println("All tasks submitted and pool is shutting down.");
        }
    }

    在使用线程池时,一个常见的陷阱就是忘记调用shutdown()方法。如果不调用,线程池中的线程会一直保持活跃状态,导致程序无法正常退出。另一个需要注意的,是选择合适的任务队列和拒绝策略,这直接影响到线程池在高负载下的行为。比如,如果使用无界队列(如LinkedBlockingQueue),即使maximumPoolSize设置得再小,也可能因为任务堆积而导致内存溢出。

    本站声明:本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系bd@zhengruan.com
    作者最新文章
    编程开发
    相关文章 更多
    chat-demo v0.1.1怎么本地运行并理解DeepSeek历史数据边界
    chat-demo v0.1.1怎么本地运行并理解DeepSeek历史数据边界

    chat-demo v0.1.1可以作为静态聊天客户端在本地运行,但模型、搜索、文件和语音能力仍由DeepSeek API提供。源码运行环境为Node.js 22.12及以上、Git与pnpm。Demo版本号不等于应用API版本;这套应用API未单独标版本,默认聊天模型ID是deepseek-flash。

    GitHub Copilot CLI v1.0.111的用量图与上下文比例应该怎样理解
    GitHub Copilot CLI v1.0.111的用量图与上下文比例应该怎样理解

    理解GitHub Copilot CLI v1.0.111的高级请求百分比、用户提示活动图与实际路由模型窗口,区分显示口径和任务状态。

    n8n 2.47.6、2.47.7、2.48.3 Beta、2.48.4 Beta、3.2.2预发布与1.123.96适用哪些安全修复?
    n8n 2.47.6、2.47.7、2.48.3 Beta、2.48.4 Beta、3.2.2预发布与1.123.96适用哪些安全修复?

    按维护分支、利用权限与节点类型对应四项修复,区分正式补丁、Beta和临时缓解的适用边界。

    GitHub合并故障的已缓解、监控与已解决有什么不同
    GitHub合并故障的已缓解、监控与已解决有什么不同

    GitHub合并故障中的“已缓解并监控”和“已解决”不能互换。前者表示影响已经采取措施缓解,仍在观察稳定性;后者是供应商正式结束这场事故的状态。11月13日的Pull Requests合并超时事件先进入监控,随后于北京时间11月14日02:29标记为已解决。

    llama.cpp v1.0.0的网页聊天分组与Markdown编辑适合哪些场景
    llama.cpp v1.0.0的网页聊天分组与Markdown编辑适合哪些场景

    llama.cpp v1.0.0改善聊天组织、长消息编辑和附件预览;界面变化与底层API迁移、缓存及访问边界需要分别理解。

    Postman 12.36.4 更新后仍报错,怎么判断是哪一层的问题
    Postman 12.36.4 更新后仍报错,怎么判断是哪一层的问题

    Postman 12.36.4 更新后仍有异常时,可按应用、API请求和平台服务区分问题范围,避免把补丁版本当作故障原因。

    n8n 2.47.6、2.48.3 Beta与1.123.96适合哪些部署环境?
    n8n 2.47.6、2.48.3 Beta与1.123.96适合哪些部署环境?

    按正式、预发布和1.x维护渠道对应补丁,再结合Redis、Agent端点和Pinecone索引判断适用范围。

    Codex CLI 0.169.0与0.171.0-alpha.2怎样选择,终端工作区适合哪些任务
    Codex CLI 0.169.0与0.171.0-alpha.2怎样选择,终端工作区适合哪些任务

    Codex CLI 0.169.0提供有明确说明的终端工作区能力;0.171.0-alpha.2为预发布,当前没有功能清单,选用时应分开评估。

    llama.cpp b12345的Hexagon后端支持哪些Q5量化格式?
    llama.cpp b12345的Hexagon后端支持哪些Q5量化格式?

    llama.cpp b12345的预发布构建为Hexagon HTP后端增加Q5_0和Q5_1支持。选择模型时需要核对完整量化名称及实际运行后端,不能只看到“Q5”就视为同一种格式。

    llama.cpp b12344的MCP工具调用在断连或超时后会怎样处理?
    llama.cpp b12344的MCP工具调用在断连或超时后会怎样处理?

    llama.cpp b12344的预发布构建调整了MCP工具调用的取消行为:客户端断连或调用超时时,服务器会向MCP服务发送带请求ID的取消通知。使用服务端工具的Web界面也属于这项变更范围。

    查看更多
    精品专题 更多
    装机必备
    装机必备

    正软商城装机必备专区,精选办公、浏览器、安全防护、影音播放、压缩解压、设计创作和系统工具等电脑常用正版软件,帮助用户快速完成新电脑软件配置。

    Windows
    Windows

    正软商城Windows软件专区,汇集适用于Windows电脑的办公、设计、安全防护、影音播放、开发工具和系统优化软件,提供软件介绍、系统要求、正版授权及购买下载服务。

    PDF教程
    PDF教程

    正软商城PDF教程频道提供PDF编辑、转换、合并、拆分、压缩及格式处理方法,同时介绍常用PDF软件和工具的使用技巧。

    Mac软件 更多
    讯飞智作 网页版
    讯飞智作 网页版
    Windows/ macOS/ Linux

    讯飞智作是一款基于语音合成技术、虚拟人驱动技术与数字人形象声音构建能力的 AI 数字人音视频创作平台。

    火山引擎 网页版
    火山引擎 网页版
    Windows/ macOS/ Linux

    火山引擎是字节跳动旗下企业级云与AI服务平台。聚焦大模型核心能力,依托字节自研豆包多模态大模型,凭借火山方舟一站式平台,提供模型精调、推理部署、智能应用搭建等全链路服务,结合高性能AI算力,助力各行业快速落地大模型数字化与智能化应用。

    Aperty macOS版
    Aperty macOS版
    macOS

    Aperty 是 Skylum 推出的 AI 人像修图软件,支持自然肤质修饰、瑕疵处理、面部与身体调整、预设及批量同步。

    WINDOWS 更多
    讯飞智作 网页版
    讯飞智作 网页版
    Windows/ macOS/ Linux

    讯飞智作是一款基于语音合成技术、虚拟人驱动技术与数字人形象声音构建能力的 AI 数字人音视频创作平台。

    火山引擎 网页版
    火山引擎 网页版
    Windows/ macOS/ Linux

    火山引擎是字节跳动旗下企业级云与AI服务平台。聚焦大模型核心能力,依托字节自研豆包多模态大模型,凭借火山方舟一站式平台,提供模型精调、推理部署、智能应用搭建等全链路服务,结合高性能AI算力,助力各行业快速落地大模型数字化与智能化应用。

    PixTV 网页版
    PixTV 网页版
    Windows

    PixTV 是一款在浏览器中使用的 AI 视觉内容创作平台,提供图片、视频、音频、文字生成、AI 分镜、局部重绘、提示词反推和无限画布等工具,适合短剧、漫剧、广告及社交媒体内容制作。