Java线程池原理与实战详解
在面向对象编程中,创建和销毁对象是很费时间的,因为创建一个对象要获取内存资源或者其它更多资源。在Java中更是如此,虚拟机将试图跟踪每一个对象,以便能够在对象销毁后进行垃圾回
前言 在面向对象编程中,创建和销毁对象是很费时间的,因为创建一个对象要获取内存资源或者其它更多资源。在Java中更是如此,虚拟机将试图跟踪每一个对象,以便能够在对象销毁后进行垃圾回收。所以提高服务程序效率的一个手段就是尽可能减少创建和销毁对象的次数,特别是一些很耗资源的对象创建和销毁。如何利用已有对象来服务就是一个需要解决的关键问题,其实这就是一些"池化资源"技术产生的原因。比如大家所熟悉的数据库连接池正是遵循这一思想而产生的! 线程池是什么? 简单来说,线程池是指提前创建若干个线程,当有任务需要处理时,线程池里的线程就会处理任务,处理完成后的线程并不会被销毁,而是继续等待下一个任务。由于创建和销毁线程都是消耗系统资源的,所以,当某个业务需要频繁进行线程的创建和销毁时,就可以考虑使用线程池来提高系统的性能啦。 线程池可以做什么? 借由《Java并发编程的艺术》这本书,使用线程池能够帮助我们 : 如何创建一个线程池 首先创建一个 Runnable 接口实现类。
这里让我们使用 ThreadPoolExecutor 来创建一个线程池进行测试:
最后让我们来看一下运行结果 : 可以看到,当核心线程数为 5 时,即使总共要运行的线程有 15 个,每次也只会同时执行 5 个任务,剩下的任务则会被放入等待队列,等待核心线程空闲后执行。总的来说步骤如下 : Executor框架 Executor 框架是 Java5 之后引进的。在 Java5 之后,通过 Executor 来启动线程比使用 Thread 的 start 方法更好。除了更易管理,效率更好(用线程池实现,节约开销)外,还有关键的一点 :有助于避免 this 逃逸问题。 this 逃逸this 逃逸是指在构造函数返回之前其他线程就持有该对象的引用,调用尚未构造完全的对象的方法时可能引发奇怪的错误。 引发 this 逃逸通常需要满足两个条件 :一个是在构造函数中创建内部类,另一个就是在构造函数中将这个内部类发布了出去。 由于发布出去的内部类对象自带对外部类 this 的访问权限,这就导致在通过内部类对象访问外部类 this 时,外部类可能并未构造完成,从而导致一些意想不到的问题。 典型的 this 逃逸情景如下 :
通过使用线程池进行统一的线程调度,省去了在程序中手动启动线程的步骤,从而避免了在构造器中启动一个线程的情况,因此能够有效规避 this 逃逸。 ThreadPoolExecutor常用参数 1. corePoolSize :核心线程线程数 定义了最小可以同时运行的线程数量。 2. maximumPoolSize :最大线程数 当队列中存放的任务达到队列容量时,当前可以同时运行的线程数量会扩大到最大线程数。 3. keepAliveTime :等待时间 当线程数大于核心线程数时,多余的空闲线程存活的最长时间。 4. unit :时间单位。 keepAliveTime 参数的时间单位,包括 TimeUnit.SECONDS、TimeUnit.MINUTES、TimeUnit.HOURS、TimeUnit.DAYS 等等。 5. workQueue :任务队列 任务队列,用来储存等待执行任务的队列。 6. threadFactory :线程工厂 线程工厂,用来创建线程,一般默认即可。 7. handler :拒绝策略 也称饱和策略;当提交的任务过多而不能及时处理时,可以通过定制策略来处理任务。 ThreadPoolExecutor 饱和策略 : 指当前同时运行的线程数量达到最大线程数量并且队列也已经被放满时,ThreadPoolTaskExecutor 所执行的策略。 常用的拒绝策略包括 : 为什么推荐使用 ThreadPoolExecutor 来创建线程? 规约一 :线程资源必须通过线程池提供,不允许在应用中自行显示创建线程。 使用线程池的好处是减少在创建和销毁线程上所消耗的时间以及系统资源开销,解决资源不足的问题。如果不使用线程池,有可能会造成系统创建大量同类线程而导致消耗完内存或者“过度切换”的问题。 规约二 :强制线程池不允许使用 Executors 去创建,而是通过 ThreadPoolExecutor 构造函数的方式,这样的处理方式让写的同学更加明确线程池的运行规则,规避资源耗尽的风险。 Executors 返回线程池对象的弊端如下: FixedThreadPool 和 SingleThreadExecutor : 允许请求的队列长度为 Integer.MAX_VALUE,可能会堆积大量请求,从而导致 OOM。 CachedThreadPool 和 ScheduledThreadPool : 允许创建的线程数量为 Integer.MAX_VALUE,可能会创建大量线程,从而导致 OOM。几种常见的线程池 FixThreadPool 固定线程池 FixThreadPool :可重用固定线程数的线程池。
执行机制 : FixThreadPool 使用的是无界队列 LinkedBlockingQueue(队列容量为 Integer.MAX_VALUE),而它会给线程池带来如下影响 : SingleThreadExecutor 单一线程池 SingleThreadExecutor 是只有一个线程的线程池。
除了池中只有一个线程外,其他和 FixThreadPool 是基本一致的。 CachedThreadPool 缓存线程池 CachedThreadPool 是一个会根据需要创建新线程的线程池,但会在先前构建的线程可用时重用它。
其 corePoolSize 被设置为 0,maximumPoolSize 被设置为 Integer.MAX.VALUE,也就是无界的。虽然是无界,但由于该线程池还存在一个销毁机制,即如果一个线程 60 秒内未被使用过,则该线程就会被销毁,这样就节省了很多资源。 但是,如果主线程提交任务的速度高于 maximunPool 中线程处理任务的速度,CachedThreadPool 将会源源不断地创建新的线程,从而依然可能导致 CPU 耗尽或内存溢出。 执行机制 : 如何拟定线程池的大小? 上下文切换 多线程变编程中一般线程的个数都大于 CPU 核心的个数,而一个 CPU 核心在任意时刻只能被一个线程使用。为了让这些线程都能得到有效执行,CPU 采取的策略是为每个线程分配时间片并轮转的形式。当一个线程的时间片用完的时候就会重新处于就绪状态让给其他线程使用,这个过程就属于一次上下文切换。 概括来说就是,当前任务在执行完 CPU 时间片切换到另一个任务之前,会先保存自己的状态,以便下次再切换回这个任务时,可以直接加载到上次的状态。任务从保存到再加载的过程就是一次上下文切换。 上下文切换通常是计算密集型的。也就是说,它需要相当可观的处理器时间,在每秒几十上百次的切换中,每次切换都需要纳秒量级的时间。所以,上下文切换对系统来说意味着消耗大量的 CPU 时间,事实上,可能是操作系统中时间消耗最大的操作。 Linux 相比与其他操作系统(包括其他类 Unix 系统)有许多,其中有一项就是,其上下文切换和模式切换的时间消耗非常少。 简单的拟定判断 CPU 密集型任务(N+1): 这种任务消耗的主要是 CPU 资源,可以将线程数设置为 N(CPU 核心数)+1,比 CPU 核心数多出来的一个线程是为了防止线程偶发的缺页中断,或者其它原因导致的任务暂停而带来的影响。一旦任务暂停,CPU 就会处于空闲状态,而在这种情况下多出来的一个线程就可以充分利用 CPU 的空闲时间。 I/O 密集型任务(2N): 这种任务应用起来,系统会用大部分的时间来处理 I/O 交互线程池linux,而线程在处理 I/O 的时间段内不会占用 CPU 来处理,这时就可以将 CPU 交出给其它线程使用。因此在 I/O 密集型任务的应用中,我们可以多配置一些线程,具体的计算方法是 2N。 好了,本文就到这里了,如果觉得文中有错误信息欢迎在评论区留言指出! 面试造火箭,入职拧螺丝,希望能够帮助到你。 多多转发,让更多人受益! (编辑:海南站长网) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |