Elasticsearch 简介

::: info 概述

Elasticsearch 是一个基于 Lucene 的搜索和数据分析工具，它提供了一个分布式服务。Elasticsearch 是遵从 Apache 开源条款的一款开源产品，是当前主流的企业级搜索引擎。

本文简单介绍了 Elasticsearch 的功能、特性、简史、概念，可以让读者在短时间内对于 Elasticsearch 有一个初步的认识。

:::

Elasticsearch 运维

Elasticsearch 是一个分布式、RESTful 风格的搜索和数据分析引擎，能够解决不断涌现出的各种用例。 作为 Elastic Stack 的核心，它集中存储您的数据，帮助您发现意料之中以及意料之外的情况。

Elasticsearch 安装

Elasticsearch 官方下载安装说明

（1）下载解压

访问 官方下载地址 ，选择需要的版本，下载解压到本地。

（2）运行

运行 bin/elasticsearch (Windows 系统上运行 bin\elasticsearch.bat )

（3）访问

执行 curl http://localhost:9200/ 测试服务是否启动

Elasticsearch 集群规划

ElasticSearch 集群需要根据业务实际情况去合理规划。

需要考虑的问题点：

• 集群部署几个节点？
• 有多少个索引？
• 每个索引有多大数据量？
• 每个索引有多少个分片？

一个参考规划：

• 3 台机器，每台机器是 6 核 64G 的。
• 我们 es 集群的日增量数据大概是 2000 万条，每天日增量数据大概是 500MB，每月增量数据大概是 6 亿，15G。目前系统已经运行了几个月，现在 es 集群里数据总量大概是 100G 左右。
• 目前线上有 5 个索引（这个结合你们自己业务来，看看自己有哪些数据可以放 es 的），每个索引的数据量大概是 20G，所以这个数据量之内，我们每个索引分配的是 8 个 shard，比默认的 5 个 shard 多了 3 个 shard。

Elasticsearch 配置

ES 的默认配置文件为 config/elasticsearch.yml

基本配置说明如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

cluster.name: elasticsearch
#配置es的集群名称，默认是elasticsearch，es会自动发现在同一网段下的es，如果在同一网段下有多个集群，就可以用这个属性来区分不同的集群。
node.name: 'Franz Kafka'
#节点名，默认随机指定一个name列表中名字，该列表在es的jar包中config文件夹里name.txt文件中，其中有很多作者添加的有趣名字。
node.master: true
#指定该节点是否有资格被选举成为node，默认是true，es是默认集群中的第一台机器为master，如果这台机挂了就会重新选举master。
node.data: true
#指定该节点是否存储索引数据，默认为true。
index.number_of_shards: 5
#设置默认索引分片个数，默认为5片。
index.number_of_replicas: 1
#设置默认索引副本个数，默认为1个副本。
path.conf: /path/to/conf
#设置配置文件的存储路径，默认是es根目录下的config文件夹。
path.data: /path/to/data
#设置索引数据的存储路径，默认是es根目录下的data文件夹，可以设置多个存储路径，用逗号隔开，例：
#path.data: /path/to/data1,/path/to/data2
path.work: /path/to/work
#设置临时文件的存储路径，默认是es根目录下的work文件夹。
path.logs: /path/to/logs
#设置日志文件的存储路径，默认是es根目录下的logs文件夹
path.plugins: /path/to/plugins
#设置插件的存放路径，默认是es根目录下的plugins文件夹
bootstrap.mlockall: true
#设置为true来锁住内存。因为当jvm开始swapping时es的效率会降低，所以要保证它不swap，可以把#ES_MIN_MEM和ES_MAX_MEM两个环境变量设置成同一个值，并且保证机器有足够的内存分配给es。同时也要#允许elasticsearch的进程可以锁住内存，linux下可以通过`ulimit -l unlimited`命令。
network.bind_host: 192.168.0.1
#设置绑定的ip地址，可以是ipv4或ipv6的，默认为0.0.0.0。
network.publish_host: 192.168.0.1
#设置其它节点和该节点交互的ip地址，如果不设置它会自动判断，值必须是个真实的ip地址。
network.host: 192.168.0.1
#这个参数是用来同时设置bind_host和publish_host上面两个参数。
transport.tcp.port: 9300
#设置节点间交互的tcp端口，默认是9300。
transport.tcp.compress: true
#设置是否压缩tcp传输时的数据，默认为false，不压缩。
http.port: 9200
#设置对外服务的http端口，默认为9200。
http.max_content_length: 100mb
#设置内容的最大容量，默认100mb
http.enabled: false
#是否使用http协议对外提供服务，默认为true，开启。
gateway.type: local
#gateway的类型，默认为local即为本地文件系统，可以设置为本地文件系统，分布式文件系统，hadoop的#HDFS，和amazon的s3服务器，其它文件系统的设置方法下次再详细说。
gateway.recover_after_nodes: 1
#设置集群中N个节点启动时进行数据恢复，默认为1。
gateway.recover_after_time: 5m
#设置初始化数据恢复进程的超时时间，默认是5分钟。
gateway.expected_nodes: 2
#设置这个集群中节点的数量，默认为2，一旦这N个节点启动，就会立即进行数据恢复。
cluster.routing.allocation.node_initial_primaries_recoveries: 4
#初始化数据恢复时，并发恢复线程的个数，默认为4。
cluster.routing.allocation.node_concurrent_recoveries: 2
#添加删除节点或负载均衡时并发恢复线程的个数，默认为4。
indices.recovery.max_size_per_sec: 0
#设置数据恢复时限制的带宽，如入100mb，默认为0，即无限制。
indices.recovery.concurrent_streams: 5
#设置这个参数来限制从其它分片恢复数据时最大同时打开并发流的个数，默认为5。
discovery.zen.minimum_master_nodes: 1
#设置这个参数来保证集群中的节点可以知道其它N个有master资格的节点。默认为1，对于大的集群来说，可以设置大一点的值（2-4）
discovery.zen.ping.timeout: 3s
#设置集群中自动发现其它节点时ping连接超时时间，默认为3秒，对于比较差的网络环境可以高点的值来防止自动发现时出错。
discovery.zen.ping.multicast.enabled: false
#设置是否打开多播发现节点，默认是true。
discovery.zen.ping.unicast.hosts: ['host1', 'host2:port', 'host3[portX-portY]']
#设置集群中master节点的初始列表，可以通过这些节点来自动发现新加入集群的节点。

Elasticsearch FAQ

elasticsearch 不允许以 root 权限来运行

问题：在 Linux 环境中，elasticsearch 不允许以 root 权限来运行。

如果以 root 身份运行 elasticsearch，会提示这样的错误：

1

can not run elasticsearch as root

解决方法：使用非 root 权限账号运行 elasticsearch

1
2
3
4
5
6
7
8

# 创建用户组
groupadd elk
# 创建新用户，-g elk 设置其用户组为 elk，-p elk 设置其密码为 elk
useradd elk -g elk -p elk
# 更改 /opt 文件夹及内部文件的所属用户及组为 elk:elk
chown -R elk:elk /opt # 假设你的 elasticsearch 安装在 opt 目录下
# 切换账号
su elk

vm.max_map_count 不低于 262144

问题：vm.max_map_count 表示虚拟内存大小，它是一个内核参数。elasticsearch 默认要求 vm.max_map_count 不低于 262144。

1

max virtual memory areas vm.max_map_count [65530] is too low, increase to at least [262144]

解决方法：

你可以执行以下命令，设置 vm.max_map_count ，但是重启后又会恢复为原值。

1

sysctl -w vm.max_map_count=262144

持久性的做法是在 /etc/sysctl.conf 文件中修改 vm.max_map_count 参数：

1
2

echo "vm.max_map_count=262144" > /etc/sysctl.conf
sysctl -p

注意

如果运行环境为 docker 容器，可能会限制执行 sysctl 来修改内核参数。

这种情况下，你只能选择直接修改宿主机上的参数了。

nofile 不低于 65536

问题： nofile 表示进程允许打开的最大文件数。elasticsearch 进程要求可以打开的最大文件数不低于 65536。

1

max file descriptors [4096] for elasticsearch process is too low, increase to at least [65536]

解决方法：

在 /etc/security/limits.conf 文件中修改 nofile 参数：

1
2

echo "* soft nofile 65536" > /etc/security/limits.conf
echo "* hard nofile 131072" > /etc/security/limits.conf

nproc 不低于 2048

问题： nproc 表示最大线程数。elasticsearch 要求最大线程数不低于 2048。

1

max number of threads [1024] for user [user] is too low, increase to at least [2048]

解决方法：

在 /etc/security/limits.conf 文件中修改 nproc 参数：

1
2

echo "* soft nproc 2048" > /etc/security/limits.conf
echo "* hard nproc 4096" > /etc/security/limits.conf

参考资料

• Elasticsearch 官方下载安装说明
• Install Elasticsearch with RPM
• Elasticsearch 使用积累

Elasticsearch 面试

Elasticsearch 简介

扩展阅读：

• Elasticsearch 官方文档之基础知识

【基础】什么是 ES？

:::details 要点

Elasticsearch 是一个开源的分布式搜索和分析引擎。

Elasticsearch 基于搜索库 Lucene 开发。Elasticsearch 隐藏了 Lucene 的复杂性，提供了简单易用的 REST API / Java API 接口（另外还有其他语言的 API 接口）。

Elasticsearch 是面向文档的，它将复杂数据结构序列化为 JSON 形式存储。

Elasticsearch 提供近实时（Near Realtime，缩写 NRT）的全文搜索。近实时是指：

• 从写入数据到数据可以被搜索，存在较小的延迟（大概是 1s）。
• 基于 Elasticsearch 执行搜索和分析可以达到秒级。

:::

【基础】ES 有哪些应用场景？

:::details 要点

Elasticsearch 的主要功能如下：

• 海量数据的分布式存储及集群管理
• 提供丰富的近实时搜索能力
• 海量数据的近实时分析（聚合）

Elasticsearch 被广泛应用于以下场景：

• 搜索
  • 全文检索 - Elasticsearch 通过快速搜索大型数据集，使复杂的搜索查询变得更加容易。它对于需要即时和相关搜索结果的网站、应用程序或企业特别有用。
  • 自动补全和拼写纠正 - 可以在用户输入内容时，实时提供自动补全和拼写纠正，以增加用户体验并提高搜索效率。
  • 地理空间搜索 - 使用地理空间查询搜索位置并计算空间关系。
  • 近实时分析 - Elasticsearch 能够进行实时分析，使其适用于追踪实时数据的仪表板，例如用户活动、用户画像等，分析后进行推送。
• 可观测性
  • 日志、指标和链路追踪 - 收集、存储和分析来自应用程序、系统和服务的日志、指标和追踪。
  • 性能监控 - 监控和分析业务关键性能指标。
  • OpenTelemetry - 使用 OpenTelemetry 标准，将遥测数据采集到 Elastic Stack。

:::

【基础】Elasticsearch 有哪些里程碑版本？

:::details 要点

Elasticsearch 里程碑版本：

• 1.0（2014 年）
• 5.0（2016 年）
  • Lucene 6.x
  • 默认打分机制从 TD-IDF 改为 BM25
  • 增加 Keyword 类型
• 6.0（2017 年）
  • Lucene 7.x
  • 跨集群复制
  • 索引生命周期管理
  • SQL 的支持
• 7.0（2019 年）
  • Lucene 8.0
  • 移除 Type
  • ECK （用于支持 K8S）
  • 集群协调
  • High Level Rest Client
  • Script Score 查询
• 8.0（2022 年）
  • Lucene 9.0
  • 向量搜索
  • 支持 OpenTelemetry

:::

【基础】什么是 Elasic Stack(ELK)？

:::details 要点

Elastic Stack 通常被用来作为日志采集、检索、可视化的解决方案。

Elastic Stack 也常被称为 ELK，这是 Elastic 公司旗下三款产品 Elasticsearch 、Logstash 、Kibana 的首字母组合。

• Elasticsearch 负责存储数据，并提供对数据的检索和分析。
• Logstash 传输和处理你的日志、事务或其他数据。
• Kibana 将 Elasticsearch 的数据分析并渲染为可视化的报表。

Elastic Stack，在 ELK 的基础上扩展了一些新的产品。如：Beats，这是针对不同类型数据的轻量级采集器套件。

此外，基于 Elastic Stack，其技术生态还可以和一些主流的分布式中间件进行集成，以应对各种不同的场景。

:::

Elasticsearch CRUD

扩展阅读：

• Elasticsearch 官方文档之 REST API

【基础】如何在 ES 中 CRUD？

:::details 要点

Elasticsearch 的基本 CRUD 方式如下：

• 添加索引
  • PUT <index>/_create/<id> - 指定 id，如果 id 已存在，报错
  • POST <index>/_doc - 自动生成 _id
• 删除索引 - DELETE /<index>？pretty
• 更新索引 - POST <index>/_update/<id>
• 查询索引 - GET <index>/_doc/<id>
• 批量更新 - bulk API 支持 index/create/update/delete
• 批量查询 - _mget 和 _msearch 可以用于批量查询

扩展阅读：Quick starts

:::

Elasticsearch Mapping

扩展阅读：

• Elasticsearch 官方文档之 Mapping
• Elasticsearch 从入门到实践之 Mapping

【基础】ES 支持哪些数据类型？

:::details 要点

Elasticsearch 支持丰富的数据类型，常见的有：

• 文本类型：text、keyword、constant_keyword、 wildcard
• 二进制类型：binary
• 数值类型：long、float 等
• 日期类型：date
• 布尔类型：boolean
• 对象类型：object、nested

扩展：数据类型

:::

【基础】ES 如何识别字段的数据类型？

:::details 要点

在 Elasticsearch 中，Mapping（映射），用来定义一个文档以及其所包含的字段如何被存储和索引，可以在映射中事先定义字段的数据类型、字段的权重、分词器等属性，就如同在关系型数据库中创建数据表时会设置字段的类型。简言之，Mapping 定义了索引中的文档有哪些字段及其类型、这些字段是如何存储和索引的，就好像数据库的表定义一样。

Mapping 会把 json 文档映射成 Lucene 所需要的扁平格式

一个 Mapping 属于一个索引的 Type

• 每个文档都属于一个 Type
• 一个 Type 有一个 Mapping 定义
• 7.0 开始，不需要在 Mapping 定义中指定 type 信息

每个 document 都是 field 的集合，每个 field 都有自己的数据类型。映射数据时，可以创建一个 mapping，其中包含与 document 相关的 field 列表。映射定义还包括元数据 field，例如 _source ，它自定义如何处理 document 的关联元数据。

在 Elasticsearch 中，映射可分为静态映射和动态映射。在关系型数据库中写入数据之前首先要建表，在建表语句中声明字段的属性，在 Elasticsearch 中，则不必如此，Elasticsearch 最重要的功能之一就是让你尽可能快地开始探索数据，文档写入 Elasticsearch 中，它会根据字段的类型自动识别，这种机制称为动态映射，而静态映射则是写入数据之前对字段的属性进行手工设置。

静态映射

Elasticsearch 官方将静态映射称为显式映射（Explicit mapping）。静态映射是在创建索引时手工指定索引映射。静态映射和 SQL 中在建表语句中指定字段属性类似。相比动态映射，通过静态映射可以添加更详细、更精准的配置信息。

例如：

• 哪些字符串字段应被视为全文字段。
• 哪些字段包含数字、日期或地理位置。
• 日期值的格式。
• 用于控制动态添加字段的自定义规则。

【示例】创建索引时，显示指定 mapping

1
2
3
4
5
6
7
8
9
10

PUT /my-index-000001
{
  "mappings": {
    "properties": {
      "age":    { "type": "integer" },
      "email":  { "type": "keyword"  },
      "name":   { "type": "text"  }
    }
  }
}

【示例】在已存在的索引中，指定一个 field 的属性

1
2
3
4
5
6
7
8
9

PUT /my-index-000001/_mapping
{
  "properties": {
    "employee-id": {
      "type": "keyword",
      "index": false
    }
  }
}

【示例】查看 mapping

1

GET /my-index-000001/_mapping

【示例】查看指定 field 的 mapping

1

GET /my-index-000001/_mapping/field/employee-id

动态映射

动态映射机制，允许用户不手动定义映射，Elasticsearch 会自动识别字段类型。在实际项目中，如果遇到的业务在导入数据之前不确定有哪些字段，也不清楚字段的类型是什么，使用动态映射非常合适。当 Elasticsearch 在文档中碰到一个以前没见过的字段时，它会利用动态映射来决定该字段的类型，并自动把该字段添加到映射中。

示例：创建一个名为 data 的索引、其 mapping 类型为 _doc，并且有一个类型为 long 的字段 count。

1
2

PUT data/_doc/1
{ "count": 5 }

:::

Elasticsearch 存储

扩展阅读：

• Elasticsearch 官方文档之索引
• Elasticsearch 从入门到实践之倒排索引的实现
• https://blog.devgenius.io/elasticsearch-solution-to-searching-71116220c82f

【基础】ES 的逻辑存储是怎样设计的？

:::details 要点

Elasticsearch 的逻辑存储被设计为层级结构，自上而下依次为：

各层级结构的说明如下：

（1）Document（文档）

Elasticsearch 是面向文档的，这意味着读写数据的最小单位是文档。Elasticsearch 以 JSON 文档的形式序列化和存储数据。文档是一组字段，这些字段是包含数据的键值对。每个文档都有一个唯一的 ID。

一个简单的 Elasticsearch 文档可能如下所示：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

{
  "_index": "my-first-elasticsearch-index",
  "_id": "DyFpo5EBxE8fzbb95DOa",
  "_version": 1,
  "_seq_no": 0,
  "_primary_term": 1,
  "found": true,
  "_source": {
    "email": "john@smith.com",
    "first_name": "John",
    "last_name": "Smith",
    "info": {
      "bio": "Eco-warrior and defender of the weak",
      "age": 25,
      "interests": ["dolphins", "whales"]
    },
    "join_date": "2024/05/01"
  }
}

Elasticsearch 中的 document 是无模式的，也就是并非所有 document 都必须拥有完全相同的字段，它们不受限于同一个模式。

（2）Field（字段）

field 包含数据的键值对。默认情况下，Elasticsearch 对每个字段中的所有数据建立索引，并且每个索引字段都具有专用的优化数据结构。

document 包含数据和元数据。Metadata Field（元数据字段） 是存储有关文档信息的系统字段。在 Elasticsearch 中，元数据字段都以 _ 开头。常见的元数据字段有：

• _index - 文档所属的索引
• _id - 文档的 ID
• _source - 表示文档原文的 JSON

（3）Type（类型）

在 Elasticsearch 中，type 是 document 的逻辑分类。每个 index 里可以有一个或多个 type。

不同的 type 应该有相似的结构（schema）。举例来说，id字段不能在这个组是字符串，在另一个组是数值。

注意：Elasticsearch 7.x 版已彻底移除 type。

（4）Index（索引）

在 Elasticsearch 中，可以将 index 视为 document 的集合。

Elasticsearch 会为所有字段建立索引，经过处理后写入一个倒排索引（Inverted Index）。查找数据的时候，直接查找该索引。

所以，Elasticsearch 数据管理的顶层单位就叫做 Index。它是单个数据库的同义词。每个 Index 的名字必须是小写。

（5）Elasticsearch 概念和 RDBM 概念

:::

【基础】ES 的物理存储是怎样设计的？

:::details 要点

Elasticsearch 的物理存储，天然使用了分布式设计。

每个 Elasticsearch 进程都从属于一个 cluster，一个 cluster 可以有一个或多个 node（即 Elasticsearch 进程）。

Elasticsearch 存储会将每个 index 分为多个 shard，而 shard 可以分布在集群中不同节点上。正是由于这个机制，使得 Elasticsearch 有了水平扩展的能力。shard 也是 Elasticsearch 将数据从一个节点迁移到拎一个节点的最小单位。

Elasticsearch 的每个 shard 对应一个 Lucene index（一个包含倒排索引的文件目录）。Lucene index 又会被分解为多个 segment。segment 是索引中的内部存储元素，由于写入效率的考虑，所以被设计为不可变更的。segment 会定期 合并 较大的 segment，以保持索引大小。简单来说，Lucene 就是一个 jar 包，里面包含了封装好的构建、管理倒排索引的算法代码。

:::

【中级】什么是倒排索引？

:::details 要点

既然有倒排索引，顾名思义，有与之相对的正排索引。这里，以实现一个诗词检索器为例，来说明一下正排索引和倒排索引的区别。

正排索引是 ID 到数据的映射关系。如下所示，每首诗词用一个 ID 唯一识别。如果，我们要查找诗歌内容中是否包含某个关键字，就不得不在内容的完整文本中进行检索，效率很低。即使针对文档内容创建传统 RDBM 的索引（通常为 B+ 树结构），查找效率依然低下，并且会产生较大的额外存储空间开销。

倒排索引的实现与正排索引相反。将文本分词后保存为多个词项，词项到 ID 的映射关系称为倒排索引（Inverted index）。

除了要保存词项与 ID 的关系外，还需要保存这个词项在对应文档出现的位置、偏移量等信息，这是因为很多检索的场景中还需要判断关键词前后的内容是否符合搜索要求。

有了倒排索引，搜索引擎可以很方便地响应用户的查询。比如用户输入查询 明月，搜索系统查找倒排索引，从中读出包含这个单词的文档，这些文档就是提供给用户的搜索结果。

要注意倒排索引的两个重要细节：

• 倒排索引中的所有词项对应一个或多个文档；
• 倒排索引中的词项根据字典顺序升序排列

:::

【中级】什么是字典树？

:::details 要点

Trie（字典树），也被称为前缀树，是一种树状数据结构，用于有效检索键值对。它通常用于实现字典和自动补全功能，使其成为许多搜索算法的基本组件。

Trie 遵循一个规则：如果两个字符串有共同的前缀，那么它们在 Trie 中将具有相同的祖先。

Trie 的检索能力也可以使用 Hash 替代，但是 Trie 比 Hash 更高效。此外，Trie 有 Hash 不具备的优点：Trie 支持前缀搜索和排序。Trie 的主要缺点是：存储词项需要额外的空间，对于长文本，空间可能会变得很大。

:::

【高级】ES 如何实现倒排索引？

:::details 要点

在 Elasticsearch 中，数据存储、检索实际上是基于 Lucene 实现。

一个 Elasticsearch shard 对应一个 Lucene index，

Elasticsearch 的每个 shard 对应一个 Lucene index（一个包含倒排索引的文件目录）。Lucene index 又会被分解为多个 segment。segment 是索引中的内部存储元素，由于写入效率的考虑，所以被设计为不可变更的。segment 会定期 合并 较大的 segment，以保持索引大小。

倒排索引的组成主要有 3 个部分：

• Term Dictionary - Term Dictionary 用于保存 term（词项）。由于 ES 会对 document 中的每个 field 都进行分词，所以数据量可能会非常大。
  • Term Dictionary 存储数据时，先将所有的 term 进行排序，然后将 Term Dictionary 中有共同前缀的 term 抽取出来进行分块存储；再对共同前缀做索引，最后通过索引就可以找到公共前缀对应的块在 Term Dictionary 文件中的偏移地址。
  • 由于每个块中都有共同前缀，所以不需要再保存每个 Term 的全部内容，只需要保存其后缀即可，而且这些后缀都是排好序的。
• Term Index - Term Index 是 Term Dictionary 的索引。由于 Term Dictionary 存储的 term 可能会非常多，为了提高查询效率，从而设计了 Term Index。
  • 为了提高检索效率以及节省空间，Term Index 只使用公共前缀做索引。
  • Lucene 中实现 Term Index 采用了 FST 算法。FST 是一种非常复杂的结构，可以把它简单理解为一个占用空间小且高效的 KV 数据结构，有点类似于 Trie（字典树）。FST 有以下的特点：
    • 通过对 Term Dictionary 数据的前缀复用，压缩了存储空间；
    • 高效的查询性能，O(len(prefix)) 的复杂度；
    • 构建后不可修改，因此 Lucene segment 也不允许修改。
• Posting List - Posting List 保存着每个 term 的映射信息。如文档 ID、词频、位置等。Lucene 把这些数据分成 3 个文件进行存储：
  • .doc 文件，记录了文档 ID 信息和 term 的词频，还额外记录了跳表的信息，用来加速文档 ID 的查询；并且还记录了 term 在 .pos 和 .pay 文件中的位置，有助于进行快速读取。
  • .pay 文件，记录了 payload 信息和 term 在 doc 中的偏移信息；
  • .pos 文件，记录了 term 在 doc 中的位置信息。

:::

Elasticsearch 搜索

扩展阅读：

• Elasticsearch 官方文档之搜索数据
• 极客时间教程 - Elasticsearch 核心技术与实战
• Elasticsearch 从入门到实践之分布式文档搜索机制
• Elasticsearch 官方文档之搜索数据
• Elasticsearch 官方文档之全文查询
• Elasticsearch 官方文档之词项查询
• Elasticsearch 官方文档之组合查询
• Elasticsearch 官方文档之推荐查询
• Elasticsearch 官方文档之查询和过滤上下文

【基础】ES 索引别名有什么用？

:::details 要点

Elasticsearch 中的别名可用于更轻松地管理和使用索引。别名允许同时对多个索引执行操作，或者通过隐藏底层索引结构的复杂性来简化索引管理。

扩展阅读：https://www.elastic.co/guide/en/elasticsearch/reference/current/aliases.html

:::

【基础】ES 中有哪些全文搜索 API？

:::details 要点

ES 支持全文搜索的 API 主要有以下几个：

• intervals - 根据匹配词的顺序和近似度返回文档。
• match - 匹配查询，用于执行全文搜索的标准查询，包括模糊匹配和短语或邻近查询。
• match_bool_prefix - 对检索文本分词，并根据这些分词构造一个布尔查询。除了最后一个分词之外的每个分词都进行 term 查询。最后一个分词用于 prefix 查询；其他分词都进行 term 查询。
• match_phrase - 短语匹配查询，短语匹配会将检索内容分词，这些词语必须全部出现在被检索内容中，并且顺序必须一致，默认情况下这些词都必须连续。
• match_phrase_prefix - 与 match_phrase 查询类似，但对最后一个单词执行通配符搜索。
• multi_match 支持多字段 match 查询
• combined_fields - 匹配多个字段，就像它们已索引到一个组合字段中一样。
• query_string - 支持紧凑的 Lucene query string（查询字符串）语法，允许指定 AND|OR|NOT 条件和单个查询字符串中的多字段搜索。仅适用于专家用户。
• simple_query_string - 更简单、更健壮的 query_string 语法版本，适合直接向用户公开。

扩展阅读：Elasticsearch 官方文档之全文查询

:::

【基础】ES 中有哪些词项搜索 API？

:::details 要点

Term（词项）是表达语意的最小单位。搜索和利用统计语言模型进行自然语言处理都需要处理 Term。

全文查询在执行查询之前会分析查询字符串。与全文查询不同，词项级别查询不会分词，而是将输入作为一个整体，在倒排索引中查找准确的词项。并且使用相关度计算公式为每个包含该词项的文档进行相关度计算。一言以概之：词项查询是对词项进行精确匹配。词项查询通常用于结构化数据，如数字、日期和枚举类型。

ES 支持词项搜索的 API 主要有以下几个：

• exists - 返回在指定字段上有值的文档。
• fuzzy - 模糊查询，返回包含与搜索词相似的词的文档。
• ids - 根据 ID 返回文档。此查询使用存储在 _id 字段中的文档 ID。
• prefix - 前缀查询，用于查询某个字段中包含指定前缀的文档。
• range - 范围查询，用于匹配在某一范围内的数值型、日期类型或者字符串型字段的文档。
• regexp - 正则匹配查询，返回与正则表达式相匹配的词项所属的文档。
• term - 用来查找指定字段中包含给定单词的文档。
• terms - 与 term 相似，但可以搜索多个值。
• terms set - 与 term 相似，但可以定义返回文档所需的匹配词数。
• wildcard - 通配符查询，返回与通配符模式匹配的文档。

扩展阅读：Elasticsearch 官方文档之词项查询

:::

【基础】ES 支持哪些组合查询？

:::details 要点

复合查询就是把一些简单查询组合在一起实现更复杂的查询需求，除此之外，复合查询还可以控制另外一个查询的行为。

复合查询有以下类型：

• bool - 布尔查询，可以组合多个过滤语句来过滤文档。
• boosting - 提供调整相关性打分的能力，在 positive 块中指定匹配文档的语句，同时降低在 negative 块中也匹配的文档的得分。
• constant_score - 使用 constant_score 可以将 query 转化为 filter，filter 可以忽略相关性算分的环节，并且 filter 可以有效利用缓存，从而提高查询的性能。
• dis_max - 返回匹配了一个或者多个查询语句的文档，但只将最佳匹配的评分作为相关性算分返回。
• function_score - 支持使用函数来修改查询返回的分数。

扩展阅读：Elasticsearch 官方文档之组合查询

:::

【基础】ES 中的 query 和 filter 有什么区别？

:::details 要点

在 Elasticsearch 中，可以在两个不同的上下文中执行查询：

• query context - 有相关性计算，采用相关性算法，计算文档与查询关键词之间的相关度，并根据评分（_score）大小排序。
• filter context - 无相关性计算，可以利用缓存，性能更好。

扩展阅读：Elasticsearch 官方文档之查询和过滤上下文

:::

【中级】ES 支持哪些推荐查询？

:::details 要点

ES 通过 Suggester 提供了推荐搜索能力，可以用于文本纠错，文本自动补全等场景。

根据使用场景的不同，ES 提供了以下 4 种 Suggester：

• Term Suggester - 基于词项的纠错补全。
• Phrase Suggester - 基于短语的纠错补全。
• Completion Suggester - 自动补全单词，输入词语的前半部分，自动补全单词。
• Context Suggester - 基于上下文的补全提示，可以实现上下文感知推荐。

扩展阅读：Elasticsearch 官方文档之推荐查询

:::

【高级】ES 搜索数据的流程是怎样的？

:::details 要点

在 Elasticsearch 中，搜索一般分为两个阶段，query 和 fetch 阶段。可以简单的理解，query 阶段确定要取哪些 doc，fetch 阶段取出具体的 doc。

Query 阶段会根据搜索条件遍历每个分片（主分片或者副分片中的其一）中的数据，返回符合条件的前 N 条数据的 ID 和排序值，然后在协调节点中对所有分片的数据进行排序，获取前 N 条数据的 ID。

Query 阶段的流程如下：

1. 客户端发送请求到任意一个节点，这个 node 成为 coordinate node（协调节点）。coordinate node 创建一个大小为 from + size 的优先级队列用来存放结果。
2. coordinate node 对 document 进行路由，将请求转发到对应的 node，此时会使用 round-robin 随机轮询算法，在 primary shard 以及其所有 replica 中随机选择一个，让读请求负载均衡。
3. 每个分片在本地执行搜索请求，并将查询结果打分排序，然后将结果保存到 from + size 大小的有序队列中。
4. 接着，每个分片将结果返回给 coordinate node，coordinate node 对数据进行汇总处理：合并、排序、分页，将汇总数据存到一个大小为 from + size 的全局有序队列。

需要注意的是，在协调节点转发搜索请求的时候，如果有 N 个 Shard 位于同一个节点时，并不会合并这些请求，而是发生 N 次请求！

在 Fetch 阶段，协调节点会从 Query 阶段产生的全局排序列表中确定需要取回的文档 ID 列表，然后通过路由算法计算出各个文档对应的分片，并且用 multi get 的方式到对应的分片上获取文档数据。

Fetch 阶段的流程如下：

1. coordinate node 确定需要获取哪些文档，然后向相关节点发起 multi get 请求；
2. 分片所在节点读取文档数据，并且进行 _source 字段过滤、处理高亮参数等，然后把处理后的文档数据返回给协调节点；
3. coordinate node 汇总所有数据后，返回给客户端。

:::

【高级】ES 为什么会有深分页问题？

:::details 要点

在 Elasticsearch 中，支持三种分页查询方式：

• from + size - 可以使用 from 和 size 参数分别指定查询的起始页和每页记录数。
• search_after - 不支持指定页数，只能向下翻页；并且需要指定 sort，并保证值是唯一的。然后，可以反复使用上次结果中最后一个文档的 sort 值进行查询。
• scroll - 类似于 RDBMS 中的游标，只允许向下翻页。每次下一页查询后，使用返回结果的 scroll id 来作为下一次翻页的标记。scroll 查询会在搜索初始化阶段会生成快照，后续数据的变化无法及时体现在查询结果，因此更加适合一次性批量查询或非实时数据的分页查询。

前文中，我们已经了解了 ES 两阶段搜索流程（Query 和 Fetch）。从中不难发现，这种搜索方式在分页查询时会出现以下情况：

• 每个 shard 要扫描 from + size 条数据；
• coordinate node 需要接收并处理 (from + size) * primary_shard_num 条数据。

如果 from 或 size 很大，需要处理的数据量也会很大，代价很高，这就是深分页产生的原因。为了避免深分页，ES 默认限制 from + size 不能超过 10000，可以通过 index.max_result_window 设置。

如何解决 Elasticsearch 深分页问题？

ES 官方提供了另外两种分页查询方式 search_after + PIT 和 scroll（注意：官方已不再推荐） 来避免深分页问题。

:::

Elasticsearch 聚合

扩展阅读：

• 极客时间教程 - Elasticsearch 核心技术与实战
• Elasticsearch 官方文档之聚合
• Elasticsearch 从入门到实践之聚合

【基础】什么是聚合？ES 中有哪些聚合？

:::details 要点

在数据库中，聚合是指将数据进行分组统计，得到一个汇总的结果。例如，计算总和、平均值、最大值或最小值等操作。

Elasticsearch 将聚合分为三类：

:::

【中级】ES 如何对海量数据（过亿）进行聚合计算？

:::details 要点

Elasticsearch 支持 cardinality（近似计算非重复值） 。它提供一个字段的基数，即该字段的 distinct 或者 unique 值的数目。它是基于 HLL 算法的。HLL 会先对我们的输入作哈希运算，然后根据哈希运算的结果中的 bits 做概率估算从而得到基数。其特点是：可配置的精度，用来控制内存的使用（更精确 ＝ 更多内存）；小的数据集精度是非常高的；我们可以通过配置参数，来设置去重需要的固定内存使用量。无论数千还是数十亿的唯一值，内存使用量只与你配置的精确度相关。

:::

Elasticsearch 分析

【基础】什么是文本分析？为什么需要文本分析？

:::details 要点

Elasticsearch 中存储的数据可以粗略分为：

• 词项数据 - 采用精确查询。比较两条词项数据是否相对，实际是比较二者的二进制数据，结果只有相等或不相等。
• 文本数据 - 采用全文搜索。比较两个文本数据是否相等，没有太大意义，一般只会比较二者是否相似。相似性比较，是通过相关性评分来评估的。而计算相关性评分，需要对全文先分词处理，然后对分词后的词项进行统计才能进行相似性评估。

Elasticsearch 文本分析是将非结构化文本转换为一组词项（term）的过程。

文本分析可以分为两个方面：

• Tokenization（分词化） - 分词化将文本分解成更小的块，称为分词。在大多数情况下，这些分词是单独的 term（词项）。
• Normalization（标准化） - 经过分词后的文本只能进行词项匹配，但是无法进行同义词匹配。为解决这个问题，可以将文本进行标准化处理。例如：将 foxes 标准化为 fox。

:::

【基础】Elasticsearch 中的分析器是什么？

:::details 要点

文本分析由 analyzer（分析器） 执行，分析器是一组控制整个过程的规则。无论是索引还是搜索，都需要使用分析器。

analyzer（分析器） 由三个组件组成：零个或多个 Character Filters（字符过滤器）、有且仅有一个 Tokenizer（分词器）、零个或多个 Token Filters（分词过滤器）。分析的执行顺序为：character filters -> tokenizer -> token filters。

Elasticsearch 内置的分析器：

• standard - 根据单词边界将文本划分为多个 term，如 Unicode 文本分割算法所定义。它删除了大多数标点符号、小写 term，并支持删除停用词。
• simple - 遇到非字母字符时将文本划分为多个 term，并将其转为小写。
• whitespace - 遇到任何空格时将文本划分为多个 term，不转换为小写。
• stop - 与 simple 相似，同时支持删除停用词（如：the、a、is）。
• keyword - 部分词，直接将输入当做输出。
• pattern - 使用正则表达式将文本拆分为 term。它支持小写和非索引字。
• fingerprint - 可创建用于重复检测的指纹。
• 语言分析器 - 提供了 30 多种常见语言的分词器。

默认情况下，Elasticsearch 使用 standard analyzer（标准分析器），它开箱即用，适用于大多数使用场景。Elasticsearch 也允许定制分析器。

Character Filters（字符过滤器）

Character Filters（字符过滤器） 将原始文本作为字符流接收，并可以通过添加、删除或更改字符来转换文本。分析器可以有零个或多个 Character Filters（字符过滤器），如果配置了多个，它会按照配置的顺序执行。

Elasticsearch 内置的字符过滤器：

• html_strip - html_strip字符过滤器用于去除 HTML 元素（如 <b>）并转义 HTML 实体（如 &）。
• mapping - mapping 字符过滤器用于将指定字符串的任何匹配项替换为指定的替换项。
• pattern_replace - pattern_replace 字符筛选器将匹配正则表达式的任何字符替换为指定的替换。

Tokenizer（分词器）

Tokenizer（分词器） 接收字符流，将其分解为分词（通常是单个单词），并输出一个分词流。分词器还负责记录每个 term 的顺序或位置，以及该 term 所代表的原始单词的开始和结束字符偏移量。分析器有且仅有一个 Tokenizer（分词器）。

Elasticsearch 内置的分词器：

• 面向单词的分词器
  • standard - 将文本划分为单词边界上的 term，如 Unicode 文本分割算法所定义。它会删除大多数标点符号。它是大多数语言的最佳选择。
  • letter - 遇到非字母字符时将文本划分为多个 term。
  • lowercase - 到非字母字符时将文本划分为多个 term，并将其转为小写。
  • whitespace - 遇到任何空格时将文本划分为多个 term。
  • uax_url_email - 与 standard 相似，不同之处在于它将 URL 和电子邮件地址识别为单个分词。
  • classic - 基于语法的英语分词器。
  • thai - 将泰语文本分割为单词。
• 部分单词分词器
  • n-gram - 遇到指定字符列表（例如空格或标点符号）中的任何一个时，将文本分解为单词，然后返回每个单词的 n-gram：一个连续字母的滑动窗口，例如 quick→ [qu， ui， ic， ck]。
  • edge_n-gram - 遇到指定字符列表（例如空格或标点符号）中的任何一个时，将文本分解为单词，然后返回锚定到单词开头的每个单词的 n 元语法，例如 quick → [q， qu， qui， quic， quick]。
• 结构化文本分词器
  • keyword - 接受给定的任何文本，并输出与单个 term 完全相同的文本。它可以与 lowercase 等分词过滤器结合使用，以规范化分析的 term。
  • pattern - 使用正则表达式在文本与单词分隔符匹配时将文本拆分为 term，或者将匹配的文本捕获为 term。
  • simple_pattern - 使用正则表达式将匹配的文本捕获为 term。它使用正则表达式特征的受限子集，并且通常比 pattern 更快。
  • char_group - 可以通过要拆分的字符集进行配置，这通常比运行正则表达式代价更小。
  • simple_pattern_split - 使用与 simple_pattern 分词器相同的受限正则表达式子集，但在匹配项处拆分输入，而不是将匹配项作为 term 返回。
  • path_hierarchy - 基于文件系统的路径分隔符，进行拆分，例如 /foo/bar/baz → [/foo, /foo/bar, /foo/bar/baz ] 。

Token Filters（分词过滤器）

Token Filters（分词过滤器） 接收分词流，并可以添加、删除或更改分词。常用的分词过滤器有： lowercase（小写转换）、stop（停用词处理）、synonym（同义词处理） 等等。分析器可以有零个或多个 Token Filters（分词过滤器），如果配置了多个，它会按照配置的顺序执行。

Elasticsearch 内置了很多分词过滤器，这里列举几个常见的：

• classic - 从单词末尾删除英语所有格 （'s），并删除首字母缩略词中的点。它使用 Lucene 的 ClassicFilter。
• lowercase - 将分词转为小写。
• stop - 从分词中删除 stop word（停用词）。
• synonym - 允许在分析过程中轻松处理 近义词。

:::

【中级】如果需要中文分词怎么办？

:::details 要点

在英文中，单词有自然的空格作为分隔。

在中文中，分词有以下难点：

• 中文不能根据一个个汉字进行分词
• 不同于英文可以根据自然的空格进行分词；中文中一般不会有空格。
• 同一句话，在不同的上下文中，有不同个理解。例如：这个苹果，不大好吃；这个苹果，不大，好吃！

可以使用一些插件来获得对中文更好的分析能力：

• analysis-icu - 添加了扩展的 Unicode 支持，包括更好地分析亚洲语言、Unicode 规范化、Unicode 感知大小写折叠、排序规则支持和音译。
• elasticsearch-analysis-ik - 支持自定义词库，支持热更新分词字典
• elasticsearch-thulac-plugin - 清华大学自然语言处理和社会人文计算实验室的一套中文分词器。

:::

Elasticsearch 复制

【中级】ES 如何保证高可用？

:::details 要点

ES 通过副本机制实现高可用。ES 的数据副本模型参考了 PacificA 算法。

ES 必须满足以下条件才能运行：

• 至少需要 选举一个主节点
• 每个 角色 至少一个节点
• 每个 分片 至少有一个副本（主副本）

默认的情况下，ES 的数据写入只需要保证主副本写入了即可，ES 在写上选择的是可用性优先，而并不是像 PacificA 协议那样的强一致性。而数据读取方面，ES 可能会读取到没有 commit 的数据，所以 ES 的数据读取可能产生不一致的情况。

在数据恢复方面，系统可以借助 GlobalCheckpoint 和 LocalCheckpoint 来加速数据恢复的过程。如果集群中只有旧的副本可用，那么可以使用 allocate_stale_primary 将一个指定的旧分片分配为主分片，但会造成数据丢失，慎用！

扩展：

• https://www.elastic.co/guide/en/elasticsearch/reference/current/high-availability.html
• Elasticsearch 从入门到实践之副本策略
• Elasticsearch 从入门到实践之 ES 的数据副本模型

:::

【中级】ES 是如何实现选主的？

:::details 要点

发起选主流程的条件：

• 只有 master-eligible 节点（通过 node.master: true 设置）才能发起选主流程。
• 该 master-eligible 节点的当前状态不是 master。
• 该 master-eligible 节点通过 ZenDiscovery 模块的 ping 操作询问其已知的集群其他节点，没有任何节点连接到 master。
• 包括本节点在内，当前已有超过 discovery.zen.minimum_master_nodes 个节点没有连接到 master。

一般，应设置 discovery.zen.minimum_master_nodes 为 N / 2 + 1，以保证各种分布式决议能得到大多数节点认可。当集群由于故障（如：通信失联）被分割成多个子集群时，节点数未达到半数以上的子集群，不允许进行选主。以此，来避免出现脑裂问题。

选主流程：

• Elasticsearch 的选主是 ZenDiscovery 模块负责的，主要包含 Ping（节点之间通过这个 RPC 来发现彼此）和 Unicast（单播模块，包含一个主机列表以控制哪些节点需要 ping 通）这两部分；
• 对所有 master-eligible 节点根据 nodeId 字典排序：每次选举时，每个节点都把自己所知道的节点排一次序，然后选出 id 最小的节点，投票该节点为 master 节点。
• 如果对某个节点的投票数达到一定的值（投票数 > N / 2 + 1），并且该节点自己也投票自己，那这个节点就当选 master。否则，重新发起选举，直到满足上述条件。

:::

【中级】ES 如何避免脑裂问题？

:::details 要点

ES 集群采用主从架构模式，集群中有且只能有一个 Master 存在。

现在假设这样一种场景，ES 集群部署在 2 个不同的机房。若两个机房网络断连，其中没有主节点的机房进行选主，产生了一个新的主节点。这时，就同时存在了两个主节点，它们各自负责处理接收的请求，会存在数据不一致。一旦，两个机房恢复通信，又将以哪个主节点为主，数据不一致问题怎么办，这就是脑裂问题。

那如何避免产生脑裂呢？ES 使用了 Quorum 机制来避免脑裂，在进行选主的时候，需要超过半数 Master 候选节点参与选主才行。假如有 5 个 Master 候选节点，如果要成功选举出 Master，必须有 (5 / 2) + 1 = 3 个 Master 候选节点参与选主才行。

在 6.x 及之前的版本使用 Zen Discovery 的集群协调子系统，Zen Discovery 允许用户通过使用 discovery.zen.minimum_master_nodes 设置来决定多少个符合主节点条件的节点可以选举出主节点。通常，只有 Master Eligible 节点（Master 候选节点）数大于 Quorum 的时候才能进行选主。计算公式如下：

1

Quorum = (Master 候选节点数 / 2) + 1

Elasticsearch 7.0 中，重新设计并重建了集群协调子系统：

• 移除了 discovery.zen.minimum_master_nodes 设置，让 Elasticsearch 自己选择可以形成法定数量的节点。
• 典型的主节点选举只需很短时间就能完成。
• 集群的扩充和缩减变得更加安全和简单，并且大幅降低了因系统配置不当而可能造成数据丢失的风险。
• 节点状态记录比以往清晰很多，有助于诊断它们不能加入集群的原因，或者为何不能选举出主节点。

:::

Elasticsearch 分片

【中级】ES 是如何实现水平扩展的？

:::details 要点

Elasticsearch 通过分片来实现水平扩展。在 Elasticsearch 中，分片是索引的逻辑划分。索引可以有一个或多个分片，并且每个分片可以存储在集群中的不同节点上。分片用于在多个节点之间分配数据，从而提高性能和可扩展性。

Elasticsearch 中有两种类型的分片：

• primary shard（主分片） - 用于存储原始数据。适当增加主分片数，可以提升 Elasticsearch 集群的吞吐量和整体容量。
• replica shard（副本分片） - 用于存储数据备份。

默认情况下，每个索引都有 1 个主分片（早期版本，默认每个索引有 5 个主分片）。

:::

【中级】ES 如何选择读写数据映射到哪个分片上？

:::details 要点

为了避免出现数据倾斜，系统需要一种高效的方式把数据均匀分散到各个节点上存储，并且在检索的时候可以快速找到文档所在的节点与分片。这就需要确立路由算法，使得数据可以映射到指定的节点上。

常见的路由方式如下：

ES 的数据路由算法是根据文档 ID 和 routing key 来确定 Shard ID 的过程。默认的情况下 routing key 为文档 ID，路由算法一般情况下的计算公式如下：

1

shard_number = hash(_routing) % numer_of_primary_shards

也可以在请求中指定 routing key，下面是新增数据的时候指定 routing 的方式：

1
2
3
4
5

PUT <index>/_doc/<id>?routing=routing_key
{
    "field1": "xxx",
    "field2": "xxx"
}

添加数据时，如果不指定文档 ID，ES 会自动分片一个随机 ID。这种情况下，结合 Hash 算法，可以保证数据被均匀分布到各个分片中。如果指定文档 ID，或指定 routing key，Hash 计算得出的值可能会不够随机，从而导致数据倾斜。

index 一旦设置了主分片数就不能修改，如果要修改就需要 reindex（即数据迁移）。之所以如此，就是因为：一旦修改了主分片数，即等于修改了原 Hash 计算中的变量，无法再通过 Hash 计算正确路由到数据存储的分片。

:::

【中级】如何合理设置 ES 分片？

:::details 要点

ES 索引设置多分片有以下好处：

• 多分片如果分布在不同的节点，查询可以在不同分片上并行执行，提升查询速度；
• 数据写入时，会分散在不同节点存储，避免数据倾斜。

设置多少分片合适：

一般，分片数要大于节点数，这样可以保证：一旦集群中有新的数据节点加入，ES 会自动对分片数进行再均衡，使得分片尽量在集群中分布均匀。

分片数也不宜设置过多，这会带来一些问题：

• 每一个 ES 分片对应一个 Lucene 索引，Lucene 索引存储在一个文件系统的目录中，它又可以分为多个 Segment，每个存储在一个文件中。因此，过多的分片意味着过多的文件，这会导致较大的读写性能开销。
• 此外，分片的元数据信息由 Master 节点维护，分片过多，会增加管理负担。建议，集群的总分片数控制在 10w 以内。

单数据节点分片限制：

• 每个非冻结数据节点 1000 个分片，通过 cluster.max_shards_per_node 控制
• 每个冻结数据节点 3000 个分片，通过 cluster.max_shards_per_node.frozen 控制

此外，分片大小也要有所限制：

• 理论上，一个分片最多包含约 20 亿个文档（Integer.MAX_VALUE - 128）。但是，经验表明，每个分片的文档数量最好保持在 2 亿以下。
• 非日志型（搜索型、线上业务型） ES 的单分片容量最好在 [10GB, 30GB] 范围内；
• 日志型 ES 的单分片容量最好在 [30GB, 30GB] 范围内；

分片大小的上下限可以分别通过 max_primary_shard_size 和 min_primary_shard_size 来控制。

扩展：

• https://www.elastic.co/cn/blog/how-many-shards-should-i-have-in-my-elasticsearch-cluster
• https://elastic.ac.cn/guide/en/elasticsearch/reference/current/size-your-shards.html

:::

Elasticsearch 集群

【中级】Elasticsearch 集群中有哪些不同类型的节点？

:::details 要点

Elasticsearch 中的节点是指集群中的单个 Elasticsearch 进程实例。节点用于存储数据并参与集群的索引和搜索功能。

节点间会相互通信以分配数据和工作负载，从而确保集群的平衡和高性能。节点可以配置不同的角色，这些角色决定了它们在集群中的职责。

可以通过在 elasticsearch.yml 中设置 node.roles 来为节点分配角色。

ES 中主要有以下节点类型：

:::

Elasticsearch 架构

【高级】ES 存储数据的流程是怎样的？

:::details 要点

ES 存储数据的流程可以从三个角度来阐述：

• 从集群的角度来看，数据写入会先路由到主分片，在主分片上写入成功后，会并发写副本分片，最后响应给客户端。

  

• 从分片的角度来看，数据到达分片后需要对内容进行格式校验、分词处理然后再索引数据。

• 从节点的角度来看，ES 数据持久化的步骤可归纳为：Refresh、写 Translog、Flush、Merge。

  

  • 默认，ES 会每秒执行一次 Refresh 操作，把 Index Buffer 的数据写入磁盘中，但不会调用 fsync 刷盘。ES 提供近实时搜索的原因是因为数据被 Refresh 后才能被检索出来 。
  • 为了保证数据不丢失，在写完 Index Buffer 后，ES 还要写 Translog。Translog 是追加写入的，并且默认是调用 fsync 进行刷盘的。
  • Flush 操作会将 Filesystem Cache 中的数据持久化到磁盘中，默认 30 分钟或者在 Translog 写满时（默认 512 MB）触发执行。Flush 将磁盘缓存持久化到磁盘后，会清空 Translog。
  • 最后，ES 和 Lucene 会自动执行 Merge 操作，清理过多的 Segment 文件，这个时候被标记为删除的文档会正式被物理删除。

扩展：

• Elasticsearch 从入门到实践之分布式文档的存储流程
• https://github.com/doocs/advanced-java/blob/main/docs/high-concurrency/es-write-query-search.md

:::

【中级】ES 相关性计算和聚合计算为什么会有计算偏差？

:::details 要点

在 ES 中，不仅仅是普通搜索，相关性计算（评分）和聚合计算也是先在每个 shard 的本地进行计算，再由 coordinate node 进行汇总。由于分片的本地计算是独立的，只能基于数据子集来进行计算，所以难免出现数据偏差。

解决这个问题的方式也有多种：

• 当数据量不大的情况下，设置主分片数为 1，这意味着在数据全集上进行聚合。 但这种方案不太现实。
• 设置 shard_size 参数，将计算数据范围变大，牺牲整体性能，提高精准度。shard_size 的默认值是 size * 1.5 + 10。
• 使用 DFS Query Then Fetch， 在 URL 参数中指定：_search?search_type=dfs_query_then_fetch。这样设定之后，ES 先会把每个分片的词频和文档频率的数据汇总到协调节点进行处理，然后再进行相关性算分。这样的话会消耗更多的 CPU 和内存资源，效率低下！
• 尽量保证数据均匀地分布在各个分片中。

:::

【高级】ES 如何保证读写一致？

:::details 要点

乐观锁机制 - 可以通过版本号使用乐观并发控制，以确保新版本不会被旧版本覆盖，由应用层来处理具体的冲突；

另外对于写操作，一致性级别支持 quorum/one/all，默认为 quorum，即只有当大多数分片可用时才允许写操作。但即使大多数可用，也可能存在因为网络等原因导致写入副本失败，这样该副本被认为故障，分片将会在一个不同的节点上重建。

对于读操作，可以设置 replication 为 sync（默认），这使得操作在主分片和副本分片都完成后才会返回；如果设置 replication 为 async 时，也可以通过设置搜索请求参数、_preference 为 primary 来查询主分片，确保文档是最新版本。

:::

【高级】ES 查询速度为什么快？

:::details 要点

• 倒排索引 - Elasticsearch 查询速度快最核心的点在于使用倒排索引。
  • 在 Elasticsearch 中，为了提高查询效率，它对存储的文档进行了分词处理。分词是将连续的文本切分成一个个独立的词项的过程。对文本进行分词后，Elasticsearch 会为每个词项创建一个倒排索引。这样，当用户进行查询时，Elasticsearch 只需要在倒排索引中查找匹配的词项，从而快速地定位到相关的文档。
  • 正向索引的结构是每个文档和关键字做关联，每个文档都有与之对应的关键字，记录关键字在文档中出现的位置和次数；而倒排索引则是将文档中的词项和文档的 ID 进行关联，这样就可以通过词项快速找到包含它的文档。
• 分片 - Elasticsearch 通过分片，支持分布式存储和搜索，可以实现搜索的并行处理和负载均衡。

参考：https://cloud.tencent.com/developer/article/1922613

:::

【中级】ES 生产环境部署情况是怎样的？

:::details 要点

典型问题

• 你们的 Elasticsearch 生产环境部署情况是怎样的？
• 你们的 Elasticsearch 生产环境集群规模有多大？
• 你们的 Elasticsearch 生产环境中有多少索引，每个索引大概有多少个分片？

知识点

根据实际 Elasticsearch 集群情况描述，以下是一个案例：

• 节点数：19
• 机器配置：6 核，10G 内存，800G 磁盘
• 索引数、分片数：1200+ 索引、1.7 万+ 分片
• 容量：总文档数 150 亿+，总容量 15TB，使用容量 10TB+
• 日增数据量：约 4 千万条数据，50 GB 增长容量

:::

Elasticsearch 优化

【中级】ES 使用有哪些基本规范？

:::details 要点

• 索引数
  • 大索引需要拆分，增强性能，减少风险
  • index 可以按日期拆分为 index_yyyyMMdd，然后用 alias 映射
• Mapping 设置
  • text 数据类型默认是关闭 fielddate
  • 关闭 _source 会导致无法使用 reindex
  • ES 字段数的最大限制是 1000，但是不建议超过 100
• Refersh
  • 写入时，尽量不要执行 refresh，在并发较大的情况下，ES 负载可能会被打满。
• 索引别名
  • 尽量使用索引的别名，在类似于进行索引字段类型变更需要进行索引重建的时候会减少很多的问题。
  • 别名的下面可以挂载多个索引，若是索引拆分之后业务验证允许可以这么使用。
  • alias 下面可以挂多个索引，但是需要注意的是每次请求很容易放大，比如说 alias 挂了 50 个索引，每个索引有 5 个分片，那么从集群的维度来看一共就是 50*5=250 次 query 和 fetch，很容易导致读放大的情况。

:::

【中级】ES JVM 设置需要注意什么？

:::details 要点

ES 实际上是一个 Java 进程，因此也需要考虑 JVM 设置。关于 ES JVM 的设置，有以下几点建议：

• 从 ES6 开始，支持 64 位的 JVM
• 将内存 Xms 和 Xmx 设置一样，需要注意过多的堆可能会使垃圾回收停顿时间过长
• 一般，将 50％ 的可用内存分配给 ES
• ES 内存不要超过 32 GB

扩展：https://www.elastic.co/blog/a-heap-of-trouble

:::

【高级】ES 内存为什么不要超过 32 GB？

:::details 要点

实际上，一般而言，绝大部分 JVM 内存最好都不要超过 32 GB，不仅仅是 ES 内存。

对于 32 位系统来说，JVM 的对象指针占用 32 位（4 byte），可以表示 2^32 哥内存地址。由于，CPU 寻址的最小单位是 byte，2^32 byte 即 4GB，也就是说 JVM 最大可以支持 4GB。

对于 64 位系统来说，如果直接引用，就需要使用 64 位的指针，相比 32 位 指针，多使用了一倍的内存。并且，指针在主内存和各级缓存间移动数据时，会占用更大的带宽。

Java 使用了一种叫做 Compressed oops 的技术来进行优化。该技术利用 Java 对象按照 8 字节对齐的机制，让 Java 对象指针指向一个映射地址偏移量（非真实 64 位 地址）。这种方式可以寻址最大位 32 GB 的内存空间。一旦超出 32 GB，就无法利用压缩指针技术，对象指针只能指向真实内存地址，这会造成空间的浪费。

扩展：

https://wiki.openjdk.org/display/HotSpot/CompressedOops

https://blog.csdn.net/liujianyangbj/article/details/108049482

:::

【中级】ES 主机有哪些优化点？

:::details 要点

• 关闭缓存 swap;
• 堆内存设置为：Min（节点内存/2, 32GB）;
• 设置最大文件句柄数；
• 线程池+队列大小根据业务需要做调整；
• 磁盘存储 raid 方式——存储有条件使用 RAID10，增加单节点性能以及避免单节点存储故障。

:::

【中级】ES 索引数据多，如何优化？

:::details 要点

• 动态索引 - 如果单索引数据量过大，可以创建索引模板，并周期性创建新索引（举例来说，索引名为 blog_yyyyMMdd），实现数据的分解。
• 冷热数据分离 - 将一定范围（如：一周、一月等）的数据作为热数据，其他数据作为冷数据。针对冷数据，可以考虑定期 force_merge + shrink 进行压缩，以节省存储空间和检索效率。
• 分区再均衡 - Elasticsearch 集群可以动态根据节点数的变化，调整索引分片在集群上的分布。但需要注意的是，要提前合理规划好索引的分片数：分片数过少，则增加节点也无法水平扩展；分片数过多，影响 Elasticsearch 读写效率。

:::

参考资料

• Elasticsearch 官方文档
• Elasticsearch 从入门到实践
• https://www.turing.com/interview-questions/elasticsearch
• https://github.com/rkm-ravi94/awesome-devops-interview/blob/main/elasticsearch.md

Java 虚拟机之垃圾收集

程序计数器、虚拟机栈和本地方法栈这三个区域属于线程私有的，只存在于线程的生命周期内，线程结束之后也会消失，因此不需要对这三个区域进行垃圾回收。垃圾回收主要是针对 Java 堆和方法区进行。

对象是否回收

引用计数算法

引用计数算法（Reference Counting）的原理是：在对象中添加一个引用计数器，每当有一个地方 引用它时，计数器值就加一；当引用失效时，计数器值就减一；任何时刻计数器为零的对象就是不可能再被使用的。

引用计数算法简单、高效，但是存在循环引用问题——两个对象出现循环引用的情况下，此时引用计数器永远不为 0，导致无法对它们进行回收。

1
2
3
4
5
6
7
8
9
10

public class ReferenceCountingGC {
    public Object instance = null;

    public static void main(String[] args) {
        ReferenceCountingGC objectA = new ReferenceCountingGC();
        ReferenceCountingGC objectB = new ReferenceCountingGC();
        objectA.instance = objectB;
        objectB.instance = objectA;
    }
}

因为循环引用的存在，所以 Java 虚拟机不适用引用计数算法。

可达性分析算法

通过 GC Roots 作为起始点进行搜索，JVM 将能够到达到的对象视为存活，不可达的对象视为死亡。

可达性分析算法

可作为 GC Roots 的对象包括下面几种：

• 虚拟机栈中引用的对象
• 本地方法栈中引用的对象（Native 方法）
• 方法区中，类静态属性引用的对象
• 方法区中，常量引用的对象

引用类型

无论是通过引用计算算法判断对象的引用数量，还是通过可达性分析算法判断对象的引用链是否可达，判定对象是否可被回收都与引用有关。

Java 具有四种强度不同的引用类型。

强引用

被强引用（Strong Reference）关联的对象不会被垃圾收集器回收。

强引用：使用 new 一个新对象的方式来创建强引用。

1

Object obj = new Object();

软引用

被软引用（Soft Reference）关联的对象，只有在内存不够的情况下才会被回收。

软引用：使用 SoftReference 类来创建软引用。

1
2
3

Object obj = new Object();
SoftReference<Object> sf = new SoftReference<Object>(obj);
obj = null; // 使对象只被软引用关联

弱引用

被弱引用（Weak Reference）关联的对象一定会被垃圾收集器回收，也就是说它只能存活到下一次垃圾收集发生之前。

使用 WeakReference 类来实现弱引用。

1
2
3

Object obj = new Object();
WeakReference<Object> wf = new WeakReference<Object>(obj);
obj = null;

WeakHashMap 的 Entry 继承自 WeakReference，主要用来实现缓存。

1

private static class Entry<K,V> extends WeakReference<Object> implements Map.Entry<K,V>

Tomcat 中的 ConcurrentCache 就使用了 WeakHashMap 来实现缓存功能。ConcurrentCache 采取的是分代缓存，经常使用的对象放入 eden 中，而不常用的对象放入 longterm。eden 使用 ConcurrentHashMap 实现，longterm 使用 WeakHashMap，保证了不常使用的对象容易被回收。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

public final class ConcurrentCache<K, V> {

    private final int size;

    private final Map<K, V> eden;

    private final Map<K, V> longterm;

    public ConcurrentCache(int size) {
        this.size = size;
        this.eden = new ConcurrentHashMap<>(size);
        this.longterm = new WeakHashMap<>(size);
    }

    public V get(K k) {
        V v = this.eden.get(k);
        if (v == null) {
            v = this.longterm.get(k);
            if (v != null)
                this.eden.put(k, v);
        }
        return v;
    }

    public void put(K k, V v) {
        if (this.eden.size() >= size) {
            this.longterm.putAll(this.eden);
            this.eden.clear();
        }
        this.eden.put(k, v);
    }
}

虚引用

又称为幽灵引用或者幻影引用。一个对象是否有虚引用的存在，完全不会对其生存时间构成影响，也无法通过虚引用取得一个对象实例。

为一个对象设置虚引用关联的唯一目的就是能在这个对象被收集器回收时收到一个系统通知。

使用 PhantomReference 来实现虚引用。

1
2
3

Object obj = new Object();
PhantomReference<Object> pf = new PhantomReference<Object>(obj);
obj = null;

方法区的回收

因为方法区主要存放永久代对象，而永久代对象的回收率比年轻代差很多，因此在方法区上进行回收性价比不高。

方法区的垃圾收集主要回收两部分：废弃的常量和不再使用的类型。

类的卸载条件很多，需要满足以下三个条件，并且满足了也不一定会被卸载：

• 该类所有的实例都已经被回收，也就是 Java 堆中不存在该类的任何实例。
• 加载该类的 ClassLoader 已经被回收。
• 该类对应的 java.lang.Class 对象没有在任何地方被引用，也就无法在任何地方通过反射访问该类方法。

可以通过 -Xnoclassgc 参数来控制是否对类进行卸载。

在大量使用反射、动态代理、CGLib 等字节码框架、动态生成 JSP 以及 OSGi 这类频繁自定义 ClassLoader 的场景都需要虚拟机具备类卸载功能，以保证不会出现内存溢出。

finalize()

当一个对象可被回收时，如果需要执行该对象的 finalize() 方法，那么就有可能通过在该方法中让对象重新被引用，从而实现自救。

finalize() 类似 C++ 的析构函数，用来做关闭外部资源等工作。但是 try-finally 等方式可以做的更好，并且该方法运行代价高昂，不确定性大，无法保证各个对象的调用顺序，因此**最好不要使用 finalize()**。

垃圾收集算法

垃圾收集性能

垃圾收集器的性能指标主要有两点：

• 停顿时间 - 停顿时间是因为 GC 而导致程序不能工作的时间长度。
• 吞吐量 - 吞吐量关注在特定的时间周期内一个应用的工作量的最大值。对关注吞吐量的应用来说长暂停时间是可以接受的。由于高吞吐量的应用关注的基准在更长周期时间上，所以快速响应时间不在考虑之内。

标记 - 清除（Mark-Sweep）

将需要回收的对象进行标记，然后清理掉被标记的对象。

不足：

• 标记和清除过程效率都不高；
• 会产生大量不连续的内存碎片，内存碎片过多可能导致无法给大对象分配内存。

标记 - 整理（Mark-Compact）

让所有存活的对象都向一端移动，然后直接清理掉端边界以外的内存。

这种做法能够解决内存碎片化的问题，但代价是压缩算法的性能开销。

标记 - 复制（Copying）

将内存划分为大小相等的两块，每次只使用其中一块，当这一块内存用完了就将还存活的对象复制到另一块上面，然后再把使用过的内存空间进行一次清理。

主要不足是只使用了内存的一半。

现在的商业虚拟机都采用这种收集算法来回收年轻代，但是并不是将内存划分为大小相等的两块，而是分为一块较大的 Eden 空间和两块较小的 Survior 空间，每次使用 Eden 空间和其中一块 Survivor。在回收时，将 Eden 和 Survivor 中还存活着的对象一次性复制到另一块 Survivor 空间上，最后清理 Eden 和使用过的那一块 Survivor。HotSpot 虚拟机的 Eden 和 Survivor 的大小比例默认为 8:1（可以通过参数 -XX:SurvivorRatio 来调整比例），保证了内存的利用率达到 90 %。如果每次回收有多于 10% 的对象存活，那么一块 Survivor 空间就不够用了，此时需要依赖于老年代进行分配担保，也就是借用老年代的空间存储放不下的对象。

分代收集

现在的商业虚拟机采用分代收集算法，它根据对象存活周期将内存划分为几块，不同块采用适当的收集算法。

一般将 Java 堆分为年轻代和老年代。

• 年轻代使用：复制 算法
• 老年代使用：标记 - 清理 或者 标记 - 整理 算法

新生代

新生代是大部分对象创建和销毁的区域，在通常的 Java 应用中，绝大部分对象生命周期都是很短暂的。其内部又分为 Eden 区域，作为对象初始分配的区域；两个 Survivor，有时候也叫 from、to 区域，被用来放置从 Minor GC 中保留下来的对象。

JVM 会随意选取一个 Survivor 区域作为 to，然后会在 GC 过程中进行区域间拷贝，也就是将 Eden 中存活下来的对象和 from 区域的对象，拷贝到这个to区域。这种设计主要是为了防止内存的碎片化，并进一步清理无用对象。

Java 虚拟机会记录 Survivor 区中的对象一共被来回复制了几次。如果一个对象被复制的次数为 15（对应虚拟机参数 -XX:+MaxTenuringThreshold），那么该对象将被晋升（promote）至老年代。另外，如果单个 Survivor 区已经被占用了 50%（对应虚拟机参数 -XX:TargetSurvivorRatio），那么较高复制次数的对象也会被晋升至老年代。

老年代

放置长生命周期的对象，通常都是从 Survivor 区域拷贝过来的对象。当然，也有特殊情况，如果对象较大，JVM 会试图直接分配在 Eden 其他位置上；如果对象太大，完全无法在新生代找到足够长的连续空闲空间，JVM 就会直接分配到老年代。

永久代

这部分就是早期 Hotspot JVM 的方法区实现方式了，储存 Java 类元数据、常量池、Intern 字符串缓存。在 JDK 8 之后就不存在永久代这块儿了。

JVM 参数

这里顺便提一下，JVM 允许对堆空间大小、各代空间大小进行设置，以调整 JVM GC。

垃圾收集器

以上是 HotSpot 虚拟机中的 7 个垃圾收集器，连线表示垃圾收集器可以配合使用。

注：G1 垃圾收集器既可以回收年轻代内存，也可以回收老年代内存。而其他垃圾收集器只能针对特定代的内存进行回收。

串行收集器

串行收集器（Serial）是最基本、发展历史最悠久的收集器。

串行收集器是 client 模式下的默认收集器配置。因为在客户端模式下，分配给虚拟机管理的内存一般来说不会很大。Serial 收集器收集几十兆甚至一两百兆的年轻代停顿时间可以控制在一百多毫秒以内，只要不是太频繁，这点停顿是可以接受的。

串行收集器采用单线程 stop-the-world 的方式进行收集。当内存不足时，串行 GC 设置停顿标识，待所有线程都进入安全点（Safepoint）时，应用线程暂停，串行 GC 开始工作，采用单线程方式回收空间并整理内存。

Serial / Serial Old 收集器运行示意图

单线程意味着复杂度更低、占用内存更少，垃圾回收效率高；但同时也意味着不能有效利用多核优势。事实上，串行收集器特别适合堆内存不高、单核甚至双核 CPU 的场合。

Serial 收集器

开启选项：-XX:+UseSerialGC

打开此开关后，使用 Serial + Serial Old 收集器组合来进行内存回收。

Serial Old 收集器

Serial Old 是 Serial 收集器的老年代版本，也是给 Client 模式下的虚拟机使用。如果用在 Server 模式下，它有两大用途：

• 在 JDK 1.5 以及之前版本（Parallel Old 诞生以前）中与 Parallel Scavenge 收集器搭配使用。
• 作为 CMS 收集器的后备预案，在并发收集发生 Concurrent Mode Failure 时使用。

并行收集器

开启选项：-XX:+UseParallelGC

打开此开关后，使用 Parallel Scavenge + Serial Old 收集器组合来进行内存回收。

开启选项：-XX:+UseParallelOldGC

打开此开关后，使用 Parallel Scavenge + Parallel Old 收集器组合来进行内存回收。

其他收集器都是以关注停顿时间为目标，而并行收集器是以关注吞吐量（Throughput）为目标的垃圾收集器。

• 停顿时间越短就越适合需要与用户交互的程序，良好的响应速度能提升用户体验；
• 而高吞吐量则可以高效率地利用 CPU 时间，尽快完成程序的运算任务，主要适合在后台运算而不需要太多交互的任务。

1

吞吐量 = 运行用户代码时间 / （运行用户代码时间 + 垃圾收集时间）

并行收集器是 server 模式下的默认收集器。

并行收集器与串行收集器工作模式相似，都是 stop-the-world 方式，只是暂停时并行地进行垃圾收集。并行收集器年轻代采用复制算法，老年代采用标记-整理，在回收的同时还会对内存进行压缩。并行收集器适合对吞吐量要求远远高于延迟要求的场景，并且在满足最差延时的情况下，并行收集器将提供最佳的吞吐量。

在注重吞吐量以及 CPU 资源敏感的场合，都可以优先考虑 Parallel Scavenge 收集器 + Parallel Old 收集器。

Parallel / Parallel Old 收集器运行示意图

Parallel Scavenge 收集器

Parallel Scavenge 收集器提供了两个参数用于精确控制吞吐量，分别是：

• -XX:MaxGCPauseMillis - 控制最大垃圾收集停顿时间，收集器将尽可能保证内存回收时间不超过设定值。
• -XX:GCTimeRatio - 直接设置吞吐量大小的（值为大于 0 且小于 100 的整数）。

缩短停顿时间是以牺牲吞吐量和年轻代空间来换取的：年轻代空间变小，垃圾回收变得频繁，导致吞吐量下降。

Parallel Scavenge 收集器还提供了一个参数 -XX:+UseAdaptiveSizePolicy，这是一个开关参数，打开参数后，就不需要手工指定年轻代的大小（-Xmn）、Eden 和 Survivor 区的比例（-XX:SurvivorRatio）、晋升老年代对象年龄（-XX:PretenureSizeThreshold）等细节参数了，虚拟机会根据当前系统的运行情况收集性能监控信息，动态调整这些参数以提供最合适的停顿时间或者最大的吞吐量，这种方式称为 GC 自适应的调节策略（GC Ergonomics）。

Parallel Old 收集器

是 Parallel Scavenge 收集器的老年代版本，使用多线程和 “标记-整理” 算法。

并发标记清除收集器

开启选项：-XX:+UseConcMarkSweepGC

打开此开关后，使用 CMS + ParNew + Serial Old 收集器组合来进行内存回收。

并发标记清除收集器是以获取最短停顿时间为目标。

开启后，年轻代使用 ParNew 收集器；老年代使用 CMS 收集器，如果 CMS 产生的碎片过多，导致无法存放浮动垃圾，JVM 会出现 Concurrent Mode Failure ，此时使用 Serial Old 收集器来替代 CMS 收集器清理碎片。

CMS 收集器

CMS 收集器是一种以获取最短停顿时间为目标的收集器。

CMS（Concurrent Mark Sweep），Mark Sweep 指的是标记 - 清除算法。

CMS 回收机制

CMS 收集器运行步骤如下：

1. 初始标记：仅仅只是标记一下 GC Roots 能直接关联到的对象，速度很快，需要停顿。
2. 并发标记：进行 GC Roots Tracing 的过程，它在整个回收过程中耗时最长，不需要停顿。
3. 重新标记：为了修正并发标记期间因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录，需要停顿。
4. 并发清除：回收在标记阶段被鉴定为不可达的对象。不需要停顿。

在整个过程中耗时最长的并发标记和并发清除过程中，收集器线程都可以与用户线程一起工作，不需要进行停顿。

CMS 收集器运行示意图

CMS 回收年轻代详细步骤

（1）堆空间被分割为三块空间

年轻代分割成一个 Eden 区和两个 Survivor 区。年老代一个连续的空间。就地完成对象收集。除非有 FullGC 否则不会压缩。

（2）CMS 年轻代垃圾收集如何工作

年轻代被标为浅绿色，年老代被标记为蓝色。如果你的应用已经运行了一段时间，CMS 的堆看起来应该是这个样子。对象分散在年老代区域里。

使用 CMS，年老代对象就地释放。它们不会被来回移动。这个空间不会被压缩除非发生 FullGC。

（3）年轻代收集

从 Eden 和 Survivor 区复制活跃对象到另一个 Survivor 区。所有达到他们的年龄阈值的对象会晋升到年老代。

（4）年轻代回收之后

一次年轻代垃圾收集之后，Eden 区和其中一个 Survivor 区被清空。

最近晋升的对象以深蓝色显示在上图中，绿色的对象是年轻代幸免的还没有晋升到老年代对象。

CMS 回收年老代详细步骤

（1）CMS 的年老代收集

发生两次 stop the world 事件：初始标记和重新标记。当年老代达到特定的占用比例时，CMS 开始执行。

• 初始标记是一个短暂暂停的、可达对象被标记的阶段。
• 并发标记寻找活跃对象在应用连续执行时。
• 最后，在重新标记阶段，寻找在之前并发标记阶段中丢失的对象。

（2）年老代收集-并发清除

在之前阶段没有被标记的对象会被就地释放。不进行压缩操作。

注意：未被标记的对象等于死亡对象

（3）年老代收集-清除之后

清除阶段之后，你可以看到大量内存被释放。你还可以注意到没有进行压缩操作。

最后，CMS 收集器会再次进入重新设置阶段，等待下一次垃圾收集时机的到来。

CMS 特点

CMS 收集器具有以下缺点：

• 并发收集 - 并发指的是用户线程和 GC 线程同时运行。
• 吞吐量低 - 低停顿时间是以牺牲吞吐量为代价的，导致 CPU 利用率不够高。
• 无法处理浮动垃圾 - 可能出现 Concurrent Mode Failure。浮动垃圾是指并发清除阶段由于用户线程继续运行而产生的垃圾，这部分垃圾只能到下一次 GC 时才能进行回收。由于浮动垃圾的存在，因此需要预留出一部分内存，意味着 CMS 收集不能像其它收集器那样等待老年代快满的时候再回收。
  • 可以使用 -XX:CMSInitiatingOccupancyFraction 来改变触发 CMS 收集器工作的内存占用百分，如果这个值设置的太大，导致预留的内存不够存放浮动垃圾，就会出现 Concurrent Mode Failure，这时虚拟机将临时启用 Serial Old 收集器来替代 CMS 收集器。
• 标记 - 清除算法导致的空间碎片，往往出现老年代空间剩余，但无法找到足够大连续空间来分配当前对象，不得不提前触发一次 Full GC。
  • 可以使用 -XX:+UseCMSCompactAtFullCollection ，用于在 CMS 收集器要进行 Full GC 时开启内存碎片的合并整理，内存整理的过程是无法并发的，空间碎片问题没有了，但是停顿时间不得不变长了。
  • 可以使用 -XX:CMSFullGCsBeforeCompaction ，用于设置执行多少次不压缩的 Full GC 后，来一次带压缩的（默认为 0，表示每次进入 Full GC 时都要进行碎片整理）。

ParNew 收集器

开启选项：-XX:+UseParNewGC

ParNew 收集器其实是 Serial 收集器的多线程版本。

ParNew 收集器运行示意图

是 Server 模式下的虚拟机首选年轻代收集器，除了性能原因外，主要是因为除了 Serial 收集器，只有它能与 CMS 收集器配合工作。

ParNew 收集器也是使用 -XX:+UseConcMarkSweepGC 后的默认年轻代收集器。

ParNew 收集器默认开启的线程数量与 CPU 数量相同，可以使用 -XX:ParallelGCThreads 参数来设置线程数。

G1 收集器

开启选项：-XX:+UseG1GC

前面提到的垃圾收集器一般策略是关注吞吐量或停顿时间。而 G1 是一种兼顾吞吐量和停顿时间的 GC 收集器。G1 是 Oracle JDK9 以后的默认 GC 收集器。G1 可以直观的设定停顿时间的目标，相比于 CMS GC，G1 未必能做到 CMS 在最好情况下的延时停顿，但是最差情况要好很多。

G1 最大的特点是引入分区的思路，弱化了分代的概念，合理利用垃圾收集各个周期的资源，解决了其他收集器甚至 CMS 的众多缺陷。

分代和分区

旧的垃圾收集器一般采取分代收集，Java 堆被分为年轻代、老年代和永久代。收集的范围都是整个年轻代或者整个老年代。

G1 取消了永久代，并把年轻代和老年代划分成多个大小相等的独立区域（Region），年轻代和老年代不再物理隔离。G1 可以直接对年轻代和老年代一起回收。

通过引入 Region 的概念，从而将原来的一整块内存空间划分成多个的小空间，使得每个小空间可以单独进行垃圾回收。这种划分方法带来了很大的灵活性，使得可预测的停顿时间模型成为可能。通过记录每个 Region 垃圾回收时间以及回收所获得的空间（这两个值是通过过去回收的经验获得），并维护一个优先列表，每次根据允许的收集时间，优先回收价值最大的 Region。

每个 Region 都有一个 Remembered Set，用来记录该 Region 对象的引用对象所在的 Region。通过使用 Remembered Set，在做可达性分析的时候就可以避免全堆扫描。

G1 回收机制

G1 收集器运行示意图

如果不计算维护 Remembered Set 的操作，G1 收集器的运作大致可划分为以下几个步骤：

1. 初始标记
2. 并发标记
3. 最终标记 - 为了修正在并发标记期间因用户程序继续运作而导致标记产生变动的那一部分标记记录，虚拟机将这段时间对象变化记录在线程的 Remembered Set Logs 里面，最终标记阶段需要把 Remembered Set Logs 的数据合并到 Remembered Set 中。这阶段需要停顿线程，但是可并行执行。
4. 筛选回收 - 首先对各个 Region 中的回收价值和成本进行排序，根据用户所期望的 GC 停顿是时间来制定回收计划。此阶段其实也可以做到与用户程序一起并发执行，但是因为只回收一部分 Region，时间是用户可控制的，而且停顿用户线程将大幅度提高收集效率。

具备如下特点：

• 空间整合：整体来看是基于“标记 - 整理”算法实现的收集器，从局部（两个 Region 之间）上来看是基于“复制”算法实现的，这意味着运行期间不会产生内存空间碎片。
• 可预测的停顿：能让使用者明确指定在一个长度为 M 毫秒的时间片段内，消耗在 GC 上的时间不得超过 N 毫秒。

G1 回收年轻代详细步骤

（1）G1 初始堆空间

堆空间是一个被分成许多固定大小区域的内存块。

Java 虚拟机启动时选定区域大小。Java 虚拟机通常会指定 2000 个左右的大小相等、每个大小范围在 1 到 32M 的区域。

（2）G1 堆空间分配

实际上，这些区域被映射成 Eden、Survivor、年老代空间的逻辑表述形式。

图片中的颜色表明了哪个区域被关联上什么角色。活跃对象从一个区域疏散（复制、移动）到另一个区域。区域被设计为并行的方式收集，可以暂停或者不暂停所有的其它用户线程。

明显的区域可以被分配成 Eden、Survivor、Old 区域。另外，有第四种类型的区域叫做*极大区域 (Humongous regions)*。这些区域被设计成保持标准区域大小的 50%或者更大的对象。它们被保存在一个连续的区域集合里。最后，最后一个类型的区域就是堆空间里没有使用的区域。

注意：写作此文章时，收集极大对象时还没有被优化。因此，你应该避免创建这个大小的对象。

（3）G1 的年轻代

堆空间被分割成大约 2000 个区域。最小 1M，最大 32M，蓝色区域保持年老代对象，绿色区域保持年轻代对象。

注意：区域没有必要像旧的收集器一样是保持连续的。

（4）G1 的年轻代收集

活跃对象会被疏散（复制、移动）到一个或多个 survivor 区域。如果达到晋升总阈值，对象会晋升到年老代区域。

这是一个 stop the world 暂停。为下一次年轻代垃圾回收计算 Eden 和 Survivor 的大小。保留审计信息有助于计算大小。类似目标暂停时间的事情会被考虑在内。

这个方法使重调区域大小变得很容易，按需把它们调大或调小。

（5）G1 年轻代回收的尾声

活跃对象被疏散到 Survivor 或者年老代区域。

最近晋升的对象显示为深蓝色。Survivor 区域显示为绿色。

关于 G1 的年轻代回收做以下总结：

• 堆空间是一块单独的内存空间被分割成多个区域。
• 年轻代内存是由一组非连续的区域组成。这使得需要重调大小变得容易。
• 年轻代垃圾回收是 stop the world 事件，所有应用线程都会因此操作暂停。
• 年轻代垃圾收集使用多线程并行回收。
• 活跃对象被复制到新的 Survivor 区或者年老代区域。

G1 回收年老代详细步骤

（1）初始标记阶段

年轻代垃圾收集肩负着活跃对象初始标记的任务。在日志文件中被标为* GC pause (young)(inital-mark)*

（2）并发标记阶段

如果发现空区域 (“X”标示的），在重新标记阶段它们会被马上清除掉。当然，决定活性的审计信息也在此时被计算。

（3）重新标记阶段

空的区域被清除和回收掉。所有区域的活性在此时计算。

（4）复制/清理阶段

G1 选择活性最低的区域，这些区域能够以最快的速度回收。然后这些区域会在年轻代垃圾回收过程中被回收。在日志中被指示为* [GC pause (mixed)]*。所以年轻代和年老代在同一时间被回收。

（5）复制/清理阶段之后

被选择的区域已经被回收和压缩到图中显示的深蓝色区和深绿色区中。

总结

内存分配与回收策略

对象的内存分配，也就是在堆上分配。主要分配在年轻代的 Eden 区上，少数情况下也可能直接分配在老年代中。

Minor GC

当 Eden 区空间不足时，触发 Minor GC。

Minor GC 发生在年轻代上，因为年轻代对象存活时间很短，因此 Minor GC 会频繁执行，执行的速度一般也会比较快。

Minor GC 工作流程：

1. Java 应用不断创建对象，通常都是分配在 Eden 区域，当其空间不足时（达到设定的阈值），触发 minor GC。仍然被引用的对象（绿色方块）存活下来，被复制到 JVM 选择的 Survivor 区域，而没有被引用的对象（黄色方块）则被回收。

2. 经过一次 Minor GC，Eden 就会空闲下来，直到再次达到 Minor GC 触发条件。这时候，另外一个 Survivor 区域则会成为 To 区域，Eden 区域的存活对象和 From 区域对象，都会被复制到 To 区域，并且存活的年龄计数会被加 1。

3. 类似第二步的过程会发生很多次，直到有对象年龄计数达到阈值，这时候就会发生所谓的晋升（Promotion）过程，如下图所示，超过阈值的对象会被晋升到老年代。这个阈值是可以通过 -XX:MaxTenuringThreshold 参数指定。

Full GC

Full GC 发生在老年代上，老年代对象和年轻代的相反，其存活时间长，因此 Full GC 很少执行，而且执行速度会比 Minor GC 慢很多。

内存分配策略

（一）对象优先在 Eden 分配

大多数情况下，对象在年轻代 Eden 区分配，当 Eden 区空间不够时，发起 Minor GC。

（二）大对象直接进入老年代

大对象是指需要连续内存空间的对象，最典型的大对象是那种很长的字符串以及数组。

经常出现大对象会提前触发垃圾收集以获取足够的连续空间分配给大对象。

-XX:PretenureSizeThreshold，大于此值的对象直接在老年代分配，避免在 Eden 区和 Survivor 区之间的大量内存复制。

（三）长期存活的对象进入老年代

为对象定义年龄计数器，对象在 Eden 出生并经过 Minor GC 依然存活，将移动到 Survivor 中，年龄就增加 1 岁，增加到一定年龄则移动到老年代中。

-XX:MaxTenuringThreshold 用来定义年龄的阈值。

（四）动态对象年龄判定

虚拟机并不是永远地要求对象的年龄必须达到 MaxTenuringThreshold 才能晋升老年代，如果在 Survivor 区中相同年龄所有对象大小的总和大于 Survivor 空间的一半，则年龄大于或等于该年龄的对象可以直接进入老年代，无需等到 MaxTenuringThreshold 中要求的年龄。

（五）空间分配担保

在发生 Minor GC 之前，虚拟机先检查老年代最大可用的连续空间是否大于年轻代所有对象总空间，如果条件成立的话，那么 Minor GC 可以确认是安全的；如果不成立的话虚拟机会查看 HandlePromotionFailure 设置值是否允许担保失败，如果允许那么就会继续检查老年代最大可用的连续空间是否大于历次晋升到老年代对象的平均大小，如果大于，将尝试着进行一次 Minor GC，尽管这次 Minor GC 是有风险的；如果小于，或者 HandlePromotionFailure 设置不允许冒险，那这时也要改为进行一次 Full GC。

Full GC 的触发条件

对于 Minor GC，其触发条件非常简单，当 Eden 区空间满时，就将触发一次 Minor GC。而 Full GC 则相对复杂，有以下条件：

（1）调用 System.gc()

此方法的调用是建议虚拟机进行 Full GC，虽然只是建议而非一定，但很多情况下它会触发 Full GC，从而增加 Full GC 的频率，也即增加了间歇性停顿的次数。因此强烈建议能不使用此方法就不要使用，让虚拟机自己去管理它的内存。可通过 -XX:DisableExplicitGC 来禁止 RMI 调用 System.gc()。

（2）老年代空间不足

老年代空间不足的常见场景为前文所讲的大对象直接进入老年代、长期存活的对象进入老年代等，当执行 Full GC 后空间仍然不足，则抛出 java.lang.OutOfMemoryError: Java heap space。为避免以上原因引起的 Full GC，调优时应尽量做到让对象在 Minor GC 阶段被回收、让对象在年轻代多存活一段时间以及不要创建过大的对象及数组。

（3）方法区空间不足

JVM 规范中运行时数据区域中的方法区，在 HotSpot 虚拟机中又被习惯称为永久代，永久代中存放的是类的描述信息、常量、静态变量等数据，当系统中要加载的类、反射的类和调用的方法较多时，永久代可能会被占满，在未配置为采用 CMS GC 的情况下也会执行 Full GC。如果经过 Full GC 仍然回收不了，那么 JVM 会抛出 java.lang.OutOfMemoryError: PermGen space 错误。为避免永久代占满造成 Full GC 现象，可采用的方法为增大 Perm Gen 空间或转为使用 CMS GC。

（4）Minor GC 的平均晋升空间大小大于老年代可用空间

如果发现统计数据说之前 Minor GC 的平均晋升大小比目前老年代剩余的空间大，则不会触发 Minor GC 而是转为触发 Full GC。

（5）对象大小大于 To 区和老年代的可用内存

由 Eden 区、From 区向 To 区复制时，对象大小大于 To 区可用内存，则把该对象转存到老年代，且老年代的可用内存小于该对象大小。

参考资料

• 《深入理解 Java 虚拟机》
• 从表到里学习 JVM 实现
• 详解 JVM Garbage First(G1) 垃圾收集器
• G1 垃圾收集器入门
• Getting Started with the G1 Garbage Collector

深入理解 Java 反射和动态代理

反射简介

什么是反射

反射(Reflection)是 Java 程序开发语言的特征之一，它允许运行中的 Java 程序获取自身的信息，并且可以操作类或对象的内部属性。

通过反射机制，可以在运行时访问 Java 对象的属性，方法，构造方法等。

反射的应用场景

反射的主要应用场景有：

• 开发通用框架 - 反射最重要的用途就是开发各种通用框架。很多框架（比如 Spring）都是配置化的（比如通过 XML 文件配置 JavaBean、Filter 等），为了保证框架的通用性，它们可能需要根据配置文件加载不同的对象或类，调用不同的方法，这个时候就必须用到反射——运行时动态加载需要加载的对象。
• 动态代理 - 在切面编程（AOP）中，需要拦截特定的方法，通常，会选择动态代理方式。这时，就需要反射技术来实现了。
• 注解 - 注解本身仅仅是起到标记作用，它需要利用反射机制，根据注解标记去调用注解解释器，执行行为。如果没有反射机制，注解并不比注释更有用。
• 可扩展性功能 - 应用程序可以通过使用完全限定名称创建可扩展性对象实例来使用外部的用户定义类。

反射的缺点

• 性能开销 - 由于反射涉及动态解析的类型，因此无法执行某些 Java 虚拟机优化。因此，反射操作的性能要比非反射操作的性能要差，应该在性能敏感的应用程序中频繁调用的代码段中避免。
• 破坏封装性 - 反射调用方法时可以忽略权限检查，因此可能会破坏封装性而导致安全问题。
• 内部曝光 - 由于反射允许代码执行在非反射代码中非法的操作，例如访问私有字段和方法，所以反射的使用可能会导致意想不到的副作用，这可能会导致代码功能失常并可能破坏可移植性。反射代码打破了抽象，因此可能会随着平台的升级而改变行为。

反射机制

类加载过程

类加载的完整过程如下：

1. 在编译时，Java 编译器编译好 .java 文件之后，在磁盘中产生 .class 文件。.class 文件是二进制文件，内容是只有 JVM 能够识别的机器码。
2. JVM 中的类加载器读取字节码文件，取出二进制数据，加载到内存中，解析.class 文件内的信息。类加载器会根据类的全限定名来获取此类的二进制字节流；然后，将字节流所代表的静态存储结构转化为方法区的运行时数据结构；接着，在内存中生成代表这个类的 java.lang.Class 对象。
3. 加载结束后，JVM 开始进行连接阶段（包含验证、准备、初始化）。经过这一系列操作，类的变量会被初始化。

Class 对象

要想使用反射，首先需要获得待操作的类所对应的 Class 对象。Java 中，无论生成某个类的多少个对象，这些对象都会对应于同一个 Class 对象。这个 Class 对象是由 JVM 生成的，通过它能够获悉整个类的结构。所以，java.lang.Class 可以视为所有反射 API 的入口点。

反射的本质就是：在运行时，把 Java 类中的各种成分映射成一个个的 Java 对象。

举例来说，假如定义了以下代码：

1

User user = new User();

步骤说明：

1. JVM 加载方法的时候，遇到 new User()，JVM 会根据 User 的全限定名去加载 User.class 。
2. JVM 会去本地磁盘查找 User.class 文件并加载 JVM 内存中。
3. JVM 通过调用类加载器自动创建这个类对应的 Class 对象，并且存储在 JVM 的方法区。注意：一个类有且只有一个 Class 对象。

方法的反射调用

方法的反射调用，也就是 Method.invoke 方法。

Method.invoke 方法源码：

1
2
3
4
5
6
7
8
9
10
11

public final class Method extends Executable {
  ...
  public Object invoke(Object obj, Object... args) throws ... {
    ... // 权限检查
    MethodAccessor ma = methodAccessor;
    if (ma == null) {
      ma = acquireMethodAccessor();
    }
    return ma.invoke(obj, args);
  }
}

Method.invoke 方法实际上委派给 MethodAccessor 接口来处理。它有两个已有的具体实现：

• NativeMethodAccessorImpl：本地方法来实现反射调用
• DelegatingMethodAccessorImpl：委派模式来实现反射调用

每个 Method 实例的第一次反射调用都会生成一个委派实现（DelegatingMethodAccessorImpl），它所委派的具体实现便是一个本地实现（NativeMethodAccessorImpl）。本地实现非常容易理解。当进入了 Java 虚拟机内部之后，我们便拥有了 Method 实例所指向方法的具体地址。这时候，反射调用无非就是将传入的参数准备好，然后调用进入目标方法。

【示例】通过抛出异常方式 打印 Method.invoke 调用轨迹

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

public class MethodDemo01 {

    public static void target(int i) {
        new Exception("#" + i).printStackTrace();
    }

    public static void main(String[] args) throws Exception {
        Class<?> clazz = Class.forName("io.github.dunwu.javacore.reflect.MethodDemo01");
        Method method = clazz.getMethod("target", int.class);
        method.invoke(null, 0);
    }

}
// Output:
// java.lang.Exception: #0
//     at io.github.dunwu.javacore.reflect.MethodDemo01.target(MethodDemo01.java:12)
//     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
//     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)

先调用 DelegatingMethodAccessorImpl；然后调用 NativeMethodAccessorImpl，最后调用实际方法。

为什么反射调用DelegatingMethodAccessorImpl 作为中间层，而不是直接交给本地实现？

其实，Java 的反射调用机制还设立了另一种动态生成字节码的实现（下称动态实现），直接使用 invoke 指令来调用目标方法。之所以采用委派实现，便是为了能够在本地实现以及动态实现中切换。动态实现和本地实现相比，其运行效率要快上 20 倍。这是因为动态实现无需经过 Java 到 C++ 再到 Java 的切换，但由于生成字节码十分耗时，仅调用一次的话，反而是本地实现要快上 3 到 4 倍。

考虑到许多反射调用仅会执行一次，Java 虚拟机设置了一个阈值 15（可以通过 -Dsun.reflect.inflationThreshold 来调整），当某个反射调用的调用次数在 15 之下时，采用本地实现；当达到 15 时，便开始动态生成字节码，并将委派实现的委派对象切换至动态实现，这个过程我们称之为 Inflation。

【示例】执行 java -verbose:class MethodDemo02 启动

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

public class MethodDemo02 {

    public static void target(int i) {
        new Exception("#" + i).printStackTrace();
    }

    public static void main(String[] args) throws Exception {
        Class<?> klass = Class.forName("io.github.dunwu.javacore.reflect.MethodDemo02");
        Method method = klass.getMethod("target", int.class);
        for (int i = 0; i < 20; i++) {
            method.invoke(null, i);
        }
    }

}

输出内容：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38

// ...省略
java.lang.Exception: #14
        at io.github.dunwu.javacore.reflect.MethodDemo02.target(MethodDemo02.java:13)
        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 io.github.dunwu.javacore.reflect.MethodDemo02.main(MethodDemo02.java:20)
[Loaded sun.reflect.ClassFileConstants from D:\Tools\Java\jdk1.8.0_192\jre\lib\rt.jar]
[Loaded sun.reflect.AccessorGenerator from D:\Tools\Java\jdk1.8.0_192\jre\lib\rt.jar]
[Loaded sun.reflect.MethodAccessorGenerator from D:\Tools\Java\jdk1.8.0_192\jre\lib\rt.jar]
[Loaded sun.reflect.ByteVectorFactory from D:\Tools\Java\jdk1.8.0_192\jre\lib\rt.jar]
[Loaded sun.reflect.ByteVector from D:\Tools\Java\jdk1.8.0_192\jre\lib\rt.jar]
[Loaded sun.reflect.ByteVectorImpl from D:\Tools\Java\jdk1.8.0_192\jre\lib\rt.jar]
[Loaded sun.reflect.ClassFileAssembler from D:\Tools\Java\jdk1.8.0_192\jre\lib\rt.jar]
[Loaded sun.reflect.UTF8 from D:\Tools\Java\jdk1.8.0_192\jre\lib\rt.jar]
[Loaded sun.reflect.Label from D:\Tools\Java\jdk1.8.0_192\jre\lib\rt.jar]
[Loaded sun.reflect.Label$PatchInfo from D:\Tools\Java\jdk1.8.0_192\jre\lib\rt.jar]
[Loaded java.util.ArrayList$Itr from D:\Tools\Java\jdk1.8.0_192\jre\lib\rt.jar]
[Loaded sun.reflect.MethodAccessorGenerator$1 from D:\Tools\Java\jdk1.8.0_192\jre\lib\rt.jar]
[Loaded sun.reflect.ClassDefiner from D:\Tools\Java\jdk1.8.0_192\jre\lib\rt.jar]
[Loaded sun.reflect.ClassDefiner$1 from D:\Tools\Java\jdk1.8.0_192\jre\lib\rt.jar]
[Loaded sun.reflect.GeneratedMethodAccessor1 from __JVM_DefineClass__]
java.lang.Exception: #15
        at io.github.dunwu.javacore.reflect.MethodDemo02.target(MethodDemo02.java:13)
        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 io.github.dunwu.javacore.reflect.MethodDemo02.main(MethodDemo02.java:20)
[Loaded java.util.concurrent.ConcurrentHashMap$ForwardingNode from D:\Tools\Java\jdk1.8.0_192\jre\lib\rt.jar]
java.lang.Exception: #16
        at io.github.dunwu.javacore.reflect.MethodDemo02.target(MethodDemo02.java:13)
        at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:498)
        at io.github.dunwu.javacore.reflect.MethodDemo02.main(MethodDemo02.java:20)
// ...省略

可以看到，从第 16 次开始后，都是使用 DelegatingMethodAccessorImpl ，不再使用本地实现 NativeMethodAccessorImpl。

反射调用的开销

方法的反射调用会带来不少性能开销，原因主要有三个：

• 变长参数方法导致的 Object 数组
• 基本类型的自动装箱、拆箱
• 还有最重要的方法内联

Class.forName 会调用本地方法，Class.getMethod 则会遍历该类的公有方法。如果没有匹配到，它还将遍历父类的公有方法。可想而知，这两个操作都非常费时。

注意，以 getMethod 为代表的查找方法操作，会返回查找得到结果的一份拷贝。因此，我们应当避免在热点代码中使用返回 Method 数组的 getMethods 或者 getDeclaredMethods 方法，以减少不必要的堆空间消耗。在实践中，我们往往会在应用程序中缓存 Class.forName 和 Class.getMethod 的结果。

下面只关注反射调用本身的性能开销。

第一，由于 Method.invoke 是一个变长参数方法，在字节码层面它的最后一个参数会是 Object 数组（感兴趣的同学私下可以用 javap 查看）。Java 编译器会在方法调用处生成一个长度为传入参数数量的 Object 数组，并将传入参数一一存储进该数组中。

第二，由于 Object 数组不能存储基本类型，Java 编译器会对传入的基本类型参数进行自动装箱。

这两个操作除了带来性能开销外，还可能占用堆内存，使得 GC 更加频繁。（如果你感兴趣的话，可以用虚拟机参数 -XX:+PrintGC 试试。）那么，如何消除这部分开销呢？

使用反射

java.lang.reflect 包

Java 中的 java.lang.reflect 包提供了反射功能。java.lang.reflect 包中的类都没有 public 构造方法。

java.lang.reflect 包的核心接口和类如下：

• Member 接口：反映关于单个成员(字段或方法)或构造函数的标识信息。
• Field 类：提供一个类的域的信息以及访问类的域的接口。
• Method 类：提供一个类的方法的信息以及访问类的方法的接口。
• Constructor 类：提供一个类的构造函数的信息以及访问类的构造函数的接口。
• Array 类：该类提供动态地生成和访问 JAVA 数组的方法。
• Modifier 类：提供了 static 方法和常量，对类和成员访问修饰符进行解码。
• Proxy 类：提供动态地生成代理类和类实例的静态方法。

获取 Class 对象

获取 Class 对象的三种方法：

（1）**Class.forName 静态方法**

【示例】使用 Class.forName 静态方法获取 Class 对象

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

package io.github.dunwu.javacore.reflect;

public class ReflectClassDemo01 {
    public static void main(String[] args) throws ClassNotFoundException {
        Class c1 = Class.forName("io.github.dunwu.javacore.reflect.ReflectClassDemo01");
        System.out.println(c1.getCanonicalName());

        Class c2 = Class.forName("[D");
        System.out.println(c2.getCanonicalName());

        Class c3 = Class.forName("[[Ljava.lang.String;");
        System.out.println(c3.getCanonicalName());
    }
}
//Output:
//io.github.dunwu.javacore.reflect.ReflectClassDemo01
//double[]
//java.lang.String[][]

使用类的完全限定名来反射对象的类。常见的应用场景为：在 JDBC 开发中常用此方法加载数据库驱动。

（2）类名 + .class

【示例】直接用类名 + .class 获取 Class 对象

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

public class ReflectClassDemo02 {
    public static void main(String[] args) {
        boolean b;
        // Class c = b.getClass(); // 编译错误
        Class c1 = boolean.class;
        System.out.println(c1.getCanonicalName());

        Class c2 = java.io.PrintStream.class;
        System.out.println(c2.getCanonicalName());

        Class c3 = int[][][].class;
        System.out.println(c3.getCanonicalName());
    }
}
//Output:
//boolean
//java.io.PrintStream
//int[][][]

（3）**Object 的 getClass 方法**

Object 类中有 getClass 方法，因为所有类都继承 Object 类。从而调用 Object 类来获取 Class 对象。

【示例】Object 的 getClass 方法获取 Class 对象

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

package io.github.dunwu.javacore.reflect;

import java.util.HashSet;
import java.util.Set;

public class ReflectClassDemo03 {
    enum E {A, B}

    public static void main(String[] args) {
        Class c = "foo".getClass();
        System.out.println(c.getCanonicalName());

        Class c2 = ReflectClassDemo03.E.A.getClass();
        System.out.println(c2.getCanonicalName());

        byte[] bytes = new byte[1024];
        Class c3 = bytes.getClass();
        System.out.println(c3.getCanonicalName());

        Set<String> set = new HashSet<>();
        Class c4 = set.getClass();
        System.out.println(c4.getCanonicalName());
    }
}
//Output:
//java.lang.String
//io.github.dunwu.javacore.reflect.ReflectClassDemo.E
//byte[]
//java.util.HashSet

判断是否为某个类的实例

判断是否为某个类的实例有两种方式：

1. 用 instanceof 关键字
2. 用 Class 对象的 isInstance 方法（它是一个 Native 方法）

【示例】

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

public class InstanceofDemo {
    public static void main(String[] args) {
        ArrayList arrayList = new ArrayList();
        if (arrayList instanceof List) {
            System.out.println("ArrayList is List");
        }
        if (List.class.isInstance(arrayList)) {
            System.out.println("ArrayList is List");
        }
    }
}
//Output:
//ArrayList is List
//ArrayList is List

创建实例

通过反射来创建实例对象主要有两种方式：

• 用 Class 对象的 newInstance 方法。
• 用 Constructor 对象的 newInstance 方法。

【示例】

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

public class NewInstanceDemo {
    public static void main(String[] args)
        throws IllegalAccessException, InstantiationException, NoSuchMethodException, InvocationTargetException {
        Class<?> c1 = StringBuilder.class;
        StringBuilder sb = (StringBuilder) c1.newInstance();
        sb.append("aaa");
        System.out.println(sb.toString());

        //获取String所对应的Class对象
        Class<?> c2 = String.class;
        //获取String类带一个String参数的构造器
        Constructor constructor = c2.getConstructor(String.class);
        //根据构造器创建实例
        String str2 = (String) constructor.newInstance("bbb");
        System.out.println(str2);
    }
}
//Output:
//aaa
//bbb

创建数组实例

数组在 Java 里是比较特殊的一种类型，它可以赋值给一个对象引用。Java 中，通过 Array.newInstance 创建数组的实例。

【示例】利用反射创建数组

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

public class ReflectArrayDemo {
    public static void main(String[] args) throws ClassNotFoundException {
        Class<?> cls = Class.forName("java.lang.String");
        Object array = Array.newInstance(cls, 25);
        //往数组里添加内容
        Array.set(array, 0, "Scala");
        Array.set(array, 1, "Java");
        Array.set(array, 2, "Groovy");
        Array.set(array, 3, "Scala");
        Array.set(array, 4, "Clojure");
        //获取某一项的内容
        System.out.println(Array.get(array, 3));
    }
}
//Output:
//Scala

其中的 Array 类为 java.lang.reflect.Array 类。我们Array.newInstance 的原型是：

1
2
3
4

public static Object newInstance(Class<?> componentType, int length)
    throws NegativeArraySizeException {
    return newArray(componentType, length);
}

Field

Class 对象提供以下方法获取对象的成员（Field）：

• getFiled - 根据名称获取公有的（public）类成员。
• getDeclaredField - 根据名称获取已声明的类成员。但不能得到其父类的类成员。
• getFields - 获取所有公有的（public）类成员。
• getDeclaredFields - 获取所有已声明的类成员。

示例如下：

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

public class ReflectFieldDemo {
    class FieldSpy<T> {
        public boolean[][] b = { {false, false}, {true, true} };
        public String name = "Alice";
        public List<Integer> list;
        public T val;
    }

    public static void main(String[] args) throws NoSuchFieldException {
        Field f1 = FieldSpy.class.getField("b");
        System.out.format("Type: %s%n", f1.getType());

        Field f2 = FieldSpy.class.getField("name");
        System.out.format("Type: %s%n", f2.getType());

        Field f3 = FieldSpy.class.getField("list");
        System.out.format("Type: %s%n", f3.getType());

        Field f4 = FieldSpy.class.getField("val");
        System.out.format("Type: %s%n", f4.getType());
    }
}
//Output:
//Type: class [[Z
//Type: class java.lang.String
//Type: interface java.util.List
//Type: class java.lang.Object

Method

Class 对象提供以下方法获取对象的方法（Method）：

• getMethod - 返回类或接口的特定方法。其中第一个参数为方法名称，后面的参数为方法参数对应 Class 的对象。
• getDeclaredMethod - 返回类或接口的特定声明方法。其中第一个参数为方法名称，后面的参数为方法参数对应 Class 的对象。
• getMethods - 返回类或接口的所有 public 方法，包括其父类的 public 方法。
• getDeclaredMethods - 返回类或接口声明的所有方法，包括 public、protected、默认（包）访问和 private 方法，但不包括继承的方法。

获取一个 Method 对象后，可以用 invoke 方法来调用这个方法。

invoke 方法的原型为:

1
2
3

public Object invoke(Object obj, Object... args)
        throws IllegalAccessException, IllegalArgumentException,
           InvocationTargetException

【示例】

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

public class ReflectMethodDemo {
    public static void main(String[] args)
        throws NoSuchMethodException, InvocationTargetException, IllegalAccessException {

        // 返回所有方法
        Method[] methods1 = System.class.getDeclaredMethods();
        System.out.println("System getDeclaredMethods 清单（数量 = " + methods1.length + "）：");
        for (Method m : methods1) {
            System.out.println(m);
        }

        // 返回所有 public 方法
        Method[] methods2 = System.class.getMethods();
        System.out.println("System getMethods 清单（数量 = " + methods2.length + "）：");
        for (Method m : methods2) {
            System.out.println(m);
        }

        // 利用 Method 的 invoke 方法调用 System.currentTimeMillis()
        Method method = System.class.getMethod("currentTimeMillis");
        System.out.println(method);
        System.out.println(method.invoke(null));
    }
}

Constructor

Class 对象提供以下方法获取对象的构造方法（Constructor）：

• getConstructor - 返回类的特定 public 构造方法。参数为方法参数对应 Class 的对象。
• getDeclaredConstructor - 返回类的特定构造方法。参数为方法参数对应 Class 的对象。
• getConstructors - 返回类的所有 public 构造方法。
• getDeclaredConstructors - 返回类的所有构造方法。

获取一个 Constructor 对象后，可以用 newInstance 方法来创建类实例。

【示例】

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

public class ReflectMethodConstructorDemo {
    public static void main(String[] args)
        throws NoSuchMethodException, IllegalAccessException, InvocationTargetException, InstantiationException {
        Constructor<?>[] constructors1 = String.class.getDeclaredConstructors();
        System.out.println("String getDeclaredConstructors 清单（数量 = " + constructors1.length + "）：");
        for (Constructor c : constructors1) {
            System.out.println(c);
        }

        Constructor<?>[] constructors2 = String.class.getConstructors();
        System.out.println("String getConstructors 清单（数量 = " + constructors2.length + "）：");
        for (Constructor c : constructors2) {
            System.out.println(c);
        }

        System.out.println("====================");
        Constructor constructor = String.class.getConstructor(String.class);
        System.out.println(constructor);
        String str = (String) constructor.newInstance("bbb");
        System.out.println(str);
    }
}

绕开访问限制

有时候，我们需要通过反射访问私有成员、方法。可以使用 Constructor/Field/Method.setAccessible(true) 来绕开 Java 语言的访问限制。

动态代理

动态代理是一种方便运行时动态构建代理、动态处理代理方法调用的机制，很多场景都是利用类似机制做到的，比如用来包装 RPC 调用、面向切面的编程（AOP）。

实现动态代理的方式很多，比如 JDK 自身提供的动态代理，就是主要利用了上面提到的反射机制。还有其他的实现方式，比如利用传说中更高性能的字节码操作机制，类似 ASM、cglib（基于 ASM）、Javassist 等。

静态代理

静态代理其实就是指设计模式中的代理模式。

代理模式为其他对象提供一种代理以控制对这个对象的访问。

Subject 定义了 RealSubject 和 Proxy 的公共接口，这样就在任何使用 RealSubject 的地方都可以使用 Proxy 。

1
2
3

abstract class Subject {
    public abstract void Request();
}

RealSubject 定义 Proxy 所代表的真实实体。

1
2
3
4
5
6

class RealSubject extends Subject {
    @Override
    public void Request() {
        System.out.println("真实的请求");
    }
}

Proxy 保存一个引用使得代理可以访问实体，并提供一个与 Subject 的接口相同的接口，这样代理就可以用来替代实体。

1
2
3
4
5
6
7
8
9
10
11

class Proxy extends Subject {
    private RealSubject real;

    @Override
    public void Request() {
        if (null == real) {
            real = new RealSubject();
        }
        real.Request();
    }
}

说明：

静态代理模式固然在访问无法访问的资源，增强现有的接口业务功能方面有很大的优点，但是大量使用这种静态代理，会使我们系统内的类的规模增大，并且不易维护；并且由于 Proxy 和 RealSubject 的功能本质上是相同的，Proxy 只是起到了中介的作用，这种代理在系统中的存在，导致系统结构比较臃肿和松散。

JDK 动态代理

为了解决静态代理的问题，就有了创建动态代理的想法：

在运行状态中，需要代理的地方，根据 Subject 和 RealSubject，动态地创建一个 Proxy，用完之后，就会销毁，这样就可以避免了 Proxy 角色的 class 在系统中冗杂的问题了。

Java 动态代理基于经典代理模式，引入了一个 InvocationHandler，InvocationHandler 负责统一管理所有的方法调用。

动态代理步骤：

1. 获取 RealSubject 上的所有接口列表；
2. 确定要生成的代理类的类名，默认为：com.sun.proxy.$ProxyXXXX；
3. 根据需要实现的接口信息，在代码中动态创建 该 Proxy 类的字节码；
4. 将对应的字节码转换为对应的 class 对象；
5. 创建 InvocationHandler 实例 handler，用来处理 Proxy 所有方法调用；
6. Proxy 的 class 对象 以创建的 handler 对象为参数，实例化一个 proxy 对象。

从上面可以看出，JDK 动态代理的实现是基于实现接口的方式，使得 Proxy 和 RealSubject 具有相同的功能。

但其实还有一种思路：通过继承。即：让 Proxy 继承 RealSubject，这样二者同样具有相同的功能，Proxy 还可以通过重写 RealSubject 中的方法，来实现多态。CGLIB 就是基于这种思路设计的。

在 Java 的动态代理机制中，有两个重要的类（接口），一个是 InvocationHandler 接口、另一个则是 Proxy 类，这一个类和一个接口是实现我们动态代理所必须用到的。

InvocationHandler 接口

InvocationHandler 接口定义：

1
2
3
4

public interface InvocationHandler {
    public Object invoke(Object proxy, Method method, Object[] args)
        throws Throwable;
}

每一个动态代理类都必须要实现 InvocationHandler 这个接口，并且每个代理类的实例都关联到了一个 Handler，当我们通过代理对象调用一个方法的时候，这个方法的调用就会被转发为由 InvocationHandler 这个接口的 invoke 方法来进行调用。

我们来看看 InvocationHandler 这个接口的唯一一个方法 invoke 方法：

1

Object invoke(Object proxy, Method method, Object[] args) throws Throwable

参数说明：

• proxy - 代理的真实对象。
• method - 所要调用真实对象的某个方法的 Method 对象
• args - 所要调用真实对象某个方法时接受的参数

如果不是很明白，等下通过一个实例会对这几个参数进行更深的讲解。

Proxy 类

Proxy 这个类的作用就是用来动态创建一个代理对象的类，它提供了许多的方法，但是我们用的最多的就是 newProxyInstance 这个方法：

1

public static Object newProxyInstance(ClassLoader loader, Class<?>[] interfaces,  InvocationHandler h)  throws IllegalArgumentException

这个方法的作用就是得到一个动态的代理对象。

参数说明：

• loader - 一个 ClassLoader 对象，定义了由哪个 ClassLoader 对象来对生成的代理对象进行加载。
• interfaces - 一个 Class<?> 对象的数组，表示的是我将要给我需要代理的对象提供一组什么接口，如果我提供了一组接口给它，那么这个代理对象就宣称实现了该接口(多态)，这样我就能调用这组接口中的方法了
• h - 一个 InvocationHandler 对象，表示的是当我这个动态代理对象在调用方法的时候，会关联到哪一个 InvocationHandler 对象上

JDK 动态代理实例

上面的内容介绍完这两个接口(类)以后，我们来通过一个实例来看看我们的动态代理模式是什么样的：

首先我们定义了一个 Subject 类型的接口，为其声明了两个方法：

1
2
3
4
5
6

public interface Subject {

    void hello(String str);

    String bye();
}

接着，定义了一个类来实现这个接口，这个类就是我们的真实对象，RealSubject 类：

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

public class RealSubject implements Subject {

    @Override
    public void hello(String str) {
        System.out.println("Hello  " + str);
    }

    @Override
    public String bye() {
        System.out.println("Goodbye");
        return "Over";
    }
}

下一步，我们就要定义一个动态代理类了，前面说个，每一个动态代理类都必须要实现 InvocationHandler 这个接口，因此我们这个动态代理类也不例外：

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

public class InvocationHandlerDemo implements InvocationHandler {
    // 这个就是我们要代理的真实对象
    private Object subject;

    // 构造方法，给我们要代理的真实对象赋初值
    public InvocationHandlerDemo(Object subject) {
        this.subject = subject;
    }

    @Override
    public Object invoke(Object object, Method method, Object[] args)
        throws Throwable {
        // 在代理真实对象前我们可以添加一些自己的操作
        System.out.println("Before method");

        System.out.println("Call Method: " + method);

        // 当代理对象调用真实对象的方法时，其会自动的跳转到代理对象关联的handler对象的invoke方法来进行调用
        Object obj = method.invoke(subject, args);

        // 在代理真实对象后我们也可以添加一些自己的操作
        System.out.println("After method");
        System.out.println();

        return obj;
    }
}

最后，来看看我们的 Client 类：

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

public class Client {
    public static void main(String[] args) {
        // 我们要代理的真实对象
        Subject realSubject = new RealSubject();

        // 我们要代理哪个真实对象，就将该对象传进去，最后是通过该真实对象来调用其方法的
        InvocationHandler handler = new InvocationHandlerDemo(realSubject);

        /*
         * 通过Proxy的newProxyInstance方法来创建我们的代理对象，我们来看看其三个参数
         * 第一个参数 handler.getClass().getClassLoader() ，我们这里使用handler这个类的ClassLoader对象来加载我们的代理对象
         * 第二个参数realSubject.getClass().getInterfaces()，我们这里为代理对象提供的接口是真实对象所实行的接口，表示我要代理的是该真实对象，这样我就能调用这组接口中的方法了
         * 第三个参数handler， 我们这里将这个代理对象关联到了上方的 InvocationHandler 这个对象上
         */
        Subject subject = (Subject)Proxy.newProxyInstance(handler.getClass().getClassLoader(), realSubject
                .getClass().getInterfaces(), handler);

        System.out.println(subject.getClass().getName());
        subject.hello("World");
        String result = subject.bye();
        System.out.println("Result is: " + result);
    }
}

我们先来看看控制台的输出：

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

com.sun.proxy.$Proxy0
Before method
Call Method: public abstract void io.github.dunwu.javacore.reflect.InvocationHandlerDemo$Subject.hello(java.lang.String)
Hello  World
After method

Before method
Call Method: public abstract java.lang.String io.github.dunwu.javacore.reflect.InvocationHandlerDemo$Subject.bye()
Goodbye
After method

Result is: Over

我们首先来看看 com.sun.proxy.$Proxy0 这东西，我们看到，这个东西是由 System.out.println(subject.getClass().getName()); 这条语句打印出来的，那么为什么我们返回的这个代理对象的类名是这样的呢？

1
2

Subject subject = (Subject)Proxy.newProxyInstance(handler.getClass().getClassLoader(), realSubject
                .getClass().getInterfaces(), handler);

可能我以为返回的这个代理对象会是 Subject 类型的对象，或者是 InvocationHandler 的对象，结果却不是，首先我们解释一下为什么我们这里可以将其转化为 Subject 类型的对象？

原因就是：在 newProxyInstance 这个方法的第二个参数上，我们给这个代理对象提供了一组什么接口，那么我这个代理对象就会实现了这组接口，这个时候我们当然可以将这个代理对象强制类型转化为这组接口中的任意一个，因为这里的接口是 Subject 类型，所以就可以将其转化为 Subject 类型了。

同时我们一定要记住，通过 Proxy.newProxyInstance 创建的代理对象是在 jvm 运行时动态生成的一个对象，它并不是我们的 InvocationHandler 类型，也不是我们定义的那组接口的类型，而是在运行是动态生成的一个对象，并且命名方式都是这样的形式，以$开头，proxy 为中，最后一个数字表示对象的标号。

接着我们来看看这两句

1
2

subject.hello("World");
String result = subject.bye();

这里是通过代理对象来调用实现的那种接口中的方法，这个时候程序就会跳转到由这个代理对象关联到的 handler 中的 invoke 方法去执行，而我们的这个 handler 对象又接受了一个 RealSubject 类型的参数，表示我要代理的就是这个真实对象，所以此时就会调用 handler 中的 invoke 方法去执行。

我们看到，在真正通过代理对象来调用真实对象的方法的时候，我们可以在该方法前后添加自己的一些操作，同时我们看到我们的这个 method 对象是这样的：

1
2

public abstract void io.github.dunwu.javacore.reflect.InvocationHandlerDemo$Subject.hello(java.lang.String)
public abstract java.lang.String io.github.dunwu.javacore.reflect.InvocationHandlerDemo$Subject.bye()

正好就是我们的 Subject 接口中的两个方法，这也就证明了当我通过代理对象来调用方法的时候，起实际就是委托由其关联到的 handler 对象的 invoke 方法中来调用，并不是自己来真实调用，而是通过代理的方式来调用的。

JDK 动态代理小结

代理类与委托类实现同一接口，主要是通过代理类实现 InvocationHandler 并重写 invoke 方法来进行动态代理的，在 invoke 方法中将对方法进行处理。

JDK 动态代理特点：

• 优点：相对于静态代理模式，不需要硬编码接口，代码复用率高。

• 缺点：强制要求代理类实现 InvocationHandler 接口。

CGLIB 动态代理

CGLIB 提供了与 JDK 动态代理不同的方案。很多框架，例如 Spring AOP 中，就使用了 CGLIB 动态代理。

CGLIB 底层，其实是借助了 ASM 这个强大的 Java 字节码框架去进行字节码增强操作。

CGLIB 动态代理的工作步骤：

• 生成代理类的二进制字节码文件；
• 加载二进制字节码，生成 Class 对象( 例如使用 Class.forName() 方法 )；
• 通过反射机制获得实例构造，并创建代理类对象。

CGLIB 动态代理特点：

优点：使用字节码增强，比 JDK 动态代理方式性能高。可以在运行时对类或者是接口进行增强操作，且委托类无需实现接口。

缺点：不能对 final 类以及 final 方法进行代理。

参考：深入理解 CGLIB 动态代理机制

参考资料

• Java 编程思想
• Java 核心技术（卷 1）
• 极客时间教程 - 深入拆解 Java 虚拟机
• 深入解析 Java 反射（1） - 基础
• Java 基础之—反射（非常重要）
• 官方 Reflection API 文档
• Java 的动态代理机制详解
• Java 动态代理机制详解（JDK 和 CGLIB，Javassist，ASM）
• 深入理解 JDK 动态代理机制
• 深入理解 CGLIB 动态代理机制

Java 并发面试一

并发术语

并发和并行

典型问题

• 什么是并发？
• 什么是并行？
• 并发和并行有什么区别？

知识点

并发和并行是最容易让新手费解的概念，那么如何理解二者呢？其最关键的差异在于：是否是同时发生：

• 并发：是指具备处理多个任务的能力，但不一定要同时。
• 并行：是指具备同时处理多个任务的能力。

下面是我见过最生动的说明，摘自 并发与并行的区别是什么？——知乎的高票答案

• 你吃饭吃到一半，电话来了，你一直到吃完了以后才去接，这就说明你不支持并发也不支持并行。
• 你吃饭吃到一半，电话来了，你停了下来接了电话，接完后继续吃饭，这说明你支持并发。
• 你吃饭吃到一半，电话来了，你一边打电话一边吃饭，这说明你支持并行。

同步和异步

典型问题

• 什么是同步？
• 什么是异步？
• 同步和异步有什么区别？

知识点

• 同步：是指在发出一个调用时，在没有得到结果之前，该调用就不返回。但是一旦调用返回，就得到返回值了。
• 异步：则是相反，调用在发出之后，这个调用就直接返回了，所以没有返回结果。换句话说，当一个异步过程调用发出后，调用者不会立刻得到结果。而是在调用发出后，被调用者通过状态、通知来通知调用者，或通过回调函数处理这个调用。

举例来说明：

• 同步就像是打电话：不挂电话，通话不会结束。
• 异步就像是发短信：发完短信后，就可以做其他事；当收到回复短信时，手机会通过铃声或振动来提醒。

阻塞和非阻塞

典型问题

• 什么是阻塞？
• 阻塞和非阻塞有什么区别？

知识点

阻塞和非阻塞关注的是程序在等待调用结果（消息，返回值）时的状态：

• 阻塞：是指调用结果返回之前，当前线程会被挂起。调用线程只有在得到结果之后才会返回。
• 非阻塞：是指在不能立刻得到结果之前，该调用不会阻塞当前线程。

举例来说明：

• 阻塞调用就像是打电话，通话不结束，不能放下。
• 非阻塞调用就像是发短信，发完短信后，就可以做其他事，短信来了，手机会提醒。

进程、线程、协程、管程

典型问题

• 什么是进程？
• 什么是线程？
• 什么是协程？
• 什么是管程？
• 进程和线程有什么区别？

知识点

• 进程（Process） - 进程是具有一定独立功能的程序关于某个数据集合上的一次运行活动。进程是操作系统进行资源分配的基本单位。进程可视为一个正在运行的程序。
• 线程（Thread） - 线程是操作系统进行调度的基本单位。
• 管程（Monitor） - 管程是指管理共享变量以及对共享变量的操作过程，让他们支持并发。
  • Java 通过 synchronized 关键字及 wait()、notify()、notifyAll() 这三个方法来实现管程技术。
  • 管程和信号量是等价的，所谓等价指的是用管程能够实现信号量，也能用信号量实现管程。
• 协程（Coroutine） - 协程可以理解为一种轻量级的线程。
  • 从操作系统的角度来看，线程是在内核态中调度的，而协程是在用户态调度的，所以相对于线程来说，协程切换的成本更低。
  • 协程虽然也有自己的栈，但是相比线程栈要小得多，典型的线程栈大小差不多有 1M，而协程栈的大小往往只有几 K 或者几十 K。所以，无论是从时间维度还是空间维度来看，协程都比线程轻量得多。
  • Go、Python、Lua、Kotlin 等语言都支持协程；Java OpenSDK 中的 Loom 项目目标就是支持协程。

进程和线程的差异：

• 一个程序至少有一个进程，一个进程至少有一个线程。
• 线程比进程划分更细，所以执行开销更小，并发性更高
• 进程是一个实体，拥有独立的资源；而同一个进程中的多个线程共享进程的资源。

JVM 在单个进程中运行，JVM 中的线程共享属于该进程的堆。这就是为什么几个线程可以访问同一个对象。线程共享堆并拥有自己的堆栈空间。这是一个线程如何调用一个方法以及它的局部变量是如何保持线程安全的。但是堆不是线程安全的并且为了线程安全必须进行同步。

程序计数器为什么是私有的？

程序计数器主要有下面两个作用：

1. 字节码解释器通过改变程序计数器来依次读取指令，从而实现代码的流程控制，如：顺序执行、选择、循环、异常处理。
2. 在多线程的情况下，程序计数器用于记录当前线程执行的位置，从而当线程被切换回来的时候能够知道该线程上次运行到哪儿了。

需要注意的是，如果执行的是 native 方法，那么程序计数器记录的是 undefined 地址，只有执行的是 Java 代码时程序计数器记录的才是下一条指令的地址。

所以，程序计数器私有主要是为了线程切换后能恢复到正确的执行位置。

虚拟机栈和本地方法栈为什么是私有的？

• 虚拟机栈： 每个 Java 方法在执行之前会创建一个栈帧用于存储局部变量表、操作数栈、常量池引用等信息。从方法调用直至执行完成的过程，就对应着一个栈帧在 Java 虚拟机栈中入栈和出栈的过程。
• 本地方法栈： 和虚拟机栈所发挥的作用非常相似，区别是：虚拟机栈为虚拟机执行 Java 方法 （也就是字节码）服务，而本地方法栈则为虚拟机使用到的 Native 方法服务。 在 HotSpot 虚拟机中和 Java 虚拟机栈合二为一。

所以，为了保证线程中的局部变量不被别的线程访问到，虚拟机栈和本地方法栈是线程私有的。

一句话简单了解堆和方法区

堆和方法区是所有线程共享的资源，其中堆是进程中最大的一块内存，主要用于存放新创建的对象 （几乎所有对象都在这里分配内存），方法区主要用于存放已被加载的类信息、常量、静态变量、即时编译器编译后的代码等数据。

并发概念

Java 线程和操作系统的线程有啥区别？

JDK 1.2 之前，Java 线程是基于绿色线程（Green Threads）实现的，这是一种用户级线程（用户线程），也就是说 JVM 自己模拟了多线程的运行，而不依赖于操作系统。由于绿色线程和原生线程比起来在使用时有一些限制（比如绿色线程不能直接使用操作系统提供的功能如异步 I/O、只能在一个内核线程上运行无法利用多核），在 JDK 1.2 及以后，Java 线程改为基于原生线程（Native Threads）实现，也就是说 JVM 直接使用操作系统原生的内核级线程（内核线程）来实现 Java 线程，由操作系统内核进行线程的调度和管理。

我们上面提到了用户线程和内核线程，考虑到很多读者不太了解二者的区别，这里简单介绍一下：

• 用户线程：由用户空间程序管理和调度的线程，运行在用户空间（专门给应用程序使用）。
• 内核线程：由操作系统内核管理和调度的线程，运行在内核空间（只有内核程序可以访问）。

顺便简单总结一下用户线程和内核线程的区别和特点：用户线程创建和切换成本低，但不可以利用多核。内核态线程，创建和切换成本高，可以利用多核。

一句话概括 Java 线程和操作系统线程的关系：现在的 Java 线程的本质其实就是操作系统的线程。

线程模型是用户线程和内核线程之间的关联方式，常见的线程模型有这三种：

1. 一对一（一个用户线程对应一个内核线程）
2. 多对一（多个用户线程映射到一个内核线程）
3. 多对多（多个用户线程映射到多个内核线程）

在 Windows 和 Linux 等主流操作系统中，Java 线程采用的是一对一的线程模型，也就是一个 Java 线程对应一个系统内核线程。Solaris 系统是一个特例（Solaris 系统本身就支持多对多的线程模型），HotSpot VM 在 Solaris 上支持多对多和一对一。具体可以参考 R 大的回答：JVM 中的线程模型是用户级的么？。

虚拟线程在 JDK 21 顺利转正，关于虚拟线程、平台线程（也就是我们上面提到的 Java 线程）和内核线程三者的关系可以阅读我写的这篇文章：Java 20 新特性概览。

并发（多线程）编程的好处是什么？

• 更有效率的利用多处理器核心
• 更快的响应时间
• 更好的编程模型

单核 CPU 支持 Java 多线程吗？

单核 CPU 是支持 Java 多线程的。操作系统通过时间片轮转的方式，将 CPU 的时间分配给不同的线程。尽管单核 CPU 一次只能执行一个任务，但通过快速在多个线程之间切换，可以让用户感觉多个任务是同时进行的。

这里顺带提一下 Java 使用的线程调度方式。

操作系统主要通过两种线程调度方式来管理多线程的执行：

• 抢占式调度（Preemptive Scheduling）：操作系统决定何时暂停当前正在运行的线程，并切换到另一个线程执行。这种切换通常是由系统时钟中断（时间片轮转）或其他高优先级事件（如 I/O 操作完成）触发的。这种方式存在上下文切换开销，但公平性和 CPU 资源利用率较好，不易阻塞。
• 协同式调度（Cooperative Scheduling）：线程执行完毕后，主动通知系统切换到另一个线程。这种方式可以减少上下文切换带来的性能开销，但公平性较差，容易阻塞。

Java 使用的线程调度是抢占式的。也就是说，JVM 本身不负责线程的调度，而是将线程的调度委托给操作系统。操作系统通常会基于线程优先级和时间片来调度线程的执行，高优先级的线程通常获得 CPU 时间片的机会更多。

并发和性能

典型问题

并发一定比串行更快吗？

知识点

并发不一定比串行更快！

对于多线程而言，它不仅可能会带来线程安全问题，还有可能会带来性能问题。

多线程会产生部分额外的开销：

• 线程调度
  • 上下文切换 - 在实际开发中，线程数往往是大于 CPU 核心数的，比如 CPU 核心数可能是 8 核、16 核，等等，但线程数可能达到成百上千个。这种情况下，操作系统就会按照一定的调度算法，给每个线程分配时间片，让每个线程都有机会得到运行。而在进行调度时就会引起上下文切换，上下文切换会挂起当前正在执行的线程并保存当前的状态，然后寻找下一处即将恢复执行的代码，唤醒下一个线程，以此类推，反复执行。但上下文切换带来的开销是比较大的，假设我们的任务内容非常短，比如只进行简单的计算，那么就有可能发生我们上下文切换带来的性能开销比执行线程本身内容带来的开销还要大的情况。
  • 缓存失效 - 由于程序有很大概率会再次访问刚才访问过的数据，所以为了加速整个程序的运行，会使用缓存，这样我们在使用相同数据时就可以很快地获取数据。可一旦进行了线程调度，切换到其他线程，CPU就会去执行不同的代码，原有的缓存就很可能失效了，需要重新缓存新的数据，这也会造成一定的开销，所以线程调度器为了避免频繁地发生上下文切换，通常会给被调度到的线程设置最小的执行时间，也就是只有执行完这段时间之后，才可能进行下一次的调度，由此减少上下文切换的次数。
• 线程协作 - 因为线程之间如果有共享数据，为了避免数据错乱，为了保证线程安全，就有可能禁止编译器和 CPU 对其进行重排序等优化，也可能出于同步的目的，反复把线程工作内存的数据 flush 到主存中，然后再从主内存 refresh 到其他线程的工作内存中，等等。这些问题在单线程中并不存在，但在多线程中为了确保数据的正确性，就不得不采取上述方法，因为线程安全的优先级要比性能优先级更高，这也间接降低了我们的性能。

并发安全

经典问题

（1）有哪些线程不安全的情况

（2）哪些场景需要额外注意线程安全问题？

知识点

（1）有哪些线程不安全的情况

1. 运行结果错误；
2. 发布和初始化导致线程安全问题；
3. 活跃性问题。典型的有：死锁、活锁和饥饿
   1. 死锁是指两个以上的线程永远相互阻塞的情况。
   2. 活锁 - 活锁是指两个或多个线程在执行各自的逻辑时，相互之间不断地做出反应和改变状态，从而陷入无限循环，而这种循环不会导致任何线程向前推进。
   3. 饥饿 - 饥饿是指线程需要某些资源时始终得不到，尤其是 CPU 资源，就会导致线程一直不能运行而产生的问题。

【示例】运行结果错误

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39

public class WrongResult {

   volatile static int i;

   public static void main(String[] args) throws InterruptedException {

       Runnable r = new Runnable() {

           @Override

           public void run() {

               for (int j = 0; j < 10000; j++) {

                   i++;

               }

           }

       };

       Thread thread1 = new Thread(r);

       thread1.start();

       Thread thread2 = new Thread(r);

       thread2.start();

       thread1.join();

       thread2.join();

       System.out.println(i);

    }

}

启动两个线程，分别对变量 i 进行 10000 次 i++ 操作。理论上得到的结果应该是 20000，但实际结果却远小于理论结果。这是因为 i 变量虽然被修饰为 volatile，但由于 i++ 不是原子操作，而 volatile 无法保证原子性，这就导致两个线程在循环 ++ 操作时，无法及时感知 i 的数值变化，最终导致累加数值远小于预期值。

【示例】发布和初始化导致线程安全问题

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

public class WrongInit {

    private Map<Integer, String> students;

    public WrongInit() {
        new Thread(() -> {
            students = new HashMap<>();
            students.put(1, "王小美");
            students.put(2, "钱二宝");
            students.put(3, "周三");
            students.put(4, "赵四");
        }).start();
    }

    public Map<Integer, String> getStudents() {
        return students;
    }

    public static void main(String[] args) throws InterruptedException {
        WrongInit demo = new WrongInit();
        System.out.println(demo.getStudents().get(1));
    }

}

（2）哪些场景需要额外注意线程安全问题？

• 访问共享变量或资源 - 典型的场景有访问共享对象的属性，访问 static 静态变量，访问共享的缓存，等等。因为这些信息不仅会被一个线程访问到，还有可能被多个线程同时访问，那么就有可能在并发读写的情况下发生线程安全问题。
• 依赖时序的操作 - 如果我们操作的正确性是依赖时序的，而在多线程的情况下又不能保障执行的顺序和我们预想的一致，这个时候就会发生线程安全问题。
• 不同数据之间存在绑定关系 - 有时候，不同数据之间是成组出现的，存在着相互对应或绑定的关系，最典型的就是 IP 和端口号。有时候我们更换了 IP，往往需要同时更换端口号，如果没有把这两个操作绑定在一起，就有可能出现单独更换了 IP 或端口号的情况，而此时信息如果已经对外发布，信息获取方就有可能获取一个错误的 IP 与端口绑定情况，这时就发生了线程安全问题。
• 对方没有声明自己是线程安全的 - 在我们使用其他类时，如果对方没有声明自己是线程安全的，那么这种情况下对其他类进行多线程的并发操作，就有可能会发生线程安全问题。举个例子，比如说我们定义了 ArrayList，它本身并不是线程安全的，如果此时多个线程同时对 ArrayList 进行并发读/写，那么就有可能会产生线程安全问题，造成数据出错，而这个责任并不在 ArrayList，因为它本身并不是并发安全的。

死锁

典型问题

（1）什么是死锁？

（2）如何预防和避免线程死锁？

知识点

（1）什么是死锁？

死锁是指两个以上的线程永远相互阻塞的情况。产生死锁的四个必要条件：

1. 互斥条件：该资源任意一个时刻只由一个线程占用。
2. 请求与保持条件：一个线程因请求资源而阻塞时，对已获得的资源保持不放。
3. 不剥夺条件：线程已获得的资源在未使用完之前不能被其他线程强行剥夺，只有自己使用完毕后才释放资源。
4. 循环等待条件：若干线程之间形成一种头尾相接的循环等待资源关系。

（2）如何预防和避免线程死锁？

如何预防死锁？ 破坏死锁的产生的必要条件即可：

1. 破坏请求与保持条件：一次性申请所有的资源。
2. 破坏不剥夺条件：占用部分资源的线程进一步申请其他资源时，如果申请不到，可以主动释放它占有的资源。
3. 破坏循环等待条件：靠按序申请资源来预防。按某一顺序申请资源，释放资源则反序释放。破坏循环等待条件。

如何避免死锁？

避免死锁就是在资源分配时，借助于算法（比如银行家算法）对资源分配进行计算评估，使其进入安全状态。

安全状态 指的是系统能够按照某种线程推进顺序（P1、P2、P3……Pn）来为每个线程分配所需资源，直到满足每个线程对资源的最大需求，使每个线程都可顺利完成。称 <P1、P2、P3.....Pn> 序列为安全序列。

线程基础

线程生命周期

典型问题

Java 线程生命周期中有哪些状态？各状态之间如何切换？

知识点

java.lang.Thread.State 中定义了 6 种不同的线程状态，在给定的一个时刻，线程只能处于其中的一个状态。

以下是各状态的说明，以及状态间的联系：

• 开始（NEW） - 尚未调用 start 方法的线程处于此状态。此状态意味着：创建的线程尚未启动。
• 可运行（RUNNABLE） - 已经调用了 start 方法的线程处于此状态。此状态意味着，线程已经准备好了，一旦被线程调度器分配了 CPU 时间片，就可以运行线程。
  • 在操作系统层面，线程有 READY 和 RUNNING 状态；而在 JVM 层面，只能看到 RUNNABLE 状态，所以 Java 系统一般将这两个状态统称为 RUNNABLE（运行中） 状态 。
• 阻塞（BLOCKED） - 此状态意味着：线程处于被阻塞状态。表示线程在等待 synchronized 的隐式锁（Monitor lock）。synchronized 修饰的方法、代码块同一时刻只允许一个线程执行，其他线程只能等待，即处于阻塞状态。当占用 synchronized 隐式锁的线程释放锁，并且等待的线程获得 synchronized 隐式锁时，就又会从 BLOCKED 转换到 RUNNABLE 状态。
• 等待（WAITING） - 此状态意味着：线程无限期等待，直到被其他线程显式地唤醒。 阻塞和等待的区别在于，阻塞是被动的，它是在等待获取 synchronized 的隐式锁。而等待是主动的，通过调用 Object.wait 等方法进入。
  • 进入：Object.wait()；退出：Object.notify / Object.notifyAll
  • 进入：Thread.join()；退出：被调用的线程执行完毕
  • 进入：LockSupport.park()；退出：LockSupport.unpark
• 定时等待（TIMED_WAITING） - 等待指定时间的状态。一个线程处于定时等待状态，是由于执行了以下方法中的任意方法：
  • 进入：Thread.sleep(long)；退出：时间结束
  • 进入：Object.wait(long)；退出：时间结束 / Object.notify / Object.notifyAll
  • 进入：Thread.join(long)；退出：时间结束 / 被调用的线程执行完毕
  • 进入：LockSupport.parkNanos(long)；退出：LockSupport.unpark
  • 进入：LockSupport.parkUntil(long)；退出：LockSupport.unpark
• 终止 (TERMINATED) - 线程 run() 方法执行结束，或者因异常退出了 run() 方法，则该线程结束生命周期。死亡的线程不可再次复生。

👉 扩展阅读：

• Java Thread Methods and Thread States
• Java 线程的 5 种状态及切换（透彻讲解）
• Java 线程运行怎么有第六种状态？ - Dawell 的回答

线程创建

典型问题

• Java 中，如何创建线程？
• Java 中，创建线程有几种方式？

知识点

一般来说，创建线程有很多种方式，例如：

• 实现 Runnable 接口
• 实现 Callable 接口
• 继承 Thread 类
• 通过线程池创建线程
• 使用 CompletableFuture 创建线程
• …

虽然，看似有多种多样的创建线程方式。但是，从本质上来说，Java 就只有一种方式可以创建线程，那就是通过 new Thread().start() 创建。不管是哪种方式，最终还是依赖于 new Thread().start()。

👉 扩展阅读：大家都说 Java 有三种创建线程的方式！并发编程中的惊天骗局！。

线程启动

典型问题

（1）Thread.start() 和 Thread.run() 有什么区别？

（2）可以直接调用 Thread.run() 方法么？

（3）一个线程两次调用 Thread.start() 方法会怎样

知识点

（1）Thread.start() 和 Thread.run() 的区别：

• run() 方法是线程的执行体。
• start() 方法负责启动线程，然后 JVM 会让这个线程去执行 run() 方法。

（2）可以直接调用 Thread.run() 方法，但是它的行为和普通方法一样，不会启动新线程去执行。调用 start() 方法方可启动线程并使线程进入就绪状态，直接执行 run() 方法的话不会以多线程的方式执行。

（3）Java 的线程是不允许启动两次的，第二次调用必然会抛出 IllegalThreadStateException。

线程等待

典型问题

（1）Thread.sleep()、Thread.yield()、Thread.join()、Object.wait() 方法有什么区别？

（2）为什么 Thread.sleep()、Thread.yield() 设计为静态方法？

知识点

（1）Thread.sleep()、Thread.yield()、Thread.join() 方法的区别：

• Thread.sleep()
  • Thread.sleep() 方法需要指定等待的时间，它可以让当前正在执行的线程在指定的时间内暂停执行，进入 Blocked 状态。
  • 该方法既可以让其他同优先级或者高优先级的线程得到执行的机会，也可以让低优先级的线程得到执行机会。
  • 但是，Thread.sleep() 方法不会释放“锁标志”，也就是说如果有 synchronized 同步块，其他线程仍然不能访问共享数据。
• Thread.yield()
  • Thread.yield() 方法可以让当前正在执行的线程暂停，但它不会阻塞该线程，它只是将该线程从 Running 状态转入 Runnable 状态。
  • 当某个线程调用了 Thread.yield() 方法暂停之后，只有优先级大于等于当前线程的处于就绪状态的线程才会获得执行的机会。
• Thread.join()
  • Thread.join() 方法会使当前线程转入 Blocked 状态，等待调用 Thread.join() 方法的线程结束后才能继续执行。
• Object.wait()
  • Object.wait() 用于使当前线程等待，直到其他线程调用相同对象的 Object.notify() 或 Object.notifyAll() 方法唤醒它。
  • 调用 Object.wait() 时，线程会释放对象锁，并进入等待状态。

（2）为什么 Thread.sleep()、Thread.yield() 设计为静态方法？

Thread.sleep()、Thread.yield() 针对的是 Running 状态的线程，也就是说在非 Running 状态的线程上执行这两个方法没有意义。这就是为什么这两个方法被设计为静态的。它们只针对正在 Running 状态的线程工作，避免程序员错误的认为可以在其他非 Running 状态线程上调用。

👉 扩展阅读：Java 线程中 yield 与 join 方法的区别
👉 扩展阅读：sleep()，wait()，yield() 和 join() 方法的区别

线程通信

线程间通信是线程间共享资源的一种方式。Object.wait(), Object.notify() 和 Object.notifyAll() 是用于线程之间协作和通信的方法，它们通常与synchronized 关键字一起使用来实现线程的同步。

典型问题

（1）为什么线程通信的方法 Object.wait()、Object.notify() 和 Object.notifyAll() 被定义在 Object 类里？

（2）为什么 Object.wait()、Object.notify() 和 Object.notifyAll() 必须在 synchronized 方法/块中被调用？

（3） Object.wait() 和 Thread.sleep 有什么区别？

知识点

（1）为什么线程通信的方法 Object.wait()、Object.notify() 和 Object.notifyAll() 被定义在 Object 类里？

Java 的每个对象中都有一个称之为 monitor 监视器的锁，由于每个对象都可以上锁，这就要求在对象头中有一个用来保存锁信息的位置。这个锁是对象级别的，而非线程级别的，wait/notify/notifyAll 也都是锁级别的操作，它们的锁属于对象，所以把它们定义在 Object 类中是最合适，因为 Object 类是所有对象的父类。

如果把 wait/notify/notifyAll 方法定义在 Thread 类中，会带来很大的局限性，比如一个线程可能持有多把锁，以便实现相互配合的复杂逻辑，假设此时 wait 方法定义在 Thread 类中，如何实现让一个线程持有多把锁呢？又如何明确线程等待的是哪把锁呢？既然我们是让当前线程去等待某个对象的锁，自然应该通过操作对象来实现，而不是操作线程。

• Object.wait()
  • Object.wait() 方法用于使当前线程进入等待状态，直到其他线程调用相同对象的 notify() 或 notifyAll() 方法唤醒它。
  • 在调用 wait() 方法时，线程会释放对象的锁，并进入等待状态。通常在使用 wait() 方法时需要放在一个循环中，以避免虚假唤醒（spurious wakeups）。
• Object.notify()
  • Object.notify() 方法用于唤醒正在等待该对象的锁的一个线程。
  • 被唤醒的线程将会尝试重新获取对象的锁，一旦获取到锁，它将继续执行。
• Object.notifyAll()
  • Object.notifyAll() 方法用于唤醒正在等待该对象的锁的所有线程。
  • 所有被唤醒的线程将会竞争对象的锁，一旦获取到锁，它们将继续执行。

（2）为什么 Object.wait()、Object.notify() 和 Object.notifyAll() 必须在 synchronized 方法/块中被调用？

当一个线程需要调用对象的 wait() 方法的时候，这个线程必须拥有该对象的锁，接着它就会释放这个对象锁并进入等待状态直到其他线程调用这个对象上的 notify() 方法。同样的，当一个线程需要调用对象的 notify() 方法时，它会释放这个对象的锁，以便其他在等待的线程就可以得到这个对象锁。

由于所有的这些方法都需要线程持有对象的锁，这样就只能通过 synchronized 来实现，所以他们只能在 synchronized 方法/块中被调用。

（3） Object.wait() 和 Thread.sleep 有什么区别？

相同点：

1. 它们都可以让线程阻塞。
2. 它们都可以响应 interrupt 中断：在等待的过程中如果收到中断信号，都可以进行响应，并抛出 InterruptedException 异常。

不同点：

1. wait 方法必须在 synchronized 保护的代码中使用，而 sleep 方法并没有这个要求。
2. 在同步代码中执行 sleep 方法时，并不会释放 monitor 锁，但执行 wait 方法时会主动释放 monitor 锁。
3. sleep 方法中会要求必须定义一个时间，时间到期后会主动恢复，而对于没有参数的 wait 方法而言，意味着永久等待，直到被中断或被唤醒才能恢复，它并不会主动恢复。
4. wait/notify 是 Object 类的方法，而 sleep 是 Thread 类的方法。

👉 扩展阅读：Java 并发编程：线程间协作的两种方式：wait、notify、notifyAll 和 Condition

线程终止

经典问题

（1）如何正确停止线程？

（2）可以使用 Thread.stop，Thread.suspend 和 Thread.resume 停止线程吗？为什么？

（3）使用 volatile 标记方式停止线程正确吗？

知识点

（1）如何正确停止线程？

通常情况下，我们不会手动停止一个线程，而是允许线程运行到结束，然后让它自然停止。但是依然会有许多特殊的情况需要我们提前停止线程，比如：用户突然关闭程序，或程序运行出错重启等。

对于 Java 而言，最正确的停止线程的方式是：通过 Thread.interrupt 和 Thread.isInterrupted 配合来控制线程终止。但 Thread.interrupt 仅仅起到通知被停止线程的作用。而对于被停止的线程而言，它拥有完全的自主权，它既可以选择立即停止，也可以选择一段时间后停止，也可以选择压根不停止。

事实上，Java 希望程序间能够相互通知、相互协作地管理线程，因为如果不了解对方正在做的工作，贸然强制停止线程就可能会造成一些安全的问题，为了避免造成问题就需要给对方一定的时间来整理收尾工作。比如：线程正在写入一个文件，这时收到终止信号，它就需要根据自身业务判断，是选择立即停止，还是将整个文件写入成功后停止，而如果选择立即停止就可能造成数据不完整，不管是中断命令发起者，还是接收者都不希望数据出现问题。

一旦调用某个线程的 Thread.interrupt 之后，这个线程的中断标记位就会被设置成 true。每个线程都有这样的标记位，当线程执行时，应该定期检查这个标记位，如果标记位被设置成 true，就说明有程序想终止该线程。回到源码，可以看到在 while 循环体判断语句中，首先通过 Thread.currentThread().isInterrupt() 判断线程是否被中断，随后检查是否还有工作要做。&& 逻辑表示只有当两个判断条件同时满足的情况下，才会去执行下面的工作。

需要留意一个特殊场景：**Thread.sleep 后，线程依然可以感知 Thread.interrupt**。

【示例】正确停止线程的方式——Thread.interrupt

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

public class ThreadStopDemo {

    public static void main(String[] args) throws Exception {
        Thread thread = new Thread(new MyTask(), "MyTask");
        thread.start();
        TimeUnit.MILLISECONDS.sleep(10);
        thread.interrupt();
    }

    private static class MyTask implements Runnable {

        private long count = 0L;

        @Override
        public void run() {
            System.out.println(Thread.currentThread().getName() + " 线程启动");
            // 通过 Thread.interrupted 和 interrupt 配合来控制线程终止
            while (!Thread.currentThread().isInterrupted() && count < 10000) {
                System.out.println("count = " + count++);
            }
            System.out.println(Thread.currentThread().getName() + " 线程终止");
        }

    }

}
// 输出（count 未到 10000，线程就主动结束）：
// MyTask 线程启动
// count = 0
// count = 1
// ...
// count = 840
// count = 841
// count = 842
// MyTask 线程终止

（2）可以使用 Thread.stop，Thread.suspend 和 Thread.resume 停止线程吗？为什么？

Thread.stop，Thread.suspend 和 Thread.resume 方法已经被 Java 标记为 @Deprecated。为什么废弃呢？

• Thread.stop 会直接把线程停止，这样就没有给线程足够的时间来处理想要在停止前保存数据的逻辑，任务戛然而止，会导致出现数据完整性等问题。
• 而对于Thread.suspend 和 Thread.resume 而言，它们的问题在于：如果线程调用 Thread.suspend，它并不会释放锁，就开始进入休眠，但此时有可能仍持有锁，这样就容易导致死锁问题。因为这把锁在线程被 Thread.resume 之前，是不会被释放的。假设线程 A 调用了 Thread.suspend 方法让线程 B 挂起，线程 B 进入休眠，而线程 B 又刚好持有一把锁，此时假设线程 A 想访问线程 B 持有的锁，但由于线程 B 并没有释放锁就进入休眠了，所以对于线程 A 而言，此时拿不到锁，也会陷入阻塞，那么线程 A 和线程 B 就都无法继续向下执行。

【示例】Thread.stop 终止线程，导致线程任务戛然而止

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48

public class ThreadStopErrorDemo {

    public static void main(String[] args) {
        MyTask thread = new MyTask();
        thread.start();
        try {
            Thread.sleep(1000);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        // 终止线程
        thread.stop();
        // 确保线程终止后，才执行下面的代码
        while (thread.isAlive()) { }
        // 输出两个计数器的最终状态
        thread.print();
    }

    /**
     * 持有两个计数器，run 方法中每次执行都会使计数器自增
     */
    private static class MyTask extends Thread {

        private int i = 0;

        private int j = 0;

        @Override
        public void run() {
            synchronized (this) {
                ++i;
                try {
                    // 模拟耗时操作
                    TimeUnit.SECONDS.sleep(5);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
                ++j;
            }
        }

        public void print() {
            System.out.println("i=" + i + " j=" + j);
        }

    }

}

（3）使用 volatile 标记方式停止线程正确吗？

使用 volatile 标记方式停止线程并不总是正确的。虽然 volatile 变量可以确保可见性，即当一个线程修改了 volatile 变量的值，其他线程能够立即看到最新的值，但它并不能保证原子性，也就是说并不能保证多个线程对 volatile 变量的操作是互斥的。

当我们使用 volatile 变量来控制线程的停止，通常是通过设置一个 volatile 标志位来告诉线程停止执行。例如：

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