Java线程池基础详解.docVIP

Java 线程池基础详解 对项目进行重构，目标是提高吞吐量和可用性，在这个过程中对原有的线程模型和处理逻辑进行了修改，发现有很多基础的多线程的知识已经模糊不清，如底层线程的运行情况、现有的线程池的策略和逻辑、池中线程的健康状况的监控等，这次重新回顾了一下，其中涉及大量java.util.concurrent包中的类。本文将会包含以下内容： Java中的Thread与操作系统中的线程的关系 线程切换的各种开销 ThreadGroup存在的意义 使用线程池减少线程开销 Executor的概念 ThreadPoolExecutor中的一些具体实现 如何监控线程的健康 参考ThreadPoolExecutor来设计适合自己的线程模型 一、问题描述 这个项目所在系统的软件架构（从开发到运维）基本上采用的是微服务架构，微服务很好地解决了我们系统的复杂性问题，但是随之也带来了一些问题，比如在此架构中大部分的服务都拥有自己单独的数据库，而有些（很重要的）业务需要做跨库查询。相信这种「跨库查询」的问题很多实践微服务的公司都碰到过，通常这类问题有以下几种解决方案（当然，还有更多其他的方案，这里就不一一叙述了）： 严格通过服务提供的API查询。这样做的好处是将服务完全当做黑盒，可以最大限度得减少服务间的依赖与耦合关系，其次还能根据实际需求服务之间使用不同的数据库类型；缺点是则代价太大。 将关心的信息冗余到自己的库中，并提供API让其他服务来主动修改。优点是信息更新十分实时，缺点是增加了服务间的依赖。 指令与查询分离（CQRS）。将可能被其他服务关心的数据放入数据仓库（或者做成类似于物化视图、搜索引擎等），数据仓库只提供读的功能。优点是对主库不会有压力，服务只要关心实现自己的业务就好，缺点是数据的实时性会受到了挑战。 指令与查询分离 结合实际情况，我们使用的是第3种方案。然而随着越来越多的业务依赖读库，甚至依赖其中一些状态的变化，所以读库的数据同步如果出现高延时，则会直接影响业务的进行。出了几次这种事情后，于是下决心要改善这种情况。首先想到的就是使用线程池来进行消息的消费（写入读库），JDK自从1.5开始提供了实用而强大的线程池工具——Executor框架。 二、Executor框架 Executor框架在Java1.5中引入，大部分的类都在包java.util.concurrent中，由大神Doug Lea写成，其中常用到的有以下几个类和接口： java.util.concurrent.Executor一个只包含一个方法的接口，它的抽象含义是：用来执行一个Runnable任务的执行器。 java.util.concurrent.ExecutorService对Executor的一个扩展，增加了很多对于任务和执行器的生命周期进行管理的接口，也是通常进行多线程开发最常使用的接口。 java.util.concurrent.ThreadFactory一个生成新线程的接口。用户可以通过实现这个接口管理对线程池中生成线程的逻辑 java.util.concurrent.Executors提供了很多不同的生成执行器的实用方法，比如基于线程池的执行器的实现。 三、为什么要用线程池 Java从最开始就是基于线程的，线程在Java里被封装成一个类java.lang.Thread。在面试中很多面试官都会问一个很基础的关于线程问题： Java中有几种方法新建一个线程？ 所有人都知道，标准答案是两种：继承Thread或者实现Runnable，在JDK源代码中Thread类的注释中也是这么写的。 然而在我看来这两种方法根本就是一种，所有想要开启线程的操作，都必须生成了一个Thread类（或其子类）的实例，执行其中的native方法start0()。 Java中的线程 Java中将线程抽象为一个普通的类，这样带来了很多好处，譬如可以很简单的使用面向对象的方法实现多线程的编程，然而这种程序写多了容易会忘记，这个对象在底层是实实在在地对应了一个OS中的线程。 操作系统中的线程和进程 上图中的进程（Process）可以看做一个JVM，可以看出，所有的进程有自己的私有内存，这块内存会在主存中有一段映射，而所有的线程共享JVM中的内存。在现代的操作系统中，线程的调度通常都是集成在操作系统中的，操作系统能通过分析更多的信息来决定如何更高效地进行线程的调度，这也是为什么Java中会一直强调，线程的执行顺序是不会得到保证的，因为JVM自己管不了这个，所以只能认为它是完全无序的。 另外，类java.lang.Thread中的很多属性也会直接映射为操作系统中线程的一些属性。Java的Thread中提供的一些方法如sleep和yield其实依赖于操作系统中线程的调度算法。 关于线程的调度算法可以去