关于linux:Java-并发编程解析-如何正确理解Java领域中的多线程模型主要用来解决什么问题

天穹之边，浩瀚之挚，眰恦之美；悟心悟性，虎头蛇尾，惟善惟道！—— 朝槿《朝槿兮年说》

写在结尾

我国宋代禅宗巨匠青原行思在《三重境界》中有这样一句话：“参禅之初，看山是山，看水是水；禅有悟时，看山不是山，看水不是水；禅中彻悟，看山依然山，看水依然是水。”

作为一名 Java Developer，在面对 Java 并发编程的时候，有过哪些的纳闷与不解？对于 Java 畛域中的线程机制与多线程，你都做了哪些功课？是否和我一样，在看完《Java 编程思维》和《Java 并发编程实战》之后，仍旧一头雾水，不知其迹？那么，心愿你看完此篇文章之后，对你有所帮忙。

从肯定水平上说，Java 并发编程之路，实则是一条“看山是山，看山不是山，看山还是山”的修行之路。大多数状况下，当咱们感觉有迹可循到有迹可寻时，何尝不是陷入了另外一个“怪圈”之中？

从搭载 Linux 零碎上的服务器程序来说，应用 Java 编写的是”单过程 - 多线程 ” 程序, 而用 C ++ 语言编写的，可能是“单过程 - 多线程”程序，“多过程 - 单线程”程序或者是“多过程 - 多线程”程序。其中，“多过程 - 多线程”程序是”单过程 - 多线程 ” 程序和“多过程 - 单线程”程序的组合体。

绝对于操作系统内核来说，Java 程序属于应用程序，只能在这一个过程外面，个别咱们都是间接利用 JDK 提供的 API 开发多个线程实现并发。

而 C ++ 间接运行在 Linux 零碎上，能够间接利用 Linux 零碎提供的弱小的过程间通信(Inter-Process Communication，IPC), 很容易创立多个过程实现并发程序，并实现过程间通信。

然而，多线程的开发难度远远高于单线程的开发，次要是须要解决线程间的通信，须要对线程并发做管制，须要做好线程间的协调工作。

对于固定负载状况下，在形容和钻研计算并发零碎解决能力，以及形容并行处理成果的减速比，始终有一个比拟驰名的计算公式:

就是咱们熟知的阿姆达尔定律(Amdahl”s Law)，在这个公式中，

[1]. P：指的是程序中可并行局部的程序在单核上执行的工夫占比。个别用作示意可改良性能的部件原先运行占用的工夫与零碎整体运行须要的工夫的比值，取值范畴是 0 ≤ P ≤ 1。

[2]. S：指的是处理器的个数(总外围数)。个别用作示意降级减速比，可改良部件原先运行速度与改良后的部件速度的比值，取值范畴是 S ≥ 1。

[3]. Slatency(s)：指的是程序在 S 个处理器绝对在单个处理器 (单核) 中速度晋升比率。个别用作示意整个工作的提速比。

依据这个公式，咱们能够根据可确定程序中可并行代码的比例，来决定咱们理论工作中减少处理器 (总外围数) 所能带来的速度晋升的下限。

无论是 C ++ 开发者在 Linux 零碎中应用的 pthread，还是 Java 开发者应用的 java.util.concurrent(JUC)库，这些线程机制的都须要肯定的线程 I / O 模型来做实践撑持。

所以，接下来，咱们就让咱们一起探讨和揭开 Java 畛域中的线程 I / O 模型的神秘面纱，针对那些盘根错落的枝末细节，能力让咱们更好地理解和正确认识 ava 畛域中的线程机制。

关健术语

本文用到的一些要害词语以及罕用术语，次要如下：

• 阿姆达尔定律(Amdahl 定律): 用于确定并发零碎中性能瓶颈部件在采纳措施提示性能后，此部件对系统性能提醒的改良水平，即零碎减速比。
• 工作(Task): 示意一个程序须要被实现工作内容，与线程非一对一对应的关系，是一个绝对概念。
• 并发(Concurrent): 示意至多一个工作或者若干 个工作同一个时间段内被执行，然而不是程序执行，大多数都是以交替的形式被执行。
• 并行(Parallel): 示意至多一个工作或者若干 个工作同一个时刻被执行。次要是指一个并行连贯通过多个通道在同一时间内流传多个数据流。
• 串行(Serial): 示意至少一个工作或者只有一个 个工作同一个时刻被执行。次要是指在同一时间内只连贯传输一个数据流。
• 内核线程 (Kernel Thread): 示意由内核治理的线程，处于操作系统内核空间。用户应用程序通过 API 和零碎调用(system call) 来拜访线程工具。
• 利用线程(Application Thread): 示意不须要内核反对而在用户应用程序中实现的线程，处于应用程序空间，也称作用户线程。次要是由 JVM 治理的线程和 JVM 本人携带的 JVM 线程。
• 上下文切换(Context Switch): 个别是指工作切换, 或者 CPU 寄存器切换。当多任务内核决定运行另外的工作时, 它保留正在运行工作的以后状态, 也就是 CPU 寄存器中的全部内容。这些内容被保留在工作本人的堆栈中, 入栈工作实现后就把下一个将要运行的工作的当前状况从该工作的栈中从新装入 CPU 寄存器, 并开始下一个工作的运行过程。在 Java 畛域中，线程有生命周期，其上下文信息的保留和复原的过程。
• 线程平安(Thread Safe): 一段操作共享数据的代码可能保障同一个工夫内被多个线程执行而仍然保障其数据的正确性的考量。

根本概述

Java 畛域中的线程次要分为 Java 层线程(Java Thread) ,JVM 层线程(JVM Thread), 操作系统层线程(Kernel Thread)。

对于 Java 畛域中，从肯定水平上来说，因为 Java 程序并不间接运行在 Linux 零碎上，而是运行在 JVM(Java 虚拟机)上，而一个 JVM 实例是一个 Linux 过程，每一个 JVM 都是一个独立的“沙盒”，JVM 之间互相独立，互不通信。

依照操作系统和应用程序两个档次来说，线程次要能够分为内核线程(Kernel Thread) 和利用线程(Application Thread)。

其中，在 Java 畛域中的线程次要分为 Java 层线程(Java Thread) ,JVM 层线程(JVM Thread), 操作系统层线程(Kernel Thread)。

一般来说，咱们把利用线程看作更高层面的线程，而内核线程须要向利用线程提供反对。由此可见，内核线程和利用线程之间存在肯定的映射关系。

因而，从线程映射关系来看，不同的操作系统可能采纳不同的映射形式，咱们把这些映射关系称为线程的映射，或者能够说作线程映射实践模型(Thread Mappered Theory Model)。

在 Java 畛域中，对于文件的 I / O 操作，提供了一系列的 I / O 性能 API，次要基于基于流模型实现。咱们把这些流模型的设计，称作为 I / O 流模型(I/O Stream Model)。

其中，Java 对照操作系统内核以及网络通信 I / O 中的传统 BIO 来说，提供并反对了 NIO 和 AIO 的性能 API 设计，咱们把这些设计，称作为线程 I / O 参考模型(Thread I/O Reference Model)。

另外，对于 NIO 和 AIO 还参考了肯定的设计模式来实现，咱们把这些基于设计模式的设计，称作为线程设计模式模型(Thread I/O Design Pattern Model)。

综上所述，在 Java 畛域中，咱们在学习和把握 Java 并发编程的时候，能够依照：线程映射实践模型 ->I/ O 流模型 -> 线程 I / O 参考模型 -> 线程设计模式模型 -> 线程价值模型等脉络来一一进行比照剖析。

一. Java 畛域中的线程映射实践模型

Java 畛域中的线程映射模型次要有内核级线程模型 (Kernel-Level Thread，KLT)、利用级线程模型(Application-Level Thread，ALT)、混合两级线程模型(Mixture-Level Thread，MLT) 等 3 种模型。

从 Java 线程映射类型来看，次要有线程一对一 (1:1) 映射，线程多对多 (M:1) 映射，线程多对多 (M:N) 映射等关系。

对应到线程模型来说，线程一对一 (1:1) 映射对应着内核线程 (Kernel-Level Thread，KLT), 线程多对多(M:1) 映射对应着利用级线程 (Application-Level Thread，ALT)，线程多对多(M:N) 映射对应着混合两级线程(Mixture-Level Thread，MLT)。

因而，Java 畛域中实现多线程次要有 3 种模型：内核级线程模型、利用级线程模型、混合两级线程模型。它们之间最大的差别就在于线程与内核调度实体 (Kernel Scheduling Entity, 简称 KSE) 之间的对应关系上。

顾名思义，内核调度实体就是能够被内核的调度器调度的对象, 因而称为内核级线程，是操作系统内核的最小调度单元。

综上所述，接下来，咱们来具体探讨 Java 畛域中的线程映射实践模型。

1. 利用级线程模型

利用级线程模型次要是指(Application-Level Thread，ALT)，就是多个用户线程映射到同一个内核线程上，用户线程的创立、调度、同步的所有操作全部都是由用户空间的线程来实现的。

在 Java 畛域中，利用级线程次要是指 Java 语言编写应用程序的 Java 线程 (Java Thread) 和 JVM 虚拟机中 JVM 线程(JVM Thread)。

在利用级线程模型下，齐全建设在用户空间的线程库上，不依赖于零碎内核，用户线程的创立、同步、切换和销毁等操作齐全在用户态执行，不须要切换到内核态。

其中，用户过程应用零碎内核提供的接口——轻量级过程 (Light Weight Process，LWP) 来应用零碎内核线程。

在此种线程模型下，因为一个用户线程对应一个 LWP，因而某个 LWP 在调用过程中阻塞了不会影响整个过程的执行。

然而各种线程的操作都须要在用户态和内核态之间频繁切换，耗费太大，速度绝对用户线程模型来说要慢。

2. 内核级线程模型

内核级线程模型次要是指(Kernel-Level Thread，KLT)，用户线程与内核线程建设了一对一的关系，即一个用户线程对应一个内核线程，内核负责每个线程的调度。

在 Linux 中，对于内核级线程，操作系统会为其创立一套栈：用户栈 + 内核栈，其中用户栈工作在用户态，内核栈工作在内核态，在产生零碎调用时，线程的执行会从用户栈切换到内核栈。

在内核级线程模型下，齐全依赖操作系统内核提供的内核线程来实现多线程。线程的切换调度由零碎内核实现，零碎内核负责将多个线程执行的工作映射到各个 CPU 中去执行。

其中，glibc 中的 pthread_create 办法次要是创立一个 OS 内核级线程，咱们不深刻细节，次要是为该线程调配了栈资源；须要留神的是这个栈资源对于 JVM 而言是堆外内存，因而堆外内存的大小会影响 JVM 能够创立的线程数。

在 JVM 概念中，JVM 栈用来执行 Java 办法，而本地办法栈用来执行 native 办法；但须要留神的是 JVM 只是在概念上辨别了这两种栈，而并没有规定如何实现。

在 HotSpot 中，则是将 JVM 栈与本地办法栈二合一，应用外围线程的用户栈来实现(因为 JVM 栈和本地办法栈都是属于用户态的栈)，即 Java 办法与 native 办法都在同一个用户栈中调用，而当产生零碎调用时，再切换到外围栈运行。

这种设计的益处是线程的各种操作以及切换耗费很低；

然而线程的所有操作都须要在用户态实现，线程的调度实现起来异样简单，并且零碎内核对 ULT 无感知，如果线程阻塞则会引起整个过程的阻塞。

3. 混合两级线程模型

混合两级线程模型次要是指(Mixture-Level Thread，MLT)，是利用级线程模型和内核级线程模型等两种模型的混合版本，用户线程依然是在用户态中创立，用户线程的创立、切换和销毁的耗费很低，用户线程的数量不受限制。

对于混合两级线程模型，是利用级线程模型和内核级线程模型等两种模型的混合版本，次要是充沛排汇后面两种线程模型的长处且尽量躲避它们的毛病。

在此模型下用户线程与内核线程是多对多（M : N，通常 M >= N）的映射模型。次要是保护一个轻量级过程(Light Weight Process，LWP)，在用户线程和内核线程之间充当桥梁，就能够应用操作系统提供的线程调度和处理器映射性能。

一般来说，Java 虚拟机应用的线程模型是基于操作系统提供的原生线程模型来实现的，Windows 零碎和 Linux 零碎都是应用的内核线程模型，而 Solaris 零碎反对混合线程模型和内核线程模型两种实现。

还有，Java 线程内存模型中，能够将虚拟机内存划分为两局部内存：主内存和线程工作内存，主内存是多个线程共享的内存，线程工作内存是每个线程独享的内存。办法区和堆内存就是主内存区域，而虚拟机栈、本地办法栈以及程序计数器则属于每个线程独享的工作内存。

Java 内存模型规定所有成员变量都须要存储在主内存中，线程会在其工作内存中保留须要应用的成员变量的拷贝，线程对成员变量的操作 (读取和赋值等) 都是对其工作内存中的拷贝进行操作。各个线程之间不能相互拜访工作内存，线程间变量的传递须要通过主内存来实现。

二. Java 畛域中的 I / O 流模型

Java 畛域中的 I / O 模型次要指 Java 畛域中的 I / O 模型大抵能够分为字符流 I / O 模型，字节流 I / O 模型以及网络通信 I / O 模型。

在编程语言的 I / O 类库中常应用流 (Stream) 这个概念，代表了任何有能力产出数据的数据源对象或者是有能力接收数据的接收端对象。

流是个形象的概念, 是对输入输出设施的高度形象，一般来说，编程语言都会波及输出流和输入流两局部。

肯定意义上来说，输出流能够看作一个输出通道，输入流能够看作一个输入通道，其中：

• 输出流是绝对程序而言的，内部传入数据给程序须要借助输出流。
• 输入流是绝对程序而言的，程序把数据传输到内部须要借助输入流。

因为，“流”模型屏蔽了理论的 I / O 设施中解决数据的细节，这就意味着咱们只须要依据相干的根底 API 的性能和设计，便可实现数据处理和交互。

Java IO 形式有很多种，基于不同的 IO 形象模型和交互方式，能够进行简略辨别：
第一，传统的 java.io 包，它基于流模型实现，提供了咱们最熟知的一些 IO 性能，比方 File 形象、输入输出流等。交互方式是同步、阻塞的形式，也就是说，在读取输出流或者写入输入流时，在读、写动作实现之前，线程会始终阻塞在那里，它们之间的调用是牢靠的线性程序。java.io 包的益处是代码比较简单、直观，毛病则是 IO 效率和扩展性存在局限性，容易成为利用性能的瓶颈。

很多时候，人们也把 java.net 上面提供的局部网络 API，比方 Socket、ServerSocket、HttpURLConnection 也归类到同步阻塞 IO 类库，因为网络通信同样是 IO 行为。

第二，在 Java 1.4 中引入了 NIO 框架（java.nio 包），提供了 Channel、Selector、Buffer 等新的形象，能够构建多路复用的、同步非阻塞 IO 程序，同时提供了更靠近操作系统底层的高性能数据操作形式。

第三，在 Java 7 中，NIO 有了进一步的改良，也就是 NIO 2，引入了异步非阻塞 IO 形式，也有很多人叫它 AIO（Asynchronous IO）。异步 IO 操作基于事件和回调机制，能够简略了解为，利用操作间接返回，而不会阻塞在那里，当后盾解决实现，操作系统会告诉相应线程进行后续工作。

其中，Java 类库中的 I / O 类分成输出和输入两局部，次要是对应着实现咱们与计算机操作交互时的一种标准和束缚，然而对于不同的数据有着不同的实现。

综上所述，Java 畛域中的 I / O 模型大抵能够分为字符流 I / O 模型，字节流 I / O 模型以及网络通信 I / O 模型等 3 类。

1. 字节流 I / O 模型

字节流 I / O 模型是指在 I / O 操作，数据传输过程中，传输数据的最根本单位是字节的流，依照 8 位传输字节为单位输出 / 输入数据。

在 Java 畛域中，对字节流的类通常以 stream 结尾，对于字节数据的操作，提供了输出流(InputStream)、输入流（OutputStream）这样式的设计，是用于读取或写入字节的根底 API，个别罕用于操作相似文本或者图片文件。

2. 字符流 I / O 模型

字符流 I / O 模型是指在 I / O 操作，数据传输过程中，传输数据的最根本单位是字符的流，依照 16 位传输字符为单位输出 / 输入数据。

在 Java 畛域中，对字符流的类通常以 reader 和 writer 结尾，对于字节数据的操作，提供了输出流(Reader)、输入流（Writer）这样式的设计，是用于读取或写入字节的根底 API，个别罕用于相似从文件中读取或者写入文本信息。

3. 网络通信 I / O 模型

网络通信 I / O 模型是指 java.net 下，提供的局部网络 API，比方 Socket、ServerSocket、HttpURLConnection 等 IO 类库，实现网络通信同样是 IO 行为。

在 Java 畛域中，NIO 提供了与传统 BIO 模型中的 Socket 和 ServerSocket 绝对应的 SocketChannel 和 ServerSocketChannel 两种不同的套接字通道实现。SocketChannel 能够看作是 socket 的一个欠缺类，除了提供 Socket 的相干性能外，还提供了许多其余个性，如前面要讲到的向选择器注册的性能。

其中，新增的 SocketChannel 和 ServerSocketChannel 两种通道都反对阻塞和非阻塞两种模式。

三. Java 畛域中的线程 I / O 参考模型

在 Java 畛域中，咱们对照线程概念 (单线程和多线程) 来说，能够分为 Java 线程 - 阻塞 I / O 模型和 Java 线程 - 非阻塞 I / O 模型两种。

因为阻塞与非阻塞次要是针对于应用程序对于零碎函数调用角度来限定的，从阻塞与非阻塞的意义上来说，I/ O 能够分为阻塞 I / O 和非阻塞 I / O 两种大类。其中：

• 阻 塞 I/O：进行 I / O 操作时，使以后线程进入阻塞状态，从具体应用程序来看，如果当一次 I / O 操作 (Read/Write) 没有就绪或者没有实现，则函数调用则会始终处于期待状态。
• 非阻塞 I /O：进行 I / O 操作时，使以后线程不进入阻塞状态，从具体应用程序来看，如果当一次 I / O 操作 (Read/Write) 即便没有就绪或者没有实现，则函数调用立刻返回后果，而后由应用程序轮询解决。

而同步与异步次要正针对应用程序对于零碎函数调用后，其 I / O 操作中读 / 写 (Read/Write) 是由谁实现来限定的，I/ O 能够分为同步 I / O 和异步 I / O 两种大类。其中：

• 同步 I /O：进行 I / O 操作时，能够使以后线程进入进入阻塞或或非阻塞状态，从具体应用程序来看，如果当一次 I / O 操作 (Read/Write) 都是托管给应用程序来实现。
• 异步 I /O：进行 I / O 操作时，能够使以后线程进入进入非阻塞状态，从具体应用程序来看，如果当一次 I / O 操作 (Read/Write) 都是托管给操作系统来实现，实现后回调或者事件告诉应用程序。

由此可见，依照这些个定义能够晓得：

• 当程序在执行 I / O 操作时，经典的网络 I / O 操作 (Read/Write) 场景，次要能够分为阻塞 I /O，非阻塞 I /O，单线程以及多线程等场景。
• 异步 I / O 肯定是非阻塞 I /O，不存在是异步还阻塞的状况；同步 I / O 可能存在阻塞或或非阻塞的状况，还有可能是 I / O 线程多路复用的状况。

因而，咱们能够对其线程 I / O 模型来说，I/ O 能够分为同步 - 阻塞 I / O 和同步 - 非阻塞 I /O，以及异步 I / O 等 3 种，其中 I / O 多路复用属于同步 - 阻塞 I /O。

综上所所述,，在 Java 畛域中，咱们对照线程概念 (单线程和多线程) 来说，能够分为 Java 线程 - 阻塞 I / O 模型和 Java 线程 - 非阻塞 I / O 模型两种。接下来，咱们就具体地来探讨一下。

(一). Java 线程阻塞 I / O 模型

Java 线程 - 阻塞 I / O 模型次要能够分为单线程阻塞 I / O 模型和多线程阻塞 I / O 模型。

从一个服务器解决客户端连贯来说，单线程状况下，个别都是以一个线程负责解决所有客户端连贯的 I / O 操作 (Read/Write) 操作。

程序在执行 I / O 操作，个别都是从内核空间复制数据，但内核空间的数据可能须要很长的工夫去筹备数据，由此很有可能导致用户空间产生阻塞。

其产生阻塞的过程，次要如下：

• 应用程序发动 I / O 操作 (Read/Write) 之后，进入阻塞状态，而后提交给操作系统内核实现 I / O 操作。
• 当内核没有筹备数据，须要一直从网络中读取数据，一旦准备就绪，则将数据复制到用户空间供应用程序应用。
• 应用程序从发动读取数据操作到继续执行后续解决的这段时间，便是咱们说的阻塞状态。

由此可见，引入 Java 线程的概念，咱们能够把 Java 线程 - 阻塞 I / O 模型次要能够分为单线程阻塞 I / O 模型和多线程阻塞 I / O 模型。

1. 单线程阻塞 I / O 模型

单线程阻塞 I / O 模型次要是指对于多个客户端拜访时，只能同时解决一个客户端的拜访，并且在 I / O 操作上是阻塞的，线程会始终处于期待状态，直到以后线程中前一个客户端拜访完结后，才持续开始下一个客户端的拜访。

单线程阻塞 I / O 模型是最简略的服务器模型，是 Java Developer 面对网络编程最根底的模型。

因为对于多个客户端拜访时，只能同时解决一个客户端的拜访，并且在 I / O 操作上是阻塞的，线程会始终处于期待状态，直到以后线程中前一个客户端拜访完结后，才持续开始下一个客户端的拜访。

也就意味着，客户端的拜访申请须要一个一个排队期待，只提供一问一答的服务机制。

这种模型的特点，次要在于单线程和阻塞 I /O。其中：

• 单线程：指的是服务器端只有一个线程解决客户端的申请，客户端连贯与服务器端的解决线程比例关系为 N：1, 无奈同时解决多个连贯，只能串行形式连贯解决。
• 阻塞 I /O：服务器在 I / O 操作 (Read/Write) 操作时是阻塞的，次要体现在读取客户端数据时，须要期待客户端发送数据并且把操作系统内核中的数据复制到用户空间中的用户线程中，实现后才解除阻塞状态；同时，数据回写客户端要期待用户过程把数据写入到操作系统零碎内核后才解除阻塞状态。

综上所述，单线程阻塞 I / O 模型最显著的特点就是服务机制简略，服务器的系统资源开销小，然而并发能力低，容错能力也低。

2. 多线程阻塞 I / O 模型

多线程阻塞 I / O 模型次要是指对于多个客户端拜访时，利用多线程机制为每一个客户端的拜访调配独立线程，实现同时解决，并且在 I / O 操作上是阻塞的，线程不会始终处于期待状态，而是并发解决客户端的申请拜访。

多线程阻塞 I / O 模型是针对于单线程阻塞 I / O 模型的毛病，对其进行多线程化改良，使之能对于多个客户端的申请拜访实现并发响应解决。

也就意味着，客户端的拜访申请不须要一个一个排队期待，利用多线程机制为每一个客户端的拜访调配独立线程。

这种模型的特点，次要在于多线程和阻塞 I /O。其中：

• 多线程：指的是服务器端至多有一个线程或者若干个线程解决客户端的申请，客户端连贯与服务器端的解决线程比例关系为 M：N, 并发同时解决多个连贯，能够并行形式连贯解决。但客户端连贯与服务器解决线程的关系是一对一的。
• 阻塞 I /O：服务器在 I / O 操作 (Read/Write) 操作时是阻塞的，次要体现在读取客户端数据时，须要期待客户端发送数据并且把操作系统内核中的数据复制到用户空间中的用户线程中，实现后才解除阻塞状态；同时，数据回写客户端要期待用户过程把数据写入到操作系统零碎内核后才解除阻塞状态。

综上所述，多线程阻塞 I / O 模型最显著的特点就是反对多个客户端并发响应，解决能力失去极大进步，有肯定的并发能力和容错能力，然而服务器资源耗费较大，且多线程之间会产生线程切换老本，构造也比较复杂。

(二). Java 线程非阻塞 I / O 模型

Java 线程 - 非阻塞 I / O 模型次要能够分为应用层 I / O 多路复用模型和内核层 I / O 多路复用模型，以及内核回调事件驱动 I / O 模型。

从一个服务器解决客户端连贯来说，多线程状况下，个别都是至多一个线程或者若干个线程负责解决所有客户端连贯的 I / O 操作 (Read/Write) 操作。

非阻塞 I / O 模型与阻塞 I / O 模型，雷同的中央在于是程序在执行 I / O 操作，个别都是从内核空间和利用空间复制数据。

与之不同的是，非阻塞 I / O 模型不会始终等到内核空间筹备好数据，而是立刻返回去做其余的事，因而不会产生阻塞。其中：

• 应用程序中的用户线程蕴含一个缓冲区，单个线程会一直轮询客户端，以及一直尝试进行 I /O(Read/Write)操作。
• 一旦内核准好数据，应用程序中的用户线程就会把数据复制到用户空间应用。

由此可见，咱们能够把 Java 线程 - 非阻塞 I / O 模型次要能够分为应用层 I / O 多路复用模型和内核层 I / O 多路复用模型，以及内核回调事件驱动 I / O 模型。

1. 应用层 I / O 多路复用模型

应用层 I / O 多路复用模型次要是指当多个客户端向服务器发出请求时，服务器会将每一个客户端连贯保护到一个 socket 列表中，应用程序中的用户线程会一直轮询 sockst 列表中的客户端连贯申请拜访，并尝试进行读写。

应用层 I / O 多路复用模型最大的特点就是，不管有多少个 socket 连贯，都能够应用应用程序中的用户线程的一个线程来治理。

这个线程负责轮询 socket 列表，一直进行尝试进行 I /O(Read/Write)操作，其中：

• I/O(Read)操作：如果胜利读取数据，则对数据进行解决。反之，如果失败，则下一个循环再持续尝试。
• I/O(Write)操作：须要先尝试把数据写入指定的 socket，直到调用胜利完结。反之，如果失败，则下一个循环再持续尝试。

这种模型，尽管很好地利用了阻塞的工夫，使得批处理能晋升。然而因为一直轮询 sockst 列表，同时也须要解决数据的拼接。

2. 内核层 I / O 多路复用模型

内核层 I / O 多路复用模型次要是指当多个客户端向服务器发出请求时，服务器会将每一个客户端连贯保护到一个 socket 列表中，操作系统内核一直轮询 sockst 列表，并把遍历后果组织列举成一系列的事件，并驱动事件返回到应用层解决，最初托管给应用程序中的用户线程依照须要解决对应的事件对象。

内核层 I / O 多路复用模型与应用层 I / O 多路复用模型，最大的不同就是，轮询 sockst 列表是操作系统内核来实现的，有助于检测效率。

操作系统内核负责轮询 socket 列表的过程，其中：

• 首先，最次要的就是将所有连贯的标记为可读事件和可写事件列表，最初传入到应用程序的用户空间解决。
• 而后，操作系统内核复制数据到应用层的用户空间的用户线程，会随着 socket 数量的减少，也会造成不小的开销。
• 另外，当沉闷连接数比拟少时，内核空间和用户空间会存在很多有效的数据正本，并且不论是否沉闷，都会复制到用户空间的应用层。

3. 内核回调事件驱动 I / O 模型

内核回调事件驱动 I / O 模型次要是指当多个客户端向服务器发出请求时，服务器会将每一个客户端连贯保护到一个 socket 列表中，操作系统内核一直轮询 sockst 列表，利用回调函数来检测 socket 列表是否可读可写的一种事件驱动 I / O 机制。

不论是内核层的轮询 sockst 列表，还是应用层的轮询 sockst 列表，通过循环遍历的形式来检测 socket 列表是否可读可写的操作形式，其效率都比拟低效。

为了寻求一种高效的机制来优化循环遍历形式，因而，提出了会回调函数事件驱动机制。其中，次要是：

• 内核空间：当客户端往 socket 发送数据时，内核中 socket 都对应着一个回调函数，内核就能够间接从网卡中接收数据后，间接调用回调函数。
• 利用空间：回调函数会保护一个事件列表，应用层则获取事件即能够失去感兴趣的事件，而后进行后续操作。

一般来说，内核回调事件驱动的形式次要有 2 种：

• 第一种：利用可读列表 (ReadList) 和可写列表 (WriteList) 来标记读事件 (Read-Event)/ 写事件(Write-Event) 来进行 I /O(Read/Write)操作。
• 第二种：利用在应用层中间接指定 socket 感兴趣的事件，通过保护事件列表 (EventList) 再来进行 I /O(Read/Write)操作。

综上所述，这两种形式都是有操作系统内核保护客户端中的所有连贯，再通过回调函数不断更新事件列表，利用空间中的应用层的用户线程只须要依据轮询遍历事件列表即可晓得是否进行 I /O(Read/Write)操作。

由此可见，这种形式极大地提高了检测效率，也加强了数据处理能力。

特地指出，在 Java 畛域中，非阻塞 I / O 的实现齐全是基于操作系统内核的非阻塞 I /O，Java 把操作系统中的非阻塞 I / O 的差别最大限度的屏蔽并提供了对立的 API，JDK 本人会帮忙咱们抉择非阻塞 I / O 的实现形式。

一般来说，在 Linux 零碎中，只有反对 epoll，JDK 会优先选择 epoll 来实现 Java 的非阻塞 I /O。

(三). Java 线程异步 I / O 模型

Java 线程异步 I / O 模型次要是指异步非阻塞模型(AIO 模型)，须要操作系统负责将数据读写到利用传递进来的缓冲区供应用程序操作。

对于非阻塞 I / O 模型 (NIO) 来说，异步 I / O 模型的工作机制来说，与之不同的是采纳“订阅(Subscribe)- 告诉(Notification)”模式，次要如下：

• 订阅(Subscribe): 用户线程通过操作系统调用，向内核注册某个 IO 操作后，即应用程序向操作系统注册 IO 监听，而后持续做本人的事件。
• 告诉(Notification)：当操作系统产生 IO 事件，并且筹备好数据后，即内核在整个 IO 操作（包含数据筹备、数据复制）实现后，再被动告诉应用程序，触发相应的函数，执行后续的业务操作。

在异步 IO 模型中，整个内核的数据处理过程中，包含内核将数据从网络物理设施（网卡）读取到内核缓存区、将内核缓冲区的数据复制到用户缓冲区，用户程序都不须要阻塞。

由此可见，异步 I / O 模型 (AIO 模型) 须要依赖操作系统的反对，CPU 资源开销比拟大，最大的个性是异步能力，对 socket 和 I / O 起作用，适宜连贯数目比拟多以及连接时间长的零碎架构。

一般来说，在操作系统里，异步 IO 是指 Windows 零碎的 IOCP(Input/Output Completion Port)，或者 C ++ 的网络库 asio。

在 Linux 零碎中，aio 尽管是异步 IO 模型的具体实现，然而因为不成熟，当初大部分还是根据是否反对 epoll 等，来模仿和封装 epoll 实现的。

在 Java 畛域中，反对异步 I / O 模型 (AIO 模型) 是 Jdk 1.7 版本开始的，基于 CompletionHandler 接口来实现操作实现回调，其中别离有三个新的异步通道，AsynchronousFileChannel，AsynchronousSocketChannel 和 AsynchronousServerSocketChannel。

然而，对于反对异步编程模式是在 Jdk 1.5 版本就曾经存在，最典型的就是基于 Future 模型实现的 Executor 和 FutureTask。

因为 Future 模型存在肯定的局限性，在 JDK 1.8 之后，对 Future 的扩大和加强实现又新增了一个 CompletableFuture。

由此可见，在 Java 畛域中，对于异步 I / O 模型提供了异步文件通道 (AsynchronousFileChannel) 和异步套接字通道 (AsynchronousSocketChannel 和 AsynchronousServerSocketChannel) 的实现。其中：

• 首先，对于异步文件通道的实现，提供两种形式获取操作后果:

  • 通过 java.util.concurrent.Future 类來示意异步操作的后果：
  • 在执行异步操作的时候传入一个 java.nio.channels.CompletionHandler 接口的实现类作为操作实现的回调。

• 其次，对于异步套接字通道的是实现：

  • 异步 Socket Channel 是被动执行对象，不须要像 NIO 编程那样创立一个独立的 I/ O 线程来解决读写操作。
  • 对于 AsynchronousServerSocketChannel 和 AsynchronousSocketChannel 都由 JDK 底层的线程池负责回调并驱动读写操作。
  • 异步套接字通道是真正的异步非阻塞 I /O, 它对应 UNIX 网络编程中的事件驱动 I /O (AIO), 它不须要通过多路复用器 (Selector) 对注册的通道进行轮询操作即可实现异步读写，从而简化了 NIO 的编程模型。

综上所述，对于在 Java 畛域中的异步 IO 模型，咱们在应用的时候，须要根据理论业务场景须要而进行抉择和考量。

⚠️[特地留神]：

[1].IOCP：输入输出实现端口（Input/Output Completion Port，IOCP）, 是反对多个同时产生的异步 I / O 操作的应用程序编程接口。

[2].epoll: Linux 零碎中 I / O 多路复用实现形式的一种，次要是(select,poll,epoll)。都是同步 I /O，同时也是阻塞 I /O。

[3].Future: 属于 Java JDK 1.5 版本反对的编程异步模型，在包 java.util.concurrent. 上面。

[4].CompletionHandler: 属于 Java JDK 1.7 版本反对的编程异步 I / O 模型，在包 java.nio.channels. 上面。

[5].CompletableFuture: 属于 Java JDK 1.8 版本对 Future 的扩大和加强实现编程异步 I / O 模型，在 java.util.concurrent. 上面。

四. Java 畛域中的线程设计模型

Java 畛域中的线程设计模型最典型就是基于 Reactor 模式设计的非阻塞 I / O 模型和 基于 Proactor 模式设计的异步 I / O 模型和基于 Promise 模式的 Promise 模型。

在 Java 畛域中，对于并发编程的反对，不仅提供了线程机制，也引入了多线程机制，还有许多同步和异步的实现。

单从设计准则和实现来说，都采纳了许多设计模式，其中多线程机制最常见的就是线程池模式。

对于非阻塞 I / O 模型，次要采纳基于 Reactor 模式设计，而异步 I / O 模型，次要采纳基于 Proactor 模式设计。

当然，还有基于 Promise 模式的异步编程模型，不过这算是一个特例。

综上所述，Java 畛域中的线程设计模型最典型就是基于 Reactor 模式设计的非阻塞 I / O 模型和 基于 Proactor 模式设计的异步 I / O 模型和基于 Promise 模式的 Promise 模型。

1. 多线程非阻塞 I / O 模型

多线程非阻塞 I / O 模型是针对于多线程机制而设计的，依据 CPU 的数量来创立线程数，并且可能让多个线程并行执行的非阻塞 I / O 模型。

当初的计算机大多数都是多核 CPU 的，而且操作系统都提供了多线程机制，然而咱们也没有方法抹掉单线程的劣势。

单线程最大的劣势就是一个 CPU 只负责一个线程，对于多线程中呈现的疑难杂症，它都能够防止，而且编码简略。

在一个线程对应一个 CPU 的状况下，如果多核计算机中 只执行一个线程，那么就只有一个 CPU 工作，无奈充分发挥 CPU 和劣势，且资源也无奈充分利用。

因而，咱们的程序则能够依据 CPU 的数量来创立线程数，N 个 CPU 对应多个 N 个线程，便能够充分利用多个 CPU。同时也放弃了单线程的特点，相当于多个线程并行执行而不是并发执行。

在多核计算机时代，多线程和非阻塞都是晋升服务器解决性能的利器。个别咱们都是将客户端连贯依照分组调配给至多一个线程或者若干线程，每个线程负责解决对应组的连贯。

在 Java 畛域中，最常见的多线程阻塞 I / O 模型就是基于 Reactor 模式的 Reactor 模型。

2. 基于 Reactor 模式的 Reactor 模型

Reactor 模型是指在事件驱动的思维上，基于 Reactor 的工作模式而设计的非阻塞 I / O 模型(NIO 模型)。肯定水平上来说，能够说是被动模式 I / O 模型。

对于 Reactor 模式，我特意在网上查问了一下材料，查问的后果都是无疾而终，解释更是形形色色的。最初，参考一些材料整顿得出结论。

援用一下 Doug Lea 巨匠在文章“Scalable IO in Java”中对 Reactor 模式的定义：

Reactor 模式由 Reactor 线程、Handlers 处理器两大角色组成，两大角色的职责别离如下：

• Reactor 线程的职责：负责响应 IO 事件，并且散发到 Handlers 处理器。
• Handlers 处理器的职责：非阻塞的执行业务解决逻辑。

集体了解，Reactor 模式是指在事件驱动的思维上，通过一个或多个输出同时传递给服务处理器的服务申请的事件驱动解决模式。其中，根本思维有两个：

• 基于 I/O 复用模型：多个连贯共用一个阻塞对象，应用程序只须要在一个阻塞对象期待，无需阻塞期待所有连贯。当某个连贯有新的数据能够解决时，操作系统告诉应用程序，线程从阻塞状态返回，开始进行业务解决
• 基于线程池复用线程资源：不用再为每个连贯创立线程，将连贯实现后的业务解决任务分配给线程进行解决，一个线程能够解决多个连贯的业务。

总体来说，Reactor 模式有点相似事件驱动模式。在事件驱动模式中，当有事件触发时，事件源会将事件散发到 Handler（处理器），由 Handler 负责事件处理。Reactor 模式中的反应器角色相似于事件驱动模式中的事件散发器（Dispatcher）角色。

具体来说，在 Reactor 模式中有 Reactor 和 Handler 两个重要的组件：

• Reactor：负责查问 IO 事件，当检测到一个 IO 事件时将其发送给相应的 Handler 处理器去解决。其中，IO 事件就是 NIO 中选择器查问进去的通道 IO 事件。
• Handler：与 IO 事件（或者选择键）绑定，负责 IO 事件的解决，实现真正的连贯建设、通道的读取、解决业务逻辑、负责将后果写到通道等。

从 Reactor 的代码实现上来看，实现 Reactor 模式须要实现以下几个类：

• EventHandler：事件处理器，能够依据事件的不同状态创立解决不同状态的处理器。
• Handler：能够了解为事件，在网络编程中就是一个 Socket，在数据库操作中就是一个 DBConnection。
• InitiationDispatcher：用于治理 EventHandler，散发 event 的容器，也是一个事件处理调度器，Tomcat 的 Dispatcher 就是一个很好的实现，用于接管到网络申请后进行第一步的工作散发，分发给相应的处理器去异步解决，来保障吞吐量。
• Demultiplexer：阻塞期待一系列的 Handle 中的事件到来，如果阻塞期待返回，即示意在返回的 Handler 中能够不阻塞的执行返回的事件类型。这个模块个别应用操作系统的 select 来实现。在 Java NIO 中用 Selector 来封装，当 Selector.select()返回时，能够调用 Selector 的 selectedKeys()办法获取 Set，一个 SelectionKey 表白一个有事件产生的 Channel 以及该 Channel 上的事件类型。

接下来，咱们便从具体的常见来一一探讨一下 Reactor 模式下的各种线程模型。

从肯定意义上来说，基于 Reactor 模式的 Reactor 模型是非阻塞 I / O 模型。

2.0. 单 Reactor 单线程模型

单 Reactor 单线程模型次要是指将服务端的整个处理事件分为若干个事件，Reactor 通过事件检测机制把若干个事件 Handler 分发给不同的处理器去解决。简略来说，Reactor 和 Handle 都放入一个线程中执行。

在理论工作中，若干个客户端连贯拜访服务端，假如会有接管事件 (Accept Event)，读事件(Read Event)，写事件(Write Event)，以及执行事件(Process Event) 等，其中，：

• Reactor 模型则把这些事件都散发到各自的处理器。
• 整个过程，只有有期待解决的事件存在，Reactor 线程模型一直往后续执行，而且不会阻塞，所以效率很高。

由此可见，单 Reactor 单线程模型具备简略，没有多线程，没有过程通信。然而从性能上来说，无奈施展多核的极致，一个 Handler 卡死，导致以后过程无奈应用，IO 和 CPU 不匹配。

在 Java 畛域中，对于一个单 Reactor 单线程模型的实现，次要需用到 SelectionKey（选择键）的几个重要的成员办法：

• void attach(Object o)：将对象附加到选择键。能够将任何 Java POJO 对象作为附件增加到 SelectionKey 实例。
• Object attachment()：从选择键获取附加对象。与 attach(Object o)是配套应用的，其作用是取出之前通过 attach(Object o)办法增加到 SelectionKey 实例的附加对象。这个办法同样十分重要，当 IO 事件产生时，选择键将被 select 办法查问进去，能够间接将选择键的附件对象取出。

因而，在 Reactor 模式实现中，通过 attachment()办法所取出的是之前通过 attach(Object o)办法绑定的 Handler 实例，而后通过该 Handler 实例实现相应的传输解决。

综上所述，在 Reactor 模式中，须要将 attach 和 attachment 联合应用：

• 在选择键注册实现之后调用 attach()办法，将 Handler 实例绑定到选择键。
• 当 IO 事件产生时调用 attachment()办法，能够从选择键取出 Handler 实例，将事件散发到 Handler 处理器中实现业务解决。

从肯定意义上来说，单 Reactor 单线程模型是基于单线程的 Reactor 模式。

2.1. 单 Reactor 多线程模型

单 Reactor 多线程模型是指采纳多线程机制，将服务端的整个处理事件分为若干个事件，Reactor 通过事件检测机制把若干个事件 Handler 分发给不同的处理器去解决。

单 Reactor 多线程模型是基于单线程的 Reactor 模式的构造，将其利用线程池机制改良多线程模式。

相当于，Reactor 对于接管事件 (Accept Event)，读事件(Read Event)，写事件(Write Event)，以及执行事件(Process Event) 等散发到各自的处理器时：

• 首先，对于耗时的工作引入线程池机制，事件处理器本人不执行工作，而是交给线程池来托管，防止了耗时的操作。
• 其次，尽管 Reactor 只有一个线程，然而也保障了 Reactor 的高效。

在 Java 畛域中，对于一个单 Reactor 多线程模型的实现，次要能够从降级 Handler 和降级 Reactor 来改良：

• 降级 Handler：既要应用多线程，又要尽可能高效率，则能够思考应用线程池。
• 降级 Reactor：能够思考引入多个 Selector（选择器），晋升抉择大量通道的能力。

总体来说，多线程版本的 Reactor 模式大抵如下：

• 将负责数据传输解决的 IOHandler 处理器的执行放入独立的线程池中。这样，业务解决线程与负责新连贯监听的反应器线程就能互相隔离，防止服务器的连贯监听受到阻塞。
• 如果服务器为多核的 CPU，能够将反应器线程拆分为多个子反应器（SubReactor）线程；同时，引入多个选择器，并且为每一个 SubReactor 引入一个线程，一个线程负责一个选择器的事件轮询。这样充沛开释了系统资源的能力，也大大晋升了反应器治理大量连贯或者监听大量传输通道的能力。

由此可见，单 Reactor 单线程模型具备充分利用的 CPU 的特点，然而过程通信，简单，Reactor 承放了太多业务，高并发下可能成为性能瓶颈。

从肯定意义上来说，单 Reactor 多线程模型是基于多线程的 Reactor 模式。

2.2. 主从 Reactor 多线程模型

主从 Reactor 多线程模型采纳多个 Reactor 的机制，将服务端的整个处理事件分为若干个事件，Reactor 通过事件检测机制把若干个事件 Handler 分发给不同的处理器去解决。每一个 Reactor 对应着一个线程。

采纳多个 Reactor 实例的机制：
- 主 Reactor：负责建设连贯，建设连贯后的句柄丢给从 Reactor。
- 从 Reactor：负责监听所有事件进行解决。

相当于，Reactor 对于接管事件 (Accept Event)，读事件(Read Event)，写事件(Write Event)，以及执行事件(Process Event) 等散发到各自的处理器时：

• 因为接管事件是针对于服务器端而言的，连贯接管的工作对立由连贯处理器实现，则连贯处理器把接管到的客户端连贯平均调配到所有的实例中去。
• 每一个 Reactor 实例负责解决调配到该 Reactor 实例的客户端连贯，实现连贯时的读写操作和其余逻辑操作。

由此可见，主从 Reactor 多线程模型中 Reactor 实例职责分工明确，具备肯定摊派压力的效力，咱们常见 Nginx/Netty/Memcached 等就是采纳这中模型。

从肯定意义上来说，主从 Reactor 多线程模型是基于多实例的 Reactor 模式。

2. 基于 Proactor 模式的 Proactor 模型

Proactor 模型是指在事件驱动的思维上，基于 Proactor 的工作模式而设计的异步 I / O 模型(AIO 模型)，肯定水平上来说，能够说是被动模式 I / O 模型。

无论是 Reactor，还是 Proactor，都是一种基于事件散发的网络编程模式，区别在于 Reactor 模式是基于「待实现」的 I/O 事件，而 Proactor 模式则是基于「已实现」的 I/O 事件。

绝对于 Reactor 来说，Proactor 模型解决读取操作的次要流程：

• 应用程序初始化一个异步读取操作，而后注册相应的事件处理器，此时事件处理器不关注读取就绪事件，而是关注读取实现事件。
• 事件分离器期待读取操作实现事件。
• 在事件分离器期待读取操作实现的时候，操作系统调用内核线程实现读取操作，并将读取的内容放入用户传递过去的缓存区中。
• 事件分离器捕捉到读取实现事件后，激活应用程序注册的事件处理器，事件处理器间接从缓存区读取数据，而不须要进行理论的读取操作。

由此可见，Proactor 中写入操作和读取操作基本一致，只不过监听的事件是写入实现事件而已。

在 Java 畛域中，异步 IO(AIO)是在 Java JDK 7 之后引入的，都是操作系统负责将数据读写到利用传递进来的缓冲区供应用程序操作。

其中，从对于 Proactor 模式的设计来看，Proactor 模式的工作流程：

• Proactor Initiator：负责创立 Proactor 和 Handler 对象，并将 Proactor 和 Handler 都通过 Asynchronous Operation Processor 注册到内核。
• Asynchronous Operation Processor：负责解决注册申请，并解决 I/O 操作。
• Asynchronous Operation Processor：实现 I/O 操作后告诉 Proactor。
• Proactor：依据不同的事件类型回调不同的 Handler 进行业务解决。
• Handler：实现业务解决，其中是通过 CompletionHandler 示意实现后处理器。

从肯定意义上来说，基于 Proactor 模式的 Proactor 模型是异步 IO。

3. 基于 Promise 模式的 Promise 模型

Promise 模型是基于 Promise 异步编程模式，客户端代码调用某个异步办法所失去的返回值仅是一个凭据对象，凭借该对象，客户端代码能够获取异步办法相应的真正工作的执行后果的一种模型。

Promise 模式是开始一个工作的执行，并失去一个用于获取该工作执行后果的凭据对象，而不用期待该工作执行结束就能够继续执行其余操作。

从 Promise 模式的工作机制来看，次要如下：

• 当咱们开始一个工作的执行，并失去一个用于获取该工作执行后果的凭据对象，而不用期待该工作执行结束就能够继续执行其余操作。
• 等到咱们须要该工作的执行后果时，再调用凭据对象的相干办法来获取。

由此能够确定的是，Promise 模式既施展了异步编程的劣势——减少零碎的并发性，缩小不必要的期待，又放弃了同步编程的简略性。

从 Promise 模式技术实现来说，主要职责角色如下：

• Promisor：负责对外裸露能够返回 Promise 对象的异步办法，并启动异步工作的执行，次要利用 compute 办法启动异步工作的执行，并返回用于获取异步工作执行后果的凭据对象。
• Promise：负责包装异步工作处理结果的凭据对象。负责检测异步工作是否处理完毕、返回和存储异步工作处理结果。
• Result：负责示意异步工作处理结果。具体类型由利用决定。
• TaskExecutor：负责真正执行异步工作所代表的计算，并将其计算结果设置到相应的 Promise 实例对象。

在 Java 畛域中，最典型的就是基于 Future 模型实现的 Executor 和 FutureTask。

因为 Future 模型存在肯定的局限性，在 JDK 1.8 之后，对 Future 的扩大和加强实现又新增了一个 CompletableFuture。

当然，Promise 模式在前端技术 JavaScript 中 Promise 有具体的体现，而且随着前端技术的倒退日趋成熟，对于这种模式的使用早已日臻化境。

写在最初

在 Java 畛域中，Java 畛域中的线程次要分为 Java 层线程(Java Thread) ,JVM 层线程(JVM Thread), 操作系统层线程(Kernel Thread)。

从 Java 线程映射类型来看，次要有线程一对一 (1:1) 映射，线程多对多 (M:1) 映射，线程多对多 (M:N) 映射等关系。

因而，Java 畛域中的线程映射模型次要有内核级线程模型 (Kernel-Level Thread，KLT)、利用级线程模型(Application-Level Thread，ALT)、混合两级线程模型(Mixture-Level Thread，MLT) 等 3 种模型。

在 Java 畛域中，咱们对照线程概念 (单线程和多线程) 来说，能够分为 Java 线程 - 阻塞 I / O 模型和 Java 线程 - 非阻塞 I / O 模型两种。其中，

• Java 线程 - 阻塞 I / O 模型：次要能够分为单线程阻塞 I / O 模型和多线程阻塞 I / O 模型。
• Java 线程 - 非阻塞 I / O 模型：次要能够分为应用层 I / O 多路复用模型和内核层 I / O 多路复用模型，以及内核回调事件驱动 I / O 模型。

特地指出，在 Java 畛域中，非阻塞 I / O 的实现齐全是基于操作系统内核的非阻塞 I /O，JDK 会根据操作系统内核反对的非阻塞 I / O 形式来帮忙咱们抉择实现形式。

综上所述，在 Java 畛域中，并发编程中的线程机制以及多线程的管制，在理论开发过程中，须要根据理论业务场景来思考和掂量，这须要咱们对其有更深的钻研，才能够得心应手。

在探讨编程模型的时候，咱们提到了像基于 Promise 模式和基于 Thread Pool 模式的这样的设计模式的概念，这也是一个咱们比拟容易疏忽的概念，如果有趣味的话，能够自行进行查问相干材料进行理解。

最初，祝愿大家在 Java 并发编程的“看山是山，看山不是山，看山还是山”的修行之路上，“拨开云雾见天日，守得云开见月明”，早日达到有迹可循到有迹可寻的指标！

版权申明：本文为博主原创文章，遵循相干版权协定，如若转载或者分享请附上原文出处链接和链接起源。