上帝视角拆解 Tomcat 架构设计，在理解整个组件设计思路之后。咱们须要下凡深刻理解每个组件的细节实现。从远到近，架构给人以宏观思维，细节展示丰满的美。关注「码哥字节」获取更多硬核，你，筹备好了么？

上回「码哥字节」站在上帝视角给大家拆解了 Tomcat 架构设计，剖析 Tomcat 如何实现启动、进行，通过设计连接池与容器两大组件实现了一个申请的承受与响应。连接器负责对外交换，解决 socket 连贯，容器对内负责，加载 Servlet 以及解决具体 Request 申请与响应。详情点我进入传输门：Tomcat 架构解析到工作借鉴。

高并发拆解外围筹备

这回，再次拆解，专一 Tomcat 高并发设计之道与性能调优，让大家对整个架构有更高层次的理解与感悟。其中设计的每个组件思路都是将 Java 面向对象、面向接口、如何封装变与不变，如何依据理论需要形象不同组件分工合作，如何设计类实现繁多职责，怎么做到将类似性能高内聚低耦合，设计模式使用到极致的学习借鉴。

这次次要波及到的是 I/O 模型，以及线程池的根底内容。

在学习之前，心愿大家积攒以下一些技术内容，很多内容「码哥字节」也在历史文章中分享过。大家可爬楼回顾……。心愿大家器重如下几个知识点，在把握以下知识点再来拆解 Tomcat，就会事倍功半，否则很容易迷失方向不得其法。

一起来看 Tomcat 如何实现并发连贯解决以及工作解决，性能的优化是每一个组件都起到对应的作用，如何应用起码的内存，最快的速度执行是咱们的指标。

设计模式

模板办法模式： 形象算法流程在抽象类中，封装流程中的变动与不变点。将变动点提早到子类实现，达到代码复用，开闭准则。

观察者模式：针对事件不同组件有不同响应机制的需要场景，达到解耦灵便告诉上游。

责任链模式：将对象连接成一条链，将沿着这条链传递申请。在 Tomcat 中的 Valve 就是该设计模式的使用。

更多设计模式可查看「码哥字节」之前的设计模式专辑，这里是传送门。

I/O 模型

Tomcat 实现高并发接管连贯，必然波及到 I/O 模型的使用，理解同步阻塞、异步阻塞、I/O 多路复用，异步非阻塞相干概念以及 Java NIO 包的使用很有必要。本文也会带大家着重阐明 I/O 是如何在 Tomcat 使用实现高并发连贯。大家通过本文我置信对 I/O 模型也会有一个粗浅意识。

Java 并发编程

实现高并发，除了整体每个组件的优雅设计、设计模式的正当、I/O 的使用，还须要线程模型，如何高效的并发编程技巧。在高并发过程中，不可避免的会呈现多个线程对共享变量的拜访，须要加锁实现，如何高效的升高锁抵触。因而作为程序员，要无意识的尽量避免锁的应用，比方能够应用原子类 CAS 或者并发汇合来代替。如果万不得已须要用到锁，也要尽量放大锁的范畴和锁的强度。

对于并发相干的基础知识，如果读者感兴趣「码哥字节」前面也给大家安顿上，目前也写了局部并发专辑，大家可移步到历史文章或者专辑翻阅，这里是传送门，次要解说了并发实现的原理、什么是内存可见性，JMM 内存模模型、读写锁等并发知识点。

Tomcat 总体架构

再次回顾下 Tomcat 整体架构设计，次要设计了 connector 连接器解决 TCP/IP 连贯，container 容器作为 Servlet 容器，解决具体的业务申请。对外对内别离形象两个组件实现拓展。

  • 一个 Tomcat 实例默认会有一个 Service，而一个 Service 能够蕴含多个连接器。连接器次要有 ProtocalHandler 和 Adapter 两个组件共同完成连接器外围性能。
  • ProtocolHandler 次要由 Acceptor 以及 SocketProcessor 形成，实现了 TCP/IP 层 的 Socket 读取并转换成 TomcatRequest 和 TomcatResponse，最初依据 http 或者 ajp 协定获取适合的 Processor 解析为应用层协定，并通过 Adapter 将 TomcatRequest、TomcatResponse 转化成 规范的 ServletRequest、ServletResponse。通过 getAdapter().service(request, response);将申请传递到 Container 容器。
  • adapter.service()实现将申请转发到容器 org.apache.catalina.connector.CoyoteAdapter
// Calling the containerconnector.getService().getContainer().getPipeline().getFirst().invoke(                        request, response);

这个调用会触发 getPipeline 形成的责任链模式将申请一步步走入容器外部，每个容器都有一条 Pipeline，通过 First 开始到 Basic 完结并进入容器外部持有的子类容器，最初到 Servlet，这里就是责任链模式的经典使用。具体的源码组件是 Pipeline 形成一条申请链，每一个链点由 Valve 组成。「码哥字节」在上一篇Tomcat 架构解析到工作借鉴 曾经具体解说。如下图所示，整个 Tomcat 的架构设计重要组件清晰可见，心愿大家将这个全局架构图深深印在脑海里，把握全局思路能力更好地剖析细节之美。

启动流程：startup.sh 脚本到底产生了什么

  • Tomcat 本生就是一个 Java 程序，所以 startup.sh 脚本就是启动一个 JVM 来运行 Tomcat 的启动类 Bootstrap。
  • Bootstrap 次要就是实例化 Catalina 和初始化 Tomcat 自定义的类加载器。热加载与热部署就是靠他实现。
  • Catalina: 解析 server.xml 创立 Server 组件，并且调用 Server.start() 办法。
  • Server：治理 Service 组件，调用 Server 的 start() 办法。
  • Service：主要职责就是治理简介器的顶层容器 Engine，别离调用 Connector 和 Engine 的 start 办法。

Engine 容器次要就是组合模式将各个容器依据父子关系关联，并且 Container 容器继承了 Lifecycle 实现各个容器的初始化与启动。Lifecycle 定义了 init()、start()、stop() 管制整个容器组件的生命周期实现一键启停。

这里就是一个面向接口、繁多职责的设计思维 ，Container 利用组合模式治理容器，LifecycleBase 抽象类继承 Lifecycle 将各大容器生命周期对立治理这里便是，而实现初始化与启动的过程又 LifecycleBase 使用了模板办法设计模式形象出组件变动与不变的点，将不同组件的初始化提早到具体子类实现。并且利用观察者模式公布启动事件解耦。

具体的 init 与 start 流程如下泳道图所示：这是我在浏览源码 debug 所做的笔记，读者敌人们不要怕笔记破费工夫长，本人跟着 debug 缓缓记录，置信会有更深的感悟。

init 流程

start 流程

读者敌人依据我的两篇内容，抓住主线组件去 debug，而后跟着该泳道图浏览源码，我置信都会有所播种，并且事倍功半。在读源码的过程中，切勿进入某个细节，肯定要先把各个组件形象进去，理解每个组件的职责即可。最初在理解每个组件的职责与设计哲学之后再深刻了解每个组件的实现细节，千万不要一开始就想着深刻了解具体一篇叶子。

每个外围类我在架构设计图以及泳道图都标识进去了，「码哥字节」给大家分享下如何高效浏览源码，以及放弃学习趣味的心得体会。

如何正确浏览源码

切勿陷入细节，不看全局：我还没弄清楚森林长啥样，就盯着叶子看 ，看不到全貌和整体设计思路。所以浏览源码学习的时候不要一开始就进入细节，而是宏观对待整体架构设计思维，模块之间的关系。

1.浏览源码之前，须要有肯定的技术储备

比方罕用的设计模式，这个必须把握，尤其是：模板办法、策略模式、单例、工厂、观察者、动静代理、适配器、责任链、装璜器。大家能够看 「码哥字节」对于设计模式的历史文章，打造好的根底。

2.必须会应用这个框架/类库，精通各种变通用法

魔鬼都在细节中，如果有些用法基本不晓得，可能你能看明确代码是什么意思，然而不晓得它为什么这些写。

3.先去找书，找材料，理解这个软件的整体设计。

从全局的视角去对待，上帝视角理出次要外围架构设计，先森林后树叶。都有哪些模块？ 模块之间是怎么关联的？怎么关联的？

可能一下子了解不了，然而要建设一个整体的概念，就像一个地图，避免你迷航。

在读源码的时候能够时不时看看本人在什么中央。就像「码哥字节」给大家梳理好了 Tomcat 相干架构设计，而后本人再尝试跟着 debug，这样的效率锦上添花。

4. 搭建零碎，把源代码跑起来！

Debug 是十分十分重要的伎俩， 你想通过只看而不运行就把零碎搞清楚，那是基本不可能的！正当使用调用栈（察看调用过程上下文）。

5.笔记

一个十分重要的工作就是记笔记（又是写作！），画出零碎的类图（不要依附 IDE 给你生成的）， 记录下次要的函数调用， 不便后续查看。

文档工作极为重要，因为代码太简单，人的大脑容量也无限，记不住所有的细节。 文档能够帮忙你记住关键点， 到时候能够回想起来，迅速地接着往下看。

要不然，你明天看的，可能到今天就忘个差不多了。所以敌人们记得珍藏后多翻来看看，尝试把源码下载下来重复调试。

谬误形式

  • 陷入细节，不看全局：我还没弄清楚森林长啥样，就盯着叶子看 ，看不到全貌和整体设计思路。所以浏览源码学习的时候不要一开始就进入细节，而是宏观对待整体架构设计思维，模块之间的关系。
  • 还没学会用就钻研如何设计：首先基本上框架都使用了设计模式，咱们最起码也要理解罕用的设计模式，即便是“背”，也得了然于胸。在学习一门技术，我举荐先看官网文档，看看有哪些模块、整体设计思维。而后下载示例跑一遍，最初才是看源码。
  • 看源码深究细节：到了看具体某个模块源码的时候也要下意识的不要去深刻细节，重要的是学习设计思路，而不是具体一个办法实现逻辑。除非本人要基于源码做二次开发，而且二次开发也是基于在理解扎鞥个架构的状况下能力深刻细节。

组件设计-落实繁多职责、面向接口思维

当咱们接到一个性能需要的时候，最重要的就是形象设计，将性能拆解次要外围组件，而后找到需要的变动与不变点，将类似性能内聚，性能之间若耦合，同时对外反对可拓展，对内敞开批改。努力做到一个需要下来的时候咱们须要正当的形象能力形象出不同组件，而不是一锅端将所有性能糅合在一个类甚至一个办法之中，这样的代码牵一发而动全身，无奈拓展，难以保护和浏览。

带着问题咱们来剖析 Tomcat 如何设计组件实现连贯与容器治理。

看看 Tomcat 如何实现将 Tomcat 启动，并且又是如何承受申请，将申请转发到咱们的 Servlet 中。

Catalina

次要工作就是创立 Server，并不是简略创立，而是解析 server.xml 文件把文件配置的各个组件意义创立进去，接着调用 Server 的 init() 和 start() 办法，启动之旅从这里开始…，同时还要兼顾异样，比方敞开 Tomcat 还须要做到优雅敞开启动过程创立的资源须要开释，Tomcat 则是在 JVM 注册一个「敞开钩子」，源码我都加了正文，省略了局部无关代码。同时通过 await() 监听进行指令敞开 Tomcat。

    /**     * Start a new server instance.     */    public void start() {                // 若 server 为空，则解析 server.xml 创立        if (getServer() == null) {            load();        }                // 创立失败则报错并退出启动        if (getServer() == null) {            log.fatal("Cannot start server. Server instance is not configured.");            return;        }        // 开始启动 server        try {            getServer().start();        } catch (LifecycleException e) {            log.fatal(sm.getString("catalina.serverStartFail"), e);            try {                // 异样则执行 destroy 销毁资源                getServer().destroy();            } catch (LifecycleException e1) {                log.debug("destroy() failed for failed Server ", e1);            }            return;        }        // 创立并注册 JVM 敞开钩子        if (useShutdownHook) {            if (shutdownHook == null) {                shutdownHook = new CatalinaShutdownHook();            }            Runtime.getRuntime().addShutdownHook(shutdownHook);        }                // 通过 await 办法监听进行申请        if (await) {            await();            stop();        }    }

通过「敞开钩子」，就是当 JVM 敞开的时候做一些清理工作，比如说开释线程池，清理一些零时文件，刷新内存数据到磁盘中…...

「敞开钩子」实质就是一个线程，JVM 在进行之前会尝试执行这个线程。咱们来看下 CatalinaShutdownHook 这个钩子到底做了什么。

    /**     * Shutdown hook which will perform a clean shutdown of Catalina if needed.     */    protected class CatalinaShutdownHook extends Thread {        @Override        public void run() {            try {                if (getServer() != null) {                    Catalina.this.stop();                }            } catch (Throwable ex) {               ...        }    }    /**     * 敞开曾经创立的 Server 实例     */    public void stop() {        try {            // Remove the ShutdownHook first so that server.stop()            // doesn't get invoked twice            if (useShutdownHook) {                Runtime.getRuntime().removeShutdownHook(shutdownHook);            }        } catch (Throwable t) {            ......        }        // 敞开 Server        try {            Server s = getServer();            LifecycleState state = s.getState();           // 判断是否曾经敞开，若是在敞开中，则不执行任何操作            if (LifecycleState.STOPPING_PREP.compareTo(state) <= 0                    && LifecycleState.DESTROYED.compareTo(state) >= 0) {                // Nothing to do. stop() was already called            } else {                s.stop();                s.destroy();            }        } catch (LifecycleException e) {            log.error("Catalina.stop", e);        }    }

实际上就是执行了 Server 的 stop 办法，Server 的 stop 办法会开释和清理所有的资源。

Server 组件

来领会上面向接口设计美，看 Tomcat 如何设计组件与接口，形象 Server 组件，Server 组件须要生命周期治理，所以继承 Lifecycle 实现一键启停。

它的具体实现类是 StandardServer，如下图所示，咱们晓得 Lifecycle 次要的办法是组件的 初始化、启动、进行、销毁，和 监听器的治理保护，其实就是观察者模式的设计，当触发不同事件的时候公布事件给监听器执行不同业务解决，这里就是如何解耦的设计哲学体现。

而 Server 自生则是负责管理 Service 组件。

接着，咱们再看 Server 组件的具体实现类是 StandardServer 有哪些性能，又跟哪些类关联？

在浏览源码的过程中，咱们肯定要多关注接口与抽象类，接口是组件全局设计的形象；而抽象类基本上是模板办法模式的使用，次要目标就是形象整个算法流程，将变动点交给子类，将不变点实现代码复用。

StandardServer 继承了 LifeCycleBase，它的生命周期被对立治理，并且它的子组件是 Service，因而它还须要治理 Service 的生命周期，也就是说在启动时调用 Service 组件的启动办法，在进行时调用它们的进行办法。Server 在外部保护了若干 Service 组件，它是以数组来保留的，那 Server 是如何增加一个 Service 到数组中的呢？

    /**     * 增加 Service 到定义的数组中     *     * @param service The Service to be added     */    @Override    public void addService(Service service) {        service.setServer(this);        synchronized (servicesLock) {           // 创立一个 services.length + 1 长度的 results 数组            Service results[] = new Service[services.length + 1];           // 将老的数据复制到 results 数组            System.arraycopy(services, 0, results, 0, services.length);            results[services.length] = service;            services = results;                        // 启动 Service 组件            if (getState().isAvailable()) {                try {                    service.start();                } catch (LifecycleException e) {                    // Ignore                }            }            // 观察者模式使用，触发监听事件            support.firePropertyChange("service", null, service);        }    }

从下面的代码能够晓得，并不是一开始就调配一个很长的数组，而是在新增过程中动静拓展长度，这里就是为了节俭空间，对于咱们平时开发是不是也要次要空间复杂度带来的内存损耗，谋求的就是极致的美。

除此之外，还有一个重要性能，下面 Caralina 的启动办法的最初一行代码就是调用了 Server 的 await 办法。

这个办法次要就是监听进行端口，在 await 办法里会创立一个 Socket 监听 8005 端口，并在一个死循环里接管 Socket 上的连贯申请，如果有新的连贯到来就建设连贯，而后从 Socket 中读取数据；如果读到的数据是进行命令“SHUTDOWN”，就退出循环，进入 stop 流程。

Service

同样是面向接口设计，Service 组件的具体实现类是 StandardService，Service 组件仍然是继承 Lifecycle 治理生命周期，这里不再累赘展现图片关系图。咱们先来看看 Service 接口次要定义的办法以及成员变量。通过接口咱们能力晓得外围性能，在浏览源码的时候肯定要多关注每个接口之间的关系，不要急着进入实现类。

public interface Service extends Lifecycle {  // ----------次要成员变量    //Service 组件蕴含的顶层容器 Engine    public Engine getContainer();    // 设置 Service 的 Engine 容器    public void setContainer(Engine engine);    // 该 Service 所属的 Server 组件    public Server getServer();    // --------------------------------------------------------- Public Methods   // 增加 Service 关联的连接器    public void addConnector(Connector connector);    public Connector[] findConnectors();   // 自定义线程池    public void addExecutor(Executor ex);   // 次要作用就是依据 url 定位到 Service，Mapper 的次要作用就是用于定位一个申请所在的组件解决    Mapper getMapper();}

接着再来细看 Service 的实现类：

public class StandardService extends LifecycleBase implements Service {    // 名字    private String name = null;    //Server 实例    private Server server = null;    // 连接器数组    protected Connector connectors[] = new Connector[0];    private final Object connectorsLock = new Object();    // 对应的 Engine 容器    private Engine engine = null;    // 映射器及其监听器，又是观察者模式的使用    protected final Mapper mapper = new Mapper();    protected final MapperListener mapperListener = new MapperListener(this);}

StandardService 继承了 LifecycleBase 抽象类，抽象类定义了 三个 final 模板办法定义生命周期，每个办法将变动点定义形象办法让不同组件工夫本人的流程。这里也是咱们学习的中央，利用模板办法形象变与不变。

此外 StandardService 中还有一些咱们相熟的组件，比方 Server、Connector、Engine 和 Mapper。

那为什么还有一个 MapperListener？这是因为 Tomcat 反对热部署，当 Web 利用的部署发生变化时，Mapper 中的映射信息也要跟着变动，MapperListener 就是一个监听器，它监听容器的变动，并把信息更新到 Mapper 中，这是典型的观察者模式。上游服务依据多上游服务的动作做出不同解决，这就是观察者模式的使用场景，实现一个事件多个监听器触发，事件发布者不必调用所有上游，而是通过观察者模式触发达到解耦。

Service 治理了 连接器以及 Engine 顶层容器，所以持续进入它的 startInternal 办法，其实就是 LifecycleBase 模板定义的 形象办法。看看他是怎么启动每个组件程序。

protected void startInternal() throws LifecycleException {    //1. 触发启动监听器    setState(LifecycleState.STARTING);    //2. 先启动 Engine，Engine 会启动它子容器，因为使用了组合模式，所以每一层容器在会先启动本人的子容器。    if (engine != null) {        synchronized (engine) {            engine.start();        }    }    //3. 再启动 Mapper 监听器    mapperListener.start();    //4. 最初启动连接器，连接器会启动它子组件，比方 Endpoint    synchronized (connectorsLock) {        for (Connector connector: connectors) {            if (connector.getState() != LifecycleState.FAILED) {                connector.start();            }        }    }}

Service 先启动了 Engine 组件，再启动 Mapper 监听器，最初才是启动连接器。这很好了解，因为内层组件启动好了能力对外提供服务，能力启动外层的连接器组件。而 Mapper 也依赖容器组件，容器组件启动好了能力监听它们的变动，因而 Mapper 和 MapperListener 在容器组件之后启动。组件进行的程序跟启动程序正好相同的，也是基于它们的依赖关系。

Engine

作为 Container 的顶层组件，所以 Engine 实质就是一个容器，继承了 ContainerBase ，看到抽象类再次使用了模板办法设计模式。ContainerBase 应用一个 HashMap<String, Container> children = new HashMap<>(); 成员变量保留每个组件的子容器。同时应用 protected final Pipeline pipeline = new StandardPipeline(this); Pipeline 组成一个管道用于解决连接器传过来的申请，责任链模式构建管道。

 public class StandardEngine extends ContainerBase implements Engine { }

Engine 的子容器是 Host，所以 children 保留的就是 Host。

咱们来看看 ContainerBase 做了什么...

  • initInternal 定义了容器初始化，同时创立了专门用于启动进行容器的线程池。
  • startInternal：容器启动默认实现，通过组合模式构建容器父子关系，首先获取本人的子容器，应用 startStopExecutor 启动子容器。
public abstract class ContainerBase extends LifecycleMBeanBase        implements Container {   // 提供了默认初始化逻辑    @Override    protected void initInternal() throws LifecycleException {        BlockingQueue<Runnable> startStopQueue = new LinkedBlockingQueue<>();       // 创立线程池用于启动或者进行容器        startStopExecutor = new ThreadPoolExecutor(                getStartStopThreadsInternal(),                getStartStopThreadsInternal(), 10, TimeUnit.SECONDS,                startStopQueue,                new StartStopThreadFactory(getName() + "-startStop-"));        startStopExecutor.allowCoreThreadTimeOut(true);        super.initInternal();    }  // 容器启动    @Override    protected synchronized void startInternal() throws LifecycleException {        // 获取子容器并提交到线程池启动        Container children[] = findChildren();        List<Future<Void>> results = new ArrayList<>();        for (Container child : children) {            results.add(startStopExecutor.submit(new StartChild(child)));        }        MultiThrowable multiThrowable = null;        // 获取启动后果        for (Future<Void> result : results) {            try {                result.get();            } catch (Throwable e) {                log.error(sm.getString("containerBase.threadedStartFailed"), e);                if (multiThrowable == null) {                    multiThrowable = new MultiThrowable();                }                multiThrowable.add(e);            }        }       ......        // 启动 pipeline 管道，用于解决连接器传递过去的申请        if (pipeline instanceof Lifecycle) {            ((Lifecycle) pipeline).start();        }                 // 公布启动事件        setState(LifecycleState.STARTING);        // Start our thread        threadStart();    }}

继承了 LifecycleMBeanBase 也就是还实现了生命周期的治理，提供了子容器默认的启动形式，同时提供了对子容器的 CRUD 性能。

Engine 在启动 Host 容器就是 应用了 ContainerBase 的 startInternal 办法。Engine 本人还做了什么呢？

咱们看下 构造方法，pipeline 设置了 setBasic，创立了 StandardEngineValve。

/**     * Create a new StandardEngine component with the default basic Valve.     */    public StandardEngine() {        super();        pipeline.setBasic(new StandardEngineValve());        .....    }

容器次要的性能就是解决申请，把申请转发给某一个 Host 子容器来解决，具体是通过 Valve 来实现的。每个容器组件都有一个 Pipeline 用于组成一个责任链传递申请。而 Pipeline 中有一个根底阀（Basic Valve），而 Engine 容器的根底阀定义如下：

final class StandardEngineValve extends ValveBase {    @Override    public final void invoke(Request request, Response response)        throws IOException, ServletException {        // 抉择一个适合的 Host 解决申请，通过 Mapper 组件获取到适合的 Host        Host host = request.getHost();        if (host == null) {            response.sendError                (HttpServletResponse.SC_BAD_REQUEST,                 sm.getString("standardEngine.noHost",                              request.getServerName()));            return;        }        if (request.isAsyncSupported()) {            request.setAsyncSupported(host.getPipeline().isAsyncSupported());        }        // 获取 Host 容器的 Pipeline first Valve ,将申请转发到 Host        host.getPipeline().getFirst().invoke(request, response);}

这个根底阀实现非常简单，就是把申请转发到 Host 容器。解决申请的 Host 容器对象是从申请中拿到的，申请对象中怎么会有 Host 容器呢？这是因为申请达到 Engine 容器中之前，Mapper 组件曾经对申请进行了路由解决，Mapper 组件通过申请的 URL 定位了相应的容器，并且把容器对象保留到了申请对象中。

组件设计总结

大家有没有发现，Tomcat 的设计简直都是面向接口设计，也就是通过接口隔离功能设计其实就是繁多职责的体现，每个接口形象对象不同的组件，通过抽象类定义组件的独特执行流程。繁多职责四个字的含意其实就是在这里体现进去了。在剖析过程中，咱们看到了观察者模式、模板办法模式、组合模式、责任链模式以及如何形象组件面向接口设计的设计哲学。

连接器之 I/O 模型与线程池设计

连接器次要性能就是承受 TCP/IP 连贯，限度连接数而后读取数据，最初将申请转发到 Container 容器。所以这里必然波及到 I/O 编程，明天带大家一起剖析 Tomcat 如何使用 I/O 模型实现高并发的，一起进入 I/O 的世界。

I/O 模型次要有 5 种：同步阻塞、同步非阻塞、I/O 多路复用、信号驱动、异步 I/O。是不是很相熟然而又傻傻分不清他们有何区别？

所谓的I/O 就是计算机内存与外部设备之间拷贝数据的过程。

CPU 是先把外部设备的数据读到内存里，而后再进行解决。请考虑一下这个场景，当程序通过 CPU 向外部设备收回一个读指令时，数据从外部设备拷贝到内存往往须要一段时间，这个时候 CPU 没事干了，程序是被动把 CPU 让给他人？还是让 CPU 不停地查：数据到了吗，数据到了吗……

这就是 I/O 模型要解决的问题。明天我会先说说各种 I/O 模型的区别，而后重点剖析 Tomcat 的 NioEndpoint 组件是如何实现非阻塞 I/O 模型的。

I/O 模型

一个网络 I/O 通信过程，比方网络数据读取，会波及到两个对象，别离是调用这个 I/O 操作的用户线程和操作系统内核。一个过程的地址空间分为用户空间和内核空间，用户线程不能间接拜访内核空间。

网络读取次要有两个步骤：

  • 用户线程期待内核将数据从网卡复制到内核空间。
  • 内核将数据从内核空间复制到用户空间。

同理，将数据发送到网络也是一样的流程，将数据从用户线程复制到内核空间，内核空间将数据复制到网卡发送。

不同 I/O 模型的区别：实现这两个步骤的形式不一样。

  • 对于同步，则指的应用程序调用一个办法是否立马返回，而不须要期待。
  • 对于阻塞与非阻塞：次要就是数据从内核复制到用户空间的读写操作是否是阻塞期待的。

同步阻塞 I/O

用户线程发动read调用的时候，线程就阻塞了，只能让出 CPU，而内核则期待网卡数据到来，并把数据从网卡拷贝到内核空间，当内核把数据拷贝到用户空间，再把刚刚阻塞的读取用户线程唤醒，两个步骤的线程都是阻塞的。

同步非阻塞

用户线程始终不停的调用read办法，如果数据还没有复制到内核空间则返回失败，直到数据达到内核空间。用户线程在期待数据从内核空间复制到用户空间的工夫里始终是阻塞的，等数据达到用户空间才被唤醒。循环调用read办法的时候不阻塞。

I/O 多路复用

用户线程的读取操作被划分为两步：

  1. 用户线程先发动 select 调用，次要就是询问内核数据转备好了没？当内核把数据筹备好了就执行第二步。
  2. 用户线程再发动 read 调用，在期待内核把数据从内核空间复制到用户空间的工夫里，发动 read 线程是阻塞的。

为何叫 I/O 多路复用，外围次要就是：一次 select 调用能够向内核查问多个数据通道(Channel)的状态，因而叫多路复用。

异步 I/O

用户线程执行 read 调用的时候会注册一个回调函数， read 调用立刻返回，不会阻塞线程，在期待内核将数据筹备好当前，再调用刚刚注册的回调函数解决数据，在整个过程中用户线程始终没有阻塞。

Tomcat NioEndpoint

Tomcat 的 NioEndpoit 组件实际上就是实现了 I/O 多路复用模型，正式因为这个并发能力才足够优良。让咱们一起窥探下 Tomcat NioEndpoint 的设计原理。

对于 Java 的多路复用器的应用，无非是两步：

  1. 创立一个 Seletor，在它身上注册各种感兴趣的事件，而后调用 select 办法，期待感兴趣的事件产生。
  2. 感兴趣的事件产生了，比方能够读了，这时便创立一个新的线程从 Channel 中读数据。

Tomcat 的 NioEndpoint 组件尽管实现比较复杂，但基本原理就是下面两步。咱们先来看看它有哪些组件，它一共蕴含 LimitLatch、Acceptor、Poller、SocketProcessor 和 Executor 共 5 个组件，它们的工作过程如下图所示：

正是因为应用了 I/O 多路复用，Poller 外部实质就是持有 Java Selector 检测 channel 的 I/O 工夫，当数据可读写的时候创立 SocketProcessor 工作丢到线程池执行，也就是大量线程监听读写事件，接着专属的线程池执行读写，进步性能。

自定义线程池模型

为了进步解决能力和并发度， Web 容器通常会把解决申请的工作放在线程池来解决， Tomcat 拓展了 Java 原生的线程池来晋升并发需要，在进入 Tomcat 线程池原理之前，咱们先回顾下 Java 线程池原理。

Java 线程池

简略的说，Java 线程池里外部保护一个线程数组和一个工作队列，当工作解决不过去的时，就把工作放到队列里缓缓解决。

ThreadPoolExecutor

来窥探线程池外围类的构造函数，咱们须要了解每一个参数的作用，能力了解线程池的工作原理。

    public ThreadPoolExecutor(int corePoolSize,                              int maximumPoolSize,                              long keepAliveTime,                              TimeUnit unit,                              BlockingQueue<Runnable> workQueue,                              ThreadFactory threadFactory,                              RejectedExecutionHandler handler) {        ......    }
  • corePoolSize：保留在池中的线程数，即便它们闲暇，除非设置了 allowCoreThreadTimeOut，不然不会敞开。
  • maximumPoolSize：队列满后池中容许的最大线程数。
  • keepAliveTime、TimeUnit：如果线程数大于外围数，多余的闲暇线程的放弃的最长工夫会被销毁。unit 是 keepAliveTime 参数的工夫单位。当设置 allowCoreThreadTimeOut(true) 时，线程池中 corePoolSize 范畴内的线程闲暇工夫达到 keepAliveTime 也将回收。
  • workQueue：当线程数达到 corePoolSize 后，新增的工作就放到工作队列 workQueue 里，而线程池中的线程则致力地从 workQueue 里拉活来干，也就是调用 poll 办法来获取工作。
  • ThreadFactory：创立线程的工厂，比方设置是否是后盾线程、线程名等。
  • RejectedExecutionHandler：回绝策略，处理程序因为达到了线程界线和队列容量执行回绝策略。也能够自定义回绝策略，只有实现 RejectedExecutionHandler 即可。默认的回绝策略：AbortPolicy 回绝工作并抛出 RejectedExecutionException 异样；CallerRunsPolicy 提交该工作的线程执行；``

来剖析下每个参数之间的关系：

提交新工作的时候，如果线程池数 < corePoolSize，则创立新的线程池执行工作，当线程数 = corePoolSize 时，新的工作就会被放到工作队列 workQueue 中，线程池中的线程尽量从队列里取工作来执行。

如果工作很多，workQueue 满了，且 以后线程数 < maximumPoolSize 时则长期创立线程执行工作，如果总线程数量超过 maximumPoolSize，则不再创立线程，而是执行回绝策略。DiscardPolicy 什么都不做间接抛弃工作；DiscardOldestPolicy 抛弃最旧的未处理程序;

具体执行流程如下图所示：

Tomcat 线程池

定制版的 ThreadPoolExecutor，继承了 java.util.concurrent.ThreadPoolExecutor。 对于线程池有两个很要害的参数：

  • 线程个数。
  • 队列长度。

Tomcat 必然须要限定想着两个参数不然在高并发场景下可能导致 CPU 和内存有资源耗尽的危险。继承了 与 java.util.concurrent.ThreadPoolExecutor 雷同，但实现的效率更高。

其构造方法如下，跟 Java 官网的一模一样

public ThreadPoolExecutor(int corePoolSize, int maximumPoolSize, long keepAliveTime, TimeUnit unit, BlockingQueue<Runnable> workQueue, RejectedExecutionHandler handler) {        super(corePoolSize, maximumPoolSize, keepAliveTime, unit, workQueue, handler);        prestartAllCoreThreads();    }

在 Tomcat 中控制线程池的组件是 StandardThreadExecutor , 也是实现了生命周期接口，上面是启动线程池的代码

    @Override    protected void startInternal() throws LifecycleException {        // 自定义工作队列        taskqueue = new TaskQueue(maxQueueSize);        // 自定义线程工厂        TaskThreadFactory tf = new TaskThreadFactory(namePrefix,daemon,getThreadPriority());       // 创立定制版线程池        executor = new ThreadPoolExecutor(getMinSpareThreads(), getMaxThreads(), maxIdleTime, TimeUnit.MILLISECONDS,taskqueue, tf);        executor.setThreadRenewalDelay(threadRenewalDelay);        if (prestartminSpareThreads) {            executor.prestartAllCoreThreads();        }        taskqueue.setParent(executor);        // 观察者模式，公布启动事件        setState(LifecycleState.STARTING);    }

其中的关键点在于：

  1. Tomcat 有本人的定制版工作队列和线程工厂，并且能够限度工作队列的长度，它的最大长度是 maxQueueSize。
  2. Tomcat 对线程数也有限度，设置了外围线程数（minSpareThreads）和最大线程池数（maxThreads）。

除此之外， Tomcat 在官网原有根底上从新定义了本人的线程池解决流程，原生的解决流程上文曾经说过。

  • 前 corePoolSize 个工作时，来一个工作就创立一个新线程。
  • 还有工作提交，间接放到队列，队列满了，然而没有达到最大线程池数则创立长期线程救火。
  • 线程总线数达到 maximumPoolSize ，间接执行回绝策略。

Tomcat 线程池扩大了原生的 ThreadPoolExecutor，通过重写 execute 办法实现了本人的工作解决逻辑：

  • 前 corePoolSize 个工作时，来一个工作就创立一个新线程。
  • 还有工作提交，间接放到队列，队列满了，然而没有达到最大线程池数则创立长期线程救火。
  • 线程总线数达到 maximumPoolSize ，持续尝试把工作放到队列中。如果队列也满了，插入工作失败，才执行回绝策略。

最大的差异在于 Tomcat 在线程总数达到最大数时，不是立刻执行回绝策略，而是再尝试向工作队列增加工作，增加失败后再执行回绝策略。

代码如下所示:

    public void execute(Runnable command, long timeout, TimeUnit unit) {       // 记录提交工作数 +1        submittedCount.incrementAndGet();        try {            // 调用 java 原生线程池来执行工作，当原生抛出回绝策略            super.execute(command);        } catch (RejectedExecutionException rx) {          //总线程数达到 maximumPoolSize，Java 原生会执行回绝策略            if (super.getQueue() instanceof TaskQueue) {                final TaskQueue queue = (TaskQueue)super.getQueue();                try {                    // 尝试把工作放入队列中                    if (!queue.force(command, timeout, unit)) {                        submittedCount.decrementAndGet();                      // 队列还是满的，插入失败则执行回绝策略                        throw new RejectedExecutionException("Queue capacity is full.");                    }                } catch (InterruptedException x) {                    submittedCount.decrementAndGet();                    throw new RejectedExecutionException(x);                }            } else {              // 提交任务书 -1                submittedCount.decrementAndGet();                throw rx;            }        }    }

Tomcat 线程池是用 submittedCount 来保护曾经提交到了线程池，这跟 Tomcat 的定制版的工作队列无关。Tomcat 的工作队列 TaskQueue 扩大了 Java 中的 LinkedBlockingQueue，咱们晓得 LinkedBlockingQueue 默认状况下长度是没有限度的，除非给它一个 capacity。因而 Tomcat 给了它一个 capacity，TaskQueue 的构造函数中有个整型的参数 capacity，TaskQueue 将 capacity 传给父类 LinkedBlockingQueue 的构造函数，避免有限增加工作导致内存溢出。而且默认是无限度，就会导致以后线程数达到外围线程数之后，再来工作的话线程池会把工作增加到工作队列，并且总是会胜利，这样永远不会有机会创立新线程了。

为了解决这个问题，TaskQueue 重写了 LinkedBlockingQueue 的 offer 办法，在适合的机会返回 false，返回 false 示意工作增加失败，这时线程池会创立新的线程。

public class TaskQueue extends LinkedBlockingQueue<Runnable> {  ...   @Override  // 线程池调用工作队列的办法时，以后线程数必定曾经大于外围线程数了  public boolean offer(Runnable o) {      // 如果线程数曾经到了最大值，不能创立新线程了，只能把工作增加到工作队列。      if (parent.getPoolSize() == parent.getMaximumPoolSize())          return super.offer(o);      // 执行到这里，表明以后线程数大于外围线程数，并且小于最大线程数。      // 表明是能够创立新线程的，那到底要不要创立呢？分两种状况：      //1. 如果已提交的工作数小于以后线程数，示意还有闲暇线程，无需创立新线程      if (parent.getSubmittedCount()<=(parent.getPoolSize()))          return super.offer(o);      //2. 如果已提交的工作数大于以后线程数，线程不够用了，返回 false 去创立新线程      if (parent.getPoolSize()<parent.getMaximumPoolSize())          return false;      // 默认状况下总是把工作增加到工作队列      return super.offer(o);  }}

只有以后线程数大于外围线程数、小于最大线程数，并且已提交的工作个数大于以后线程数时，也就是说线程不够用了，然而线程数又没达到极限，才会去创立新的线程。这就是为什么 Tomcat 须要保护已提交工作数这个变量，它的目标就是在工作队列的长度无限度的状况下，让线程池有机会创立新的线程。能够通过设置 maxQueueSize 参数来限度工作队列的长度。

性能优化

线程池调优

跟 I/O 模型严密相干的是线程池，线程池的调优就是设置正当的线程池参数。咱们先来看看 Tomcat 线程池中有哪些要害参数：

参数详情
threadPriority线程优先级，默认是 5
daemon是否是 后盾线程，默认 true
namePrefix线程名前缀
maxThreads最大线程数，默认 200
minSpareThreads最小线程数（闲暇超过肯定工夫会被回收），默认 25
maxIdleTime线程最大闲暇工夫，超过该工夫的会被回收，直到只有 minSpareThreads 个。默认是 1 分钟
maxQueueSize工作队列最大长度
prestartAllCoreThreads是否在线程池启动的时候就创立 minSpareThreads 个线程，默认是 fasle

这外面最外围的就是如何确定 maxThreads 的值，如果这个参数设置小了，Tomcat 会产生线程饥饿，并且申请的解决会在队列中排队期待，导致响应工夫变长；如果 maxThreads 参数值过大，同样也会有问题，因为服务器的 CPU 的核数无限，线程数太多会导致线程在 CPU 上来回切换，消耗大量的切换开销。

线程 I/O 工夫与 CPU 工夫

至此咱们又失去一个线程池个数的计算公式，假如服务器是单核的：

线程池大小 = （线程 I/O 阻塞工夫 + 线程 CPU 工夫 ）/ 线程 CPU 工夫

其中：线程 I/O 阻塞工夫 + 线程 CPU 工夫 = 均匀申请解决工夫。

Tomcat 内存溢出的起因剖析及调优

JVM 在抛出 java.lang.OutOfMemoryError 时，除了会打印出一行形容信息，还会打印堆栈跟踪，因而咱们能够通过这些信息来找到导致异样的起因。在寻找起因前，咱们先来看看有哪些因素会导致 OutOfMemoryError，其中内存透露是导致 OutOfMemoryError 的一个比拟常见的起因。

其实调优很多时候都是在找零碎瓶颈，如果有个情况：零碎响应比较慢，但 CPU 的用率不高，内存有所增加，通过剖析 Heap Dump 发现大量申请沉积在线程池的队列中，请问这种状况下应该怎么办呢？可能是申请解决工夫太长，去排查是不是拜访数据库或者内部利用遇到了提早。

java.lang.OutOfMemoryError: Java heap space

当 JVM 无奈在堆中调配对象的会抛出此异样，个别有以下起因：

  1. 内存透露：本该回收的对象呗程序始终持有援用导致对象无奈被回收，比方在线程池中应用 ThreadLocal、对象池、内存池。为了找到内存透露点，咱们通过 jmap 工具生成 Heap Dump，再利用 MAT 剖析找到内存透露点。jmap -dump:live,format=b,file=filename.bin pid
  2. 内存不足：咱们设置的堆大小对于应用程序来说不够，批改 JVM 参数调整堆大小，比方 -Xms256m -Xmx2048m。
  3. finalize 办法的适度应用。如果咱们想在 Java 类实例被 GC 之前执行一些逻辑，比方清理对象持有的资源，能够在 Java 类中定义 finalize 办法，这样 JVM GC 不会立刻回收这些对象实例，而是将对象实例增加到一个叫“java.lang.ref.Finalizer.ReferenceQueue”的队列中，执行对象的 finalize 办法，之后才会回收这些对象。Finalizer 线程会和主线程竞争 CPU 资源，但因为优先级低，所以处理速度跟不上主线程创建对象的速度，因而 ReferenceQueue 队列中的对象就越来越多，最终会抛出 OutOfMemoryError。解决办法是尽量不要给 Java 类定义 finalize 办法。

java.lang.OutOfMemoryError: GC overhead limit exceeded

垃圾收集器继续运行，然而效率很低简直没有回收内存。比方 Java 过程破费超过 96％的 CPU 工夫来进行一次 GC，然而回收的内存少于 3％的 JVM 堆，并且间断 5 次 GC 都是这种状况，就会抛出 OutOfMemoryError。

这个问题 IDE 解决办法就是查看 GC 日志或者生成 Heap Dump，先确认是否是内存溢出，不是的话能够尝试减少堆大小。能够通过如下 JVM 启动参数打印 GC 日志:

-verbose:gc //在控制台输入GC状况-XX:+PrintGCDetails  //在控制台输入具体的GC状况-Xloggc: filepath  //将GC日志输入到指定文件中

比方 能够应用 java -verbose:gc -Xloggc:gc.log -XX:+PrintGCDetails -jar xxx.jar 记录 GC 日志，通过 GCViewer 工具查看 GC 日志，用 GCViewer 关上产生的 gc.log 剖析垃圾回收状况。

java.lang.OutOfMemoryError: Requested array size exceeds VM limit

抛出这种异样的起因是“申请的数组大小超过 JVM 限度”，应用程序尝试调配一个超大的数组。比方程序尝试调配 128M 的数组，然而堆最大 100M，个别这个也是配置问题，有可能 JVM 堆设置太小，也有可能是程序的 bug，是不是创立了超大数组。

java.lang.OutOfMemoryError: MetaSpace

JVM 元空间的内存在本地内存中调配，然而它的大小受参数 MaxMetaSpaceSize 的限度。当元空间大小超过 MaxMetaSpaceSize 时，JVM 将抛出带有 MetaSpace 字样的 OutOfMemoryError。解决办法是加大 MaxMetaSpaceSize 参数的值。

java.lang.OutOfMemoryError: Request size bytes for reason. Out of swap space

当本地堆内存调配失败或者本地内存快要耗尽时，Java HotSpot VM 代码会抛出这个异样，VM 会触发“致命错误处理机制”，它会生成“致命谬误”日志文件，其中蕴含解体时线程、过程和操作系统的有用信息。如果碰到此类型的 OutOfMemoryError，你须要依据 JVM 抛出的错误信息来进行诊断；或者应用操作系统提供的 DTrace 工具来跟踪零碎调用，看看是什么样的程序代码在一直地调配本地内存。

java.lang.OutOfMemoryError: Unable to create native threads

  1. Java 程序向 JVM 申请创立一个新的 Java 线程。
  2. JVM 本地代码（Native Code）代理该申请，通过调用操作系统 API 去创立一个操作系统级别的线程 Native Thread。
  3. 操作系统尝试创立一个新的 Native Thread，须要同时调配一些内存给该线程，每一个 Native Thread 都有一个线程栈，线程栈的大小由 JVM 参数-Xss决定。
  4. 因为各种起因，操作系统创立新的线程可能会失败，上面会具体谈到。
  5. JVM 抛出“java.lang.OutOfMemoryError: Unable to create new native thread”谬误。

这里只是概述场景，对于生产在线排查后续会陆续推出，受限于篇幅不再开展。关注「码哥字节」给你硬货来啃！

总结

回顾 Tomcat 总结架构设计，具体拆解 Tomcat 如何解决高并发连贯设计。并且分享了如何高效浏览开源框架源码思路，设计模式、并发编程根底是重中之重，读者敌人能够翻阅历史「码哥字节」的历史文章学习。

举荐浏览

Tomcat 架构解析到工作借鉴

设计模式专辑

并发编程实战

拆解 Tomcat 外围组件，去领会 Tomcat 如何面向接口设计、落实繁多职责的设计哲学思想。接着概括了 连接器波及到的 I/O 模型，并对不同的 I/O 模型进行了详解，接着看 Tomcat 如何实现 NIO，如何自定义线程池以及队列实现高并发设计，最初简略分享常见的 OOM 场景以及解决思路，限于篇幅不再具体开展，关注「码哥字节」后续会分享各种线上故障排查调优思路，敬请期待…...

有任何疑难或者计数探讨能够加集体微信：MageByte1024，一起学习提高。

也能够通过公众号菜单退出技术群，外面有阿里、腾讯的大佬。

编写文章不易，如果浏览后感觉有用，心愿关注「码哥字节」公众号，点击「分享」、「点赞」、「在看」是最大的激励。