要搞明白IO相关的概念，首先就得弄清楚同步与异步，阻塞与非阻塞到底是什么意思。

同步与异步

想要搞明白IO模型，就先得搞明白“同步”与“异步”的关系。

所谓的“同步”，比如说调用者去调用一个接口，这个接口比如要执行一些磁盘文件读写操作，或者是网络通信操作。

假设是“同步”的模式，调用者必须要等待这个接口的磁盘读写或者网络通信的操作执行完毕了，调用者才能返回，这就是“同步”，如下图所示：

所谓的“异步”，就是说这个调用者调用接口之后，直接就返回了，他去干别的事儿了，也不管那个接口的磁盘读写或者是网络通信是否成功。

然后这个接口后续如果干完了自己的任务，比如写完了文件或者是什么的，会反过来通知调用者，之前你的那个调用成功了。可以通过一些内部通信机制来通知，也可以通过回调函数来通知，如下图。

用生活中的例子理解同步与异步

如果给大家举个生活中的例子，那么就可以用买烟这个事儿来举个例子

比如说现在你要去一个柜台买很多条香烟，但是现在柜台没那么多货，他需要打电话给库房来查一下有没有足够的货。

这个时候，库房的工作人员正好去吃饭了，那现在你有两种选择：

第一种选择，你可以在柜台等着，一直等待库房工作人员回来，柜台专员打通电话给他查到了库存是否充足，你再走。

这个就是“同步”，你找柜台工作人员买香烟，他要打电话给库房工作人员问库存，如果你选择“同步”模式，那么你就在柜台一直等着，直到成功查询到库存为止。

第二种选择，你可以先回家干点儿别的，比如说洗衣服做饭之类的，然后过了一会儿，柜台工作人员打通电话给库房工作人员，查到香烟库存了，就会打个电话给你，告诉你这个事儿。

这就是“异步”，你跟柜台工作人员说了这个事儿，就直接走了，干别的去了，柜台工作人员后面完成他的任务之后，就会反过来打电话回调通知你。

阻塞与非阻塞

实际上阻塞与非阻塞的概念，通常是针对底层的IO操作来说的。

比如现在我们的程序想要通过网络读取数据，如果是阻塞IO模式，一旦发起请求到操作系统内核去从网络中读取数据，就会阻塞在那里，必须要等待网络中的数据到达了之后，才能从网络读取数据到内核，再从内核返回给程序，如下图。

而非阻塞，指的就是程序发送请求给内核要从网络读取数据，但是此时网络中的数据还没到，此时不会阻塞住，内核会返回一个异常消息给程序。

程序就可以干点儿别的，然后过一会儿再来发起一次请求给内核，让内核尝试从网络读取数据。

因为如果网络中的数据还没到位，是不会阻塞住程序的，需要程序自己不断的轮询内核去尝试读取数据，所以这种IO就是非阻塞的。如下图：

不要把“同步/异步”概念和“阻塞/非阻塞”概念混淆起来，实际上他们是两组不同的概念。

“同步/异步”更多的是针对比如接口调用，服务调用，API类库调用，类似这样的场景。

而“阻塞/非阻塞”概念针对的是底层IO操作的场景，比如磁盘IO，网络IO。但是在Java IO模型里，两种概念之间是有一定的关联关系的 。

Unix支持的5种IO模型

Unix操作系统支持的IO模型主要就是5种：

1. 阻塞IO：就是上面图里的那种阻塞IO模式，程序发起请求之后会阻塞，一直到系统内核发现网络中有数据到达了，拷贝数据给程序进程了，才能返回
2. 非阻塞IO：就是上面图里的那种非阻塞IO模式，程序发起请求读取数据，系统内核发现网络数据还没到，就返回一个异常信息，程序不会阻塞在IO操作上，但是过一会儿还得再来发起请求给内核，直到内核发现网络数据到达了，此时就会拷贝数据给程序进程
3. IO多路复用：这个下面来讲
4. 信号驱动式IO：一般很少用到，这里不说明
5. 异步IO：下面来讲

JDK 1.4之前的同步阻塞IO

在JDK 1.4之前，主要就是同步阻塞IO模型，在Java里叫做BIO。

在Java代码里调用IO相关接口，发起IO操作之后，Java程序就会同步等待，这个同步指的是Java程序调用IO API接口的层面而言。

而IO API在底层的IO操作是基于阻塞IO来的，向操作系统内核发起IO请求，系统内核会等待数据就位之后，才会执行IO操作，执行完毕了才会返回。

JDK 1.4之后的同步非阻塞NIO

在JDK 1.4之后提供了NIO，他的概念是同步非阻塞，也就是说如果你调用NIO接口去执行IO操作，其实还是同步等待的，但是在底层的IO操作上 ，会对系统内核发起非阻塞IO请求，以非阻塞的形式来执行IO。

也就是说，如果底层数据没到位，那么内核返回异常信息，不会阻塞住，但是NIO接口内部会采用非阻塞方式过一会儿再次调用内核发起IO请求，直到成功为止。

但是之所以说是同步非阻塞，这里的“同步”指的就是因为在你的Java代码调用NIO接口层面是同步的，你还是要同步等待底层IO操作真正完成了才可以返回，只不过在执行底层IO的时候采用了非阻塞的方式来执行罢了。

对于我们这些 MySQL的使用者来说，平时用的最多的就是查询功能。DBA时不时丢过来一些慢查询语句让优化，如果连查询是怎么执行的都不清楚还优化个毛线，所以是时候掌握真正的技术了。 MySQL有一个称为 查询优化器的模块，一条查询语句进行语法解析之后就会被交给查询优化器来进行优化，优化的结果就是生成一个所谓的 执行计划，这个执行计划表明了应该使用哪些索引进行查询，表之间的连接顺序是啥样的，最后会按照执行计划中的步骤调用存储引擎提供的方法来真正的执行查询，并将查询结果返回给用户。不过查询优化这个主题有点儿大，在学会跑之前还得先学会走，所以本章先来瞅瞅 MySQL怎么执行单表查询（就是 FROM子句后边只有一个表，最简单的那种查询～）。

为了故事的发展，先得有个表：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

CREATE TABLE single_table (
	id INT NOT NULL AUTO_INCREMENT,
    key1 VARCHAR(100),
    key2 INT,
    key3 VARCHAR(100),
    key_part1 VARCHAR(100),
    key_part2 VARCHAR(100),
    key_part3 VARCHAR(100),
    common_field VARCHAR(100),
    PRIMARY KEY (id),
    KEY idx_key1 (key1),
    UNIQUE KEY idx_key2 (key2),
    KEY idx_key3 (key3),
    KEY idx_key_part(key_part1, key_part2, key_part3)
) Engine=InnoDB CHARSET=utf8;

我们为这个 single_table表建立了1个聚簇索引和4个二级索引，分别是：

• 为 id列建立的聚簇索引。
• 为 key1列建立的 idx_key1二级索引。
• 为 key2列建立的 idx_key2二级索引，而且该索引是唯一二级索引。
• 为 key3列建立的 idx_key3二级索引。
• 为 key_part1、 key_part2、 key_part3列建立的 idx_key_part二级索引，这也是一个联合索引。

然后我们需要为这个表插入10000行记录，除 id列外其余的列都插入随机值就好了，具体的插入语句我就不写了，自己写个程序插入吧（id列是自增主键列，不需要我们手动插入）。

访问方法（access method）的概念

我们平时所写的那些查询语句本质上只是一种声明式的语法，只是告诉 MySQL我们要获取的数据符合哪些规则，至于 MySQL背地里是怎么把查询结果搞出来的那是 MySQL自己的事儿。对于单个表的查询来说，设计MySQL的大叔把查询的执行方式大致分为下边两种：

使用全表扫描进行查询

这种执行方式很好理解，就是把表的每一行记录都扫一遍嘛，把符合搜索条件的记录加入到结果集就完了。不管是啥查询都可以使用这种方式执行，当然，这种也是最笨的执行方式。

使用索引进行查询

因为直接使用全表扫描的方式执行查询要遍历好多记录，所以代价可能太大了。如果查询语句中的搜索条件可以使用到某个索引，那直接使用索引来执行查询可能会加快查询执行的时间。使用索引来执行查询的方式五花八门，又可以细分为许多种类：

• 针对主键或唯一二级索引的等值查询
• 针对普通二级索引的等值查询
• 针对索引列的范围查询
• 直接扫描整个索引

设计 MySQL的大叔把 MySQL执行查询语句的方式称之为 访问方法或者 访问类型。同一个查询语句可能可以使用多种不同的访问方法来执行，虽然最后的查询结果都是一样的，但是执行的时间可能差老鼻子远了，就像是从钟楼到大雁塔，你可以坐火箭去，也可以坐飞机去，当然也可以坐乌龟去。下边细细道来各种 访问方法的具体内容。

const

有的时候我们可以通过主键列来定位一条记录，比方说这个查询：

1

SELECT * FROM single_table WHERE id = 1438;

MySQL会直接利用主键值在聚簇索引中定位对应的用户记录，就像这样：

原谅我把聚簇索引对应的复杂的 B+树结构搞了一个极度精简版，为了突出重点，我们忽略掉了 页的结构，直接把所有的叶子节点的记录都放在一起展示，而且记录中只展示我们关心的索引列，对于 single_table表的聚簇索引来说，展示的就是 id列。我们想突出的重点就是： B+树叶子节点中的记录是按照索引列排序的，对于的聚簇索引来说，它对应的 B+树叶子节点中的记录就是按照 id列排序的。 B+树本来就是一个矮矮的大胖子，所以这样根据主键值定位一条记录的速度贼快。类似的，我们根据唯一二级索引列来定位一条记录的速度也是贼快的，比如下边这个查询：

1

SELECT * FROM single_table WHERE key2 = 3841;

这个查询的执行过程的示意图就是这样：

可以看到这个查询的执行分两步，第一步先从 idx_key2对应的 B+树索引中根据 key2列与常数的等值比较条件定位到一条二级索引记录，然后再根据该记录的 id值到聚簇索引中获取到完整的用户记录。

设计 MySQL的大叔认为通过主键或者唯一二级索引列与常数的等值比较来定位一条记录是像坐火箭一样快的，所以他们把这种通过主键或者唯一二级索引列来定位一条记录的访问方法定义为： const，意思是常数级别的，代价是可以忽略不计的。不过这种 const访问方法只能在主键列或者唯一二级索引列和一个常数进行等值比较时才有效，如果主键或者唯一二级索引是由多个列构成的话，索引中的每一个列都需要与常数进行等值比较，这个 const访问方法才有效（这是因为只有该索引中全部列都采用等值比较才可以定位唯一的一条记录）。

对于唯一二级索引来说，查询该列为 NULL值的情况比较特殊，比如这样：

1

SELECT * FROM single_table WHERE key2 IS NULL;

因为唯一二级索引列并不限制 NULL值的数量，所以上述语句可能访问到多条记录，也就是说上边这个语句不可以使用 const访问方法来执行。

ref

有时候我们对某个普通的二级索引列与常数进行等值比较，比如这样：

1

SELECT * FROM single_table WHERE key1 = 'abc';

对于这个查询，我们当然可以选择全表扫描来逐一对比搜索条件是否满足要求，我们也可以先使用二级索引找到对应记录的 id值，然后再回表到聚簇索引中查找完整的用户记录。由于普通二级索引并不限制索引列值的唯一性，所以可能找到多条对应的记录，也就是说使用二级索引来执行查询的代价取决于等值匹配到的二级索引记录条数。如果匹配的记录较少，则回表的代价还是比较低的，所以 MySQL可能选择使用索引而不是全表扫描的方式来执行查询。设计 MySQL的大叔就把这种搜索条件为二级索引列与常数等值比较，采用二级索引来执行查询的访问方法称为： ref。我们看一下采用 ref访问方法执行查询的图示：

从图示中可以看出，对于普通的二级索引来说，通过索引列进行等值比较后可能匹配到多条连续的记录，而不是像主键或者唯一二级索引那样最多只能匹配1条记录，所以这种 ref访问方法比 const差了那么一丢丢，但是在二级索引等值比较时匹配的记录数较少时的效率还是很高的（如果匹配的二级索引记录太多那么回表的成本就太大了），跟坐高铁差不多。不过需要注意下边两种情况：

1、二级索引列值为 NULL的情况，不论是普通的二级索引，还是唯一二级索引，它们的索引列对包含 NULL值的数量并不限制，所以我们采用 key IS NULL这种形式的搜索条件最多只能使用 ref的访问方法，而不是 const的访问方法。

2、对于某个包含多个索引列的二级索引来说，只要是最左边的连续索引列是与常数的等值比较就可能采用 ref的访问方法，比方说下边这几个查询：

1

SELECT * FROM single_table WHERE key_part1 = 'god like';SELECT * FROM single_table WHERE key_part1 = 'god like' AND key_part2 = 'legendary';SELECT * FROM single_table WHERE key_part1 = 'god like' AND key_part2 = 'legendary' AND key_part3 = 'penta kill';

但是如果最左边的连续索引列并不全部是等值比较的话，它的访问方法就不能称为 ref了，比方说这样：

1

SELECT * FROM single_table WHERE key_part1 = 'god like' AND key_part2 > 'legendary';

ref or null

有时候我们不仅想找出某个二级索引列的值等于某个常数的记录，还想把该列的值为 NULL的记录也找出来，就像下边这个查询：

1

SELECT * FROM single_demo WHERE key1 = 'abc' OR key1 IS NULL;

当使用二级索引而不是全表扫描的方式执行该查询时，这种类型的查询使用的访问方法就称为 ref_or_null，这个 ref_or_null访问方法的执行过程如下：

可以看到，上边的查询相当于先分别从 idx_key1索引对应的 B+树中找出 key1 IS NULL和 key1='abc'的两个连续的记录范围，然后根据这些二级索引记录中的 id值再回表查找完整的用户记录。

在Java中，集合和数组是我们经常会用到的数据结构，需要经常对他们做增、删、改、查、聚合、统计、过滤等操作。相比之下，关系型数据库中也同样有这些操作，但是在Java 8之前，集合和数组的处理并不是很便捷。

不过，这一问题在Java 8中得到了改善，Java 8 API添加了一个新的抽象称为流Stream，可以让你以一种声明的方式处理数据。本文就来介绍下如何使用Stream。

Stream介绍

Stream 使用一种类似用 SQL 语句从数据库查询数据的直观方式来提供一种对 Java 集合运算和表达的高阶抽象。

Stream API可以极大提高Java程序员的生产力，让程序员写出高效率、干净、简洁的代码。

这种风格将要处理的元素集合看作一种流，流在管道中传输，并且可以在管道的节点上进行处理，比如筛选，排序，聚合等。

Stream有以下特性及优点：

• 无存储。Stream不是一种数据结构，它只是某种数据源的一个视图，数据源可以是一个数组，Java容器或I/O channel等。
• 为函数式编程而生。对Stream的任何修改都不会修改背后的数据源，比如对Stream执行过滤操作并不会删除被过滤的元素，而是会产生一个不包含被过滤元素的新Stream。
• 惰式执行。Stream上的操作并不会立即执行，只有等到用户真正需要结果的时候才会执行。
• 可消费性。Stream只能被“消费”一次，一旦遍历过就会失效，就像容器的迭代器那样，想要再次遍历必须重新生成。

我们举一个例子，来看一下到底Stream可以做什么事情：

上面的例子中，获取一些带颜色塑料球作为数据源，首先过滤掉红色的、把它们融化成随机的三角形。再过滤器并删除小的三角形。最后计算出剩余图形的周长。

如上图，对于流的处理，主要有三种关键性操作：分别是流的创建、中间操作（intermediate operation）以及最终操作(terminal operation)。

Stream的创建

在Java 8中，可以有多种方法来创建流。

通过已有的集合来创建流

在Java 8中，除了增加了很多Stream相关的类以外，还对集合类自身做了增强，在其中增加了stream方法，可以将一个集合类转换成流。

1
2

List<String> strings = Arrays.asList("Hollis", "HollisChuang", "hollis", "Hello", "HelloWorld", "Hollis");
Stream<String> stream = strings.stream();

以上，通过一个已有的List创建一个流。除此以外，还有一个parallelStream方法，可以为集合创建一个并行流。

这种通过集合创建出一个Stream的方式也是比较常用的一种方式。

通过Stream创建流

可以使用Stream类提供的方法，直接返回一个由指定元素组成的流。

1

Stream<String> stream = Stream.of("Hollis", "HollisChuang", "hollis", "Hello", "HelloWorld", "Hollis");

如以上代码，直接通过of方法，创建并返回一个Stream。

Stream中间操作

Stream有很多中间操作，多个中间操作可以连接起来形成一个流水线，每一个中间操作就像流水线上的一个工人，每人工人都可以对流进行加工，加工后得到的结果还是一个流。

以下是常用的中间操作列表:

filter

filter 方法用于通过设置的条件过滤出元素。以下代码片段使用 filter 方法过滤掉空字符串：

1
2
3

List<String> strings = Arrays.asList("Hollis", "", "HollisChuang", "H", "hollis");
strings.stream().filter(string -> !string.isEmpty()).forEach(System.out::println);
//Hollis, , HollisChuang, H, hollis

map

map 方法用于映射每个元素到对应的结果，以下代码片段使用 map 输出了元素对应的平方数：

1
2
3

List<Integer> numbers = Arrays.asList(3, 2, 2, 3, 7, 3, 5);
numbers.stream().map( i -> i*i).forEach(System.out::println);
//9,4,4,9,49,9,25

limit/skip

limit 返回 Stream 的前面 n 个元素；skip 则是扔掉前 n 个元素。以下代码片段使用 limit 方法保理4个元素：

1
2
3

List<Integer> numbers = Arrays.asList(3, 2, 2, 3, 7, 3, 5);
numbers.stream().limit(4).forEach(System.out::println);
//3,2,2,3

sorted

sorted 方法用于对流进行排序。以下代码片段使用 sorted 方法进行排序：

1
2
3

List<Integer> numbers = Arrays.asList(3, 2, 2, 3, 7, 3, 5);
numbers.stream().sorted().forEach(System.out::println);
//2,2,3,3,3,5,7

distinct

distinct主要用来去重，以下代码片段使用 distinct 对元素进行去重：

1
2
3

List<Integer> numbers = Arrays.asList(3, 2, 2, 3, 7, 3, 5);
numbers.stream().distinct().forEach(System.out::println);
//3,2,7,5

接下来我们通过一个例子和一张图，来演示下，当一个Stream先后通过filter、map、sort、limit以及distinct处理后会发生什么。

代码如下：

1
2
3

List<String> strings = Arrays.asList("Hollis", "HollisChuang", "hollis", "Hello", "HelloWorld", "Hollis");
Stream s = strings.stream().filter(string -> string.length()<= 6).map(String::length).sorted().limit(3)
            .distinct();

过程及每一步得到的结果如下图

Stream最终操作

Stream的中间操作得到的结果还是一个Stream，那么如何把一个Stream转换成我们需要的类型呢？比如计算出流中元素的个数、将流装换成集合等。这就需要最终操作（terminal operation）

最终操作会消耗流，产生一个最终结果。也就是说，在最终操作之后，不能再次使用流，也不能在使用任何中间操作，否则将抛出异常：

1

java.lang.IllegalStateException: stream has already been operated upon or closed

俗话说，“你永远不会两次踏入同一条河”也正是这个意思。

Java工程部署在 CentOS 服务器上。项目偶尔会出现无响应的情况，这时理所当然要上去用 JDK 相关命令看看堆栈和GC等信息了。近期在开发环境的docker排查问题时，发现GC异常频繁，且为full GC，导致系统资源消耗严重，然而jmap命令不可用，导致无法查看Java虚拟机内存占用情况，无法进一步分析。

jps、top、jstat命令均可用。

然而，使用jmap命令

1

jmap -heap 1

打印堆栈信息时，却报错了

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

Attaching to process ID 1, please wait...
Error attaching to process: sun.jvm.hotspot.debugger.DebuggerException: Can't attach to the process: ptrace(PTRACE_ATTACH, ..) failed for 1: Operation not permitted
sun.jvm.hotspot.debugger.DebuggerException: sun.jvm.hotspot.debugger.DebuggerException: Can't attach to the process: ptrace(PTRACE_ATTACH, ..) failed for 1: Operation not permitted
        at sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal$LinuxDebuggerLocalWorkerThread.execute(LinuxDebuggerLocal.java:163)
        at sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal.attach(LinuxDebuggerLocal.java:278)
        at sun.jvm.hotspot.HotSpotAgent.attachDebugger(HotSpotAgent.java:671)
        at sun.jvm.hotspot.HotSpotAgent.setupDebuggerLinux(HotSpotAgent.java:611)
        at sun.jvm.hotspot.HotSpotAgent.setupDebugger(HotSpotAgent.java:337)
        at sun.jvm.hotspot.HotSpotAgent.go(HotSpotAgent.java:304)
        at sun.jvm.hotspot.HotSpotAgent.attach(HotSpotAgent.java:140)
        at sun.jvm.hotspot.tools.Tool.start(Tool.java:185)
        at sun.jvm.hotspot.tools.Tool.execute(Tool.java:118)
        at sun.jvm.hotspot.tools.JInfo.main(JInfo.java:138)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:498)
        at sun.tools.jinfo.JInfo.runTool(JInfo.java:108)
        at sun.tools.jinfo.JInfo.main(JInfo.java:76)
Caused by: sun.jvm.hotspot.debugger.DebuggerException: Can't attach to the process: ptrace(PTRACE_ATTACH, ..) failed for 1: Operation not permitted
        at sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal.attach0(Native Method)
        at sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal.access$100(LinuxDebuggerLocal.java:62)
        at sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal$1AttachTask.doit(LinuxDebuggerLocal.java:269)
        at sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal$LinuxDebuggerLocalWorkerThread.run(LinuxDebuggerLocal.java:138)

以上的关键信息就是：Can't attach to the process: ptrace(PTRACE_ATTACH, ..) failed for 1: Operation not permitted，操作不允许。

解决方案

这其实不是什么 Bug，而是 Docker 自 1.10 版本开始加入的安全特性。

类似于 jmap 这些 JDK 工具依赖于 Linux 的 PTRACE_ATTACH，而是 Docker 自 1.10 在默认的 seccomp 配置文件中禁用了 ptrace。

主要有三种解决办法：

–security-opt seccomp=unconfined

简单暴力（不推荐），直接关闭 seccomp 配置。用法：

1

docker run --security-opt seccomp:unconfined ...

–cap-add=SYS_PTRACE

使用 –cap-add 明确添加指定功能：

1

docker run --cap-add=SYS_PTRACE ...

Docker Compose 的支持

Docker Compose 自 version 1.1.0 (2015-02-25) 起支持 cap_add。官方文档：cap_add, cap_drop。用法：

前面的 docker-compose.yml 改写后文件内容如下（相同内容部分就不重复贴了）：

1
2
3
4
5
6
7
8
9
10

version: '2'

services:
  mysql:
   ...
  api:
   ...
   cap_add:

    - SYS_PTRACE

成功将博客迁移到新的笔记本上，以此纪念。