技术 on 边个濑椰的博客

从零开始配置VPS

Tue, 30 Jun 2026 15:17:20 +0800

近日，出于笔者对高质量LLM的需求，引发了对高峰期仍能保持稳定的代理、纯净度较高的IP地址的需要。所以笔者决定不再用机场服务作主力，转向租用海外VPS做个人自用代理。

折腾的两个月以来，笔者遇到了VPS被恶意攻击、IP地址被封禁等问题。与此同时，网络上，比如YouTube的视频教程大多都极简，只能保证用户成功搭建起入站、客户端，但是既缺少对VPS本身安全性的保护教程，也容易使用户“知其然而不知其所以然”。但也不乏新协议、技术相关的内容，比如使用XHTTP协议使被封IP的VPS重焕生机、BBRv3的介绍等…这些是笔者所欠缺的知识。

综上，笔者将从自身的折腾经验出发，分享如何从零开始配置VPS，主要内容如下：

VPS 选购
安全性配置
3x-ui 安装
入站与客户端配置
clash 订阅配置
CloudFlare Tunnel
客户端导入订阅

参考网站：

VPS选购

这篇博客并非广告，VPS 提供商的来源为 NodeSeek 以及 LLM 的输出（多为ChatGPT）。笔者在选购的时候，主要是找带有三网优化（TRI）的 VPS 服务，比如BandwagonHost、DMIT、GigsGigsCloud、Vmiss和Hostdare等一系列 VPS 提供商，它们的价格、地区均有差异。作为中国用户，首先要关注的就是 VPS 的线路，大致有以下几种：

TRI 在 VPS 商家语境里通常是 Tri-network optimized 的缩写，即“三网优化”。它不是某个运营商的正式线路名称，而是套餐命名方式。一般表示电信、联通、移动三家分别尽量走较优路径，例如电信走 CN2 GIA，联通走 9929 或 4837 优化，移动走 CMI/CMIN2。
CN2 常见于中国电信方向，全称通常理解为 China Telecom Next Generation Carrier Network，常见分类有 CN2 GT 和 CN2 GIA。GIA，即 Global Internet Access，通常比 GT 更高端，价格更贵，低峰和晚高峰的稳定性也通常更好。
9929 通常指中国联通 AS9929，也常被称为联通精品网、CUII，是一类走联通优质国际链路的线路标识。相比联通普通骨干网 AS4837，9929 一般更适合对联通用户优化，常见于香港、日本、美国西海岸等面向中国大陆优化的 VPS。
4837 通常指中国联通普通骨干网 AS4837，也就是 China169 Backbone。它覆盖面广、成本相对低，但国际方向在高峰期更容易受到拥塞影响。
CMI 通常指中国移动国际线路，常见 AS 号是 AS58453；CMIN2 则是近年 VPS 圈里常见的移动高端线路说法，常与 AS58807 相关。对于中国移动用户，CMI/CMIN2 的体验往往比绕路国际 BGP 更稳定。

不同的 VPS 的服务详情，节点速率、延迟等数据，均可以通过搜索引擎查阅到，笔者不多赘述。此外，两个月前笔者挑选 VPS 时，就有优质线路服务短缺的问题，比如 DMIT，笔者观察了许久，时至今日大多产品也都是"Out of stock"的状态，其它的提供商也是同理（除了配置比较豪华的服务）。现在看来当时能搞到一台 VPS 用到现在，大概是运气好吧。

下面，当成功付款后，会被分配到一台 VPS 供我们折腾，操作系统的选择个人认为区别大不，管理界面大致如下：

通常这里会有最为重要的，VPS 的 IP 信息，以及一些基本的管理功能。

安全性配置

开机后，第一步就是基本的安全性配置，避免被恶意攻击。笔者在前几天遭遇了一次，原因是因为偷懒没有禁用密码登录，fail2ban的规则也没设置好，于是在被攻击了长达1个小时后，IP也被封了（可能是巧合）。这还是 IP 被封了以后，发现 CPU 利用率在一段时间内竟是 100% 发现的。

首先，通过 SSH 和提供的最初的 root 账户连接到 VPS 上（使用提供商的 VNC console 也可以），执行下面的命令进行软件的更新，以及必要的 ufw 和 fail2ban 的安装：

1
2


apt update && apt full-upgrade -y
apt install -y sudo curl wget vim git ufw fail2ban

SSH登录

出于历史教训，应尽早关闭密码登录，仅保留 SSH 密钥登录方法。笔者是用了 VPS 官方控制台的 openSSH，它会自动生成好密钥文件到 VPS 中，并关闭密码登录，我需要做的只是把密钥文件配置到客户端的机器上，以便于访问。

切换到客户端机器的用户目录下，找到（或者创建）.ssh 目录，存放生成的密钥文件，文件名随意。之后再创建（或编辑）一个名为 config 的文件，需要新增内容样式如下：

1
2
3
4
5


Host vps
 HostName 1.2.3.4
 User root
 IdentityFile ~/.ssh/id_ed25519
 IdentitiesOnly yes

字段解释如下：

1
2
3
4
5


Host : 本地别名（以后 ssh vps）
HostName : VPS 的 IP 或域名
User : 登录用户名（root / deploy）
IdentityFile : 私钥路径
IdentitiesOnly : 强制只用该密钥，避免 SSH 自动尝试其他 key

如果要自己生成密钥文件的话，那么顺序不同，且 VPS 上也要进行对应操作。首先，在客户端机器上生成一个随机密钥：

1

ssh-keygen -t ed25519

把密钥复制到 VPS 上：

1
2
3
4


mkdir -p ~/.ssh
nano ~/.ssh/authorized_keys # 把生成好的密钥复制进去
chmod 600 ~/.ssh/authorized_keys
chmod 700 ~/.ssh

稀疏向量与 SPLADE 模型

Tue, 12 May 2026 16:17:17 +0800

参考网站

稀疏向量与 SPLADE 模型

在 RAG 系统里，dense vector 已经是最常见的召回方式。它把文本映射到连续向量空间中，适合捕捉语义相近的表达，例如“员工离职流程”和“人员退出手续”。但 dense vector 也有明显短板：它不一定擅长精确匹配实体、编号、术语、错误码、产品型号、表格字段名和代码片段。

这时 sparse vector 就有价值了。它更像一个“神经网络增强版倒排索引”：文本仍然被表示为词项维度上的稀疏权重，但这些权重不是 BM25 这类纯统计方法算出来的，而是由模型预测出来的。

简单说：

dense vector 负责语义相似。
BM25 负责原词匹配。
SPLADE sparse vector 负责神经词项扩展后的加权匹配。
Hybrid Search 则把 dense 和 sparse 两种召回结果融合起来。

论文模型

SPLADE 基于 Masked Language Model 的 logits，把一段文本映射到词表空间中。假设词表里有 30522 个 WordPiece token，那么每个文本最终可以表示为：

1

token_id -> weight

也就是一个稀疏向量。大部分 token 的权重为 0，只有少量被模型认为重要的 token 会有非零权重。

这和普通 embedding 最大的区别是：dense embedding 的每一维通常不可解释，而 sparse vector 的维度就是词表 token。一个被模型激活的 token 可以理解为“这段文本与这个词项相关”。

例如一段文档没有显式出现“报销”，但出现了“差旅费”“发票”“审批单”，SPLADE 可能会激活与“报销”相关的 token。这样在查询“报销流程”时，即便文档没有完全命中原词，也可能被召回。

更具体地说，SPLADE 会利用 Masked Language Model 层的 logits，在 BERT WordPiece 词表中预测每个词项的重要性。假设输入文本在分词后是：

$$ t=(t_{1},t_{2},...,t_{N}) $$

对应的上下文表示是：

$$ (h_{1},h_{2},...,h_{N}) $$

那么对输入中第 $i$ 个 token，模型会计算它对词表中第 $j$ 个 token 的重要性：

$$ w_{ij}=transform(h_{i})^{T}E_{j}+b_{j}, \quad j\in\{1,...,|V|\} $$

这里 $E_j$ 词表 ${token}_j$ 的 BERT 输入嵌入，$b_j$ 是 token 级偏置，transform(.) 通常是带 GeLU 和 LayerNorm 的线性变换。直觉上，这一步是在问：输入里的这个位置，和词表里的每个词项分别有多相关。

但检索时需要的不是“某个位置对某个词的分数”，而是“整段文本对某个词的分数”。因此 SPLADE 会把不同位置的激活聚合成整段文本的稀疏表示：

$$ w_{j}=\sum_{i\in t}\log(1+ReLU(w_{ij})) $$

这个公式里有三层含义：

ReLU 把负分清零，只保留正向相关的词项。
$log(1+x)$ 做对数饱和，避免高频词或重复词的分数被无限放大。
$\sum$ 把不同位置对同一个词表 token 的激活累加起来，得到整段文本的词项权重。

最后，文本就变成了一个很高维但很稀疏的向量：

1

token_id -> weight

查询和文档都映射到同一个词表空间后，检索分数就是稀疏向量点积：

$$ s(q,d)=\sum_j w_j^q w_j^d $$

这也是 SPLADE 能接入倒排索引或稀疏向量索引的原因。

排序损失

训练时，SPLADE 要让相关文档得分更高，不相关文档得分更低。给定一个查询 $q_i$ 、一个正样本文档 $d_i^+$ 、一个困难负样本 $d_i^-$ ，以及一组批内负样本 ${d_{i,j}^{-}}$ ，可以使用类似下面的对比排序损失：

$$ \mathcal{L}_{rank-IBN} = -\log \frac{e^{s(q_i,d_i^+)}} {e^{s(q_i,d_i^+)} + e^{s(q_i,d_i^-)} + \sum e^{s(q_i,d_{i,j}^{-})}} $$

它的目标很直接：让正样本在候选集合里的概率尽可能大。工程上可以理解为，模型会不断学习哪些词项扩展能帮助它把正确文档排到前面。

FLOPS 稀疏正则

如果只优化排序效果，模型可能会激活太多 token。这样虽然召回可能变强，但倒排索引会膨胀，查询时需要访问的 posting list 也会变多。

因此 SPLADE 引入 FLOPS 正则来控制稀疏性。对一批文档来说，可以先估计词表 token (j) 在这批文档中的平均激活：

$$ \overline{a}_{j}=\frac{1}{N}\sum_{i=1}^{N}w_{j}^{(d_i)} $$

然后对平均激活做平方求和：

$$ l_{FLOPS}=\sum_{j\in V}\overline{a}_{j}^{2} =\sum_{j\in V}(\frac{1}{N}\sum_{i=1}^{N}w_{j}^{(d_i)})^{2} $$

这个正则项不是简单控制“向量维度”，而是在控制非零 token 的数量和分布。它希望模型不要把大量文档都绑定到少数高频词上，也不要让每个文档都激活过多词项。

因此，稀疏性权重可以理解为一个召回质量和检索成本之间的旋钮：

权重更大：稀疏向量更短，索引更小，检索更快，但可能损失召回。
权重更小：稀疏向量更长，扩展更丰富，但索引和检索成本更高。

总体损失

最终，SPLADE 会把排序损失和稀疏正则放在一起训练：

$$ \mathcal{L}=\mathcal{L}_{rank-IBN} +\lambda_q\mathcal{L}_{reg}^{q} +\lambda_d\mathcal{L}_{reg}^{d} $$

其中 (\lambda_q) 控制查询侧稀疏性，(\lambda_d) 控制文档侧稀疏性。查询侧通常对延迟更敏感，所以查询侧稀疏性非常重要。文档侧可以离线计算，通常可以接受更高一点的计算成本，但仍然要控制索引体积。

从求和到最大池化

原始 SPLADE 会对输入文本中每个位置的词项预测进行聚合：

$$ w_{j}=\sum_{i\in t}\log(1+ReLU(w_{ij})) $$

后续更常见的 SPLADE-max 使用最大池化：

$$ w_{j}=\max_{i\in t}\log(1+ReLU(w_{ij})) $$

这并不是整段文本只保留一个 token，而是对词表里的每个维度分别取最大激活值。这样可以减少长文本或重复词带来的累加放大，让表示更关注“是否强烈激活某个语义词项”，而不是简单依赖出现次数。

SPLADE-doc 与蒸馏训练

标准 SPLADE 会同时编码 query 和 document。也就是说，查询侧和文档侧都可能产生神经扩展词项，检索时计算的是：

$$ s(q,d)=\sum_j w_j^q w_j^d $$

SPLADE-doc 则更偏工程效率。它只在文档侧做 SPLADE 编码，查询侧通常只使用原始 query token，文档得分可以写成：

$$ s(q,d)=\sum_{j\in q}w_j^d $$

这样文档侧扩展可以离线预计算，查询侧不需要跑 SPLADE encoder，延迟会更低。代价是 query 侧没有神经扩展能力，只能利用“文档侧扩展”。

另外，很多效果较强的 SPLADE 模型会使用知识蒸馏和困难负样本。常见做法是先训练一个第一阶段检索器和 cross-encoder 重排器，再用更难的负样本和重排器分数继续训练。工程上不用自己复现这套训练流程，也能使用公开模型；但理解这一点有助于判断模型名称里 distil、ensemble、cocondenser 这类词为什么会出现。

稀疏性为什么重要

如果模型把大量 token 都激活，召回效果也许会上升，但索引会变大，检索会变慢。SPLADE 使用 FLOPS 正则化来控制非零 token 的数量和分布。

工程上可以把它理解为：稀疏向量不是越长越好。

非零 token 太少：索引小、检索快，但召回可能不够。
非零 token 太多：召回可能更好，但索引膨胀，检索成本上升。

落地时通常还会做二次裁剪，例如：

只保留 top_k 个 token
过滤 weight 低于阈值的 token
限制单个 chunk 的最大稀疏维度数量

这些参数往往比模型本身更影响线上成本。

模型选择

SPLADE 更像一类稀疏神经检索方法，而不是单一模型。Naver 官方仓库也特别提醒：不同正则化强度会得到从“非常稀疏”到“强 query/doc 扩展”的不同模型，效果、索引大小和延迟都会变。

如果只是想快速做工程验证，可以从 naver/splade-cocondenser-ensembledistil 开始。它是官方 SPLADE++ 系列里常见的强效果模型，在 Naver 官方仓库列出的 MS MARCO dev MRR@10 为 38.3，高于 splade_v2_max 的 34.0 和 splade_v2_distil 的 36.8。它适合先验证 sparse 召回是否能补足 dense 的关键词、实体、术语召回缺口。

如果更看重推理成本，可以看 naver/splade_v2_max 或 efficient SPLADE 系列。splade_v2_max 结构简单，Hugging Face 模型页标注为 DistilBERT base、512 token 最大长度、30522 维输出、点积相似度。efficient SPLADE 系列则进一步区分 document encoder 与 query encoder，目标是降低查询侧延迟。

一个实用的选型顺序是：

先选一个效果强的公开模型做离线评测，例如 naver/splade-cocondenser-ensembledistil。
如果离线评测有效，再统计平均非零 token 数、索引大小、文档侧编码吞吐和查询侧 P95 延迟。
如果查询侧太慢，优先尝试 query 缓存、ONNX/OpenVINO、量化或 efficient SPLADE。
如果索引太大，优先调小 top-k、提高最小权重阈值，或选择更强正则化、更稀疏的模型。
如果业务语料和公开英文检索数据差异很大，再考虑用领域数据微调，而不是直接相信公开榜单。

不要只按 MRR 选模型。SPLADE 选型至少要同时看五件事：检索效果、平均非零维度、索引体积、查询延迟、部署复杂度。

Sentence Transformers 现在提供了 SparseEncoder，可以直接加载 SPLADE 模型：

1
2
3
4


from sentence_transformers import SparseEncoder

model = SparseEncoder("naver/splade-cocondenser-ensembledistil")
embeddings = model.encode(["example query"])

它也提供 encode_query()、encode_document()、稀疏度统计、Qdrant/Elasticsearch/OpenSearch 集成，以及 ONNX/OpenVINO/量化相关部署能力。工程上可以优先用这条路线做原型，再根据性能瓶颈决定是否切到自定义推理服务。

SPLADE 和 BM25 的区别

BM25 和 SPLADE 都可以使用倒排索引完成检索，但权重来源不同。

BM25 的权重来自统计量，例如 TF、IDF 和文档长度归一化。它主要依赖 query 原词和 document 原词的精确匹配。

SPLADE 的权重来自神经模型预测。它不仅可以保留原文出现的 token，也可能激活原文没有出现但语义相关的 token。

因此可以粗略理解为：

1
2


BM25 = 原始词项的统计匹配
SPLADE = 神经扩展词项的加权匹配

在企业知识库、技术文档、客服 FAQ、代码文档、规范制度等场景中，BM25 和 SPLADE 都很有价值。BM25 更轻，SPLADE 更强但成本更高。

Practical BM25

Sat, 09 May 2026 13:30:00 +0800

参考网站

Practical BM25 - Part 1: How Shards Affect Relevance Scoring in Elasticsearch | Elastic Blog

Practical BM25 - Part 2: The BM25 Algorithm and its Variables | Elastic Blog

Practical BM25 - Part 3: Considerations for Picking b and k1 in Elasticsearch | Elastic Blog

tf-idf - 维基百科，自由的百科全书

Background

在 Elasticsearch 5.0 中，我们切换到 Okapi BM25 作为默认相似度算法，用于对搜索结果与查询的相关性进行评分。本文将着重介绍BM25 的实际应用，包括可用参数及其影响评分的因素。

Understanding How Shards Affect Scoring

在学习 BM25 前，必须先理解 Elasticsearch 的索引可能被切成多个 shard（索引分片/物理分区）。因为 BM25 的相关性分数不是天然基于整个 index 的全局统计计算，而默认可能是在每个 shard 内部单独计算。shard 数量越多、数据越少，分数越容易出现偏差。

下面我们照搬参考网站的示例代码，目的是先创建一个 Elasticsearch 索引 people，再往里面插入几条测试文档，然后用同一个查询词 "Shane" 反复检索，观察 BM25 相关性分数如何随着文档数量和 shard 分布发生变化：

作者创建一个名为 people 的索引，并指定它有 5 个 primary shards，默认相关性算法使用 BM25：

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


PUT people
{
 "settings": {
 "number_of_shards": 5,
 "index" : {
 "similarity" : {
 "default" : {
 "type" : "BM25"
 }
 }
 }
 }
}

作者使用它的名字做为示例：

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


PUT /people/_doc/1
{
 "title": "Shane"
}
GET /people/_doc/_search
{
 "query": {
 "match": {
 "title": "Shane"
 }
 }
}

找出 title 字段中匹配 "Shane" 的文档，自然会匹配到/people/_doc/1：

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


PUT /people/_doc/2
{
 "title": "Shane C"
}
PUT /people/_doc/3
{
 "title": "Shane Connelly"
}
PUT /people/_doc/4
{
 "title": "Shane P Connelly"
}

然后再次对它们做搜索：

1
2
3
4
5
6
7
8


GET /people/_doc/_search
{
 "query": {
 "match": {
 "title": "Shane"
 }
 }
}

也就是说现在有4条“文档”：

Shane
Shane C
Shane Connelly
Shane P Connelly

从其中，找出 title 字段中匹配 "Shane" 的文档。虽然说title字段都有"Shane"，但是它们的BM25分数不会一样。结果：doc1 和doc3 分数都是0.2876821，但doc2 分数是0.19856805，doc4分数是0.16853254。

尽管doc2和doc3很像，但是分数差了很多，这其实和"C"与"Connelly"的差异关系不大，而是和文档如何落在分片中有关。所以如何让分数更具一致性呢：

数据量越大，shard 间的统计差异越小
减少 shard 数量可以降低打分偏差
如果想让多 shard 情况下的 BM25 打分更接近“全局统计”，可以在查询时加上 ?search_type=dfs_query_then_fetch。它会先收集所有 shard 的词频统计信息，再统一计算分数，因此结果会接近甚至等同于 number_of_shards=1 时的分数。

dfs_query_then_fetch 的作用是先跨 shard 汇总词频统计，再统一计算 BM25 分数，使多 shard 的打分更接近单 shard 的全局效果；但它会增加一次额外通信，所以只有在小数据、多 shard、数据分布不均且很在意相关性分数时才值得使用。

Algorithm and its variables

BM25 model:

$$ \sum_{i}^{n} IDF(q_i) \frac{f(q_i, D) * (k_1 + 1)}{f(q_i, D) + k_1 * (1 - b + b * \frac{fieldLen}{avgFieldLen})} $$

$q_i$: 查询中的第 $i$ 个关键词。
$IDF(q_i)$: 关键词 $q_i$ 的逆文档频率（Inverse Document Frequency）。
$f(q_i, D)$ :关键词 $q_i$ 在文档 $D$ 中的词频。
$fieldLen$: 当前文档的长度。
$avgFieldLen$: 索引中所有文档的平均长度。
$k_1$ 和 $b$: 可调参数（通常 $k1 \in [1.2, 2.0]$，$b = 0.75$）。

其实简单来说，BM25就是引入了非线性，并解决了频次问题的TF-IDF模型。TF-IDF model:

$$ \text{Score} = f(q_i, D) \times \log\left(\frac{N}{n(q_i)}\right) $$

$q_i$

例如，如果我搜索“shane”，这里只有一个查询词，因此 $q_0$ 就是“shane”。如果我用英文搜索“shane connelly”，Elasticsearch 会识别其中的空格，并将其分词（tokenize）为两个词项：$q_0$ 为“shane”，$q_1$ 为“connelly”。这些查询词会被代入公式的其他部分，最后将所有结果加总求和。

$IDF(q_i)$

公式中的 IDF（逆文档频率） 部分用于衡量一个词项在所有文档中出现的频率，并会对那些出现次数过多的常用词进行“惩罚”（即降低其权重）。在 Lucene/BM25 算法中，该部分的实际公式如下：

$$ \ln \left( 1 + \frac{(docCount - f(q_i) + 0.5)}{f(q_i) + 0.5} \right) $$

其中，$docCount$ 是该分片中（如果使用的是 search_type=dfs_query_then_fetch 参数，则为跨所有分片）包含该字段值的文档总数；而 $f(q_i)$ 是包含第 $i$ 个查询词项的文档数量。在我们的示例中可以看到，“shane” 这个词在所有 4 个文档中都出现了，因此对于词项 “shane”，我们最终得到的逆文档频率 $IDF(\text{"shane"})$ 为：

$$ \ln\left(1 + \frac{(4 - 4 + 0.5)}{4 + 0.5}\right) = \ln\left(1 + \frac{0.5}{4.5}\right) = 0.105360515657826 $$

$IDF(\text{"connelly"})$为：

$$ \ln\left(1 + \frac{(4 - 2 + 0.5)}{2 + 0.5}\right) = \ln\left(1 + \frac{2.5}{2.5}\right) = 0.693147180559945 $$

我们可以看到，包含这些更罕见词项的查询（在我们的 4 文档语料库中，“connelly” 比 “shane” 更罕见）具有更高的乘数，因此它们对最终得分的贡献更大。这在直觉上是合理的：词项 “the” 可能出现在几乎每一篇英文文档中，所以当用户搜索像 “the elephant” 这样的内容时，“elephant” 显然比词项 “the”（几乎存在于所有文档中）更重要——我们也希望它能为搜索得分做出更多贡献。

$fieldLen/avgFieldLen$

档中的词项越多（至少是那些没匹配上查询条件的词项），该文档的得分就越低。同样，这在直觉上是合理的：如果一份文档长达 300 页且只提到了我的名字一次，那么它与我的相关性，很可能不如一条同样提到我一次的短推文。

$b$

如果 $b$ 的值越大，文档长度相对于平均长度所产生的影响就会被进一步放大。为了理解这一点，可以想象如果将 $b$ 设置为 0，长度比例的影响将完全消失，只受频次影响，文档的长度将对评分不产生任何影响。如果将 $b$ 设置为 1 ，则得分不受频次影响，只受长度比例的影响。

$f(q_i, D)$

这个值对应了 TF (Term Frequency, 词频)

$f(q_i, D)$ 的含义是：“第 $i$ 个查询词项在文档 $D$ 中出现了多少次？”在所有这些文档中，$f(\text{"shane"}, D)$ 都是 1，但 $f(\text{"connelly"}, D)$ 各不相同：在文档 3 和 4 中是 1，但在文档 1 和 2 中是 0。如果有第 5 个文档的文本是 “shane shane”，那么它的 $f(\text{"shane"}, D)$ 就是 2。我们可以看到，$f(q_i, D)$ 同时出现在分子和分母中，此外还有一个特殊的 “$k_1$” 因子，我们稍后会讨论它。理解 $f(q_i, D)$ 的方式是：查询词项在文档中出现的次数越多，其得分就越高。这在直觉上是合理的：一个多次提到我们名字的文档，比只提到一次的文档更有可能与我们相关。

$k_1$

在 BM25 算法中，$k_1$ 是控制词频饱和度（Term Frequency Saturation）的核心参数。它通过为词频 $f(q_i, D)$ 对相关性得分的贡献设定渐近上限确保得分随词频增加而产生的边际增益呈非线性递减。相比于传统 TF-IDF 近乎线性的权重增长，这一机制有效抑制了高频词项（如关键词堆砌）对排名的过度干扰；其中，$k_1$ 的取值直接决定了得分趋于饱和的速度：较小的 $k_1$ 值会使词频贡献快速达到瓶颈，而较大的 $k_1$ 值则允许词频在更广的数值范围内维持显著的权重增益。

如果将 $k_1$ 设置为 0，得分将固定为1。如果将 $k_1$ 设置的很大（比如10000），公式近似退化为 $\frac{TF \times k_1}{k_1} = TF$ ，变成了词频本身。

Picking $b$ and $k_1$

关于 $b$ 和 $k_1$ 的值，ES的文章也指出现在的值是个能涵盖多数情况的“经验值”，但是不存在全局最优的 b 和 k1，只能结合语料和查询做实验评估。

而且在检索性能不够好时，在调整 $b$ 和 $k_1$的值之前，应该先优化下面的内容：

对精确短语匹配进行 boost；
使用 synonyms 扩展用户可能感兴趣的同义表达；
使用 fuzziness、typeahead、phonetic matching、stemming 等分析组件，处理拼写错误、语言差异和词形变化；
使用 function score，根据发布时间、地理距离或业务特征调整文档得分。

至于后文ES的Explain API，不再赘述。

RAGFlow切片策略解析

Tue, 14 Apr 2026 20:06:34 +0800

RAGFlow 切片策略解析

众所周知RAGFlow是较早成熟且开源的RAG项目之一，近日笔者正在学习构建一个RAG项目，所以从RAGFlow的源码下手。首先学习的是它对markdown文件的解析方法和切片策略。

`rag/app/naive.py`

naive.py 中支持很多文件的类型，比如PDF, DOCX, Markdown……

那么我们要学习的markdown类，主入口是__call__()，这是核心方法，编排了整个 Markdown 解析流程。

`call()`

1

def __call__(self, filename, binary=None, separate_tables=True, delimiter=None, return_section_images=False):

参数	类型	说明
`filename`	str	文件路径（当 `binary` 为空时用来读文件）
`binary`	bytes	文件二进制内容，优先使用
`separate_tables`	bool	是否将表格从正文中分离出来
`delimiter`	str	自定义分割符，如果指定则用分割符切分而非按元素类型切分
`return_section_images`	bool	是否额外返回每个 section 对应的图片

执行流程：

 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


Step 1: 文本解码
 ┌────────────────────────────┐
 │ binary → find_codec() → │
 │ decode(encoding) │
 │ 或 open(filename).read() │
 └────────────┬───────────────┘
 ↓
Step 2: 表格提取（继承自父类）
 ┌────────────────────────────────────────────────────┐
 │ self.extract_tables_and_remainder(txt+"\n", │
 │ separate_tables) │
 │ → (remainder, tables[]) │
 │ │
 │ 注意：这里传入的是 txt+"\n"（末尾补换行） │
 └────────────┬───────────────────────────────────────┘
 ↓
Step 3: 元素扫描
 ┌────────────────────────────────────────────────────┐
 │ MarkdownElementExtractor(txt) │
 │ .extract_elements(delimiter, include_meta=True) │
 │ → element_sections[] │
 │ │
 │ ★ 关键：这里传入的是原始 txt，而非 remainder！ │
 │ （注释 L682-683 说明了原因：为避免重复表格） │
 └────────────┬───────────────────────────────────────┘
 ↓
Step 4: 图片 URL 提取
 ┌────────────────────────────────────────────────────┐
 │ self.extract_image_urls_with_lines(txt) │
 │ → image_refs = [{url, line}, ...] │
 └────────────┬───────────────────────────────────────┘
 ↓
Step 5: 元素-图片关联（核心融合逻辑）
 ┌────────────────────────────────────────────────────┐
 │ for element in element_sections: │
 │ ① 取 element 的 start_line ~ end_line │
 │ ② 筛选行范围内的 image_refs │
 │ ③ load_images_from_urls() 下载图片（有缓存） │
 │ ④ 多张图用 concat_img 合并为一张 │
 │ ⑤ sections.append((content, "")) │
 │ ⑥ section_images.append(combined_image or None) │
 └────────────┬───────────────────────────────────────┘
 ↓
Step 6: 表格后处理
 ┌────────────────────────────────────────────────────┐
 │ for table in tables: │
 │ markdown(table, extensions=["tables"]) → html │
 │ tbls.append(((None, html), "")) │
 └────────────┬───────────────────────────────────────┘
 ↓
Step 7: 返回结果
 ┌────────────────────────────────────────────────────┐
 │ if return_section_images: │
 │ return sections, tbls, section_images │
 │ else: │
 │ return sections, tbls │
 └────────────────────────────────────────────────────┘

输出数据结构：

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


sections = [
 ("## 标题\n正文内容...", ""), # (文本, 位置标签—永远为空字符串)
 ("```python\ncode\n```", ""), # 代码块
 ...
]

tbls = [
 ((None, "<table>...</table>"), ""), # (None, HTML表格字符串)
 ...
]

section_images = [
 PIL.Image, # 该 section 中所有图片合并后的图像对象
 None, # 该 section 无图片
 PIL.Image,
 ...
]

这其中最关键的是表格提取和元素扫描的部分：

`extract_tables_and_remainder()`

这个方法定义于deepdoc/parser/resume/markdown_parser.py的RAGFlowMarkdownParser类中，用于将markdown中的表格提取出来

1
2
3
4
5
6


class RAGFlowMarkdownParser:
 def __init__(self, chunk_token_num=128):
 self.chunk_token_num = int(chunk_token_num)

 def extract_tables_and_remainder(self, markdown_text, separate_tables=True):
 # 返回: (剩余正文, [表格列表])

表格识别策略：

类型	正则	示例
有边框 Markdown 表格	`	…
无边框 Markdown 表格	`text	text` + 分隔行 + 数据行
HTML 表格	`<table>...</table>`，支持包裹在 `<html><body>` 中	`<table><tr><td>...</td></tr></table>`

当 separate_tables=True 时，表格从正文里移除并单独返回；为 False 时则就地转为 HTML。

`MarkdownElementExtractor`

该类位于deepdoc/parser/markdown_parser.py，实现了一个简易的 Markdown 元素识别器，将文本按行扫描并归类为不同的块类型。

1
2
3
4
5
6
7


class MarkdownElementExtractor:
 def __init__(self, markdown_content):
 self.markdown_content = markdown_content
 self.lines = markdown_content.split("\n")

 def extract_elements(self, delimiter=None, include_meta=False):
 """提取各种元素(headers, code blocks, lists, 等)"""

输出元素结构：

1
2
3
4
5
6


{
 "type": "header" | "code_block" | "list_block" | "blockquote" | "text_block",
 "content": "具体文本内容",
 "start_line": 0, # 起始行号
 "end_line": 5, # 结束行号
}

_extract_header() : 返回单行的"header"
_extract_code_block() : 直到遇到" ``` “返回多行的代码块"code_block”
_extract_list_block() : 吞入满足以下条件的行：
- 以 -, *, + 或 数字. 开头（列表项）
- 空行（列表项间隙）
- 以 2+ 空格缩进的子列表或续行
_extract_blockquote() : 持续吞入">“开头的行或内部的空行
_extract_text_block() : 处理不属于上面几种类型的普通文本"text_block”，直到符合上面类型的元素再次出现

`extract_image_urls_with_lines()`

这个方法用于找出 Markdown 文本中所有图片引用及其所在行号。行号用于后续将图片关联到对应的 section。

三阶段提取策略：

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


阶段 1: Markdown 语法图片

 正则: ![alt](url) → 提取 url

 模式: r"!\[[^\]]*\]\(([^)\s]+)"

阶段 2: HTML 内联图片（单行）

 正则: src="url" / src='url' → 提取 url

 模式: r'src=["\\\'"]([^"\\\'>\\s]+)'

阶段 3: HTML 跨行图片（BeautifulSoup 兜底）

 解析整个文本为 HTML，查找所有 <img> 标签的 src

 通过字符偏移量计算行号

 用 seen 集合避免与阶段 1/2 重复

返回值：

1
2
3
4
5


[
 {"url": "https://example.com/img.png", "line": 5},
 {"url": "./assets/diagram.svg", "line": 12},
 ...
]

`load_images_from_urls()`

1
2


def load_images_from_urls(self, urls, cache=None):
 # 返回: (images[], cache{})

功能	细节
HTTP 图片	`requests.get(url, timeout=30)`，校验 `Content-Type` 为 `image/`
本地图片	`Path(url).exists()` 检查后用 `PIL.Image.open()`
缓存机制	`cache` dict 避免重复下载同一 URL
统一格式	所有图片转为 `RGB` 模式 (`convert("RGB")`)
错误处理	失败时 `cache[url] = None`，不中断流程

这里的思路比较朴素，但很实用：

先根据 url 判断是网络图片还是本地图片
统一加载成 PIL.Image
放入缓存，避免同一张图在多个 section 中重复读取
后续如果某个 section 对应多张图片，再交给 concat_img 合并

也就是说，RAGFlow 在 Markdown 中并不是把每一张图片都单独当成一个 chunk，而是先尝试把同一个 section 内的图片聚合起来，再与文本一起进入后续流程。

`urls_in_section = [...]`

在 Markdown.__call__() 中，真正把文本 section 和图片联系起来的代码是这一段：

1
2
3
4
5


for element in element_sections:
 content = element["content"]
 start_line = element["start_line"]
 end_line = element["end_line"]
 urls_in_section = [ref["url"] for ref in image_refs if start_line <= ref["line"] <= end_line]

其核心思想非常直接：按行号做区间归属。

一个 Markdown 元素先被标记 start_line 和 end_line
所有图片引用也带有自己的 line
只要图片所在行落在元素区间内，就认为这张图属于这个 section

这是一种很工程化的做法。它不追求复杂语义理解，而是利用 Markdown 本身“按行组织”的特点，以较低成本建立图文关联。

例如下面这段 Markdown：

1
2
3
4
5
6
7
8



### 模型结构

这里介绍整体流程。

![pipeline](./pipeline.png)

接着说明各模块职责。

如果这一整段被 MarkdownElementExtractor 视为同一个 text_block，那么图片就会和这一段正文绑定在一起；如果标题和正文被分成两个元素，则图片通常会归到正文所在的 section，而不会归到标题 section。

表格处理细节

前面提到，Markdown.__call__() 中虽然调用了：

1

remainder, tables = self.extract_tables_and_remainder(f"{txt}\n", separate_tables=separate_tables)

但后面真正做元素扫描时，使用的是：

1

extractor = MarkdownElementExtractor(txt)

而不是 remainder。

源码里其实已经留了注释：

1
2
3


# To eliminate duplicate tables in chunking result, uncomment code below and set separate_tables to True ...
# extractor = MarkdownElementExtractor(remainder)
extractor = MarkdownElementExtractor(txt)

这说明作者其实也意识到了一个现象：表格可能同时出现在 section chunk 和 table result 中。

从实现角度看，这未必是 bug，更像是一种偏保守的召回策略：

正文 chunk 中保留表格原始上下文
tables 中再额外保留结构化表格内容

这样做可能带来一定冗余，但也提高了检索时命中表格信息的概率。

`chunk()`

看到这里，其实还只是完成了解析和预处理。真正决定最终 chunk 长什么样的，不在 Markdown.__call__()，而在 rag/app/naive.py 下面的 chunk() 函数里。

Markdown 文件分支一开始会先调用前面的解析器：

1
2
3
4
5
6
7
8


markdown_parser = Markdown(int(parser_config.get("chunk_token_num", 128)))
sections, tables, section_images = markdown_parser(
 filename,
 binary,
 separate_tables=False,
 delimiter=parser_config.get("delimiter", "\n!?;。；！？"),
 return_section_images=True,
)

这里有两个细节值得注意：

return_section_images=True 说明 Markdown 解析阶段生成的图片不会丢，而是继续带到后面的 chunk 合并流程中。
separate_tables=False 说明这里并没有把表格完全从正文切走，而是倾向于让表格继续留在 Markdown 上下文里，同时又额外生成 tables 供表格索引使用。

接着，如果当前租户存在 IMAGE2TEXT 模型，chunk() 会尝试给 Markdown 中的图片补一段描述文本：

1
2
3
4
5
6


try:
 vision_model_config = get_tenant_default_model_by_type(kwargs["tenant_id"], LLMType.IMAGE2TEXT)
 vision_model = LLMBundle(kwargs["tenant_id"], vision_model_config)
except Exception as e:
 logging.warning(f"Failed to detect figure extraction: {e}")
 vision_model = None

如果视觉模型可用，则继续遍历每个 section：

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


for idx, (section_text, _) in enumerate(sections):
 images = []
 if section_images and len(section_images) > idx and section_images[idx] is not None:
 images.append(section_images[idx])

 if images and len(images) > 0:
 combined_image = reduce(concat_img, images) if len(images) > 1 else images[0]
 markdown_vision_parser = VisionFigureParser(
 vision_model=vision_model,
 figures_data=[((combined_image, ["markdown image"]), [(0, 0, 0, 0, 0)])],
 **kwargs
 )
 boosted_figures = markdown_vision_parser(callback=callback)
 sections[idx] = (
 section_text + "\n\n" + "\n\n".join([fig[0][1] for fig in boosted_figures]),
 sections[idx][1]
 )

这里可以看出 Markdown 图片增强的几个特点：

粒度是 section 级别
输入图片是前面已经聚合好的 section_images[idx]
输出不是新的 chunk，而是把图片描述文本直接追加回原 section_text

`VisionFigureParser`

该类定义在 deepdoc/parser/figure_parser.py 中：

1
2
3
4
5
6


class VisionFigureParser:
 def __init__(self, vision_model, figures_data, *args, **kwargs):
 self.vision_model = vision_model
 self.figure_contexts = kwargs.get("figure_contexts") or []
 self.context_size = max(0, int(kwargs.get("context_size", 0) or 0))
 self._extract_figures_info(figures_data)

这个类的职责并不复杂，可以理解为一个“图片描述批处理器”：

接收图片列表 figures_data
整理出图片、描述、位置信息
调用视觉模型生成描述
再把结果重新组装回原来的数据结构

Markdown 分支给它传入的 figures_data 形式是：

1

[((combined_image, ["markdown image"]), [(0, 0, 0, 0, 0)])]

也就是说，每次只处理当前 section 对应的一张聚合图，原始描述先放一个占位值 "markdown image"，位置则放一个 dummy tuple。

`_extract_figures_info()`

这个方法负责把 figures_data 拆成内部使用的三个列表：

1
2
3
4


def _extract_figures_info(self, figures_data):
 self.figures = []
 self.descriptions = []
 self.positions = []

其中核心分支是：

1
2
3
4
5
6


if len(item) == 2 and isinstance(item[0], tuple) and len(item[0]) == 2:
 img_desc = item[0]
 img = ensure_pil_image(img_desc[0])
 self.figures.append(img)
 self.descriptions.append(img_desc[1])
 self.positions.append(item[1])

因此传入的：

1

((combined_image, ["markdown image"]), [(0, 0, 0, 0, 0)])

会被拆成：

self.figures : [combined_image]
self.descriptions : [["markdown image"]]
self.positions : [[(0, 0, 0, 0, 0)]]

这里的 ensure_pil_image() 负责把输入统一成 PIL.Image 对象，因此前面无论传入的是普通图片对象还是惰性图片对象，到了这里都会被标准化。

`call()`

VisionFigureParser.__call__() 才是真正执行视觉增强的入口：

1
2


def __call__(self, **kwargs):
 callback = kwargs.get("callback", lambda prog, msg: None)

它内部先定义了一个 process()，用于处理单张图片：

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


def process(figure_idx, figure_binary):
 context_above = ""
 context_below = ""
 if figure_idx < len(self.figure_contexts):
 context_above, context_below = self.figure_contexts[figure_idx]
 if context_above or context_below:
 prompt = vision_llm_figure_describe_prompt_with_context(
 context_above=context_above,
 context_below=context_below,
 )
 else:
 prompt = vision_llm_figure_describe_prompt()

然后通过线程池并发调用：

1
2


for idx, img_binary in enumerate(self.figures or []):
 futures.append(shared_executor.submit(process, idx, img_binary))

等所有任务完成之后，将返回的描述文本写回：

1
2
3
4


for future in as_completed(futures):
 figure_num, txt = future.result()
 if txt:
 self.descriptions[figure_num] = txt + "\n".join(self.descriptions[figure_num])

最后再调用 _assemble() 重新组装：

1
2


self._assemble()
return self.assembled

对于 Markdown 分支来说，这里有两个细节：

没有显式传入 figure_contexts，因此默认使用 vision_llm_figure_describe_prompt()
回填时会把模型输出和原始描述拼在一起，因此最终描述中理论上可能保留 "markdown image" 这个占位文本

`picture_vision_llm_chunk()`

process() 里真正调用视觉模型的函数是 rag/app/picture.py 中的：

1

def vision_llm_chunk(binary, vision_model, prompt=None, callback=None):

虽然名字叫 vision_llm_chunk，但其作用其实很直接，就是把图片交给 VLM 并返回描述文本。

其主要步骤如下：

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


with io.BytesIO() as img_binary:
 try:
 img.save(img_binary, format="JPEG")
 except Exception:
 img_binary.seek(0)
 img_binary.truncate()
 img.save(img_binary, format="PNG")

 img_binary.seek(0)
 ans = clean_markdown_block(vision_model.describe_with_prompt(img_binary.read(), prompt))
 txt += "\n" + ans
 return txt

这里做了几件事：

先把 PIL.Image 编码成二进制
优先尝试保存为 JPEG，失败则退回 PNG
调用 vision_model.describe_with_prompt() 生成描述
用 clean_markdown_block() 清理模型输出中的 Markdown 包裹

因此这个函数返回的是一段纯文本，而不是结构化对象。

`vision_llm_figure_describe_prompt()`

在 VisionFigureParser.__call__() 中，无上下文情况下使用的是：

1

prompt = vision_llm_figure_describe_prompt()

而如果存在上下文，则切换到：

1
2
3
4


prompt = vision_llm_figure_describe_prompt_with_context(
 context_above=context_above,
 context_below=context_below,
)

这两组 prompt 都定义在 rag/prompts/ 下。其核心约束是：

只根据图中可见内容生成文本
如果是表格、柱状图、折线图这类“可枚举数据图”，则按固定字段输出
如果不是结构化数据图，则按空间顺序描述可见内容
不允许额外推断流程、功能或语义

也就是说，这一步生成的不是泛化摘要，而是偏向检索友好的图片文本表示。

`sections[idx] = (...)`

最终在 rag/app/naive.py 中，增强结果是这样写回 section 的：

1
2
3
4


sections[idx] = (
 section_text + "\n\n" + "\n\n".join([fig[0][1] for fig in boosted_figures]),
 sections[idx][1]
)

因此 Markdown 图像增强不会引入新的切片层级，而是把图片描述文本直接拼回现有 section。

在这一轮增强之后，chunk() 才会真正进入 Markdown 专属的 chunk 合并逻辑：

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


if is_markdown:
 merged_chunks = []
 merged_images = []
 chunk_limit = max(0, int(parser_config.get("chunk_token_num", 128)))

 current_text = ""
 current_tokens = 0
 current_image = None

 for idx, sec in enumerate(sections):
 text = sec[0] if isinstance(sec, tuple) else sec
 sec_tokens = num_tokens_from_string(text)
 sec_image = section_images[idx] if section_images and idx < len(section_images) else None

这段代码表明，Markdown 的切片单位不是“原始全文直接按分隔符硬切”，而是：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


Markdown 文本
 ↓
按元素扫描成多个 section
 ↓
每个 section 绑定对应图片
 ↓
图片描述增强（如果启用）
 ↓
按 token 上限逐个累积合并
 ↓
得到最终 chunk

RAGFlow 对 Markdown 没有直接调用通用的 naive_merge_with_images()，而是单独写了一套更简单的逻辑。其规则是：

如果加入下一个 section 后仍未超过 chunk_token_num，则继续追加
如果会超过上限，就先把当前 chunk 落盘，再开启一个新的 chunk
如果开启新 chunk 时配置了 overlapped_percent，则保留上一 chunk 尾部的一部分文本作为重叠上下文
与此同时，当前 chunk 内涉及的所有图片会被不断 concat_img 合并

关键代码如下：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


if current_text and current_tokens + sec_tokens > chunk_limit:
 merged_chunks.append(current_text)
 merged_images.append(current_image)
 overlap_part = ""
 if overlapped_percent > 0:
 overlap_len = int(len(current_text) * overlapped_percent / 100)
 if overlap_len > 0:
 overlap_part = current_text[-overlap_len:]
 current_text = overlap_part
 current_tokens = num_tokens_from_string(current_text)
 current_image = current_image if overlap_part else None

这里可以看出两个特点：

重叠是按字符长度截尾，而不是按 section 粒度重叠
图片是按 chunk 聚合的，只要 section 被并入同一个 chunk，其图片也会被拼到同一张图上

因此，一个最终的 Markdown chunk，本质上是：

1
2
3
4


{
 "text": "若干相邻 section 合并后的文本",
 "image": "这些 section 内图片拼接后的结果（如果有）"
}

在 chunk 合并完成之后，RAGFlow 会根据该批 chunk 是否含图走两条不同路径：

1
2
3
4
5
6


has_images = merged_images and any(img is not None for img in merged_images)

if has_images:
 res.extend(tokenize_chunks_with_images(chunks, doc, is_english, merged_images, child_delimiters_pattern=child_deli))
else:
 res.extend(tokenize_chunks(chunks, doc, is_english, pdf_parser, child_delimiters_pattern=child_deli))

其中：

tokenize_chunks() 负责纯文本 chunk 的分词和字段封装
tokenize_chunks_with_images() 则会把对应图片写入文档对象的 image 字段
表格则另外通过 tokenize_table(tables, doc, is_english) 进入结果集

也就是说，Markdown 在 RAGFlow 中最后会被拆成三类可检索对象：

普通文本 chunk
携带图片的多模态 chunk
表格对象

小结

至此，RAGFlow 对 Markdown 的“切片”逻辑就比较清楚了。它并不是简单地按固定长度裁文本，而是分成了几层：

先识别表格、标题、代码块、列表、引用块和普通文本块
再根据图片引用所在行号，把图片绑定到对应 section
然后按 token 上限把多个相邻 section 合并为 chunk
最后把文本、图片、表格分别包装成可检索对象

从工程实现上看，这套方案的优点是：

实现简单，可维护性高
比纯分隔符切片更保留 Markdown 结构
能较自然地支持图文混合检索
表格被单独抽出后，也便于做专门处理

当然，它也有一些局限，例如：

图片归属依赖行号，精度有限
section 的粒度较粗，未做更深层的语义切分
表格与正文可能存在信息重复

但对一个通用 RAG 系统来说，这样的取舍是相当合理的。它没有追求复杂而昂贵的 Markdown AST 解析，而是用较低复杂度完成了“结构感知切片”。

笔者认为，这也是 RAGFlow 值得学习的一点：很多时候，切片策略不一定要非常“聪明”，但一定要足够稳定、可解释，并且方便与后续检索流程对接。

CS224N Assignment3 NMT

Wed, 08 Apr 2026 09:46:07 +0800

CS 224n Spring 2024: Assignment #3

a3_spr24_student_handout.pdf

本post从cs224n独立出来，旨在尽可能掌握Assignment3中基于RNN的NMT背后各步的数学原理，以及将代码部分和数学部分对应起来。

参考论文：

NEURAL MACHINE TRANSLATION BY JOINTLY LEARNING TO ALIGN AND TRANSLATE

Neural Machine Translation with RNNs

Model description (training procedure)

Given a sentence in the source language, we look up the character or word embeddings from an embeddings matrix, yielding $\mathbf{x}_1, \ldots, \mathbf{x}_m$ ($\mathbf{x}_i \in \mathbb{R}^{e \times 1}$), where $m$ is the length of the source sentence and $e$ is the embedding size.

我们手里的一条源语言句子，由于计算机无法直接理解文字，我们首先要进行“查表”操作，也就是文本中提到的获取词嵌入（look up … embeddings matrix）。假设句子有 $m$ 个词，经过这一步，每个词都被映射成了一个长度为 $e$ 的列向量 $\mathbf{x}_i$。这样一来，整句话就被转换成了一个由实数向量构成的序列

We then feed the embeddings to a convolutional layer$^1$ while maintaining their shapes.

$^1$ : Checkout Convolutional Neural Networks for an in-depth description for convolutional layers if you are not familiar.

带着这些初步的向量表示，模型并没有直接把它们送入主要的编码器，而是先让它们穿过一个卷积层（convolutional layer）。文本中特别强调了这一步“保持了它们的形状”，这意味着经过卷积处理后，我们依然拥有 $m$ 个向量，且每个向量的维度依然是 $e$。这一步的作用通常是对局部的特征进行一次平滑和提取，为后续更深层的语义理解打好基础。

We feed the convolutional layer outputs to the bidirectional encoder, yielding hidden states and cell states for both the forwards ($\rightarrow$) and backwards ($\leftarrow$) LSTMs. The forwards and backwards versions are concatenated to give hidden states $\mathbf{h}_i^{\text{enc}}$ and cell states $\mathbf{c}_i^{\text{enc}}$:

接下来，这些被初步加工过的特征向量正式进入了核心组件——双向编码器（bidirectional encoder）。这里其实包含了两条流水线：一条是前向 LSTM（在数学符号中用向右的箭头 $\rightarrow$ 表示），它顺着我们阅读的习惯，从第一个词读到最后一个词，负责收集每个词左侧的“上文”信息；另一条是后向 LSTM（用向左的箭头 $\leftarrow$ 表示），它逆着顺序，从最后一个词倒着读回来，负责收集每个词右侧的“下文”信息。当这两条流水线各自运转完毕后，对于句子中的任意第 $i$ 个位置，我们就得到了两个不同视角的隐藏状态 $\mathbf{h}_i^{\text{enc}}$ 和细胞状态 $\mathbf{c}_i^{\text{enc}}$，前向( $\overrightarrow{\mathbf{h}_i^{\text{enc}}}$ , $\overrightarrow{\mathbf{c}_i^{\text{enc}}}$ )或后向( $\overleftarrow{\mathbf{h}_i^{\text{enc}}}$ , $\overleftarrow{\mathbf{c}_i^{\text{enc}}}$ )分别的状态量，维度都是 $h \times 1$ 。

$$ \mathbf{h}_i^{\text{enc}} = [\overleftarrow{\mathbf{h}_i^{\text{enc}}} ; \overrightarrow{\mathbf{h}_i^{\text{enc}}}] \quad \text{where} \quad \mathbf{h}_i^{\text{enc}} \in \mathbb{R}^{2h \times 1}, \overleftarrow{\mathbf{h}_i^{\text{enc}}}, \overrightarrow{\mathbf{h}_i^{\text{enc}}} \in \mathbb{R}^{h \times 1} \quad 1 \leq i \leq m \quad (1) $$$$ \mathbf{c}_i^{\text{enc}} = [\overleftarrow{\mathbf{c}_i^{\text{enc}}} ; \overrightarrow{\mathbf{c}_i^{\text{enc}}}] \quad \text{where} \quad \mathbf{c}_i^{\text{enc}} \in \mathbb{R}^{2h \times 1}, \overleftarrow{\mathbf{c}_i^{\text{enc}}}, \overrightarrow{\mathbf{c}_i^{\text{enc}}} \in \mathbb{R}^{h \times 1} \quad 1 \leq i \leq m \quad (2) $$

$[ ; ]$ 在线性代数中通常表示向量或矩阵的拼接。为了让第 $i$ 个位置最终的表示既包含左侧上下文，又包含右侧上下文，模型将同一时刻 $i$ 的前向状态和后向状态直接“拼接”在一起。因为前向和后向状态都是 $h \times 1$ 的列向量，将它们沿行方向拼接后，最终的联合隐藏状态 $\mathbf{h}_i^{\text{enc}}$ 和联合细胞状态 $\mathbf{c}_i^{\text{enc}}$ 的维度就翻倍了，变成了 $(h+h) \times 1 = \mathbf{2h \times 1}$。

We then initialize the decoder’s first hidden state $\mathbf{h}_0^{\text{dec}}$ and cell state $\mathbf{c}_0^{\text{dec}}$ with a linear projection of the encoder’s final hidden state and final cell state.$^2$

$^2$ : If it’s not obvious, think about why we regard $[\overleftarrow{\mathbf{h}_1^{\text{enc}}} , \overrightarrow{\mathbf{h}_m^{\text{enc}}}]$ as the ‘final hidden state’ of the Encoder.

双向编码器（Encoder）已经工作完毕，看完了整句源语言文本，并在每一个位置都留下了浓缩的上下文信息。接下来的任务就是把这些信息传递给解码器（Decoder），让它开始生成翻译。传递的过程就是通过下面公式中，初始化解码器在第0步的隐藏状态 $\mathbf{h}_0^{\text{dec}}$ 和细胞状态 $\mathbf{c}_0^{\text{dec}}$ 来完成的。解码器的初始状态是从编码器那里继承来的“最终状态”。

$$ \mathbf{h}_0^{\text{dec}} = \mathbf{W}_h [\overleftarrow{\mathbf{h}_1^{\text{enc}}} ; \overrightarrow{\mathbf{h}_m^{\text{enc}}}] \quad \text{where} \quad \mathbf{h}_0^{\text{dec}} \in \mathbb{R}^{h \times 1}, \mathbf{W}_h \in \mathbb{R}^{h \times 2h} \quad (3) $$$$ \mathbf{c}_0^{\text{dec}} = \mathbf{W}_c [\overleftarrow{\mathbf{c}_1^{\text{enc}}} ; \overrightarrow{\mathbf{c}_m^{\text{enc}}}] \quad \text{where} \quad \mathbf{c}_0^{\text{dec}} \in \mathbb{R}^{h \times 1}, \mathbf{W}_c \in \mathbb{R}^{h \times 2h} \quad (4) $$

编码器在“读完”整句话后的最终状态，可见公式：前向 LSTM 是顺着语序从左到右读的，所以当它读完最后一个词时，它的最终状态自然就落在了句尾，也就是第 $m$ 个位置，记作 $\overrightarrow{\mathbf{h}_m^{\text{enc}}}$。相反，后向 LSTM 是倒着从右向左读的，它“通读全文”后的最后一站其实是句子的开头，也就是第 $1$ 个位置，记作 $\overleftarrow{\mathbf{h}_1^{\text{enc}}}$。

为了把前向和后向这两股贯穿全文的“记忆”汇聚起来，我们按照公式将它们进行了拼接操作 $[\overleftarrow{\mathbf{h}_1^{\text{enc}}} ; \overrightarrow{\mathbf{h}_m^{\text{enc}}}]$。（需注意，在Decoder这一步和公式 (1) (2) 的上下文状态量不一样）

通过这个拼接，我们得到了一个维度为 $2h \times 1$ 的长向量。同样地，对于细胞状态 $\mathbf{c}$，我们用完全相同的逻辑提取出 $[\overleftarrow{\mathbf{c}_1^{\text{enc}}} ; \overrightarrow{\mathbf{c}_m^{\text{enc}}}]$。那么对于 $2h \times 1$ 的向量，我们要将其转换成 $h\times 1$ 才能满足解码器的隐藏层容量。

所以引入权重（投影）矩阵，用来做线性投影(linear projection)，维度是 $h \times 2h$ ，再通过矩阵相乘，映射出 $h\times 1$ 的向量。

With the decoder initialized, we must now feed it a target sentence.

成功初始化了解码器的第 0 步状态（$\mathbf{h}_0^{\text{dec}}$ 和 $\mathbf{c}_0^{\text{dec}}$）之后。现在，解码器已经准备好生成（或在训练时接收）目标语言的句子了。下面内容讲的就是在任意的第 $t$ 步，解码器是如何“吃进”数据并更新自己状态的。

On the $t^{th}$ step, we look up the embedding for the $t^{th}$ subword, $\mathbf{y}_t \in \mathbb{R}^{e \times 1}$.

要让解码器在第 $t$ 步进行工作，我们首先得给它提供当前的输入词，同样需要查表，把目标语言的第 $t$ 个子词（subword）变成一个维度为 $e$ 的词嵌入向量，记作 $\mathbf{y}_t$。

We then concatenate $\mathbf{y}_t$ with the combined-output vector $\mathbf{o}_{t-1} \in \mathbb{R}^{h \times 1}$ from the previous timestep (we will explain what this is later down this page!) to produce $\overline{\mathbf{y}_t} \in \mathbb{R}^{(e+h) \times 1}$.

但是，如果只把 $\mathbf{y}_t$ 喂给解码器，它会缺乏连贯性。为了让解码器知道“我刚才干了什么”，文本中引入了一个非常关键的设计：把当前的词向量 $\mathbf{y}_t$ 与上一步（第 $t-1$ 步）的维度为 $h$ 的联合输出向量 (combined-output vector) $\mathbf{o}_{t-1}$ 拼接在一起，得到新的输入向量 $\overline{\mathbf{y}_t}$，它的维度变成了 $e+h$。

Note that for the first target subword (i.e. the start token) $\mathbf{o}_0$ is a zero-vector. We then feed $\overline{\mathbf{y}_t}$ as input to the decoder.

注意到当 $t=1$ ，也就是解码器刚开始吐出第一个词（或者接收 start token）时，因为前面还没有任何输出，所以初始的 $\mathbf{o}_0$ 就简单地设定为一个全零向量。

$$ \mathbf{h}_t^{\text{dec}}, \mathbf{c}_t^{\text{dec}} = \text{Decoder}(\overline{\mathbf{y}_t}, \mathbf{h}_{t-1}^{\text{dec}}, \mathbf{c}_{t-1}^{\text{dec}}) \quad \text{where} \quad \mathbf{h}_t^{\text{dec}} \in \mathbb{R}^{h \times 1}, \mathbf{c}_t^{\text{dec}} \in \mathbb{R}^{h \times 1} \quad (5) $$

关于向Decoder中输入了三个变量后，在LSTM的Decoder里进行了什么计算，需结合CS224N中LSTM的部分进行理解：(generated by Gemini)

遗忘门 (Forget Gate)

参与者： 新输入$\overline{\mathbf{y}_t}$和旧的短期记忆$\mathbf{h}_{t-1}^{\text{dec}}$。

动作： 把这两个变量拼接在一起，乘上一个权重矩阵，加上偏置，然后送入一个 Sigmoid 激活函数。

产出： 得到一个介于 0 到 1 之间的向量 $f_t$。

意义： 这个 $f_t$ 会盯着传送带上的旧长期记忆 $\mathbf{c}_{t-1}^{\text{dec}}$ 看。0 代表“彻底忘掉”，1 代表“完全保留”。比如遇到新的主语，它可能就会决定忘掉旧主语的单复数信息。

输入门与候选记忆 (Input Gate & Candidate Memory)

参与者： 依然是 $\overline{\mathbf{y}_t}$ 和 $\mathbf{h}_{t-1}^{\text{dec}}$。

动作： 这里分两头行动：

输入门 $i_t$： 再次经过一个 Sigmoid 函数，产生 0 到 1 的值，决定我们有多希望把新信息存进去。

候选记忆 $\tilde{\mathbf{c}}_t$： 经过一个 tanh 激活函数，产生 -1 到 1 的值，这代表从当前输入中提取出的全部潜在新知识。

意义： 这两步结合，就是要把提炼出的新知识（$\tilde{\mathbf{c}}_t$）按照我们的渴望程度（$i_t$）进行打包，准备放到传送带上。

状态更新 (Cell State Update)

参与者： 旧记忆 $\mathbf{c}_{t-1}^{\text{dec}}$，遗忘门 $f_t$，输入门 $i_t$，候选记忆 $\tilde{\mathbf{c}}_t$。

动作： 纯粹的数学运算。首先用旧记忆乘以遗忘门：$f_t * \mathbf{c}_{t-1}^{\text{dec}}$ （执行“丢弃”动作）；然后加上新的包裹：$i_t * \tilde{\mathbf{c}}_t$ （执行“装载”动作）。

产出： 我们得到了当前时刻的全新细胞状态 $\mathbf{c}_t^{\text{dec}}$。

意义： 长期记忆的传送带在这里完成了向前推进，旧的糟粕被剔除，新的信息被注入。这就是 LSTM 能够跨越长距离保持梯度的核心。

输出门与隐藏状态 (Output Gate & Hidden State)

参与者： $\overline{\mathbf{y}_t}$，$\mathbf{h}_{t-1}^{\text{dec}}$，以及刚刚出炉的新细胞状态 $\mathbf{c}_t^{\text{dec}}$。

动作：

用 $\overline{\mathbf{y}_t}$ 和 $\mathbf{h}_{t-1}^{\text{dec}}$ 经过 Sigmoid 算出一个输出门 $o_t$（决定展示的比例）。

把刚刚做好的新细胞状态 $\mathbf{c}_t^{\text{dec}}$ 用 tanh 函数“压”到 -1 到 1 之间。

两者相乘：$\mathbf{h}_t^{\text{dec}} = o_t * \tanh(\mathbf{c}_t^{\text{dec}})$。

产出： 我们得到了当前时刻的全新隐藏状态 $\mathbf{h}_t^{\text{dec}}$。

意义： 细胞状态 $\mathbf{c}_t$ 包含的信息太庞杂了（有些可能是给未来留的伏笔），我们不能全部暴露。输出门 $o_t$ 就像一个滤网，只把当前这一步预测下一个词最需要的那部分特征提取出来，作为对外的公开展示（$\mathbf{h}_t$）。

We then use $\mathbf{h}_t^{\text{dec}}$ to compute multiplicative attention over $\mathbf{h}_1^{\text{enc}}, \dots, \mathbf{h}_m^{\text{enc}}$:

$$ \mathbf{e}_{t,i} = (\mathbf{h}_t^{\text{dec}})^T \mathbf{W}_{\text{attProj}} \mathbf{h}_i^{\text{enc}} \quad \text{where} \quad \mathbf{e}_t \in \mathbb{R}^{m \times 1}, \mathbf{W}_{\text{attProj}} \in \mathbb{R}^{h \times 2h} \quad 1 \leq i \leq m \quad (6) $$

$\mathbf{e}_{t,i}$ is a scalar, the $i$ th element of $\mathbf{e}_t \in \mathbb{R}^{m \times 1}$, computed using the hidden state of the decoder at the $t$ th step, $\mathbf{h}_t^{\text{dec}} \in \mathbb{R}^{h \times 1}$, the attention projection $\mathbf{W}_{\text{attProj}} \in \mathbb{R}^{h \times 2h}$, and the hidden state of the encoder at the $i$ th step, $\mathbf{h}_i^{\text{enc}} \in \mathbb{R}^{2h \times 1}$.

公式(6)是注意力机制的Scoring，解码器现在的状态是 $\mathbf{h}_t^{\text{dec}}$，它需要和字典里的每一个词 $\mathbf{h}_i^{\text{enc}}$进行比对，看看有多匹配。

$(\mathbf{h}_t^{\text{dec}})^T$ , $\mathbf{W}_{\text{attProj}}$ , $\mathbf{h}_i^{\text{enc}}$ 这三者相乘后维度为 $1\times 1$ ，即Scoring出的标量 $\mathbf{e}_{t,i}$ ，它代表了在生成第 $t$ 个翻译词时，源语言句子中第 $i$ 个词的重要程度。我们把对所有 $m$ 个词的打分收集起来，就得到了一个长度为 $m$ 的得分向量 $\mathbf{e}_t$ 。

$$ \alpha_t = \text{softmax}(\mathbf{e}_t) \quad \text{where} \quad \alpha_t \in \mathbb{R}^{m \times 1} \quad (7) $$

为了把公式 (6) 的得分变成标准的“注意力分配比例”，公式 (7) 引入了 softmax 函数。它把向量 $\mathbf{e}_t$ 里的所有数字全部转换为 $0$ 到 $1$ 之间的正数，并且保证它们的总和严格等于 $1$。转换后的结果就是 $\alpha_t$（被称为注意力分布 Attention Distribution）。

$$ \mathbf{a}_t = \sum_{i=1}^m \alpha_{t,i} \mathbf{h}_i^{\text{enc}} \quad \text{where} \quad \mathbf{a}_t \in \mathbb{R}^{2h \times 1} \quad (8) $$

公式 (8) 用刚算出来的注意力百分比 $\alpha_{t,i}$，去对字典里的词 $\mathbf{h}_i^{\text{enc}}$ 进行加权求和。把这 $m$ 个按比例缩放的向量全部加起来，我们就得到了最终的注意力输出向量（Attention Output / Context Vector），记作 $\mathbf{a}_t$。由于被加和的 $\mathbf{h}_i^{\text{enc}}$ 都是 $2h \times 1$ 维的，所以最终得到的 $\mathbf{a}_t$ 也是 $2h \times 1$ 维。

We now concatenate the attention output $\mathbf{a}_t$ with the decoder hidden state $\mathbf{h}_t^{\text{dec}}$ and pass this through a linear layer, tanh, and dropout to attain the combined-output vector $\mathbf{o}_t$.

$$ \mathbf{u}_t = [\mathbf{a}_t ; \mathbf{h}_t^{\text{dec}}] \quad \text{where} \quad \mathbf{u}_t \in \mathbb{R}^{3h \times 1} \quad (9) $$

将注意力输出向量和解码器隐藏状态结合，得到维度为 $3h\times 1$ 的 $u_t$

$$ \mathbf{v}_t = \mathbf{W}_u \mathbf{u}_t \quad \text{where} \quad \mathbf{v}_t \in \mathbb{R}^{h \times 1}, \mathbf{W}_u \in \mathbb{R}^{h \times 3h} \quad (10) $$

加入了一个线性投影矩阵 $\mathbf{W}_u$（维度是 $h \times 3h$ ，当它和 $\mathbf{u}_t$ 相乘时，把维度压缩回了标准尺寸 $h \times 1$

$$ \mathbf{o}_t = \text{dropout}(\tanh(\mathbf{v}_t)) \quad \text{where} \quad \mathbf{o}_t \in \mathbb{R}^{h \times 1} \quad (11) $$

首先给它套上一个 tanh 激活函数，将其内部的数值平滑地压缩到 -1 到 1 之间，这赋予了模型非线性的表达能力。紧接着，再让它穿过一层 dropout。dropout 是一种防止模型过拟合的正则化技术，它在训练时会随机屏蔽掉一部分神经元，逼迫模型学到更鲁棒、更泛化的特征。

最后得到联合输出向量(combined-output vector) $\mathbf{o}_t$

Then, we produce a probability distribution $\mathbf{P}_t$ over target subwords at the $t^{th}$ timestep:

$$ \mathbf{P}_t = \text{softmax}(\mathbf{W}_{\text{vocab}}\mathbf{o}_t) \quad \text{where} \quad \mathbf{P}_t \in \mathbb{R}^{V_t \times 1}, \mathbf{W}_{\text{vocab}} \in \mathbb{R}^{V_t \times h} \quad (12) $$

我们要把一个 $h$ 维的向量，变成目标语言词典里的一个具体词汇。我们的目标语言词典（Vocabulary）里一共有 $V_t$ 个单词。公式 (12) 引入了一个最终的变换矩阵 $\mathbf{W}_{\text{vocab}}$，它的维度是 $V_t \times h$。相乘后输出一个 $[V_t \times 1]$ 的列向量。这个向量里的每一个数字，就代表了模型对词典里对应单词的“打分”（Logits）。

Here, $V_t$ is the size of the target vocabulary. Finally, to train the network we then compute the cross entropy loss between $\mathbf{P}_t$ and $\mathbf{g}_t$, where $\mathbf{g}_t$ is the one-hot vector of the target subword at timestep $t$:

$$ J_t(\theta) = \text{CrossEntropy}(\mathbf{P}_t, \mathbf{g}_t) \quad (13) $$

训练过程使用了交叉熵损失 (Cross Entropy Loss) 函数。简单来说，交叉熵会去对比 $\mathbf{P}_t$ 和 $\mathbf{g}_t$ (one-hot vector)之间的差距。计算出损失 $J_t(\theta)$ 之后，在接下来的代码实现中，模型就会利用反向传播机制，顺着网络一路往回找，去微调那些导致错误的参数 $\theta$。

Implementation and written questions

`init()`

在问题 (c) 的nmt_model.py的__inti__()中，关于神经网络各层的定义，其中self.att_projection的定义需注意，虽然它对应的是 $W_{attProj}$ ，但是在编写代码时，要拆解结合律，决定计算顺序。

应该先算$\mathbf{W}_{\text{attProj}} $ 和 $\mathbf{h}_i^{\text{enc}}$ 相乘，再将其乘积与 $(\mathbf{h}_t^{dec})^T$ 相乘求最终结果，这是因为所有的编码器状态 $\mathbf{h}_i^{\text{enc}}$ 在 Decoder 开始工作前就已经全部计算好了。你可以一次性把整句话的 $\mathbf{h}^{\text{enc}}$ 丢进 Linear 层进行投影（这叫 Pre-computation 预计算）。但是在某一时刻只有一个 $\mathbf{h}_t^{dec}$ 而没有未来的量，导致不能一次性投影完成，而只能把线性层放到了循环中，引发严重的性能问题（虽然数学原理上没错）。下面是一个例子(generated by Gemini) :

假设我们的模型参数如下：

隐藏层大小 $h = 512$

句子长度 $m = 50$

把 Linear 层塞进循环里

在这个路线里，Linear 层每次要干的活是：把解码器 $1 \times 512$ 的向量，乘以一个 $512 \times 1024$ 的巨大投影矩阵 $\mathbf{W}$。

计算量：这需要进行 $512 \times 1024 = \mathbf{524,288}$ 次乘加运算！

额外开销：每次循环，PyTorch 都要去内存里把这个包含 50 多万个参数的 $\mathbf{W}$ 矩阵重新搬出来读一遍，并且要经过一层完整的 nn.Linear 封装代码（包含各种维度检查、梯度跟踪的准备）。

然后，算出投影结果后，还得再去和字典做点积：$1 \times 1024$ 的向量乘以 $1024 \times 50$ 的字典，又是 $\mathbf{51,200}$ 次运算。

所以在这个路线下，解码器每走一步，都要背着将近 60万次运算 和一个巨大的矩阵跑。

预计算 + 循环内纯点积

我们把庞大的 Linear 投影放在循环外面，利用 GPU 的超级并行能力，**“一瞬间”**把整本字典从 $50 \times 1024$ 压成了 $50 \times 512$。我们把这本新字典称为 “投影后字典”。

现在我们进入了 for 循环。在第 $t$ 步，我们需要做的乘法是什么呢？

计算量：我们直接拿解码器原生的 $1 \times 512$ 向量，去乘以准备好的“投影后字典”（$512 \times 50$）。只需要进行 $512 \times 50 = \mathbf{25,600}$ 次乘加运算！

没有额外的层开销：这里不需要调用 nn.Linear，我们在代码里只要写一个极其轻量的纯矩阵乘法指令（比如 torch.matmul 或 @ 符号）就搞定了。不需要加载任何权重矩阵，因为权重矩阵的任务在循环外已经完成了！

`encode`

问题 (d) 是encoder部分，以及对decoder部分的初始化：

1

self.model_embeddings = ModelEmbeddings(embed_size, vocab)

self.model_embeddings是对ModelEmbeddings的一个实例化，而回到问题 (a) 发现.source是一个nn.Embedding对象：

1
2


self.source = nn.Embedding(num_embeddings=len(vocab.src),embedding_dim=self.embed_size,
 padding_idx=src_pad_token_idx)

但是在问题 (a) 中只是对它的实例化，在内存中申请了一个形状为 (num_embeddings, embedding_dim) 的大矩阵。

1

X = self.model_embeddings.source(source_padded)

又因为 nn.Embedding 继承自 nn.Module，而 nn.Module 重写了 __call__ 方法，所以你可以像函数一样使用它（调用），参数设为source_padded这样一个Tensor，它把 Tensor 里的每一个数字当成“行号”，去刚才创建的那个大矩阵里把对应的行找出来，然后输出包含词向量的 Tensor。

下面在将Tensor送进Encoder之前，要用torch.permute变换形状，从(src_len, b, e)变到(b, e, src_len)。那么torch.permute的参数，只是参数位置（索引号）。如下，将原来索引为1的b放到第0个位置，原来索引为2的放到第1个位置，原来索引为0的放到第2个位置。

1

X = X.permute(1, 2, 0)

之后将Tensor X送进LSTM的Encoder后，得到输出：

1
2

output,(last_hidden,last_cell) = self.encoder(X)

output对应的就是双向LSTM的全局上下文向量： $\mathbf{h}_1^{\text{enc}}, \ldots, \mathbf{h}_m^{\text{enc}}$

last_hidden对应的是：$\overrightarrow{\mathbf{h}_m^{\text{enc}}}$ 和 $\overleftarrow{\mathbf{h}_1^{\text{enc}}}$ ，它的形状是 (num_layers * num_directions, batch_size, hidden_size) ，由于它是双向的，所以索引0和索引1分别对应，我们需要将其分离再拼接，形成我们需要的$\overleftarrow{\mathbf{h}_1^{\text{enc}}} ; \overrightarrow{\mathbf{h}_m^{\text{enc}}}$ 。注意torch.cat的参数dim=1表示为横向拼接，即拼接好的向量的列数变成了2 * hidden_size

与投影矩阵相乘的部分，由实例化好的线性层self.h_projection完成。

1

init_decoder_hidden = self.h_projection(torch.cat((last_hidden[0],last_hidden[1]),dim=1))

last_cell同理，不再赘述。

`decode`

问题 (e) 是decode部分： enc_hiddens_proj = self.att_projection(enc_hiddens) 对应公式 (6) 中 $\mathbf{W}_{\text{attProj}} \mathbf{h}_i^{\text{enc}}$ 的部分。正如在 __init__() 部分讨论的，编码器的全部隐藏状态在进入 decode 时已经固定，所以可以在循环外一次性完成投影预计算，将 enc_hiddens 从 (b, src_len, 2h) 投影为 (b, src_len, h)。

Y = self.model_embeddings.target(target_padded) 和 encode 中对源语言做查表的操作对称，这里调用目标语言的嵌入矩阵，将 target_padded 中的词索引映射成词向量，得到形状为 (tgt_len, b, e) 的张量 Y。

torch.split(Y, 1) 沿第 0 维（时间维度）将 Y 切成一系列 (1, b, e) 的张量。squeeze(Y_t, 0) 去掉多余的维度变为 (b, e)。注意必须指定 dim=0，否则当 batch_size = 1 时会误删 batch 维度。

torch.cat((Y_t, o_prev), dim=1) 对应前文的拼接操作：将 $\mathbf{y}_t$（维度 $e$）与 $\mathbf{o}_{t-1}$（维度 $h$）拼接为 $\overline{\mathbf{y}_t} \in \mathbb{R}^{(e+h)}$。

self.step(...) 内部一次性完成公式 (5)-(11) 的计算：Decoder LSTM 前向传播 → 注意力评分与分布 → 加权求和得到上下文向量 → 线性投影、tanh、dropout，最终产出联合输出向量 $\mathbf{o}_t$。每步将 $\mathbf{o}_t$ 存入列表并更新 o_prev。

torch.stack(combined_outputs, dim=0) 将列表中所有 (b, h) 的张量堆叠为 (tgt_len, b, h)，随后送入公式 (12) 的词汇投影层生成概率分布。

`step`

问题 (f) 是step部分，即解码器单步计算，内部完成公式 (5)-(11)。核心代码分两段：

第一段（~3行）：Decoder LSTM 前向 + 注意力评分

1
2
3


dec_state = self.decoder(Ybar_t, dec_state)
dec_hidden, dec_cell = dec_state
e_t = torch.bmm(enc_hiddens_proj, torch.unsqueeze(dec_hidden, 2)).squeeze(2)

前两行直接对应公式 (5)：将 $\overline{\mathbf{y}_t}$ 和上一步状态送入 Decoder LSTM，得到新的 dec_state，再拆分为 dec_hidden（$\mathbf{h}_t^{\text{dec}}$）和 dec_cell（$\mathbf{c}_t^{\text{dec}}$），形状均为 (b, h)。

第三行对应公式 (6) 中的注意力评分。这里的关键在于 torch.bmm 的形状要求——它执行批量矩阵乘法，要求输入严格为三维张量 (b, n, m) × (b, m, p) → (b, n, p)。而我们手里的张量：

enc_hiddens_proj：形状 (b, src_len, h) — 已经是三维，无需处理
dec_hidden：形状 (b, h) — 只有二维，不满足 bmm 的要求

所以需要 torch.unsqueeze(dec_hidden, 2) 在第 2 维（最后）插入一个维度，将 (b, h) 变为 (b, h, 1)。这样 bmm 的乘法就变成了：

$$\underbrace{(b, \text{src\_len}, h)}_{\text{enc\_hiddens\_proj}} \times \underbrace{(b, h, 1)}_{\text{dec\_hidden}} = \underbrace{(b, \text{src\_len}, 1)}_{e_t}$$

这实质上就是对 batch 内的每一条样本，让 enc_hiddens_proj 的每一行（某个源词的投影）与 dec_hidden 做点积，得到该源词的注意力分数——正是公式 (6) 的 $(\mathbf{h}_t^{\text{dec}})^T \mathbf{W}_{\text{attProj}} \mathbf{h}_i^{\text{enc}}$。

最后 .squeeze(2) 去掉末尾多余的维度 1，从 (b, src_len, 1) 变回 (b, src_len)，得到注意力得分向量 $\mathbf{e}_t$。

第二段（~6行）：注意力加权 → 联合输出

1
2
3
4
5


alpha_t = F.softmax(e_t, dim=1)
a_t = torch.bmm(torch.unsqueeze(alpha_t, 1), enc_hiddens).squeeze(1)
U_t = torch.cat((a_t, dec_hidden), dim=1)
V_t = self.combined_output_projection(U_t)
O_t = self.dropout(torch.tanh(V_t))

F.softmax(e_t, dim=1) 对应公式 (7)，沿 dim=1（即 src_len 维度）做 softmax，将分数归一化为注意力分布 $\alpha_t$，形状仍为 (b, src_len)。

计算上下文向量 $\mathbf{a}_t$（公式 (8)）时又遇到了 bmm 的三维要求。alpha_t 是 (b, src_len)，需要 unsqueeze(alpha_t, 1) 在第 1 维插入，变为 (b, 1, src_len)：

$$\underbrace{(b, 1, \text{src_len})}_{\alpha_t} \times \underbrace{(b, \text{src_len}, 2h)}_{\text{enc_hiddens}} = \underbrace{(b, 1, 2h)}_{a_t}$$

这就是用注意力权重对编码器隐藏状态做加权求和。.squeeze(1) 去掉中间的 1，得到 (b, 2h) 的上下文向量 $\mathbf{a}_t$。

后三行依次对应公式 (9)(10)(11)：torch.cat 拼接 $\mathbf{a}_t$ 与 $\mathbf{h}_t^{\text{dec}}$ 得到 (b, 3h) 的 $\mathbf{u}_t$；线性层投影回 (b, h) 的 $\mathbf{v}_t$；最后 tanh + dropout 得到联合输出 $\mathbf{o}_t$。

Attention Masking

问题 (g) 是关于 step() 中注意力掩码的作用。在 step() 的两段代码之间，有这样一段：

1
2


if enc_masks is not None:
 e_t.data.masked_fill_(enc_masks.bool(), -float('inf'))

enc_masks 由 generate_sent_masks() 生成：它创建一个 (b, src_len) 的零矩阵，然后对 batch 中每条句子，在其实际长度之后的位置全部填 1。换言之，1 标记的是 <pad> token 的位置，0 标记的是真实词的位置。

掩码对注意力计算的影响： masked_fill_ 将 $\mathbf{e}_t$ 中所有对应 <pad> 位置的注意力分数替换为 $-\infty$。当这些 $-\infty$ 的值随后经过 softmax 时，$e^{-\infty} = 0$，因此 <pad> 位置的注意力权重 $\alpha_{t,i}$ 会变为 $0$，而所有真实词的权重之和仍归一化为 $1$。这意味着在公式 (8) 的加权求和中，<pad> 位置的编码器隐藏状态对上下文向量 $\mathbf{a}_t$ 完全没有贡献。

为什么必须这样做： 由于 batch 内各句子长度不一，短句会被 <pad> 填充到统一长度。如果不加掩码，<pad> 对应位置的编码器隐藏状态（本质上是无意义的噪声）会分走一部分注意力权重，从而污染上下文向量，导致翻译质量下降。

Training

问题 (h) 是在代码工作完成后，进入训练阶段。由于我没有海外支付方式，用不了cs224n指定的Google Cloud，所以使用本机显卡进行训练（速度快于文档的预估值）

1

bash run.sh train

观察tensorboard可见loss曲线并无异常，待训练完成后进行测试评估：

1

bash run.sh test

结果：the model’s corpus BLEU Score is larger than 18, tests passed.

Attention Comparison

最后问题 (i) 是点积注意力、加性注意力分别与乘性注意力进行比较：

Dot Product vs. Multiplicative

Dot Product Attention: $\mathbf{e}_{t,i} = \mathbf{s}_t^T \mathbf{h}_i$
Multiplicative Attention: $\mathbf{e}_{t,i} = \mathbf{s}_t^T \mathbf{W} \mathbf{h}_i$

点积注意力的优势：

计算速度更快，显存占用更小。 点积注意力没有任何可学习的权重矩阵 $\mathbf{W}$，它仅仅是两个向量的内积。在 GPU 上，这种纯粹的向量点积运算被优化到了极致，没有任何额外的内存开销和参数更新负担。

点积注意力的劣势：

强制要求维度严格一致，且表达能力较弱。 要做点积，解码器状态 $\mathbf{s}_t$ 和编码器状态 $\mathbf{h}_i$ 的维度必须完全相同。更致命的是，它假设这两个空间天然就是对齐的。而乘性注意力多了一个矩阵 $\mathbf{W}$，不仅允许两者的维度不同（$\mathbf{W}$ 可以做维度转换），还能通过学习 $\mathbf{W}$ 将它们投影到一个更好的共享特征空间中再进行比较。

Additive vs. Multiplicative

Additive Attention: $\mathbf{e}_{t,i} = \mathbf{v}^T \tanh(\mathbf{W}_1 \mathbf{h}_i + \mathbf{W}_2 \mathbf{s}_t)$
Multiplicative Attention: $\mathbf{e}_{t,i} = \mathbf{s}_t^T \mathbf{W} \mathbf{h}_i$

(注：Additive Attention 也就是大名鼎鼎的 Bahdanau Attention，它是 Attention 机制的开山鼻祖；而 Multiplicative 则是 Luong Attention 的核心。)

加性注意力的优势：

在特征维度很大时，表现通常更好（模型容量大）。 乘性注意力在维度很大时，点积的结果方差会变得极其巨大，容易把 Softmax 推向梯度消失的边缘（也就是后来 Transformer 引入缩放因子的原因）。而加性注意力通过 $\tanh$ 激活函数将内部数值稳稳地压制在 $[-1, 1]$ 之间，天然具有极好的数值稳定性，对超大维度的宽容度更高。

加性注意力的劣势：

计算效率较低，难以发挥底层矩阵乘法的极致加速。 乘性注意力可以极其优雅地打包成一个巨大的矩阵乘法（在 Transformer 里就是 $\mathbf{Q}\mathbf{K}^T$），这正是现代 GPU 最擅长的事情。而加性注意力不仅要做两次独立的线性变换，还要过一遍非线性激活函数 $\tanh$，最后再乘一个向量 $\mathbf{v}$。这种复杂的计算图打破了矩阵乘法的纯粹性，导致它在实际工程中的运行速度明显慢于乘性注意力。

Analyzing NMT Systems

问题 (a) 是为什么在embedding层后加1D卷积后，再输入双向encoder效果会好一些？

添加一维卷积层可以作为 n-gram 特征提取器，用于捕捉局部组合性。由于中文词语通常由多个词素组成（例如，“电”+“脑”=“电脑”），一维卷积神经网络的滑动窗口会在序列建模之前，将相邻字符/子词的嵌入向量显式地组合成更高层次的语义表示（一个词或短语）。这提供了一种层级结构，其中卷积神经网络处理局部词汇语义（充当软分词器），从而使双向编码器能够专注于学习全局的、长程的句法依存关系。

问题 (b) 是分析四句中文为什么翻译错了，那么作为普通话母语者不难解答：

i. (2 points) Source Sentence: 贼人其后被警方拘捕及被判处盗窃罪名成立。 Reference Translation: the culprits were subsequently arrested and convicted. NMT Translation: the culprit was subsequently arrested and sentenced to theft.

ii. (2 points) Source Sentence: 几乎已经没有地方容纳这些人, 资源已经用尽。 Reference Translation: there is almost no space to accommodate these people, and resources have run out. NMT Translation: the resources have been exhausted and resources have been exhausted.

iii. (2 points) Source Sentence: 当局已经宣布今天是国殇日。 Reference Translation: authorities have announced a national mourning today. NMT Translation: the administration has announced today’s day. NMT Translation: the administration has announced today’s day.

iv. (2 points) Source Sentence: 俗语有云:“唔做唔错”。 Reference Translation: “ act not, err not ”, so a saying goes. NMT Translation: as the saying goes, “ it’s not wrong. ”

(i) 是单/复数的问题，缺少上下文以及整体理解，难以判断“贼人”是复数还是单数。
(ii) “资源已经用尽”被重复翻译了两遍，简单来说是注意力先偏移到了后半句，然后NMT不知道前半句没有翻译，加上前面错译出的"…and"，导致重复翻译后半句。
(iii) src.vocab没有记录“国殇”，所以NMT越过了这个词。
(iv) 本质是句俗语，或者说是粤语，而多数模型都是基于普通话训练的。

BLEU

BLEU score is the most commonly used automatic evaluation metric for NMT systems. It is usually calculated across the entire test set, but here we will consider BLEU defined for a single example. Suppose we have a source sentence s, a set of k reference translations $\mathbf{r}_1,\dots,\mathbf{r}_k$, and a candidate translation c. To compute the BLEU score of c, we first compute the modified n-gram precision pn of c, for each of n = 1,2,3,4, where n is the n in n-gram:

BLEU 分数是 NMT (神经机器翻译) 系统中最常用的自动评估指标。它通常在整个测试集上计算，但在这里我们将考虑为单个示例定义的 BLEU。假设我们有一个源句子 $\mathbf{s}$，一组 $k$ 个参考翻译 $\mathbf{r}_1,\dots,\mathbf{r}_k$，以及一个候选翻译 $\mathbf{c}$。为了计算 $\mathbf{c}$ 的 BLEU 分数，我们首先计算 $\mathbf{c}$ 的修正 n-gram 精确度 (modified n-gram precision) $p_n$，其中 $n = 1, 2, 3, 4$，$n$ 是 n-gram 中的 $n$：

$$ p_n = \frac{\sum_{\text{ngram} \in \mathbf{c}} \min \left( \max_{i=1,\dots,k} \text{Count}_{\mathbf{r}_i}(\text{ngram}), \text{Count}_{\mathbf{c}}(\text{ngram}) \right)}{\sum_{\text{ngram} \in \mathbf{c}} \text{Count}_{\mathbf{c}}(\text{ngram})} $$

Here, for each of the n-grams that appear in the candidate translation c, we count the maxi mum number of times it appears in any one reference translation, capped by the number of times it appears in c (this is the numerator). We divide this by the number of n-grams in c (denominator).

这里，对于出现在候选翻译 $\mathbf{c}$ 中的每一个 $n$-gram，我们计算它在任何一个参考翻译中出现的最大次数，上限为它在 $\mathbf{c}$ 中出现的次数（这是分子）。我们将其除以 $\mathbf{c}$ 中 $n$-gram 的数量（分母）。

$p_n$ 公式的分母部分比较清晰，分子部分我们继续拆解：

$\text{Count}_{\mathbf{c}}(\text{ngram})$ : 该词组在模型输出中出现几次。

$\max_{i=1,\dots,k} \text{Count}_{\mathbf{r}_i}(\text{ngram})$ : 该词组在所有参考答案中出现次数最多的那一次。比如三个参考答案里，the 分别出现了 1、2、1 次，那么这个值就是 2。

$\min(\dots)$ : 这是**截断（Clipping）**机制。它规定：即便你在输出里写了 10 个 the，如果参考答案里最多只出现了 2 个，那我也只算你命中了 2 个。

综上，公式可以被翻译成：
$$ > p_n = \frac{\text{被认可的 n-gram 匹配总数}}{\text{候选翻译中总共生成的 n-gram 数量}} > $$

Next, we compute the brevity penalty BP. Let $len(\mathbf{c})$ be the length of c and let $len(\mathbf{r})$ be the length of the reference translation that is closest to $len(\mathbf{c})$ (in the case of two equally-close reference translation lengths, choose $len(\mathbf{r})$ as the shorter one).

接下来，我们计算长度惩罚 (brevity penalty) $BP$。令 $len(\mathbf{c})$ 为 $\mathbf{c}$ 的长度，令 $len(\mathbf{r})$ 为最接近 $len(\mathbf{c})$ 的参考翻译的长度（在有两个同样接近的参考翻译长度的情况下，选择较短的那个作为 $len(\mathbf{r})$）。

$$ BP = \begin{cases} 1 & \text{if } len(\mathbf{c}) \geq len(\mathbf{r}) \\ \exp\left(1 - \frac{len(\mathbf{r})}{len(\mathbf{c})}\right) & \text{otherwise} \end{cases} $$

那么引入 $BP$ 有什么用？首先 $len(\mathbf{c}) \geq len(\mathbf{r})$ 时 $BP=1$ ，这是在NMT输出较长时，$BP$ 不需要惩罚它，而会在 $p_n$ 的分母体现（分母变大，概率降低）。

$len(\mathbf{c}) < len(\mathbf{r})$ 时引入指数惩罚，如果NMT只翻译最有把握的一个词（比如输出一个单词 apple），$p_n$ 可能是 100%，但这没有意义。这个指数函数 $\exp(1 - r/c)$ 在 $c$ 越小时，值会迅速接近 0，从而给短句一个沉重的打击。

Lastly, the BLEU score for candidate c with respect to $\mathbf{r}_1,\dots,\mathbf{r}_k$ is:

最后，候选 $\mathbf{c}$ 相对于 $\mathbf{r}_1,\dots,\mathbf{r}_k$ 的 BLEU 分数为：

$$ BLEU = BP \times \exp \left( \sum_{n=1}^4 \lambda_n \log p_n \right) $$

本质上等同于：
$$ > BLEU = BP \times (p_1^{\lambda_1} \cdot p_2^{\lambda_2} \cdot p_3^{\lambda_3} \cdot p_4^{\lambda_4}) > $$

where $\lambda_1, \lambda_2, \lambda_3, \lambda_4$ are weights that sum to 1. The log here is natural log.

其中 $\lambda_1, \lambda_2, \lambda_3, \lambda_4$ 是总和为 1 的权重。此处的 $\log$ 是自然对数。

几何平均的一个特性是：如果其中任何一项 $p_n$ 为 0，最终结果就会是 0。所以模型的词汇和语序的正确性都会被计算。

问题 (c) 结合实例运算：

i. Source Sentence s: 需要有充足和可预测的资源。 Reference Translation $r_1$ : resources have to be sufficient and they have to be predictable Reference Translation $r_2$ : adequate and predictable resources are required NMT Translation $c_1$ : there is a need for adequate and predictable resources NMT Translation $c_2$ : resources be sufficient and predictable to Please compute the BLEU scores for and $c_1$ $c_2$. Let $\lambda_i = 0.5$ for $i \in \{1, 2\}$ and $\lambda_i = 0$ for $i \in \{3, 4\}$ (this means we ignore 3-grams and 4-grams, i.e., don’t compute $p_3$ or $p_4$). When computing BLEU scores, show your work (i.e., show your computed values for $p_1$, $p_2$, $len(c)$, $len(r)$ and $BP$). Note that the BLEU scores can be expressed between 0 and 1 or between 0 and 100. The code is using the 0 to 100 scale while in this question we are using the 0 to 1 scale. Please round your responses to 3 decimal places.

先计算 $c_1$ : $len(c_1)=9$ 更接近于 $len(r_1)=11$ , $BP=exp(1-\frac{11}{9})$

$p_1$ 匹配的Unigrams 为 {adequate, and, predictable, resources}，共 4 个。 $p_1=4/9$

$p_2$ 匹配的Bigrams 为 {adequate and, and predictable, predictable resources}，共 3 个。 $p_2=3/8$

$BLEU_{c1} = BP \times \sqrt{p_1 \times p_2}$

$c_2$ 同理。

ii. Our hard drive was corrupted and we lost Reference Translation $r_1$. Please recom pute BLEU scores for $c_1$ and $c_2$, this time with respect to $r_2$ only. Which of the two NMT translations now receives the higher BLEU score? Do you agree that it is the better translation?

计算方式不变，但是在去掉了 $r_1$ 后， ${BLEU}_{c_1}$ 不变， ${BLEU}_{c_2}$ 大幅缩小（由于 $p_1$ 和 $p_2$ 下降）

这说明了 $c_1$ 的鲁棒性更强，它使用了更通用的词汇（如 adequate），即使在参考答案有限的情况下，依然能保持较合理的得分，这更符合人类对“好翻译”的评价标准。

iv. List two advantages and two disadvantages of BLEU, compared to human evaluation, as an evaluation metric for Machine Translation.

优点不列了，缺点：BLEU 仅进行字面上的 N-gram 匹配，缺乏语义理解。由于 BLEU 主要关注局部词汇的重合度，它往往无法识别严重的语法错误或逻辑扭曲。一个逻辑完全相反、但在词汇上高度重合的句子可能获得极高的 BLEU 分，却无法被人类理解，所以它无法准确衡量语言质量。

问题 (d) 是Beam Search相关的，关于训练次数与其“假设”质量的问题，比如i. 要求进行三个对比：

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


// iteration 200
{
 "hypothesis": [
 "▁it",
 "▁is",
 "▁not",
 "▁that",
 "▁the",
 "▁united",
 "▁nations",
 "▁of",
 "▁the",
 "▁united",
 "▁nations",
 "▁of",
 "▁the",
 "▁united",
 "▁nations",
 "."
 ],
 "score": -31.211565017700195
 }

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


// iteration 3000
{
 "hypothesis": [
 "▁i",
 "▁would",
 "▁also",
 "▁like",
 "▁to",
 "▁clarify",
 "▁the",
 "▁number",
 "▁of",
 "▁cases",
 "▁in",
 "▁the",
 "▁conference",
 "."
 ],
 "score": -15.013087272644043
 }

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


// iteration 17200 (last)
{
 "hypothesis": [
 "▁i",
 "▁have",
 "▁also",
 "▁clarified",
 "▁a",
 "▁number",
 "▁of",
 "▁matters",
 "▁raised",
 "▁by",
 "▁the",
 "▁conference",
 "."
 ],
 "score": -7.69414758682251
 }

群晖NAS代理及Emby配置

Mon, 16 Feb 2026 11:12:15 +0800

近日笔者在使用群晖NAS的v2rayA时遇到了时间同步不正确导致的无法正常使用的问题，导致emby无法刮削。虽然不知道原因，但也是个老问题了，版本很旧，而且用的是第三方软件市场的docker，现在docker也不能裸连获取了。下面是解决经验：

重新安装v2rayA
配置docker版的emby。

参考网站：

Linux 后备安装方式 - v2rayA

XTLS/Xray-core: Xray, Penetrates Everything. Also the best v2ray-core. Where the magic happens. An open platform for various uses.

群晖实现透明代理 - v2rayA

sjtuross/syno-iptables: Some missing iptables modules for Synology

群晖 DSM 7.2 为 Container Manager（docker）设置代理_群晖docker设置代理-CSDN博客

v2rayA

由v2rayA的官方文档可见，群晖并没有特别适配的版本，所以采用通用的二进制文件进行安装。既然裸连也无法从github上拉取文件，我们在电脑上下好传到NAS上。此外，下面的安装内容实则和文档略有不同。

拷贝v2rayA和xray

1
2
3
4


cp v2raya_linux_x64 /usr/local/bin/v2raya
cp xray /usr/local/bin/
chmod +x /usr/local/bin/v2raya
chmod +x /usr/local/bin/xray

拷贝xray自带的GFWList代理规则文件：geoip.dat和geosite.dat
1 2 3

cd /usr/local/share mkdir xray cp .../g* xray

修改service配置文件

1

sudo vi /etc/systemd/system/v2raya.service

内容由ChatGPT结合官方文档生成：

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


[Unit]
Description=v2rayA Service
After=network.target

[Service]
Type=simple
User=root
Environment="V2RAYA_CONFIG=/usr/local/etc/v2raya"
Environment="V2RAYA_LOG_FILE=/tmp/v2raya.log"
Environment="XRAY_LOCATION_ASSET=/usr/local/share/xray"
ExecStart=/usr/local/bin/v2raya --passcheckroot
Restart=on-failure
LimitNOFILE=1000000

[Install]
WantedBy=multi-user.target

激活v2rayA，根据官方文档，采用服务的形式运行
1 2

sudo systemctl start v2raya sudo systemctl status v2raya
配置开机自启。理论上这步之后配置完毕，笔者又顺便解决了群晖用不了透明代理的问题
1 2

sudo systemctl enable v2raya sudo systemctl is-enabled v2raya

激活透明代理

arch	kernel	iptables version	system model	platform version
apollolake	4.4.180+	v1.8.3	DS918+	7.0.1-42218
apollolake	4.4.59+	v1.6.0	DS918+	6.2.3-25426
broadwell	3.10.105	v1.6.0	DS3617xs	6.2.3-25426
bromolow	3.10.105	v1.6.0	DS3615xs	6.2.3-25426
geminilake	4.4.180+	v1.8.3	DS920+	7.1-42661
geminilake	4.4.302+	v1.8.3	DS220+	7.2-64570

由于群晖系统的原因，先根据型号确定架构，然后从github仓库中下好的模块中选出适配机器的文件（比如笔者的DS224是geminilake）

上传相应的ko模块至/lib/modules/，上传相应的so模块至/usr/lib/iptables/，即可。

运行sudo -i之后再运行以下insmod命令尝试加载ko内核模块。由于模块互相有依赖性，需按一定顺序加载

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


insmod /lib/modules/nfnetlink.ko
insmod /lib/modules/ip_set.ko
insmod /lib/modules/ip_set_hash_ip.ko
insmod /lib/modules/xt_set.ko
insmod /lib/modules/ip_set_hash_net.ko
insmod /lib/modules/xt_mark.ko
insmod /lib/modules/xt_connmark.ko
insmod /lib/modules/xt_comment.ko
insmod /lib/modules/xt_TPROXY.ko
insmod /lib/modules/xt_socket.ko
insmod /lib/modules/iptable_mangle.ko
insmod /lib/modules/textsearch.ko
insmod /lib/modules/ts_bm.ko
insmod /lib/modules/xt_string.ko

insmod /lib/modules/nf_nat_ipv6.ko
insmod /lib/modules/nf_nat_masquerade_ipv6.ko
insmod /lib/modules/ip6t_MASQUERADE.ko
insmod /lib/modules/ip6table_nat.ko
insmod /lib/modules/ip6table_raw.ko
insmod /lib/modules/ip6table_mangle.ko

但是系统重启后，模块需要重新加载，所以用以上内容生成脚本在/usr/local/bin/load_v2raya_mods.sh

然后重启v2rayA服务:

1

sudo systemctl restart v2raya

Emby

在配置好v2rayA后，即使采用了改配置文件的办法，emby的流量仍不能成功地通过v2rayA来走，各种修改配置ip后无果，于是自然想到是docker变成本机服务导致的。

在v2rayA上多次修改配置后，终于发现开启透明代理解决问题，同时也解决了连接不上Docker仓库的问题，但更大的问题是启用透明代理会使外网访问全部失败（亏好内网还能连接）。“透明代理”我想可以理解为“全局代理”。

Docker(Container Manager)单独设置代理的问题详见前言链接。

在“映像”中选中emby并运行，在“存储空间设置”中加入媒体库的路径，在“环境”中加入三个环境变量，“网络”中选择host模式：
1 2 3

HTTP_PROXY = http://127.0.0.1:20171 HTTPS_PROXY = http://127.0.0.1:20171 NO_PROXY = localhost,127.0.0.1
完成基本设置，安装好之前的动漫相关的插件，刮削成功。

如何在WSL2上使用本机代理

Fri, 30 Jan 2026 16:31:20 +0800

由于近日笔者经常用Python下载各种模型，终要解决困扰已久的wsl2与Windows主机代理不互通的问题。笔者浪费了半个下午后终于搞定，在得力助手Gemini的帮助下，主要步骤如下：

Windows的.wslconfig设置
v2rayN的核心设置
Windows的防火墙设置
wsl2的旧设置清理
wsl2的~/.bashrc设置
wsl2的curl -v测试

参考网站：

Advanced settings configuration in WSL | Microsoft Learn

WSL2 使用 V2RayN 局域网 proxychains 代理方案 · Issue #2653 · 2dust/v2rayN

记一次用wsl2中共享宿主机的代理-v2rayN - 沉迷于学习，无法自拔^_^

.wslconfig

访问Windows下的个人账户文件夹，按下 Win + R，输入 %UserProfile% 并回车
检查是否有 .wslconfig 文件。如果没有，新建一个文本文件并命名为 .wslconfig
将以下内容粘贴到.wslconfig中：
1 2 3 4 5

[wsl2] # 开启镜像网络模式 networkingMode=mirrored # 自动同步代理设置（可选true/false） autoProxy=true
需注意的是：autoProxy这个参数决定了wsl2代理的方式，设置为true可以不再配置~/.bashrc，但是问题在于：
1. 当我们使用env | grep -i proxy命令，会看到很多奇怪的和网络有关的变量，虽然确实能成功实现代理。
不能在wsl2中开关代理，导致很多流量都通过代理来走

后面我们将其设置为false，以便于在wsl2内部可以方便地控制代理的开关，保证wsl2系统的清晰透明。
在Windows终端中输入wsl --shutdown关闭wsl2

v2rayN

在v2rayN（撰文时版本为V7.15.7）的基础设置中，启用“允许来自局域网的连接”以及“为局域网开启新的端口”（可选）
在v2rayN客户端的主界面左下角能看到为互联网开放的端口，笔者这里是10810
这里系统代理是“自动配置系统代理”，路由模式是“绕过(Whitelist)”
然后选好节点，保持v2rayN的进行

FireWall

在 Windows 搜索框输入“防火墙”，选择 Windows Defender 防火墙
点击 “允许应用或功能通过 Windows Defender 防火墙”。
找到或添加 v2rayN.exe 和其核心程序（如 v2ray.exe 或 xray.exe），确保专用和公用都勾选上。通常路径分别在v2rayN\和v2rayN\bin\xray下
在防火墙高级设置中，新建一个入站规则，允许端口 10810 的 TCP 流量（与v2rayN相对应）

wsl2

清理旧设置

1
2
3
4
5
6
7
8


# 1. 清除旧的、混乱的代理环境变量
unset http_proxy
unset https_proxy
unset no_proxy

# 2. 重新设置正确的代理（指向镜像模式下的本地端口）
export http_proxy="http://127.0.0.1:10810"
export https_proxy="http://127.0.0.1:10810"

确保在第一步已开启镜像网络模式并重启好wsl2。当然这步也不是必须的，因为后面~/.bashrc会自动处理这些就变量。

~/.bashrc

1
2


# 用其它的编辑器同理
sudo vim ~/.bashrc

在与Gemini多次实验后，得出以下内容用于添加到~/.bashrc底部：

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


function proxy_on() {
 # 彻底清理可能残留的变量（防止大小写混用冲突）
 unset http_proxy https_proxy ALL_PROXY NO_PROXY HTTP_PROXY HTTPS_PROXY all_proxy no_proxy
 
 # 设置你验证成功的端口（既然 10810 测通了，就用 10810）
 export hostip="127.0.0.1"
 export port="10810"
 
 export http_proxy="http://$hostip:$port"
 export https_proxy="http://$hostip:$port"
 export all_proxy="socks5://$hostip:$port"
 
 # 这里的 no_proxy 只保留本地回环
 export no_proxy="localhost,127.0.0.1"
 
 echo "WSL Proxy: ON (127.0.0.1:10810)"
}

function proxy_off() {
 unset http_proxy https_proxy ALL_PROXY NO_PROXY HTTP_PROXY HTTPS_PROXY all_proxy no_proxy
 echo "WSL Proxy: OFF"
}

保存以上内容后，输入：

1

source ~/.bashrc

然后再：

1

curl -I https://www.google.com

应该就会出现以下内容，表示连接成功：

笔者同时也用ping去测试了一下，虽然不成功，但不影响使用。

1

HTTP/1.1 200 Connection established

笔者再次尝试下载模型，果然成功：

1
2


import gensim.downloader as api
wv_from_bin = api.load("glove-wiki-gigaword-200")

再不成功的解决方案

最有效的方法的就是在完成了上面步骤后，wsl2中输入：

1

curl -v https://www.google.com

然后把输出的结果交给AI，它会告诉你的。

CS224N

Wed, 28 Jan 2026 14:31:08 +0800

Intro

本篇是对Stanford CS 224N | Natural Language Processing with Deep Learning (Spring 2024) 这门课程的学习笔记。关于这门课的知识点，总结如下：

词向量、RNN、LSTM、Seq2Seq 模型、机器翻译、注意力机制、Transformer 等等

What is this course about?

Natural language processing (NLP) or computational linguistics is one of the most important technologies of the information age. Applications of NLP are everywhere because people communicate almost everything in language: web search, advertising, emails, customer service, language translation, virtual agents, medical reports, politics, etc. In the 2010s, deep learning (or neural network) approaches obtained very high performance across many different NLP tasks, using single end-to-end neural models that did not require traditional, task-specific feature engineering. In the 2020s amazing further progress was made through the scaling of Large Language Models, such as ChatGPT. In this course, students will gain a thorough introduction to both the basics of Deep Learning for NLP and the latest cutting-edge research on Large Language Models (LLMs). Through lectures, assignments and a final project, students will learn the necessary skills to design, implement, and understand their own neural network models, using the Pytorch framework.

Word Vectors

$ vector(”King”)- vector(”Man”) + vector(”Woman”) $

results in a vector that is closest to the vector representation of the word Queen

How do we have usable meaning in a computer?

Slides里介绍了几种方式：

WordNet
one-hot vectors
word vectors

那么前两种都有其现实意义，但也有明显的弊端。

WordNet，完全靠synonum sets和hypernyms sets来确定词汇间的关系、构造复杂、无法及时吸收新词汇……
one-hot vectors给每个词都设置了symbol，尽管是用数字表达，但是相近的词之间在数学上没有联系（向量的点积为0）

那么下面就引出了一句名言：“You shall know a word by the company it keeps”

以及word vectors的思想，将词汇归一化到一个向量中，虽然每个词汇有多个词义，但其分布却近似是其多个词义的平均，并用点积来确定词向量间的相关性。

Word2vec

original word2vec paper

Word2vec很好地反映了word vectors的思想，计算中心词和相邻词的相似度，确定其概率分布：

We have a large corpus (“body”) of text: a long list of words
Every word in a fixed vocabulary is represented by a vector
Go through each position t in the text, which has a center word c and context (“outside”) words o
Use the similarity of the word vectors for c and o to calculate the probability of o given c (or vice versa)
Keep adjusting the word vectors to maximize this probability

Objective Function

那么如何计算其似然程度(Likelihood)呢，For each position = $t=1,......,T$, predict context words within a window of fixed size $m$, given center word $w_t$. Data likelihood :

$$ L(\theta) = \prod_{t=1}^{T} \prod_{\substack{-m \le j \le m \\ j \neq 0}} P(w_{t+j} \mid w_t; \theta) $$

为减小数据复杂程度，及方便计算机处理，优化上公式，对其进行平均负对数似然操作，The objective function $J(\theta)$ is the (average) negative log likelihood:

$$ J(\theta) = -\frac{1}{T} \log L(\theta) = -\frac{1}{T} \sum_{t=1}^{T} \sum_{substack{-m \le j \le m \\ j \neq 0}} \log P(w_{t+j} \mid w_t; \theta) $$

最小化 $J(\theta)$ 等价于 最大化预测准确率。

Prediction Function

$$ P(o \mid c) = \frac{\exp(u_o^T v_c)}{\sum_{w \in V} \exp(u_w^T v_c)} $$

$u_o^T v_c$ : 点积越大，代表这两个词在向量空间中的位置越接近，即语义相关性越高。 Dot product compares similarity of o and c. $u^T v = u \cdot v = \sum_{i=1}^{n} u_i v_i$ Larger dot product = larger probability.
$\exp()$ : 将任何实数映射为正数。由于指数函数的增长特性，它会放大较大点积的影响，使相关性高的词获得更高的权重。
${\sum_{w \in V} \exp(u_w^T v_c)}$ : 分母是对词汇表$V$中所有可能的词进行求和。这一步确保了所有可能输出的概率之和等于 1，从而构成一个标准的概率分布。

这也是对Softmax Function的应用

$$ \text{softmax}(x_i) = \frac{\exp(x_i)}{\sum_{j=1}^{n} \exp(x_j)} = p_i $$

Softmax 函数将任意值 $x_i$ 映射为一个概率分布 $p_i$。
“max”：因为它会放大最大值 $x_i$ 对应的概率，使大的更大。
“soft”：因为它仍然会给较小的 $x_i$ 分配一些概率。

To Train the Model

To train a model, we gradually adjust parameters to minimize a loss.

$$ \theta = \begin{bmatrix} v_{aardvark} \\ v_a \\ \vdots \\ v_{zebra} \\ u_{aardvark} \\ u_a \\ \vdots \\ u_{zebra} \end{bmatrix} \in \mathbb{R}^{2dV} $$

如果词向量维度为 $d$，词汇量为 $V$，则总参数量为 $2dV$。
每个单词有两个向量，$\theta$ 包含了词汇表中所有单词的两种向量表示（中心词向量 $v$ 和背景词向量 $u$）。
计算所有参数的梯度，以优化模型

梯度公式就是对Softmax Function的求偏导，数学过程如下：

初始损失函数 (单词对的负对数似然) 这是针对一个中心词 $c$ 和一个背景词 $o$ 的基本损失定义：
$$ \text{Loss} = -\log P(o \mid c) $$
代入Softmax定义展开 将 $P(o|c)$ 的公式代入，利用对数性质将除法化为减法：
$$ \text{Loss} = -\log \left( \frac{\exp(u_o^T v_c)}{\sum_{w \in V} \exp(u_w^T v_c)} \right) = -u_o^T v_c + \log \sum_{w \in V} \exp(u_w^T v_c) $$
第一部分求导 对点积项关于中心词向量 $v_c$ 求偏导：
$$ \frac{\partial}{\partial v_c} (u_o^T v_c) = u_o $$
第二部分求导 利用链式法则对 $\log \sum \exp(\dots)$ 形式进行求导：
$$ \frac{\partial}{\partial v_c} \log \sum_{w \in V} \exp(u_w^T v_c) = \frac{1}{\sum_{w \in V} \exp(u_w^T v_c)} \cdot \sum_{x \in V} \left[ \exp(u_x^T v_c) \cdot u_x \right] $$
转化为概率期望形式 将上一步的结果重新组合，提取出原始的概率项 $P(x|c)$：
$$ \sum_{x \in V} \left[ \frac{\exp(u_x^T v_c)}{\sum_{w \in V} \exp(u_w^T v_c)} \right] u_x = \sum_{x \in V} P(x \mid c) u_x $$
最终梯度公式 将两部分合并，得到最终用于更新 $v_c$ 的梯度：
$$ \frac{\partial \text{Loss}}{\partial v_c} = -u_o + \sum_{x \in V} P(x \mid c) u_x $$

Gradient Descent

梯度下降更新方程 (矩阵形式)

$$ \theta^{new} = \theta^{old} - \alpha \nabla_{\theta} J(\theta) $$

梯度下降更新方程 (单个参数形式)

$$ \theta_j^{new} = \theta_j^{old} - \alpha \frac{\partial}{\partial \theta_j^{old}} J(\theta) $$

$\alpha$ (alpha): 步长或学习率（step size / learning rate）。

但是实际应用并非上面的方法，而是用随机梯度下降，(Stochastic Gradient Descent, SGD)

目标函数 $J(\theta)$ 是语料库中所有窗口的函数。如果每次更新都要计算整个语料库的梯度 $\nabla_{\theta} J(\theta)$，计算成本极其昂贵，在进行单次更新前需要等待极长时间。
SGD不再计算整个语料库，而是通过重复采样窗口，每处理一个（或一小批）窗口就更新一次参数。

Skip-gram Model with Negative Sampling

negative sampling paper

$$ P(o\mid c)=\frac{\exp(u_x^T v_c)}{\sum_{w \in V} \exp(u_w^T v_c)} $$

采用最传统的方法计算概率时，即softmax，它的分母是全部词的叠加，计算量太大

而Skip-gram Model with Negative Sampling不需计算所有可能的词，而是训练一些逻辑回归，更偏好实际的上下文而非随机的上下文，实际上会选K个负样本，计算量就变为了$O(K)$

$$ J_{neg-sample}(u_o, v_c, U) = -\log \sigma(u_o^T v_c) - \sum_{k \in \{K \text{ sampled indices}\}} \log \sigma(-u_k^T v_c) $$

其中，$\sigma(x)=\frac{1}{1+e^{-x}}$即sigmoid函数，使符合的结果概率接近于1，而不符合的则接近于0

但这又会导致低频词，如"zebra"的概率过低，而像"the"这样的词则概率较高，所以给公式加上$3/4$次方：

$$ P(W)=U(W)^{3/4}/Z $$

来提高低频词的概率。

GloVe

original GloVe papar (Global Vectors for Word Representation)

Co-occurrence Martix

构建共现矩阵的方法非常简单，首先设定窗口长度，然后对在窗口长度内出现的共现词频率进行计数，一个简单的例子如上图（窗口为1，仅算相邻词）。但是：

词向量维度会随着语料库中词汇的增多而大幅增加，这会导致所需存储空间增大，且矩阵会变得相当稀疏，基于此构建的模型鲁棒性较差；
功能词出现频次极高，但没有提供相应的信息；
没有反映出词距与词相关性之间的联系。

那么如何进行降维来优化？经典的方法是进行SVD矩阵分解（虽然问了AI也没明白原理，而且Assignment1中用一个sklearn的函数就解决了）

$$ X = U \Sigma V^T $$

$X$ (共现矩阵)：大小为 $|V| \times |V|$（词表大小）。每个元素 $X_{ij}$ 代表词 $i$ 和词 $j$ 在语料库中共同出现的次数。
$U$ 和 $V$ (正交矩阵)：它们的列向量是相互正交的单位向量（Orthonormal）。在 NLP 中，$U$ 的每一行通常被视为该词的原始“嵌入”。
$\Sigma$ (对角矩阵)：对角线上的值 $\sigma_1, \sigma_2, \dots$ 称为奇异值。它们按从大到小排列，代表了数据在对应维度上的重要程度（方差/信息量）。

那么降维便是将从共现矩阵得到的的，长度为$V$的词向量降维成长度为$K$的向量

真正编码语义的不是共现概率本身，而是共现概率的比值：

共现概率的比率可以编码语义成分，我们希望将它们作为线性语义成分捕捉在词向量空间中！

	$x = \text{solid}$	$x = \text{gas}$	$x = \text{water}$	$x = \text{fashion}$
$P(x\mid\text{ice})$	$1.9 \times 10^{-4}$	$6.6 \times 10^{-5}$	$3.0 \times 10^{-3}$	$1.7 \times 10^{-5}$
$P(x\mid\text{steam})$	$2.2 \times 10^{-5}$	$7.8 \times 10^{-4}$	$2.2 \times 10^{-3}$	$1.8 \times 10^{-5}$
$\dfrac{P(x\mid\text{ice})}{P(x\mid\text{steam})}$	$8.9$	$8.5 \times 10^{-2}$	$1.36$	$0.96$

Analogies

词向量虽然数学原理上很强大，但是其实际的类比(Analogy)场景却是有不少问题：

下例可见，是一个$woman+grandfather-man=?$的问题，那么显而易见且最有可能的结果就是grandmother，那么为何程序给出的另外几个，如granddaughter, mother之类，score也几乎一样很高呢？

1
2


# Run this cell to answer the analogy -- man : grandfather :: woman : x
pprint.pprint(wv_from_bin.most_similar(positive=['woman', 'grandfather'], negative=['man']))

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


[('grandmother', 0.7608445286750793),
 ('granddaughter', 0.7200808525085449),
 ('daughter', 0.7168302536010742),
 ('mother', 0.7151536345481873),
 ('niece', 0.7005682587623596),
 ('father', 0.6659888029098511),
 ('aunt', 0.6623409390449524),
 ('grandson', 0.6618767976760864),
 ('grandparents', 0.644661009311676),
 ('wife', 0.6445354223251343)]

虽说Assignment里没有标准答案，但是通过AI可以得知：这涉及到“语义聚类”

语义的“近邻效应”
- 在向量空间中，逻辑相似的词通常会聚在一起形成一个“簇”。当你计算出 $\vec{w} + \vec{g} - \vec{m}$ 时，你实际上是在空间中定位了一个坐标点。
- granddaughter 等同样具有“女性”和“亲属”属性，且在语料库中经常与 grandfather 或 grandmother 出现在相似的上下文。在向量维度上，它们在“亲属关系”这个维度上非常接近。
维度的“重叠性”
- 词向量通常有几百个维度。虽然我们减去了 man 并加上了 grandfather，但这并不能完全抹除其他维度的相似性。
- daughter、mother、grandmother 共享了绝大部分维度：[+女性]、[+人类]、[+亲属]。

下面的例子，属于"Incorrect Analogy"，我们来看易得答案为socks，但为何模型忽略了glove和hand，而输出了各种square的名词？显然和foot“脚”的释义无关，而是“英尺”的释义。

1

pprint.pprint(wv_from_bin.most_similar(positive=['foot', 'glove'], negative=['hand']))

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


[('45,000-square', 0.4922032654285431),
 ('15,000-square', 0.4649604558944702),
 ('10,000-square', 0.4544755816459656),
 ('6,000-square', 0.44975775480270386),
 ('3,500-square', 0.444133460521698),
 ('700-square', 0.44257497787475586),
 ('50,000-square', 0.4356396794319153),
 ('3,000-square', 0.43486514687538147),
 ('30,000-square', 0.4330596923828125),
 ('footed', 0.43236875534057617)]

语义多义性的干扰
- 上面也提到，foot也是计量单位”英尺“的英文，和square组合是合理的
训练语料的偏见
- 既然foot有多个释义，但输出却全是其“英尺”的意思，那么这可能体现了用来训练的语料中多是...square和foot相关联
词的选择
- 即使输出全是...square，其score值也不过0.5，这不仅说明模型找不到强相关的词，而且说明了模型很可能没能理解glove与hand, foot的联系

Neural Network

A neural network = running several logistic regressions at the same time.

CS231n Deep Learning on Network Architectures

CS231n Deep Learning for Computer Vision on Backprop

Structure

Non-linearities

为什么神经网络需要非线性(Non-linearities)？

核心观点：神经网络执行函数逼近，例如回归或分类。
- 没有非线性：深度神经网络只能执行线性变换。
- 多层失效：额外的层会被压缩成单个线性变换：$W_1 W_2 x = Wx$（即多层线性层等同于一层）。
- 有了非线性：通过包含非线性的多层结构，网络可以逼近更复杂的函数！

左下侧图对：左图显示线性分类（只能画直线），无法区分复杂的红绿点分布；右图显示非线性分类（可以画曲线），完美分割了数据。
右侧三张波形图：展示了随着函数复杂度的增加，只有非线性模型才能拟合这些起伏的蓝点（观测数据）。

关于常用的非线性函数，在《智能计算系统》课上均有学习，不多赘述

Gradients

derivatives.pdf

梯度，简单地讲就是对变量的微积分，比如我们有：

$$ f(x)=x^3 $$

那么它的梯度就是：

$$ \frac{df}{dx}=3x^2 $$

当然，这只是个非常简单的例子，实际上是大规模的链式法则计算，对矩阵(Jacabian Matrix)进行梯度计算。

Chain Rule

在单变量微积分中，如果 $y = f(u)$ 且 $u = g(x)$，那么：

$$ \frac{dy}{dx} = \frac{dy}{du} \cdot \frac{du}{dx} $$

但在神经网络中，每一层都是一个向量 $\mathbf{h,z} \in \mathbb{R}^n$。当我们将这个逻辑扩展到向量时，乘法就变成了矩阵乘法。

对于多个变量，应与Jacobians矩阵相乘：

假设有 $\mathbf h= f(z)$ 和 $\mathbf z=Wx+b$ ，下面的这些偏导数就是雅可比矩阵

$$ \frac{\partial \mathbf{h}}{\partial \mathbf{x}} = \frac{\partial \mathbf{h}}{\partial \mathbf{z}} \frac{\partial \mathbf{z}}{\partial \mathbf{x}} $$

Matrix Calculus

由下式得，矩阵只有对角元素，其余部分均为0：

$$ \begin{aligned} \left( \frac{\partial \mathbf{h}}{\partial \mathbf{z}} \right)_{ij} &= \frac{\partial h_i}{\partial z_j} = \frac{\partial}{\partial z_j} f(z_i) \quad && \text{definition of Jacobian} \\ &= \begin{cases} f'(z_i) & \text{if } i = j \\ 0 & \text{if otherwise} \end{cases} \quad && \text{regular 1-variable derivative} \end{aligned} $$$$ \frac{\partial \mathbf h}{\partial \mathbf z} = \begin{pmatrix} f'(z_1) & 0 & \cdots & 0 \\ 0 & f'(z_2) & \cdots & 0 \\ \vdots & \vdots & \ddots & \vdots \\ 0 & 0 & \cdots & f'(z_n) \end{pmatrix} = \operatorname{diag}(f'(\mathbf z)) $$

此外，还有一常有的Jacobian：

$$ \frac{\partial}{\partial \mathbf{u}}(\mathbf{u}^T \mathbf{h})=\mathbf h^T $$

假设 $\mathbf{u}$ 和 $\mathbf{h}$ 都是 $n$ 维列向量：

$$ \mathbf{u} = \begin{bmatrix} u_1 \\ u_2 \\ \vdots \\ u_n \end{bmatrix}, \quad \mathbf{h} = \begin{bmatrix} h_1 \\ h_2 \\ \vdots \\ h_n \end{bmatrix} $$

那么它们的内积（也就是括号里的部分）是一个标量：

$$ f = \mathbf{u}^T \mathbf{h} = u_1 h_1 + u_2 h_2 + \dots + u_n h_n = \sum_{i=1}^n u_i h_i $$

我们要对向量 $\mathbf{u}$ 求导。根据 Jacobian Matrix 的定义，我们需要对 $\mathbf{u}$ 中的每一个元素 $u_k$ 分别求导：

$$ \frac{\partial f}{\partial u_k} = \frac{\partial}{\partial u_k} (u_1 h_1 + \dots + u_k h_k + \dots + u_n h_n) $$

由于除了 $u_k h_k$ 这一项外，其他项都不包含 $u_k$，所以它们对 $u_k$ 的导数都是 $0$：

$$ \frac{\partial f}{\partial u_k} = h_k $$

按照 Jacobian 矩阵的惯例，一个标量对一个列向量求导，结果是一个行向量：

$$ \frac{\partial f}{\partial \mathbf{u}} = \begin{bmatrix} \frac{\partial f}{\partial u_1} & \frac{\partial f}{\partial u_2} & \dots & \frac{\partial f}{\partial u_n} \end{bmatrix} = \begin{bmatrix} h_1 & h_2 & \dots & h_n \end{bmatrix} = \mathbf{h}^T $$

Write out the Jacobians

$$ \begin{aligned} \frac{\partial s}{\partial \mathbf{b}} &= \frac{\partial s}{\partial \mathbf{h}} \frac{\partial \mathbf{h}}{\partial \mathbf{z}} \frac{\partial \mathbf{z}}{\partial \mathbf{b}} \\ &= \mathbf{u}^T \text{diag}(f'(\mathbf{z})) \mathbf{I} \\ &= \mathbf{u}^T \odot f'(\mathbf{z}) \end{aligned} $$

$\odot$ = Hadamard product = element-wise multiplication of 2 vectors to give vector

变量	神经网络中的含义	说明
$s$	损失函数值 (Loss/Score)	最终的标量输出（例如交叉熵损失）。我们要看它随参数如何变化。
$\mathbf{b}$	偏置向量 (Bias)	当前层的偏置项，神经网络需要学习的参数之一。
$\mathbf{z}$	净输入 (Logits/Pre-activation)	线性组合后的结果，即 $\mathbf{z} = \mathbf{W}\mathbf{x} + \mathbf{b}$。
$\mathbf{h}$	激活值 (Activation/Hidden state)	$\mathbf{z}$ 经过非线性激活函数后的输出，即 $\mathbf{h} = f(\mathbf{z})$。
$\mathbf{u}^T$	上游传回的梯度 ($\frac{\partial s}{\partial \mathbf{h}}$)	损失函数对当前层输出的导数，它是从更高层“反向传播”回来的信号。
$f'(\mathbf{z})$	激活函数的导数	比如 ReLU 或 Sigmoid 的导数。它决定了哪些神经元处于活跃状态。
$\mathbf{I}$	单位矩阵 (Identity Matrix)	因为 $\mathbf{z} = \dots + \mathbf{b}$，$\mathbf{z}$ 对 $\mathbf{b}$ 求导的结果是 1（矩阵形式即为单位阵）。

Re-using Computation

误差信号（Upstream Gradient）$\boldsymbol{\delta}$：

$$ \boldsymbol{\delta} = \frac{\partial s}{\partial \mathbf{h}} \frac{\partial \mathbf{h}}{\partial \mathbf{z}} = \mathbf{u}^T \circ f'(\mathbf{z}) $$

我们先算出这个值$\boldsymbol{\delta}$ ，可以简化计算：

对权重矩阵 $W$ 的梯度展开：
$$ \frac{\partial s}{\partial \mathbf{W}} = \boldsymbol{\delta} \frac{\partial \mathbf{z}}{\partial \mathbf{W}} $$
对偏置向量 $\mathbf{b}$ 的梯度简化：
$$ \frac{\partial s}{\partial \mathbf{b}} = \boldsymbol{\delta} \frac{\partial \mathbf{z}}{\partial \mathbf{b}} = \boldsymbol{\delta} $$

Shape Convention

假设权重 $\mathbf{W} \in \mathbb{R}^{n \times m}$，输出是一个标量 $s$（损失）。按纯数学定义，$\frac{\partial s}{\partial \mathbf{W}}$ 应该是一个 $1 \times nm$ 的行向量（Jacobian）。但如果使用这种形式，梯度更新公式 $\theta^{new} = \theta^{old} - \alpha \nabla_{\theta} J(\theta)$ 就会因维度不匹配而无法直接相减。

为了计算方便，我们约定梯度的形状必须等于参数的形状。因此 $\frac{\partial s}{\partial \mathbf{W}}$ 也是一个 $n \times m$ 的矩阵：

$$ \frac{\partial s}{\partial \mathbf{W}} = \begin{bmatrix} \frac{\partial s}{\partial W_{11}} & \dots & \frac{\partial s}{\partial W_{1m}} \\ \vdots & \ddots & \vdots \\ \frac{\partial s}{\partial W_{n1}} & \dots & \frac{\partial s}{\partial W_{nm}} \end{bmatrix} $$$$ \frac{\partial s}{\partial \mathbf{W}} = \boldsymbol{\delta}^T \mathbf{x}^T $$

那么我们究竟应该以什么样的“形状”来呈现导数结果？

采取始终遵循**形状约定 (Shape Convention)**的方式：

做法：不拘泥于严格的 Jacobian 定义，而是时刻盯着变量的维度（Dimensions）。
核心技巧：通过观察维度来决定何时需要对某个项进行转置，或者调整矩阵相乘的顺序，以确保每一层算出来的梯度形状和该层的参数形状完全一致。
关于 $\boldsymbol{\delta}$ 的重要结论：传导至隐层（Hidden layer）的误差信号 $\boldsymbol{\delta}$，其维度应该与该隐层的神经元数量（即激活值向量的维度）完全相同。

Backpropagation

按流程逐步计算各函数，从输入得到输出，即是正向传播(Forward Propagation)

对于反向传播中的单个节点，有$downstream\ gradient=upstream\ gradient\times local\ gradient$

对于单节点的多输入，upstream gradient不变，各输入的local gradient不同，但计算公式是不变的

下面举个多输入的实际例子

我们可以在这个基础上，假设输入y的值变为了2.1，那么$a=x+y=3.1$，$b=max(y+z)=y=2.1$，$a\times b=6.51$

所以，y值变化的0.1导致了结果0.51的变化，那么梯度就是$\frac{\Delta f}{\Delta y}=5.1$

Implementations

那么理论上，在已知正向传播的符号和计算的情况下，计算机可以自动得出反向传播的结果。但是在现代框架中，用户需手动设计局部导数的结算，这也比全自动方式提升了系统的运行效率和稳定性。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


class MultiplyGate(object):
 def forward(self, x, y):
 z = x * y
 self.x = x # must keep these around!
 self.y = y
 return z

 def backward(self, dz):
 dx = self.y * dz # [dz/dx * dL/dz]
 dy = self.x * dz # [dz/dy * dL/dz]
 return [dx, dy]

Numeric Gradient Checking

在手动推导和实现反向传播（Backprop）时，这是确保你数学公式没推错、代码没写错的标准验证方法：

$$ f'(x) \approx \frac{f(x + h) - f(x - h)}{2h} $$

只需要前向传播函数 $f(x)$ 即可计算，不需要任何复杂的数学推导，不容易写错。
必须对模型的每一个参数分别进行两次前向传播（加 $h$ 和减 $h$），效率很低。
适合局部测试，不要对整个大型网络做验证，只针对某个特定层或小规模参数（如一个 $3 \times 3$ 的矩阵）进行。

Dependency Parsing

Syntactic Structure

Phrase structure organizes words into nested constituents.

我们可以自己定义phrase构成的语法，比如名词短语可以是“限定词 + 形容词 + 名词”，“限定词 + 名词 + 介词短语”……介词短语可以是“介词 + 名词……”

Dependency structure shows which words depend on (modify, attach to, or are arguments of) which other words

语言中很容易出现歧义(ambiguity)，在英语里有了介词短语，歧义就更多了，举个例子：

“Scientists count whales from space"可以理解为"Scientists [count] [whales from space]” 或者 “Scientists [count whales] [from space]” ……

Dependency Grammar and Treebanks

Dependency syntax postulates that syntactic structure consists of relations between lexical items, normally binary asymmetric relations (“arrows”) called dependencies

下图是个比较古老的"dependency structure"

An arrow connects a head (governor, superior, regent) with a dependent (modifier, inferior, subordinate)

Usually, dependencies form a tree (a connected, acyclic, single-root graph)

Annotated Data

起初，构建语言库（Treebank）似乎比手动编写语法规则要慢得多，且看起来没那么有用。手动标注数据确实是件麻烦的工作，但现在看来，却有很大的优势：

复用性(Reusability)：一套标注好的数据可以用来训练多种解析器（Parsers）、词性标注器（POS Taggers）
覆盖面广(Board coverage)：手动编写规则往往只能覆盖几个直觉上的例子，而标注真实语料可以涵盖语言在现实中的各种复杂用法。
频率与分布信息(Frequencies and distributional information)：它能告诉机器哪些结构更常见，帮助概率模型做出更准确的判断。
评估NLP(A way to evaluate NLP systems)：没有这套“标准”，我们就无法衡量一个 AI 模型的准确率（如 LAS/UAS 得分）

那么关于示例图中的各依存关系的意思，如下：

缩写	意思	简单理解
nsubj	名词主语	动作的发出者（如 I think）
nsubjpass	被动主语	被动语态里的主语（如 city called）
ccomp	从句	动词后面的整个小句子（如 think …）
advmod	状语修饰	修饰动词的程度、疑问等（如 Why）
amod	形容词修饰	修饰名词的形容词（如 famous goat）
compound	复合修饰	名词修饰名词（如 goat trainer）
det	限定关系	指向 a, the, any 等词
case	介词关系	指向 in, at 等介词
conj	并列关系	用 or, and 连接的词（如 trainer or something）

Dependency Conditioning Preferences

在进行句法分析时，计算机会根据“依存条件偏好（Dependency Conditioning Preferences）”来判断两个词之间是否存在依存关系：

双词亲和力 (Bilexical affinities)：依存关系（例如 [discussion → issues]）是合理的。
依存距离 (Dependency distance)：大多数（但并非所有）依存关系发生在邻近的单词之间。
介入材料 (Intervening material)：依存关系很少跨越中间的动词或标点符号。
中心词的价态 (Valency of heads)：对于一个中心词（Head）来说，通常在它的哪一侧会有多少个依存词？

Projectivity

如果一个句子的单词按线性顺序排列，且所有的依存弧（dependency arcs）都画在单词上方时，没有任何两条弧线发生交叉，那么这个解析就是“投影的”。那么互出现了交叉，就是非投影的(non-projectivity)，说明发生了“长距离位移”或结构重叠。

但是现实中非投影的例子很常见，比如"Who did Bill buy the coffee from yesterday"

Transition-Based Dependency Parser

首先，这Transition-Based Dependency Parser分有一个Stack和一个Buffer，和三种操作：

Start: $\sigma = [ROOT], \beta = w_1, ..., w_n, A = \emptyset$

Shift: $\sigma, w_i | \beta, A \Rightarrow \sigma | w_i, \beta, A $
Left-$Arc_r$: $\sigma | w_i | w_j, \beta, A \Rightarrow \sigma | w_j, \beta, A \cup \{r(w_j, w_i)\} $
Right-$Arc_r$: $\sigma | w_i | w_j, \beta, A \Rightarrow \sigma | w_j, \beta, A \cup \{r(w_i, w_j)\}$

Finish: $\sigma = [w], \beta = \emptyset$

σ（sigma）表示 堆栈（stack），存储当前正在处理或等待建立关系的词。
β（beta）表示 缓冲区（buffer），存储尚未处理的输入词序列。
A 表示 依存弧集合（set of dependency arcs），存储已建立的依存关系。
Left-$Arc_r$ 和 Right-$Arc_r$ 是两种规约模型，用来表明一个词是另一个的依存词，以左或右方向。

那么下面先来举个例子：Analysis of “I ate fish”

Left Arc操作生成了一个由栈顶指向第二个元素的弧，建立了"ate“是中心词，“I"依存于”ate“的关系。然后将”I“移出栈。
Shift操作将”fish“从缓冲区移入栈中
Right Arc操作生成了一个由第二个元素指向栈顶元素的弧，建立了”ate“是中心词,"fish“依存于”ate“的关系。然后将”fish“移出栈。
最后的Right Arc操作使”[root]“指向”ate"，并在”ate“出栈后，只剩下根节点，操作完成。

Evaluation of Dependency Parsing

评价依存分析的指标分为UAS（无标签附件分数）和 LAS（有标签附件分数），下面是一个具体的例子: “[ROOT] She saw the video lecture."，表中"Gold"是标准答案，“Parsed"是分析出的答案：

可见，UAS计算的是Head寻找得是否正确，本例中第三个"the"的依存词和标准不符。
LAS计算的它们之间的关系类型是否标注正确，即Head和关系标签(label)都要一致，本例中只有"She"和"saw"是与标准相符的。

Neural dependency parsing

More than 95% of parsing time is consumed by feature computation

所以，我们可以用神经网络来加速特征提取，当然其方法还是基于上面的基于转移（Transition-based）的神经依存句法分析器。具体使用了了向量化、非线性等深度学习知识搭建出了第一个基于神经网络的依存分析器(2014年)。

Recurrent Neural Networks

Language Modeling

语言模型(Language Modeling) 简单地讲就是输入文本（词），输出概率。

$$ \begin{aligned} P(\boldsymbol{x}^{(1)}, \dots, \boldsymbol{x}^{(T)}) &= P(\boldsymbol{x}^{(1)}) \times P(\boldsymbol{x}^{(2)} | \boldsymbol{x}^{(1)}) \times \dots \times P(\boldsymbol{x}^{(T)} | \boldsymbol{x}^{(T-1)}, \dots, \boldsymbol{x}^{(1)}) \\ &= \prod_{t=1}^{T} \underbrace{P(\boldsymbol{x}^{(t)} | \boldsymbol{x}^{(t-1)}, \dots, \boldsymbol{x}^{(1)})}_{\text{This is what our LM provides}} \end{aligned} $$

$P(\boldsymbol{x}^{(1)}, \dots, \boldsymbol{x}^{(T)})$ 表示一整个序列（如一句话）出现的概率，通过将联合概率分解为一系列条件概率的乘积（链式法则），我们可以计算序列的概率。语言模型的核心任务就是根据之前的上下文 $\boldsymbol{x}^{(t-1)}, \dots, \boldsymbol{x}^{(1)}$ 来预测下一个 token $\boldsymbol{x}^{(t)}$ 出现的概率。

n-gram Language Models

An n-gram is a chunk of n consecutive words. n表示由几个词构成一个单位，即n-gram。为实现n-gram Language Models，步骤如下：

首先，做一个马尔可夫假设：第 $t+1$ 个词 $x^{(t+1)}$ 仅取决于其前面的 $n-1$ 个词。
$$ P(x^{(t+1)} | x^{(t)}, \dots, x^{(1)}) = P(x^{(t+1)} | \underbrace{x^{(t)}, \dots, x^{(t-n+2)}}_{n-1 \text{ words}}) \quad \text{(assumption)} $$
利用条件概率的定义，上述公式可以写为 $n$-gram 与 $(n-1)$-gram 概率的比值：
$$ = \frac{P(x^{(t+1)}, x^{(t)}, \dots, x^{(t-n+2)}) \leftarrow \text{prob of a n-gram}}{P(x^{(t)}, \dots, x^{(t-n+2)}) \leftarrow \text{prob of a (n-1)-gram}} \quad \text{(definition of conditional prob)} $$
通过在大型文本语料库中计数 (Counting) 它们来统计词组出现的频率，来近似概率：
$$ \approx \frac{\text{count}(x^{(t+1)}, x^{(t)}, \dots, x^{(t-n+2)})}{\text{count}(x^{(t)}, \dots, x^{(t-n+2)})} \quad \text{(statistical approximation)} $$

举个例子，假设我们有一个4-gram Language Model，要预测最后一个空可能出现的单词：

“as the proctor started the clock, the students opened their ……”

我们只取最后的三个词组成的短语”students opened their”

$$ P(w\mid students\ opened\ their)=\frac{count(students\ opened\ their\ w)}{count(students\ opened\ their)} $$

根据语料库，"students opened their books“可能是出现频率最高的，而更符合语境的”……exams“出现频率更低

Problems with n-gram Language Models

当使用计数法计算概率，会面临稀疏性问题：

如果词组 “students opened their $w$” 在训练数据中从未出现过，那么对于任何该词 $w$，其概率都将变为 0。

通过为词表中的每个词 $w \in V$ 的计数增加一个极小的数值 $\delta$ (平滑化 Smoothing)解决
如果前缀 “students opened their” 在训练数据中从未出现过，我们将无法计算任何 $w$ 的概率，因为分母为 0。

不再考虑完整的前缀，而是退而求其次，仅根据更短的上下文（例如 “opened their”）进行条件概率计算。(回退 Backoff)

同时也会面临存储的问题：

需要存放语料库中所有n-gram的计数
若是n需要增加，语料库的size也要大幅增加

A fixed-window neural Language Model

输入层 (Words / One-hot vectors): 输入为单词的 one-hot 向量 $\boldsymbol{x}^{(1)}, \boldsymbol{x}^{(2)}, \boldsymbol{x}^{(3)}, \boldsymbol{x}^{(4)}$。
嵌入层 (Concatenated word embeddings): 将单词转换为稠密的向量表示（embeddings），并进行拼接：
$$ \boldsymbol{e} = [\boldsymbol{e}^{(1)}; \boldsymbol{e}^{(2)}; \boldsymbol{e}^{(3)}; \boldsymbol{e}^{(4)}] $$
隐藏层 (Hidden layer): 通过权重矩阵 $W$ 和偏置 $b_1$ 进行线性变换，并经过激活函数 $f$（通常为 tanh 或 ReLU）：
$$ \boldsymbol{h} = f(W\boldsymbol{e} + \boldsymbol{b}_1) $$
输出层 (Output distribution): 经过权重矩阵 $U$ 和偏置 $b_2$，最后通过 softmax 函数生成词典 $V$ 上的概率分布 $\hat{\boldsymbol{y}}$：
$$ \hat{\boldsymbol{y}} = \text{softmax}(U\boldsymbol{h} + \boldsymbol{b}_2) \in \mathbb{R}^{|V|} $$

那么相对于n-gram方法，改进了：

解决稀疏性问题：不再依赖精确的计数，通过向量空间的相似性来泛化未见过的词组。
存储优化：不需要存储所有观察到的 $n$-gram 频率，只需存储模型参数。

但是仍有问题没能解决：

固定窗口限制：
- 固定的上下文窗口通常太小。
- 扩大窗口会线性导致权重矩阵 $W$ 的参数量激增。
- 无论窗口多大，它永远无法捕捉超出该范围的长程依赖。
缺乏对称性：输入 $\boldsymbol{x}^{(1)}$ 和 $\boldsymbol{x}^{(2)}$ 与矩阵 $W$ 中完全不同的权重相乘，模型处理每个位置输入的方式没有一致性。

RNN Language Model

The Unreasonable Effectiveness of Recurrent Neural Networks

RNN 的优点：

可以处理任意长度的输入。
理论上，第 $t$ 步的计算可以使用很多步之前的信息。
模型大小固定：增加输入长度不会增加模型参数量。
对称性：每一步应用相同的权重，处理输入的方式具有一致性。

RNN 的缺点：

计算速度慢：由于是递归计算，无法并行处理。
实践难题：在实际应用中，很难获取到很多步之前的信息（梯度消失/爆炸问题）。

Train an RNN Language Modle

获取一个大型文本语料库，它是由单词序列组成的：$\boldsymbol{x}^{(1)}, \dots, \boldsymbol{x}^{(T)}$
将序列输入 RNN-LM，并为每一个时间步 $t$ 计算输出分布 $\hat{\boldsymbol{y}}^{(t)}$。这意味着模型在给定目前为止已见单词的情况下，预测每一个位置上可能出现的单词概率分布。
模型在每一个步长 $t$ 都会产生一个损失，第 $t$ 步的损失函数是预测概率分布 $\hat{\boldsymbol{y}}^{(t)}$ 与真实的下一个单词 $\boldsymbol{y}^{(t)}$（即 $\boldsymbol{x}^{(t+1)}$ 的 one-hot 向量）之间的交叉熵
$$ J^{(t)}(\theta) = CE(\boldsymbol{y}^{(t)}, \hat{\boldsymbol{y}}^{(t)}) = - \sum_{w \in V} \boldsymbol{y}^{(t)}_w \log \hat{\boldsymbol{y}}^{(t)}_w = - \log \hat{\boldsymbol{y}}^{(t)}_{\boldsymbol{x}_{t+1}} $$
为了获得整个训练集的损失，需要将所有步骤的损失取平均值：
$$ J(\theta) = \frac{1}{T} \sum_{t=1}^{T} J^{(t)}(\theta) = \frac{1}{T} \sum_{t=1}^{T} - \log \hat{\boldsymbol{y}}^{(t)}_{\boldsymbol{x}_{t+1}} $$
计算损失应用了Teacher Forcing的概念，即并不使用模型在上一步实际预测出的单词作为下一步的输入，而是直接将语料库中的真实正确答案喂给模型。
一次性计算整个语料库 $\boldsymbol{x}^{(1)}, \dots, \boldsymbol{x}^{(T)}$ 的损失（Loss）和梯度（Gradients）在内存方面是极其昂贵的，所以在实际操作中，我们将序列 $\boldsymbol{x}^{(1)}, \dots, \boldsymbol{x}^{(T)}$ 看作是一个个句子或文档，使用随机梯度下降来对一**小块数据 **计算损失和梯度，并立即进行参数更新

Backpropagation for RNN

RNN参数的训练，采用随时间的反向传播，沿着时间步 $i = t, \dots, 0$ 反向传播，并在过程中累加梯度。

由于 $\boldsymbol{W}_h$ 在每一个时间步都是共享的（相同的权重），因此总梯度是每一个时间步产生的梯度之和。

$$ \frac{\partial J^{(t)}}{\partial \boldsymbol{W}_h} = \sum_{i=1}^{t} \left. \frac{\partial J^{(t)}}{\partial \boldsymbol{W}_h} \right|_{(i)} \frac{\partial \boldsymbol{W}_h|_{(i)}}{\partial \boldsymbol{W}_h} = \sum_{i=1}^{t} \left. \frac{\partial J^{(t)}}{\partial \boldsymbol{W}_h} \right|_{(i)} $$

随着序列增长，完整的反向传播计算量极大，且容易出现梯度消失或爆炸问题。在实际应用中，为了提高训练效率，通常会在约 20 个时间步后进行“截断”。

Exploding Gradient

梯度爆炸：

如果 $W_h$ 的特征值（大致可以理解为权重的大小）大于 1。
随着时间步 $T$ 的增加，梯度会呈指数级增长。
模型权重会更新得过大，导致网络变得极不稳定，参数值可能会溢出（变成 NaN），训练崩溃。

如果在更新模型参数前，梯度的范数 (norm) 超过了预设的某个阈值，则按比例将其缩小，如果 $\|\hat{\boldsymbol{g}}\| \ge threshold$ ，则进行梯度裁剪，梯度裁剪让模型更新时保持在相同的方向上，但只迈出更小的一步：

$$ \hat{\boldsymbol{g}} \leftarrow \frac{threshold}{\|\hat{\boldsymbol{g}}\|} \hat{\boldsymbol{g}} $$

Vanishing Gradient

梯度消失：

如果 $W_h$ 的特征值小于 1，或者激活函数（如图中提到的 $f$ 或 tanh）的导数小于 1。
梯度会随着反向传播的步数增加而指数级减小。
这对应了提到的 RNN 缺点：“在实践中，很难获取到很多步之前的信息”。当梯度变得极其微小时，远距离的权重更新几乎停滞，模型“忘记”了长期的上下文。

对于 vanilla RNN（基础 RNN）来说，学习如何跨越多个时间步长来保留信息实在是太困难了，因为隐藏状态 $\boldsymbol{h}^{(t)}$ 会被不断地重写：

$$ \boldsymbol{h}^{(t)} = \sigma(\boldsymbol{W}_h \boldsymbol{h}^{(t-1)} + \boldsymbol{W}_x \boldsymbol{x}^{(t)} + \boldsymbol{b}) $$

所以，我们引入独立记忆，如LSTM。或者建立直接连接，如Attention机制。

Long Short-Term Memory

Understanding LSTM Networks – colah’s blog

遗忘门 (Forget gate)：控制从上一个细胞状态中保留什么以及忘记什么。

$$ \boldsymbol{f}^{(t)} = \sigma (\boldsymbol{W}_f \boldsymbol{h}^{(t-1)} + \boldsymbol{U}_f \boldsymbol{x}^{(t)} + \boldsymbol{b}_f) $$

输入门 (Input gate)：控制新细胞内容的哪些部分被写入到细胞中。

$$ \boldsymbol{i}^{(t)} = \sigma (\boldsymbol{W}_i \boldsymbol{h}^{(t-1)} + \boldsymbol{U}_i \boldsymbol{x}^{(t)} + \boldsymbol{b}_i) $$

输出门 (Output gate)：控制细胞的哪些部分被输出到隐藏状态中。

$$ \boldsymbol{o}^{(t)} = \sigma (\boldsymbol{W}_o \boldsymbol{h}^{(t-1)} + \boldsymbol{U}_o \boldsymbol{x}^{(t)} + \boldsymbol{b}_o) $$

New cell content：这是要被写入细胞的新内容（即我们在之前讨论中提到的“候选内容”）。

$$ \tilde{\boldsymbol{c}}^{(t)} = \tanh (\boldsymbol{W}_c \boldsymbol{h}^{(t-1)} + \boldsymbol{U}_c \boldsymbol{x}^{(t)} + \boldsymbol{b}_c) $$

Cell state：擦除（“忘记”）上一个细胞状态中的某些内容，并写入（“输入”）一些新的细胞内容。

$$ \boldsymbol{c}^{(t)} = \boldsymbol{f}^{(t)} \odot \boldsymbol{c}^{(t-1)} + \boldsymbol{i}^{(t)} \odot \tilde{\boldsymbol{c}}^{(t)} $$

隐藏状态 (Hidden state)：从细胞中读取（“输出”）某些内容。

$$ \boldsymbol{h}^{(t)} = \boldsymbol{o}^{(t)} \odot \tanh \boldsymbol{c}^{(t)} $$

Step-by-Step LSTM Walk Through

在上图中，每条线都承载着一个完整的向量，从一个节点的输出指向其他节点的输入。粉色圆圈代表逐点运算，例如向量加法，而黄色方框代表已学习的神经网络层。合并的线条表示连接，而分叉的线条表示其内容被复制，并将副本发送到不同的位置。

LSTM 的关键在于单元状态，也就是图中贯穿顶部的水平线。

单元状态就像一条传送带，它沿着整个链条直线传递，只有一些微小的线性交互。信息很容易原封不动地沿着传送带流动。
LSTM 能够对单元状态进行信息添加或移除，这种操作由称为“门”的结构进行精细调控。

门是一种选择性地允许信息通过的方式。它们由一个 sigmoid 神经网络层和一个逐点乘法运算组成。

LSTM 的第一步是决定我们要从细胞状态中丢弃什么信息。这个决定由一个称为“遗忘门层”的 sigmoid 层来做出。它接收 $h_{t-1}$ 和 $x_t$，并为细胞状态 $C_{t-1}$ 中的每个数字输出一个介于 0 和 1 之间的数值；1 代表“完全保留”，而 0 代表“彻底丢弃” 。
让我们回到之前那个尝试根据前面所有单词预测下一个单词的语言模型例子。在这样一个问题中，细胞状态可能包含了当前主语的性别信息，以便模型能使用正确的代词。当我们看到一个新的主语时，我们会希望忘记旧主语的性别。

下一步是决定我们要将什么新信息存储在细胞状态中。这包含两个部分。首先，一个称为“输入门层”的 sigmoid 层决定了我们将更新哪些值；接着，一个 $\tanh$ 层创建了一个包含新候选值的向量 $\tilde{C}_t$，这些值可以被添加到状态中。在下一步里，我们将结合这两个部分来对状态进行更新。
在我们的语言模型例子中，我们会希望将新主语的性别添加到细胞状态中，以替换我们正在遗忘的旧性别信息。

现在是时候将旧的细胞状态 $C_{t-1}$ 更新为新的细胞状态 $C_t$ 了。前面的步骤已经决定了要做什么，我们只需要去实际执行它。
我们将旧状态乘以 $f_t$，以此来忘掉我们之前决定要忘记的信息。然后我们加上 $i_t * \tilde{C}_t$。这就是新的候选值，根据我们决定更新每个状态值的程度进行了缩放。

在语言模型的例子中，正是在这里，我们实际丢弃了关于旧主语性别的信息，并添加了新信息，就像我们在前面步骤中决定的那样。

最后，我们需要决定我们要输出什么。这个输出将基于我们的细胞状态，但会是一个经过过滤的版本。

首先，我们运行一个 sigmoid 层，它决定了我们要输出细胞状态的哪些部分。然后，我们将细胞状态通过 $\tanh$（将值推到 -1 和 1 之间）并将其乘以 sigmoid 门的输出，这样我们就只输出了我们决定输出的部分。
以语言模型为例，由于它刚刚处理了一个主语，接下来可能会倾向于输出与谓语动词相关的信息，以预判后续内容。例如，模型可能会输出该主语是单数还是复数，这样如果接下来出现动词，我们就能知道该以何种形式进行词形变化。

How does LSTM solve vanishing gradients

LSTM 架构使得 RNN 更容易在多个时间步长内保留信息。例如，如果某个单元维度的遗忘门设置为 1，输入门设置为 0，那么该单元的信息将被无限期地保留。

相比之下，普通的 RNN 更难学习一个循环权重矩阵 $W_h$，以保留隐藏状态中的信息。
尽管梯度消失/爆炸现象无法避免，但对于长距离依赖关系，模型还可以创建更直接、更线性的直通连接。比如ResNet, DenseNet……都在模块之间、层之间不同程度地创建了直接连接。

Bidirectional RNNs

传统的单向 RNN 或 LSTM 存在一个明显的局限：在处理序列时，它只能“向左看”（即只利用过去的历史上下文）。然而，在许多 NLP 任务（如情感分类、命名实体识别或句子整体理解）中，当前词的准确含义往往也依赖于“右侧”（未来）的上下文。
为了解决这个问题，研究者引入了双向架构（通常使用 LSTM 实现，即 BiLSTM）：
- 前向 (Forward) RNN：按照从左到右的顺序处理输入序列，计算出一系列隐藏状态 $\overrightarrow{h}_t$。
- 后向 (Backward) RNN：按照从右到左的逆序处理同一个输入序列，计算出一系列隐藏状态 $\overleftarrow{h}_t$。
- 拼接状态 (Concatenated State)：在每一个时间步 $t$，将前向和后向的隐藏状态拼接在一起，形成该位置的最终表示 $h_t = [\overrightarrow{h}_t; \overleftarrow{h}_t]$。这样，每个词的特征表示就同时包含了整个句子的左侧和右侧完整信息。
双向 LSTM 的特征提取能力非常强大，但它仅适用于能够一次性获取完整输入序列的任务（例如对整段文本进行分类，或翻译时的源句子编码）。它不能用于传统的语言模型（Language Modeling），因为语言模型的本质任务是“预测下一个词”，如果允许模型看到右侧的“未来”信息，就违背了自回归预测的初衷。

Neural Machine Translation

神经机器翻译是 NLP 深度学习领域的第一个巨大成功。NMT 主要是基于 Sequence-to-Sequence (Seq2Seq) 架构，该架构的核心正是由两个 RNN（通常是 LSTM）组成的：编码器 (Encoder) 和 解码器 (Decoder)。
Encoder负责读取源语言句子，但在读取过程中它不产生实际的翻译输出，而是不断更新其隐藏状态。当 Encoder 处理完源句子的最后一个词后，其最终的隐藏状态（Final Hidden State）被视作整个句子的语义浓缩。它充当了一个“信息瓶颈”，因为整个源句子的所有复杂含义都必须被压缩进这一个固定维度的向量中。
Decodere端的 LSTM 本质上是一个条件语言模型 (Conditional Language Model)，初始隐藏状态不再是随机的或全零的，而是被严格赋值为 Encoder 输出的那个“瓶颈”向量。这意味着 Decoder 的所有生成动作都是以源句子的语义向量为条件展开的。在每一个时间步，它根据当前的隐藏状态输出概率最高的词，并将该词（Feeding in last word）作为下一步的输入继续循环，直到生成句子结束标记 <EOS>。

Pytorch基础

Thu, 22 Jan 2026 10:49:28 +0800

本篇是对Pytorch基础使用的学习，主要基于B站小土堆的https://www.bilibili.com/video/BV1hE411t7RN/以及Gemini的帮助，除实践外也包含了一些深度学习模型的原理

Dataset

An abstract class representing a Dataset.

All datasets that represent a map from keys to data samples should subclass it. All subclasses should overwrite __getitem__, supporting fetching a data sample for a given key. Subclasses could also optionally overwrite __len__, which is expected to return the size of the dataset by many ~torch.utils.data.Sampler implementations and the default options of ~torch.utils.data.DataLoader. Subclasses could also optionally implement __getitems__, for speedup batched samples loading. This method accepts list of indices of samples of batch and returns list of samples.

note

~torch.utils.data.DataLoader by default constructs an index sampler that yields integral indices. To make it work with a map-style dataset with non-integral indices/keys, a custom sampler must be provided.

一个表示数据集的抽象类。

所有实现从键（keys）到数据样本（data samples）映射的数据集都应该继承这个类。所有子类都必须重写 __getitem__ 方法，以支持根据给定的键获取数据样本。子类也可以选择性地重写 __len__ 方法，许多 ~torch.utils.data.Sampler 实现和 ~torch.utils.data.DataLoader 的默认选项都需要通过这个方法返回数据集的大小。子类还可以选择性地实现 __getitems__ 方法，以加速批量样本的加载。此方法接受批处理样本的索引列表，并返回样本列表。

注意

默认情况下，~torch.utils.data.DataLoader 会构造一个生成整数索引的采样器。要让其与非整数索引/键的映射式数据集一起工作，必须提供自定义的采样器。

自定义Dataset

那么在实际的使用中，比如有一个数据集（我们拿之前用过的fer2013来举例）：

先定义一个数据类继承Dataset，定义__init__()

1
2
3
4
5
6
7
8


from torch.utils.data import Dataset
import os
class MyData(Dataset):
 def __init__(self, root_dir, label_dir):
 self.root_dir = root_dir # 如 fer2013/test
 self.label_dir = label_dir # 如 angry
 self.path = os.path.join(self.root_dir, self.label_dir) # 路径合并函数 解决跨系统的文件路径问题
 self.img_path = os.listdir(self.path) # 如angry文件夹下，所有图片名的string list

重写__getitem()

1
2
3
4
5
6


def __getitem__(self, index):
 img_name = self.img_path[index]
 img_item_path = os.path.join(self.root_dir, self.label_dir, img_name) # 拼接出具体的某一个图片的路径
 img = Image.open(img_item_path)
 label = self.label_dir
 return img, label # 返回数据集中的一个对象（图片）及其类型

重写__len()__

1
2


def __len__(self):
 return len(self.img_path)

定义示例

1
2
3


root_dir = "fer2013/train"
angry_label_dir = "angry"
angry_dataset = MyData(root_dir, angry_label_dir)

Dataset合并

1
2
3
4


disguest_label_dir = "disguest"
disgust_dataset = MyData(root_dir, disguest_label_dir)

train_dataset = angry_dataset + disgust_dataset # '+'

TensorBoard

SummaryWriter

创建日志目录
初始化Writer对象
生成事件文件
- 这个文件才是真正的数据库(events.out……)当后续调用 writer.add_scalar 时，数据并不是直接画在屏幕上，而是被追加写进这个文件里。
- 当你执行完相应代码，运行 tensorboard --logdir=logs 时，TensorBoard 的后端服务器就会去读取这个文件里的内容，并在浏览器里渲染成图表。

1
2
3


from torch.utils.tensorboard import SummaryWriter

writer = SummaryWriter("logs") # 这行代码会在你的项目根目录下创建一个名为"logs"的文件夹

需注意，每次实验可以用不同的文件夹来记录数据，比如writer = SummaryWriter("logs/lr0.01_batch32")修改了学习率后writer = SummaryWriter("logs/lr0.001_batch32")

add_scalar()

绘图函数add_scalar()

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


(method) def add_scalar(
 tag: Any,
 scalar_value: Any, # 对应图像的y轴
 global_step: Any | None = None, # 对应图像的x轴
 walltime: Any | None = None,
 new_style: bool = False,
 double_precision: bool = False
) -> None

​``` 例 ```

for i in range(100):
 writer.add_scalar("y=2x", 2*i, i)
writer.close()

add_image()

查看图片函数add_image()

1
2
3
4
5
6
7


(method) def add_image(
 tag: Any,
 img_tensor: Any,
 global_step: Any | None = None,
 walltime: Any | None = None,
 dataformats: str = "CHW"
) -> None

要注意参数的类型要求：img_tensor (torch.Tensor, numpy.ndarray, or string/blobname): Image data，所以要将PIL类型的图片进行转换，比如用numpy来转换。以及数据的shape要求： Tensor with :math:(1, H, W), :math:(H, W), :math:(H, W, 3) is also suitable as long as corresponding dataformats argument is passed, e.g. CHW, HWC, HW. 即三种图片数据的格式，其通道数、高度、宽度的顺序不同。

1
2
3
4
5


img = Image.open(image_path)
img_array = np.array(img)
print(f"图像形状: {img_array.shape}")
writer.add_image("test",img_array,1,dataformats='HW') # 由.shape可得
writer.close()

add_graph()

常见的Transforms

下面基本都是对图像的处理方法

ToTensor

Convert a PIL Image or ndarray to tensor and scale the values accordingly.

This transform does not support torchscript.

Converts a PIL Image or numpy.ndarray (H x W x C) in the range [0, 255] to a torch.FloatTensor of shape (C x H x W) in the range [0.0, 1.0] if the PIL Image belongs to one of the modes (L, LA, P, I, F, RGB, YCbCr, RGBA, CMYK, 1) or if the numpy.ndarray has dtype = np.uint8

In the other cases, tensors are returned without scaling.

note

Because the input image is scaled to [0.0, 1.0], this transformation should not be used when transforming target image masks. See the [references](vscode-file://vscode-app/d:/Microsoft VS Code/resources/app/out/vs/code/electron-browser/workbench/workbench.html) for implementing the transforms for image masks.
将PIL图片转为torch类型，如torch.Size([1, 48, 48])

1
2
3
4
5


trans_totensor = transforms.ToTensor()
img_tensor = trans_totensor(img)
print(img_tensor.shape)
writer.add_image("ToTensor",img_tensor)
writer.close()

Normalize

Normalize a tensor image with mean and standard deviation.

This transform does not support PIL Image.

Given mean: (mean[1],...,mean[n]) and std: (std[1],..,std[n]) for n

channels, this transform will normalize each channel of the input

torch.*Tensor i.e.,

output[channel] = (input[channel] - mean[channel]) / std[channel]

note:

This transform acts out of place, i.e., it does not mutate the input tensor.

Args:

mean (sequence): Sequence of means for each channel.

std (sequence): Sequence of standard deviations for each channel.

inplace(bool,optional): Bool to make this operation in-place.

Normailize 的数学原理是：

$$ output = \frac{input-mean}{std} $$

参数mean影响的是“中心位置”，在ToTensor之后，像素值在 $[0, 1]$ 之间，中心大约在 $0.5$，如mean = 0.5，那么减去 $0.5$ 后，数据的中心变成了 $0$。原本 $[0, 1]$ 的范围变成了 $[-0.5, 0.5]$
参数std影响的是“缩放幅度”，如std = 0.5，那么就是将数据范围再除以$0.5$，最终范围从 $[-0.5, 0.5]$ 变成了 $[-1, 1]$

Resize

Resize the input image to the given size.

If the image is torch Tensor, it is expected

to have […, H, W] shape, where … means a maximum of two leading dimensions

Args:

size (sequence or int): Desired output size. If size is a sequence like

(h, w), output size will be matched to this. If size is an int,

smaller edge of the image will be matched to this number.

i.e, if height > width, then image will be rescaled to

(size * height / width, size).

resize()支持PIL和Tensor两种图片格式，如果是 Tensor，期望形状为 [..., H, W]。这里的 ... 表示它可以处理 [C, H, W]（单张图）或 [B, C, H, W]（一个 Batch 的图）
参数size需注意写成序列形式，如resize((512, 512))，而如果只输入一个参数，如resize(512)，那么图片短边会变为512，而长边会按比例改变

1
2
3
4


print(img.size)
trans_resize = transforms.Resize((224,224))
img_resize = trans_resize(img)
print(img_resize)

Compse

Composes several transforms together. This transform does not support torchscript.

Please, see the note below.

Args:

transforms (list of Transform objects): list of transforms to compose.

compse()操作是对各种transforms操作的流水线类
在深度学习中，图片通常需要经过一系列的固定步骤（比如：缩放 -> 转为 Tensor -> 归一化）。如果不用 Compose，你每一张图都要手动调用多个函数，代码会非常冗余
compse()的参数类型是一个列表，操作是按顺序执行的，所以前一个操作输出的数据类型必须能作为下一个操作的输入。

1
2
3
4
5
6
7
8
9


from torchvision import transforms
# 定义训练集的预处理
train_transform = transforms.Compose([
 transforms.Resize((224, 224)), # VGG16标准输入是224x224
 transforms.RandomHorizontalFlip(), # 数据增强：随机水平翻转
 transforms.ToTensor(), # 归一化到 [0.0, 1.0]
 transforms.Normalize([0.5], [0.5]) # 标准化到 [-1.0, 1.0]
])
img_tensor = train_transform(img)

Pytorch数据集使用

例如，我们要导入视觉学习的数据集，可以直接在程序中进行数据集的下载

1
2
3
4
5


import torchvision

train_set = torchvision.datasets.CIFAR10(root="./dataset...", train=True, download=True)

test_set = torchvision.datasets.CIFAR10(root="./dataset...", train=false, download=True)

root参数表示数据集存放的位置，train参数表示数据集是否用来训练，download参数表示是否下载到本地（会生成一个下载链接）
具体的参数设置，每个数据集都可能有所区别……
如果是下载完成到本地的数据集，可以将其复制到项目目录的dataset文件夹下，再运行程序即可节省下载的时间

1
2
3
4
5
6


print(test_set.classes) # 可以看到测试数据集的所有类别

img, target = test_set[0]
print(img)
print(target)
print(test_set.classes[target]) # 输出测试集第一个元素对应的类别

DataLoader

Data loader combines a dataset and a sampler, and provides an iterable over the given dataset.

The :class:~torch.utils.data.DataLoader supports both map-style and

iterable-style datasets with single- or multi-process loading, customizing

loading order and optional automatic batching (collation) and memory pinning.

在训练模型时，不能一次性把数据集中的大量数据塞进内存。DataLoader实现了：

Batching（批处理）： 把图片打包成一组组（Batch）。
Shuffling（打乱）： 每一轮训练（Epoch）开始时随机洗牌，防止模型死记硬背数据顺序。
Parallel Computing（并行加载）： 利用多核 CPU 提前准备下一批数据，不让 GPU 等待。

参数名	常用取值	作用描述
dataset	自定义 Dataset	必填。告诉 DataLoader 从哪个“仓库”取数据。
batch_size	16, 32, 64…	每批装载的数量。越大训练越快，但越占显存。在 FER 表情识别中，32 或 64 是常用数值。
shuffle	`True` / `False`	是否打乱顺序。训练集通常设为 `True`（增加随机性）；测试集通常设为 `False`。
num_workers	0, 2, 4, 8…	多进程加载。 `0` 表示只用主进程（慢）。增加数值可以加快读取速度。建议：设为 CPU 核心数的一半。
drop_last	`True` / `False`	丢弃最后多余的数据。比如有 100 张图，`batch_size=32`。最后剩 4 张不够一包，设为 `True` 就会把这 4 张扔掉，确保每个 Batch 大小一致。
pin_memory	`True`	内存锁页。如果你用 GPU 训练，设为 `True` 可以加快数据从内存传输到显存的速度。

例如，我们用DataLoader处理CIFAR10中的数据

1
2
3


test_data = torchvision.datasets.CIFAR10("./dataset", train=False, transform=torchvision.transforms.ToTensor(), download=True)

test_loader = DataLoader(dataset=test_data, batch_size=4, shuffle=True, num_workers=0, drop_last=False)

结合循环和tensorboard，输出每一个epoch中每一step用到的图片
下面代码中step + epoch * len(test_loader)是使用了全局步长，也可以不这样写，而是把每个epoch来当作一组

1
2
3
4
5
6
7
8


writer = SummaryWriter("dataloader")
for epoch in range(2):
 step = 0
 for data in test_loader:
 imgs, targets = data
 writer.add_images("test_data_batch", imgs, step + epoch * len(test_loader))
 step = step + 1
writer.close()

nn.Module

Base class for all neural network modules.

Your models should also subclass this class.

Modules can also contain other Modules, allowing to nest them in a tree structure.

在 PyTorch 中，无论是简单的线性层，还是复杂的 VGG16 或 Transformer，本质上都是一个 nn.Module。它是所有神经网络模块的基类
nn.Module 支持嵌套，当你对大模型调用 model.to("cuda") 时，PyTorch 会顺着这棵“树”，自动把里面所有的子层都搬到 GPU 上。
只要在 __init__ 中把一个层赋值给 self.xxx，PyTorch 就会自动识别出其中的权重 (Weights) 和 偏置 (Bias)，并将它们加入到待优化的参数列表中。

编写一个nn.Module子类时，必须重写__init()__和forward()

__init(self)__
- 在这里定义网络层（卷积、池化、全连接等）。
- 必须调用 super().__init__()。这行代码的作用是初始化父类的属性，如果没有它，PyTorch 就没法自动追踪定义的层，模型也就无法训练。
forward(self, x)
- 定义数据的流向。图片进去后，先过哪一层，再过哪一层。
- 不需要手动调用 forward，只需要运行 model(input)，PyTorch 会自动触发 forward。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


import torch
from torch import nn

class myModule(nn.Module):
 def __init__(self):
 super().__init__()

 def forward(self, input):
 output = input + 1 # 简单地将输出 +1 再输出
 return output

卷积 Conv

$$ \text{out}(N_i, C_{\text{out}_j}) = \text{bias}(C_{\text{out}_j}) + \sum_{k = 0}^{C_{\text{in}} - 1} \text{weight}(C_{\text{out}_j}, k) \star \text{input}(N_i, k) $$

卷积动画页面：conv_arithmetic/README.md at master · vdumoulin/conv_arithmetic

参数	含义	作用
in_channels	输入通道数	彩色图通常为 3 (RGB)，灰度图为 1。
out_channels	输出通道数	卷积核的数量。有多少个核，输出就有多少层特征图。
kernel_size	卷积核大小	提取特征的“窗口”大小。常用 3 或 5（VGG 常用 3）。
stride	步长	窗口滑动的跨度。默认为 1。步长越大，输出图片越小。
padding	填充	在图片四周补 0。`'same'` 保持大小不变，`'valid'` 则不补。
dilation	空洞卷积	卷积核点之间的间距。用于扩大感受野（不用增加参数量）。
bias	偏置	是否在结果上加一个常数偏移。默认开启。

卷积的Padding（边界扩充）参数很重要，如果周围不补零，那么卷积会导致图像尺寸越来越小
形状计算公式：

$$ H_{out} = \left\lfloor\frac{H_{in} + 2 \times \text{padding}[0] - \text{dilation}[0] \times (\text{kernel_size}[0] - 1) - 1}{\text{stride}[0]} + 1\right\rfloor $$

$W_{out}$计算同理

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


dataset = torchvision.datasets.CIFAR10("./dataset",train = False, transform=torchvision.transforms.ToTensor(),download=True)
dataloader = DataLoader(dataset, batch_size=64)

class myModule(nn.Module):
 def __init__(self):
 super().__init__()
 self.conv1 = Conv2d(in_channels=3,out_channels=6,kernel_size=3,stride=1,padding=0)

 def forward(self,x):
 x = self.conv1(x)
 return x

mymodule = myModule() # 模型实例化 

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


step = 0
for data in dataloader:
 imgs, targets = data
 output = mymodule(imgs)
 print(imgs.shape)
 # torch.Size([64, 3, 32, 32])
 print(output.shape)
 # torch.Size([64, 6, 30, 30]) channel == 6 卷积后，channel数变化，不能直接输出图像

 step = step + 1

（最大）池化 MaxPool

最大池化的逻辑非常简单：在一个窗口（Kernel）范围内，只保留最大的那个值，剩下的全部扔掉
既保留输入特征，又减小了数据量，加快训练速度

参数	独特之处
kernel_size	窗口大小。常见是 `2`（即将 $2 \times 2$ 的区域合并）。
stride	默认值等于 kernel_size！这和卷积不同。如果 `kernel_size=2`，步长默认就是 `2`，这样窗口之间就不会重叠。
ceil_mode	非常重要。默认是 `False`（向下取整）。如果设为 `True`（向上取整），当窗口超出边界时，只要窗口内有数据，就会保留结果，而不是舍弃。
padding	填充。注意池化填充的是负无穷（$-\infty$），这样是为了保证填充位不会被选为最大值。

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


input = torch.tensor([[1,2,0,3,1],
 [0,1,2,3,1],
 [1,2,1,0,0],
 [5,2,3,1,1],
 [2,1,0,1,1]], dtype=float)

input = torch.reshape(input,(-1,1,5,5))
print(input.shape)

class myMoudle(nn.Module):
 def __init__(self, *args, **kwargs):
 super(myMoudle, self).__init__()
 self.maxpool1 = MaxPool2d(kernel_size=3, ceil_mode=True) 
 '''
 ceil_mode = False 就表示只有当池化核遇到的尺寸是最大尺寸（如3x3）时
 才会取其池化的结果，否则相反
 '''
 def forward(self, input):
 output = self.maxpool1(input)
 return output
 
mymoudle = myMoudle()
output = mymoudle(input)
print(output)

1
2
3


torch.Size([1, 1, 5, 5])
tensor([[[[2., 3.],
 [5., 1.]]]], dtype=torch.float64)

损失函数与反向传播

损失函数用于计算实际输出与目标之间的差距，为反向传播、更新参数提供一定的依据。在分类任务中，常用交叉熵函数来计算误差，

1

loss_func = nn.CrossEntropyLoss()

优化器

torch.optim — PyTorch 2.10 documentation

示例代码：

1
2
3
4
5
6


for input, target in dataset:
 optimizer.zero_grad() # 梯度清零
 output = model(input)
 loss = loss_fn(output, target) # 调用损失函数
 loss.backward() # 反向传播
 optimizer.step() 

Pytorch实战：CIFAR10

针对CIFAR10图像数据集的简单分类模型实战

首先了解Sequential，nn.Sequential 是 nn.Module 的一个特殊子类，它的作用是自动完成 forward 逻辑。注意：其中每一个参数都是某层的类，所以要写逗号。Sequential既简化了模型定义，也简化了forward()。

 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


class CIFAR10_Simple(nn.Module):
 def __init__(self, *args, **kwargs):
 super(CIFAR10_Simple, self).__init__(*args, **kwargs)
 self.conv1 = Conv2d(in_channels=3, out_channels=32, kernel_size=5, padding=2)
 '''
 参数padding的数值可以从想象图像得到：5x5的卷积核，当中心在图像的(0,0)，那么卷积核是扩展出去2格的。上面是简单判断的方法，实际应该用尺寸计算公式来代入计算（参考“Conv卷积”节内容）
 '''
 self.model_s = Sequential(
 Conv2d(in_channels=3, out_channels=32, kernel_size=5, padding=2),
 nn.ReLU(),
 MaxPool2d(kernel_size=2),
 Conv2d(in_channels=32, out_channels=32, kernel_size=5, padding=2),
 nn.ReLU(),
 MaxPool2d(2),
 Conv2d(32,64,5,padding=2),
 nn.ReLU(),
 MaxPool2d(2),
 Flatten(),
 Linear(1024, 64),
 nn.ReLU(),
 Linear(64, 10)
 )

 def forward(self, x):
 '''
 x = self.conv1(x)
 x = self.maxpool1(x)
 x = self.conv2(x)
 x = self.maxpool2(x)
 x = self.conv3(x)
 x = self.maxpool3(x)
 x = self.flatten(x)
 x = self.linear1(x)
 x = self.linear2(x)
 '''
 x = self.model_s(x)
 return x

在搭建模型前，先设置DataLoader处理数据集
- 分别设置好train_data和test_data

1
2
3
4
5
6


dataset_transfrom = tf.Compose([tf.ToTensor(),tf.Normalize((0.5,0.5,0.5),(0.5,0.5,0.5))])
train_data = torchvision.datasets.CIFAR10("./dataset", transform=dataset_transfrom, download=True)
test_data = torchvision.datasets.CIFAR10("./dataset", train=False, transform=dataset_transfrom, download=True)
# --------
train_loader = DataLoader(dataset=train_data, batch_size=64, shuffle=True, drop_last=True)
test_loader = DataLoader(dataset=test_data, batch_size=64, shuffle=True, drop_last=True)

搭建好模型后，简单测试输出尺寸是否符合要求

1
2
3
4
5


cifar = CIFAR10_Simple()
print(cifar)
input = torch.ones((64, 3, 32, 32)) # 同数据集图片尺寸的测试
output = cifar(input)
print(output.shape)

训练前的基本设置
- 定义TensorBoard的writer
- 设置device调用显卡加速训练
- 实例化训练模型
- 定义损失函数
- 设置优化器

1
2
3
4
5
6


writer = SummaryWriter("./logs")
writer.add_graph(cifar, input)
device = torch.device("cuda" if torch.cuda.is_available() else "cpu")
model = CIFAR10_Simple().to(device)
loss_func = nn.CrossEntropyLoss() # 交叉熵损失函数
optim = torch.optim.SGD(cifar.parameters(), lr=0.01) # 学习率

训练部分
- 优化器的定式代码
- 记录训练损失

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


total_step = 0
for epoch in range(10):
 # --- 训练部分 ---
 model.train()
 for data in train_loader:
 imgs, targets = data
 outputs = model(imgs.to(device))
 loss = loss_func(outputs, targets.to(device))
 
 optim.zero_grad()
 loss.backward()
 optim.step()
 
 # 记录训练损失
 writer.add_scalar("Train_Loss", loss.item(), total_step)
 total_step += 1

评估部分
- 每个epoch执行一次
- with torch.no_grad()：关闭梯度记录
- 统计性能指标

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


model.eval()
 total_test_loss = 0
 total_accuracy = 0
 with torch.no_grad(): # 测试时不需要计算梯度，节省性能
 for data in test_loader:
 imgs, targets = data
 imgs, targets = imgs.to(device), targets.to(device)
 outputs = model(imgs)
 
 # 计算总损失
 loss = loss_func(outputs, targets)
 total_test_loss += loss.item()
 
 # 计算准确率：argmax(1) 找到概率最大的类别索引
 accuracy = (outputs.argmax(1) == targets).sum()
 total_accuracy += accuracy

可视化

1
2
3
4
5
6
7


# 输出到 TensorBoard
 writer.add_scalar("Test_Loss", total_test_loss / len(test_loader), epoch)
 writer.add_scalar("Test_Accuracy", total_accuracy / len(test_data), epoch)
 
 print(f"Epoch {epoch+1} 结束，准确率: {total_accuracy / len(test_data)}")

writer.close()

Maven 基础

Tue, 01 Apr 2025 14:49:00 +0800

参考网站

Maven基础 - Java教程 - 廖雪峰的官方网站

Maven 基础

maven介绍

在了解Maven之前，我们先来看看一个Java项目需要的东西。首先，我们需要确定引入哪些依赖包。例如，如果我们需要用到commons logging，我们就必须把commons logging的jar包放入classpath。如果我们还需要log4j，就需要把log4j相关的jar包都放到classpath中。这些就是依赖包的管理。

其次，我们要确定项目的目录结构。例如，src目录存放Java源码，resources目录存放配置文件，bin目录存放编译生成的.class文件。

此外，我们还需要配置环境，例如JDK的版本，编译打包的流程，当前代码的版本号。

最后，除了使用Eclipse这样的IDE进行编译外，我们还必须能通过命令行工具进行编译，才能够让项目在一个独立的服务器上编译、测试、部署。

这些工作难度不大，但是非常琐碎且耗时。如果每一个项目都自己搞一套配置，肯定会一团糟。我们需要的是一个标准化的Java项目管理和构建工具。

Maven就是是专门为Java项目打造的管理和构建工具，它的主要功能有：

提供了一套标准化的项目结构；
提供了一套标准化的构建流程（编译，测试，打包，发布……）；
提供了一套依赖管理机制。

Maven项目结构

一个使用Maven管理的普通的Java项目，它的目录结构默认如下：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


a-maven-project
├── pom.xml
├── src
│ ├── main
│ │ ├── java
│ │ └── resources
│ └── test
│ ├── java
│ └── resources
└── target

项目的根目录a-maven-project是项目名，它有一个项目描述文件pom.xml，存放Java源码的目录是src/main/java，存放资源文件的目录是src/main/resources，存放测试源码的目录是src/test/java，存放测试资源的目录是src/test/resources，最后，所有编译、打包生成的文件都放在target目录里。这些就是一个Maven项目的标准目录结构。

所有的目录结构都是约定好的标准结构，我们千万不要随意修改目录结构。使用标准结构不需要做任何配置，Maven就可以正常使用。

我们再来看最关键的一个项目描述文件pom.xml，它的内容长得像下面：

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


<project ...>
	<modelVersion>4.0.0</modelVersion>
	<groupId>com.itranswarp.learnjava</groupId>
	<artifactId>hello</artifactId>
	<version>1.0</version>
	<packaging>jar</packaging>
	<properties>
 <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
		<maven.compiler.release>17</maven.compiler.release>
	</properties>
	<dependencies>
 <dependency>
 <groupId>org.slf4j</groupId>
 <artifactId>slf4j-simple</artifactId>
 <version>2.0.16</version>
 </dependency>
	</dependencies>
</project>

其中，groupId类似于Java的包名，通常是公司或组织名称，artifactId类似于Java的类名，通常是项目名称，再加上version，一个Maven工程就是由groupId，artifactId和version作为唯一标识。

我们在引用其他第三方库的时候，也是通过这3个变量确定。例如，依赖org.slfj4:slf4j-simple:2.0.16：

1
2
3
4
5


<dependency>
 <groupId>org.slf4j</groupId>
 <artifactId>slf4j-simple</artifactId>
 <version>2.0.16</version>
</dependency>

使用<dependency>声明一个依赖后，Maven就会自动下载这个依赖包并把它放到classpath中。

另外，注意到<properties>定义了一些属性，常用的属性有：

project.build.sourceEncoding：表示项目源码的字符编码，通常应设定为UTF-8；
maven.compiler.release：表示使用的JDK版本，例如21；
maven.compiler.source：表示Java编译器读取的源码版本；
maven.compiler.target：表示Java编译器编译的Class版本。

从Java 9开始，推荐使用maven.compiler.release属性，保证编译时输入的源码和编译输出版本一致。如果源码和输出版本不同，则应该分别设置maven.compiler.source和maven.compiler.target。

通过<properties>定义的属性，就可以固定JDK版本，防止同一个项目的不同的开发者各自使用不同版本的JDK。

小结

Maven是一个Java项目的管理和构建工具：

Maven使用pom.xml定义项目内容，并使用预设的目录结构；
在Maven中声明一个依赖项可以自动下载并导入classpath；
Maven使用groupId，artifactId和version唯一定位一个依赖。

依赖管理

如果我们的项目依赖第三方的jar包，例如commons logging，那么问题来了：commons logging发布的jar包在哪下载？

如果我们还希望依赖log4j，那么使用log4j需要哪些jar包？

类似的依赖还包括：JUnit，JavaMail，MySQL驱动等等，一个可行的方法是通过搜索引擎搜索到项目的官网，然后手动下载zip包，解压，放入classpath。但是，这个过程非常繁琐。

Maven解决了依赖管理问题。例如，我们的项目依赖abc这个jar包，而abc又依赖xyz这个jar包：

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


┌──────────────┐
│Sample Project│
└──────────────┘
 │
 ▼
┌──────────────┐
│ abc │
└──────────────┘
 │
 ▼
┌──────────────┐
│ xyz │
└──────────────┘

当我们声明了abc的依赖时，Maven自动把abc和xyz都加入了我们的项目依赖，不需要我们自己去研究abc是否需要依赖xyz。

因此，Maven的第一个作用就是解决依赖管理。我们声明了自己的项目需要abc，Maven会自动导入abc的jar包，再判断出abc需要xyz，又会自动导入xyz的jar包，这样，最终我们的项目会依赖abc和xyz两个jar包。

我们来看一个复杂依赖示例：

1
2
3
4
5


<dependency>
 <groupId>org.springframework.boot</groupId>
 <artifactId>spring-boot-starter-web</artifactId>
 <version>1.4.2.RELEASE</version>
</dependency>

当我们声明一个spring-boot-starter-web依赖时，Maven会自动解析并判断最终需要大概二三十个其他依赖：

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


spring-boot-starter-web
 spring-boot-starter
 spring-boot
 sprint-boot-autoconfigure
 spring-boot-starter-logging
 logback-classic
 logback-core
 slf4j-api
 jcl-over-slf4j
 slf4j-api
 jul-to-slf4j
 slf4j-api
 log4j-over-slf4j
 slf4j-api
 spring-core
 snakeyaml
 spring-boot-starter-tomcat
 tomcat-embed-core
 tomcat-embed-el
 tomcat-embed-websocket
 tomcat-embed-core
 jackson-databind
 ...

如果我们自己去手动管理这些依赖是非常费时费力的，而且出错的概率很大。

依赖关系

Maven定义了几种依赖关系，分别是compile、test、runtime和provided：

scope	说明	示例
compile	编译时需要用到该jar包（默认）	commons-logging
test	编译Test时需要用到该jar包	junit
runtime	编译时不需要，但运行时需要用到	mysql
provided	编译时需要用到，但运行时由JDK或某个服务器提供	servlet-api

其中，默认的compile是最常用的，Maven会把这种类型的依赖直接放入classpath。

test依赖表示仅在测试时使用，正常运行时并不需要。最常用的test依赖就是JUnit：

1
2
3
4
5
6


<dependency>
 <groupId>org.junit.jupiter</groupId>
 <artifactId>junit-jupiter-api</artifactId>
 <version>5.3.2</version>
 <scope>test</scope>
</dependency>

runtime依赖表示编译时不需要，但运行时需要。最典型的runtime依赖是JDBC驱动，例如MySQL驱动：

1
2
3
4
5
6


<dependency>
 <groupId>mysql</groupId>
 <artifactId>mysql-connector-java</artifactId>
 <version>5.1.48</version>
 <scope>runtime</scope>
</dependency>

provided依赖表示编译时需要，但运行时不需要。最典型的provided依赖是Servlet API，编译的时候需要，但是运行时，Servlet服务器内置了相关的jar，所以运行期不需要：

1
2
3
4
5
6


<dependency>
 <groupId>jakarta.servlet</groupId>
 <artifactId>jakarta.servlet-api</artifactId>
 <version>4.0.0</version>
 <scope>provided</scope>
</dependency>

最后一个问题是，Maven如何知道从何处下载所需的依赖？也就是相关的jar包？答案是Maven维护了一个中央仓库（repo1.maven.org），所有第三方库将自身的jar以及相关信息上传至中央仓库，Maven就可以从中央仓库把所需依赖下载到本地。

Maven并不会每次都从中央仓库下载jar包。一个jar包一旦被下载过，就会被Maven自动缓存在本地目录（用户主目录的.m2目录），所以，除了第一次编译时因为下载需要时间会比较慢，后续过程因为有本地缓存，并不会重复下载相同的jar包。

唯一ID

对于某个依赖，Maven只需要3个变量即可唯一确定某个jar包：

groupId：属于组织的名称，类似Java的包名；
artifactId：该jar包自身的名称，类似Java的类名；
version：该jar包的版本。

通过上述3个变量，即可唯一确定某个jar包。Maven通过对jar包进行PGP签名确保任何一个jar包一经发布就无法修改。修改已发布jar包的唯一方法是发布一个新版本。

因此，某个jar包一旦被Maven下载过，即可永久地安全缓存在本地。

注：只有以-SNAPSHOT结尾的版本号会被Maven视为开发版本，开发版本每次都会重复下载，这种SNAPSHOT版本只能用于内部私有的Maven repo，公开发布的版本不允许出现SNAPSHOT。

后续我们在表示Maven依赖时，使用简写形式groupId:artifactId:version，例如：org.slf4j:slf4j-api:2.0.4。

Maven镜像

除了可以从Maven的中央仓库下载外，还可以从Maven的镜像仓库下载。如果访问Maven的中央仓库非常慢，我们可以选择一个速度较快的Maven的镜像仓库。Maven镜像仓库定期从中央仓库同步：

1
2
3
4
5
6
7
8
9


 slow ┌───────────────────┐
 ┌─────────────▶│Maven Central Repo.│
 │ └───────────────────┘
 │ │
 │ │sync
 │ ▼
┌───────┐ fast ┌───────────────────┐
│ User │─────────▶│Maven Mirror Repo. │
└───────┘ └───────────────────┘

中国区用户可以使用阿里云提供的Maven镜像仓库。使用Maven镜像仓库需要一个配置，在用户主目录下进入.m2目录，创建一个settings.xml配置文件，内容如下：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


<settings>
 <mirrors>
 <mirror>
 <id>aliyun</id>
 <name>aliyun</name>
 <mirrorOf>central</mirrorOf>
 <!-- 国内推荐阿里云的Maven镜像 -->
 <url>https://maven.aliyun.com/repository/central</url>
 </mirror>
 </mirrors>
</settings>

配置镜像仓库后，Maven的下载速度就会非常快。

搜索第三方组件

最后一个问题：如果我们要引用一个第三方组件，比如okhttp，如何确切地获得它的groupId、artifactId和version？方法是通过search.maven.org搜索关键字，找到对应的组件后，直接复制

命令行编译

在命令中，进入到pom.xml所在目录，输入以下命令：

1

$ mvn clean package

如果一切顺利，即可在target目录下获得编译后自动打包的jar。

在IDE中使用Maven

几乎所有的IDE都内置了对Maven的支持。在Eclipse中，可以直接创建或导入Maven项目。如果导入后的Maven项目有错误，可以尝试选择项目后点击右键，选择Maven - Update Project…更新

小结

Maven通过解析依赖关系确定项目所需的jar包，常用的4种scope有：compile（默认），test，runtime和provided；

Maven从中央仓库下载所需的jar包并缓存在本地；

可以通过镜像仓库加速下载。

构建流程

Maven不但有标准化的项目结构，而且还有一套标准化的构建流程，可以自动化实现编译，打包，发布，等等。

Lifecycle和Phase

使用Maven时，我们首先要了解什么是Maven的生命周期（lifecycle）。

Maven的生命周期由一系列阶段（phase）构成，以内置的生命周期default为例，它包含以下phase：

validate 校验
initialize 初始化
generate-sources 生成源码
process-sources 处理源码
generate-resources 生成资源
process-resources 处理资源
compile 编译
process-classes 处理-classes
generate-test-sources 生成测试源码
process-test-sources 处理测试源码
generate-test-resources 生成测试资源
process-test-resources 处理测试资源
test-compile 测试编译
process-test-classes 处理测试-classes
test 测试
prepare-package 准备打包
package 打包
pre-integration-test 预综合测试
integration-test 综合测试
post-integration-test 综合测试之后
verify 核实
install 安装
deploy 部署

如果我们运行mvn package，Maven就会执行default生命周期，它会从开始一直运行到package这个phase为止：

validate
initialize
…
prepare-package
package

如果我们运行mvn compile，Maven也会执行default生命周期，但这次它只会运行到compile，即以下几个phase：

validate
initialize
…
process-resources
compile

Maven另一个常用的生命周期是clean，它会执行3个phase：

pre-clean
clean （注意这个clean不是lifecycle而是phase）
post-clean

所以，我们使用mvn这个命令时，后面的参数是phase，Maven自动根据生命周期运行到指定的phase。

更复杂的例子是指定多个phase，例如，运行mvn clean package，Maven先执行clean生命周期并运行到clean这个phase，然后执行default生命周期并运行到package这个phase，实际执行的phase如下：

pre-clean
clean （注意这个clean是phase）
validate （开始执行default生命周期的第一个phase）
initialize
…
prepare-package
package

在实际开发过程中，经常使用的命令有：

mvn clean：清理所有生成的class和jar；

mvn clean compile：先清理，再执行到compile；

mvn clean test：先清理，再执行到test，因为执行test前必须执行compile，所以这里不必指定compile；

mvn clean package：先清理，再执行到package。

大多数phase在执行过程中，因为我们通常没有在pom.xml中配置相关的设置，所以这些phase什么事情都不做。

经常用到的phase其实只有几个：

clean：清理
compile：编译
test：运行测试
package：打包

Goal

执行一个phase又会触发一个或多个goal：

执行的Phase	对应执行的Goal
compile	compiler:compile
test	compiler:testCompile surefire:test

goal的命名总是abc:xyz这种形式。

其实我们类比一下就明白了：

lifecycle相当于Java的package，它包含一个或多个phase；
phase相当于Java的class，它包含一个或多个goal；
goal相当于class的method，它其实才是真正干活的。

大多数情况，我们只要指定phase，就默认执行这些phase默认绑定的goal，只有少数情况，我们可以直接指定运行一个goal，例如，启动Tomcat服务器：

1

$ mvn tomcat:run

小结

Maven通过lifecycle、phase和goal来提供标准的构建流程。

最常用的构建命令是指定phase，然后让Maven执行到指定的phase：

mvn clean
mvn clean compile
mvn clean test
mvn clean package

通常情况，我们总是执行phase默认绑定的goal，因此不必指定goal。

Java 多线程

Fri, 21 Mar 2025 14:50:07 +0800

参考网站

多线程 - Java教程 - 廖雪峰的官方网站

多数参考了廖老师的博客非常好教程

万字图解Java多线程 - 个人文章 - SegmentFault 思否

相对没那么详细，就讲到同步锁和线程池，简洁清晰

也补充了一些知识，例如线程状态，同步锁，生产者消费者模型……

Java 多线程

进程/线程

进程和线程的关系： 一个进程可以包含一个或多个线程 ，但至少会有一个线程。

操作系统调度的 最小任务单位 其实不是进程，而是线程。常用的Windows、Linux等操作系统都采用抢占式多任务，如何调度线程完全由操作系统决定，程序自己不能决定什么时候执行，以及执行多长时间。

多任务既可以由多进程实现，也可以由单进程内的多线程实现，还可以混合多进程＋多线程

和多线程相比，多进程的缺点在于：

创建进程比创建线程开销大，尤其是在Windows系统上
进程间通信比线程间通信要慢，因为线程间通信就是读写同一个变量，速度很快

多进程的优点在于：

多进程 稳定性 比多线程高，因为在多进程的情况下，一个进程崩溃不会影响其他进程
在多线程的情况下，任何一个线程崩溃会直接导致整个进程崩溃

多线程

Java语言内置了多线程支持：一个Java程序实际上是一个 JVM进程 ，JVM进程用一个主线程来执行main()方法，在main()方法内部，我们又可以启动多个线程。此外，JVM还有负责垃圾回收的其他工作线程等。

和单线程相比，多线程编程的特点在于：多线程经常需要 读写共享数据，并且需要同步 。

例如，播放电影时，就必须由一个线程播放视频，另一个线程播放音频，两个线程需要协调运行，否则画面和声音就不同步。因此，多线程编程的复杂度高，调试更困难。

创建多线程

创建新线程 - Java教程 - 廖雪峰的官方网站

要创建一个新线程非常容易，我们需要实例化一个Thread实例，然后调用它的start()方法：

1
2
3
4
5
6


public class Main {
 public static void main(String args[]) {
 Thread t = new Thread();
 t.start();
 }
}

令新线程能执行指定的代码，有以下几种方法：

方法一 ：从Thread派生一个自定义类，然后覆写run()方法：

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


public class Main {
 public static void main(String args[]) {
 Thread t = new Thread();
 t.start();
 }
}
class MyThread extends Thread {
 @Overread
 public void run(){
 	System.out.println("start new thread!");
 }
}

执行上述代码，注意到start()方法会在内部自动调用实例的run()方法。

方法二 ：创建Thread实例时，传入一个Runnable实例

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


public class Main {
 public static void main(String[] args) {
 Thread t = new Thread(new MyRunnable());
 t.start(); // 启动新线程
 }
}
class MyRunnable implements Runnable {
 @Override
 public void run() {
 System.out.println("start new thread!");
 }
}

或者用Java 8引入的lambda语法进一步简写为：

1
2
3
4
5
6
7
8


public class Main {
 public static void main(String[] args) {
 Thread t = new Thread(() -> {
 System.out.println("start new thread!");
 });
 t.start(); // 启动新线程
 }
}

但是，直接调用 run() 方法，并不能实现多线程，当前线程也不会改变，而只是执行 run() 方法

必须调用Thread实例的start()方法才能启动新线程，如果我们查看Thread类的源代码，会看到start()方法内部调用了一个private native void start0()方法，native修饰符表示这个方法是由JVM虚拟机内部的C代码实现的，不是由Java代码实现的。

使用线程和直接在 main() 方法中执行的区别：

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


public class Main {
 public static void main(String[] args) {
 System.out.println("main start...");
 Thread t = new Thread() {
 public void run() {
 System.out.println("thread run...");
 System.out.println("thread end.");
 }
 };
 t.start();
 System.out.println("main end...");
 }
}

main 中命令执行顺序：

打印 main start...
创建 Thread 对象
start 启动新线程
当start()方法被调用时，JVM就创建了一个新线程，我们通过实例变量t来表示这个新线程对象，并开始执行。
打印 main end...

但是，在 t 线程开始运行后， main 和 t 就 同时运行 了，此时程序本身无法确定线程的调度顺序

要模拟并发执行的效果，我们可以在线程中调用Thread.sleep()，参数的单位是毫秒， sleep() 强迫当前线程暂停一段时间：

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


public class Main {
 public static void main(String[] args) {
 System.out.println("main start...");
 Thread t = new Thread() {
 public void run() {
 System.out.println("thread run...");
 try {
 Thread.sleep(10);
 } catch (InterruptedException e) {}
 System.out.println("thread end.");
 }
 };
 t.start();
 try {
 Thread.sleep(20);
 } catch (InterruptedException e) {}
 System.out.println("main end...");
 }
}

线程的优先级

1

Thread.setPriority(int n) //默认为5

JVM自动把1（低）~10（高）的优先级映射到操作系统实际优先级上（不同操作系统有不同的优先级数量）。优先级高的线程被操作系统调度的优先级较高，操作系统对高优先级线程可能调度更频繁，但我们 决不能通过设置优先级来确保高优先级的线程一定会先执行 。cpu比较忙时，优先级高的线程获取更多的时间片，cpu比较闲时，优先级设置基本没用

yield() 方法会让运行中的线程切换到就绪状态，重新争抢cpu的时间片，争抢时是否获取到时间片看cpu的分配。

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


public static native void yield();

Runnable r1 = () -> {
 int count = 0;
 for (;;){
 log.info("---- 1>" + count++);
 }
};
Runnable r2 = () -> {
 int count = 0;
 for (;;){
 Thread.yield();
 log.info(" ---- 2>" + count++);
 }
};
Thread t1 = new Thread(r1,"t1");
Thread t2 = new Thread(r2,"t2");
t1.start();
t2.start();

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


// 运行结果
11:49:15.796 [t1] INFO thread.TestYield - ---- 1>129504
11:49:15.796 [t1] INFO thread.TestYield - ---- 1>129505
11:49:15.796 [t1] INFO thread.TestYield - ---- 1>129506
11:49:15.796 [t1] INFO thread.TestYield - ---- 1>129507
11:49:15.796 [t1] INFO thread.TestYield - ---- 1>129508
11:49:15.796 [t1] INFO thread.TestYield - ---- 1>129509
11:49:15.796 [t1] INFO thread.TestYield - ---- 1>129510
11:49:15.796 [t1] INFO thread.TestYield - ---- 1>129511
11:49:15.796 [t1] INFO thread.TestYield - ---- 1>129512
11:49:15.798 [t2] INFO thread.TestYield - ---- 2>293
11:49:15.798 [t1] INFO thread.TestYield - ---- 1>129513
11:49:15.798 [t1] INFO thread.TestYield - ---- 1>129514
11:49:15.798 [t1] INFO thread.TestYield - ---- 1>129515
11:49:15.798 [t1] INFO thread.TestYield - ---- 1>129516
11:49:15.798 [t1] INFO thread.TestYield - ---- 1>129517
11:49:15.798 [t1] INFO thread.TestYield - ---- 1>129518

如上述结果所示，t2线程每次执行时进行了yield()，线程1执行的机会明显比线程2要多。

小结

Java用Thread对象表示一个线程，通过调用start()启动一个新线程
一个线程对象只能调用一次start()方法
线程的执行代码写在run()方法中
线程调度由操作系统决定，程序本身无法决定调度顺序
Thread.sleep()可以把当前线程暂停一段时间

线程的阻塞

使得线程阻塞的方式有下面几种：

BIO阻塞，即使用了阻塞式的io流
sleep(long time) 让线程休眠进入阻塞状态
a.join() 调用该方法的线程进入阻塞，等待a线程执行完恢复运行
sychronized或ReentrantLock 造成线程未获得锁进入阻塞状态
获得锁之后调用wait()方法也会让线程进入阻塞状态
LockSupport.park() 让线程进入阻塞状态

`Thread.sleep()`

使线程休眠，会将运行中的线程进入阻塞状态。当休眠时间结束后，重新争抢cpu的时间片继续运行

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


// 方法的定义 native方法
public static native void sleep(long millis) throws InterruptedException; 

try {
 // 休眠2秒
 // 该方法会抛出 InterruptedException异常 即休眠过程中可被中断，被中断后抛出异常
 Thread.sleep(2000);
 } catch (InterruptedException异常 e) {
 }
 try {
 // 使用TimeUnit的api可替代 Thread.sleep 
 TimeUnit.SECONDS.sleep(1);
 } catch (InterruptedException e) {
 }

`Thread.join()`

一个线程还可以等待另一个线程直到其运行结束。例如，main线程在启动t线程后，可以通过t.join()等待t线程结束后再继续运行：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


public class Main {
 public static void main(String[] args) throws InterruptedException {
 Thread t = new Thread(() -> {
 System.out.println("hello");
 });	//java8 lambda方式
 System.out.println("start");
 t.start(); // 启动t线程
 t.join(); // 此处main线程会等待t结束
 System.out.println("end");
 }
}

当main线程对线程对象t调用join()方法时，主线程将等待变量t表示的线程运行结束，即join就是指等待该线程结束， 然后才继续往下执行自身线程 。所以，上述代码打印顺序可以肯定是main线程先打印start，t线程再打印hello，main线程最后再打印end。

如果t线程已经结束，对实例t调用join()会立刻返回。此外，join(long)的重载方法也可以指定一个等待时间，超过等待时间后就不再继续等待。

小结

线程阻塞的常见方式：BIO阻塞、sleep()、join()、未获取锁（synchronized/ReentrantLock）、wait()、LockSupport.park()。
sleep() ：让线程休眠指定时间，可被中断，推荐用TimeUnit增强可读性。
join() ：让当前线程等待目标线程执行完毕，常用于控制线程执行顺序。
阻塞与恢复：线程进入阻塞后，需等待特定条件（如时间结束、锁释放、目标线程完成）才能恢复运行。

中断线程

中断线程 - Java教程 - 廖雪峰的官方网站

如果线程需要执行一个长时间任务，就可能需要能中断线程。中断线程就是其他线程给该线程发一个信号，该线程收到信号后结束执行run()方法，使得自身线程能立刻结束运行。

例如，从网络下载一个100M的文件，如果网速很慢，用户等得不耐烦，就可能在下载过程中点“取消”，这时，程序就需要中断下载线程的执行。

`Thread.interrupt`

中断一个线程非常简单，只需要在其他线程中对目标线程调用interrupt()方法，目标线程需要反复检测自身状态是否是interrupted状态， 如果是，就立刻结束运行 。

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


public class Main {
 public static void main(String[] args) throws InterruptedException {
 Thread t = new MyThread();
 t.start();
 Thread.sleep(1); // 暂停1毫秒
 t.interrupt(); // 中断t线程
 t.join(); // 等待t线程结束
 System.out.println("end");
 }
}

class MyThread extends Thread {
 public void run() {
 int n = 0;
 while (! isInterrupted()) {
 n++;
 System.out.println(n + " hello!");
 }
 }
}

上述代码，main线程通过调用t.interrupt()方法中断t线程，但是要注意，interrupt()方法 仅仅向t线程发出了“中断请求” ，至于t线程 是否能立刻响应，要看具体代码 。而t线程的while循环会检测isInterrupted()，所以上述代码能正确响应interrupt()请求，使得自身立刻结束运行run()方法。

如果线程处于等待状态，例如，t.join()会让main线程进入等待状态，此时，如果对main线程调用interrupt()， join()方法会立刻抛出InterruptedException ，因此，目标线程只要捕获到join()方法抛出的InterruptedException，就说明有其他线程对其调用了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
36
37
38


public class Main {
 public static void main(String[] args) throws InterruptedException {
 Thread t = new MyThread();
 t.start();
 Thread.sleep(1000);
 t.interrupt(); // 中断t线程
 t.join(); // 等待t线程结束
 System.out.println("end");
 }
}

class MyThread extends Thread {
 public void run() {
 Thread hello = new HelloThread();
 hello.start(); // 启动hello线程
 try {
 hello.join(); // 等待hello线程结束
 } catch (InterruptedException e) {
 System.out.println("interrupted!");
 }
 hello.interrupt();
 }
}

class HelloThread extends Thread {
 public void run() {
 int n = 0;
 while (!isInterrupted()) {
 n++;
 System.out.println(n + " hello!");
 try {
 Thread.sleep(100);
 } catch (InterruptedException e) {
 break;
 }
 }
 }
}

main线程通过调用t.interrupt()从而通知t线程中断
此时t线程正位于hello.join()的等待中，此方法会立刻结束等待并抛出InterruptedException
在t线程中捕获了InterruptedException，准备结束该线程
t线程结束前，对hello线程也进行了interrupt()调用通知其中断

`running`标志位

另一个常用的中断线程的方法是设置标志位。我们通常会用一个running标志位来标识线程是否应该继续运行，在外部线程中，通过把HelloThread.running置为false，就可以让线程结束：

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


public class Main {
 public static void main(String[] args) throws InterruptedException {
 HelloThread t = new HelloThread();
 t.start();
 Thread.sleep(1);
 t.running = false; // 标志位置为false
 }
}

class HelloThread extends Thread {
 public volatile boolean running = true;
 public void run() {
 int n = 0;
 while (running) {
 n ++;
 System.out.println(n + " hello!");
 }
 System.out.println("end!");
 }
}

注意到HelloThread的标志位boolean running是一个 线程间共享的变量 。线程间共享变量需要使用volatile关键字标记，确保 每个线程都能读取到更新后的变量值 。

`volatile` 的用处

为什么要对线程间共享的变量用关键字volatile声明？这涉及到Java的内存模型。在Java虚拟机中，变量的值保存在主内存中，但是，当线程访问变量时，它会先获取一个副本，并保存在自己的工作内存中。如果线程修改了变量的值，虚拟机会在某个时刻把修改后的值回写到主内存，但是， 这个时间是不确定的 ！

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


// 这图画得真有水平罢 
┌ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ┐
 Main Memory
│ │
 ┌───────┐┌───────┐┌───────┐
│ │ var A ││ var B ││ var C │ │
 └───────┘└───────┘└───────┘
│ │ ▲ │ ▲ │
 ─ ─ ─│─│─ ─ ─ ─ ─ ─ ─ ─│─│─ ─ ─
 │ │ │ │
┌ ─ ─ ┼ ┼ ─ ─ ┐ ┌ ─ ─ ┼ ┼ ─ ─ ┐
 ▼ │ ▼ │
│ ┌───────┐ │ │ ┌───────┐ │
 │ var A │ │ var C │
│ └───────┘ │ │ └───────┘ │
 Thread 1 Thread 2
└ ─ ─ ─ ─ ─ ─ ┘ └ ─ ─ ─ ─ ─ ─ ┘

这会导致如果一个线程更新了某个变量，另一个线程读取的值可能还是更新前的。

例如，主内存的变量a = true，线程1执行a = false时，它在此刻仅仅是把变量a的副本变成了false，主内存的变量a还是true，在JVM把修改后的a回写到主内存之前，其他线程读取到的a的值仍然是true，这就造成了 多线程之间共享的变量不一致 。

因此，volatile关键字的目的是告诉虚拟机：

每次访问变量时，总是获取主内存的最新值；
每次修改变量后，立刻回写到主内存。

volatile关键字解决的是可见性问题：当一个线程 修改了某个共享变量的值，其他线程能够立刻看到修改后的值 。

如果我们去掉volatile关键字，运行上述程序，发现效果和带volatile差不多，这是因为在x86的架构下，JVM回写主内存的速度非常快，但是，换成ARM的架构，就会有显著的延迟。

小结

对目标线程调用interrupt()方法可以请求中断一个线程，目标线程通过检测isInterrupted()标志获取自身是否已中断。如果目标线程处于等待状态，该线程会捕获到InterruptedException；

目标线程检测到isInterrupted()为true或者捕获了InterruptedException都应该立刻结束自身线程；

通过标志位判断需要正确使用volatile关键字；

volatile关键字解决了共享变量在线程间的可见性问题。

线程状态

万字图解Java多线程 - 个人文章 - SegmentFault 思否

线程的状态 - Java教程 - 廖雪峰的官方网站

系统 - 五种状态

线程的状态可从操作系统层面分为五种状态

初始状态：创建线程对象时的状态
可运行状态(就绪状态)：调用 start() 方法后进入就绪状态，也就是准备好被cpu调度执行
运行状态：线程获取到cpu的时间片，执行 run() 方法的逻辑
阻塞状态: 线程被阻塞，放弃cpu的时间片，等待解除阻塞重新回到就绪状态争抢时间片
终止状态: 线程执行完成或抛出异常后的状态

Java - 六种状态

在Java程序中，一个线程对象只能调用一次start()方法启动新线程，并在新线程中执行run()方法。一旦run()方法执行完毕，线程就结束了。因此，Java线程的状态有以下几种：

NEW 线程对象被创建
Runnable 线程调用了 start() 方法后进入该状态，该状态包含了三种情况
1. 就绪状态 :等待cpu分配时间片
2. 运行状态:进入Runnable方法执行任务
3. 阻塞状态:BIO 执行阻塞式io流时的状态
Blocked 没获取到锁时的阻塞状态(同步锁章节会细说)
WAITING 调用 wait() join() 等方法后的状态
TIMED_WAITING 调用 sleep(time) wait(time) join(time) 等方法后的状态
TERMINATED 线程执行完成或抛出异常后的状态

当线程启动后，它可以在Runnable、Blocked、Waiting和Timed Waiting这几个状态之间切换，直到最后变成Terminated状态，线程终止。

线程终止的原因有：

线程正常终止：run()方法执行到return语句返回；
线程意外终止：run()方法因为未捕获的异常导致线程终止；
对某个线程的Thread实例调用stop()方法强制终止（强烈不推荐使用）。

Thread类中的核心方法

方法名称	是否static	方法说明
start()	否	让线程启动，进入就绪状态,等待cpu分配时间片
run()	否	重写Runnable接口的方法,线程获取到cpu时间片时执行的具体逻辑
yield()	是	线程的礼让，使得获取到cpu时间片的线程进入就绪状态，重新争抢时间片
sleep(time)	是	线程休眠固定时间，进入阻塞状态，休眠时间完成后重新争抢时间片,休眠可被打断
join()/join(time)	否	调用线程对象的join方法，调用者线程进入阻塞,等待线程对象执行完或者到达指定时间才恢复，重新争抢时间片
isInterrupted()	否	获取线程的打断标记，true:被打断，false：没有被打断。调用后不会修改打断标记
interrupt()	否	打断线程，抛出InterruptedException异常的方法均可被打断，但是打断后不会修改打断标记，正常执行的线程被打断后会修改打断标记
interrupted()	否	获取线程的打断标记。调用后会清空打断标记
stop()	否	停止线程运行不推荐
suspend()	否	挂起线程不推荐
resume()	否	恢复线程运行不推荐
currentThread()	是	获取当前线程

Object中与线程相关方法

方法名称	方法说明
wait()/wait(long timeout)	获取到锁的线程进入阻塞状态
notify()	随机唤醒被wait()的一个线程
notifyAll();	唤醒被wait()的所有线程，重新争抢时间片

守护线程

守护线程 - Java教程 - 廖雪峰的官方网站

Java程序入口就是由JVM启动main线程，main线程又可以启动其他线程。当所有线程都运行结束时，JVM退出，进程结束。

如果有一个线程没有退出，JVM进程就不会退出。所以，必须保证所有线程都能及时结束。

但是有一种线程的目的就是无限循环，例如，一个定时触发任务的线程：

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


class TimerThread extends Thread {
 @Override
 public void run() {
 while (true) {
 System.out.println(LocalTime.now());
 try {
 Thread.sleep(1000);
 } catch (InterruptedException e) {
 break;
 }
 }
 }
}

如果这个线程不结束，JVM进程就无法结束。问题是，由谁负责结束这个线程？

然而这类线程经常没有负责人来负责结束它们。但是，当其他线程结束时，JVM进程又必须要结束，怎么办？

答案是使用守护线程（Daemon Thread）。

守护线程是指为其他线程服务的线程。在JVM中， 所有非守护线程都执行完毕后 ，无论有没有守护线程，虚拟机都会自动退出。

因此，JVM退出时，不必关心守护线程是否已结束。

如何创建守护线程呢？方法和普通线程一样，只是在调用start()方法前， 调用setDaemon(true)把该线程标记为守护线程 ：

1
2
3


Thread t = new MyThread();
t.setDaemon(true);
t.start();

在守护线程中，编写代码要注意： 守护线程不能持有任何需要关闭的资源 ，例如打开文件等，因为虚拟机退出时，守护线程没有任何机会来关闭文件，这会导致数据丢失。

小结

守护线程是为其他线程服务的线程；

所有非守护线程都执行完毕后，虚拟机退出，守护线程随之结束；

守护线程不能持有需要关闭的资源（如打开文件等）。

线程同步

线程同步 - Java教程 - 廖雪峰的官方网站

当多个线程同时运行时，线程的调度由操作系统决定，程序本身无法决定。因此，任何一个线程都有可能在任何指令处被操作系统暂停，然后在某个时间段后继续执行。

这个时候，有个单线程模型下不存在的问题就来了：如果多个线程同时读写共享变量，会出现数据不一致的问题。

我们来看一个例子：

 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


// 多线程
public class Main {
 public static void main(String[] args) throws Exception {
 var add = new AddThread();
 var dec = new DecThread();
 add.start();
 dec.start();
 add.join();
 dec.join();
 System.out.println(Counter.count);
 }
}

class Counter {
 public static int count = 0;
}

class AddThread extends Thread {
 public void run() {
 for (int i=0; i<10000; i++) { Counter.count += 1; }
 }
}

class DecThread extends Thread {
 public void run() {
 for (int i=0; i<10000; i++) { Counter.count -= 1; }
 }
}

上面的代码很简单，两个线程同时对一个int变量进行操作，一个加10000次，一个减10000次，最后结果应该是0，但是，每次运行，结果实际上都是不一样的。

这是因为对变量进行读取和写入时，结果要正确， 必须保证是原子操作 。原子操作是指不能被中断的一个或一系列操作。

例如，对于语句：

1

n = n + 1;

看上去是一行语句，实际上对应了3条指令：

1
2
3


ILOAD
IADD
ISTORE

我们假设n的值是100，如果两个线程同时执行n = n + 1，得到的结果很可能不是102，而是101，原因在于：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


┌───────┐ ┌───────┐
│Thread1│ │Thread2│
└───┬───┘ └───┬───┘
 │ │
 │ILOAD (100) │
 │ │ILOAD (100)
 │ │IADD
 │ │ISTORE (101)
 │IADD │
 │ISTORE (101) │
 ▼ ▼

如果线程1在执行ILOAD后被操作系统中断，此刻如果线程2被调度执行，它执行ILOAD后获取的值仍然是100，最终结果被两个线程的ISTORE写入后变成了101，而不是期待的102。

这说明多线程模型下，要保证逻辑正确，对共享变量进行读写时， 必须保证一组指令以原子方式执行：即某一个线程执行时，其他线程必须等待 ：

`synchronized 同步锁`

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


┌───────┐ ┌───────┐
│Thread1│ │Thread2│
└───┬───┘ └───┬───┘
 │ │
 │-- lock -- │
 │ILOAD (100) │
 │IADD │
 │ISTORE (101) │
 │-- unlock -- │
 │ │-- lock --
 │ │ILOAD (101)
 │ │IADD
 │ │ISTORE (102)
 │ │-- unlock --
 ▼ ▼

通过加锁和解锁的操作，就能保证3条指令总是在一个线程执行期间，不会有其他线程会进入此指令区间。即使在执行期线程被操作系统中断执行，其他线程也会因为无法获得锁导致无法进入此指令区间。只有执行线程将锁释放后，其他线程才有机会获得锁并执行。这种加锁和解锁之间的代码块我们称之为临界区(Critical Section)，任何时候临界区最多只有一个线程能执行。

可见， 保证一段代码的原子性就是通过加锁和解锁实现的 。Java程序使用synchronized关键字对一个对象进行加锁：

1
2
3


synchronized(lock) {
 n = n + 1;
}

synchronized保证了代码块在 任意时刻最多只有一个线程能执行 。我们把上面的代码用synchronized改写如下：

 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


// 多线程
public class Main {
 public static void main(String[] args) throws Exception {
 var add = new AddThread();
 var dec = new DecThread();
 add.start();
 dec.start();
 add.join();
 dec.join();
 System.out.println(Counter.count);
 }
}

class Counter {
 public static final Object lock = new Object();
 public static int count = 0;
}

class AddThread extends Thread {
 public void run() {
 for (int i=0; i<10000; i++) {
 synchronized(Counter.lock) {
 Counter.count += 1;
 }
 }
 }
}

class DecThread extends Thread {
 public void run() {
 for (int i=0; i<10000; i++) {
 synchronized(Counter.lock) {
 Counter.count -= 1;
 }
 }
 }
}

注意到代码：

1
2
3


synchronized(Counter.lock) { // 获取锁
 ...
} // 释放锁

它表示用Counter.lock实例作为锁，两个线程在执行各自的synchronized(Counter.lock) { ... }代码块时，必须先获得锁，才能进入代码块进行。执行结束后，在synchronized语句块结束会自动释放锁。这样一来，对Counter.count变量进行读写就不可能同时进行。上述代码无论运行多少次，最终结果都是0。

使用synchronized解决了多线程同步访问共享变量的正确性问题。但是，它的缺点是带来了性能下降。因为synchronized代码块无法并发执行。此外，加锁和解锁需要消耗一定的时间，所以，synchronized会降低程序的执行效率。

我们来概括一下如何使用synchronized：

找出修改共享变量的线程代码块；
选择一个共享实例作为锁；
使用synchronized(lockObject) { ... }。

在使用synchronized的时候， 不必担心抛出异常 。因为无论是否有异常，都会在synchronized结束处正确释放锁：

1
2
3
4
5
6
7
8


public void add(int m) {
 synchronized (obj) {
 if (m < 0) {
 throw new RuntimeException();
 }
 this.value += m;
 } // 无论有无异常，都会在此释放锁
}

此外，多个线程各自都可以同时获得锁：因为JVM只保证同一个锁在任意时刻只能被一个线程获取， 但两个不同的锁在同一时刻可以被两个线程分别获取 。

因此，使用synchronized的时候， 获取到的是哪个锁非常重要 。锁对象如果不对，代码逻辑就不对。

下面是应用了两个不同的锁来提升效率的示例：

 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


public class Main {
 public static void main(String[] args) throws Exception {
 var ts = new Thread[] { new AddStudentThread(), new DecStudentThread(), new AddTeacherThread(), new DecTeacherThread() };
 for (var t : ts) {
 t.start();
 }
 for (var t : ts) {
 t.join();
 }
 System.out.println(Counter.studentCount);
 System.out.println(Counter.teacherCount);
 }
}

class Counter {
 public static final Object lockStudent = new Object();
 public static final Object lockTeacher = new Object();
 public static int studentCount = 0;
 public static int teacherCount = 0;
}

class AddStudentThread extends Thread {
 public void run() {
 for (int i=0; i<10000; i++) {
 synchronized(Counter.lockStudent) {
 Counter.studentCount += 1;
 }
 }
 }
}

class DecStudentThread extends Thread {
 public void run() {
 for (int i=0; i<10000; i++) {
 synchronized(Counter.lockStudent) {
 Counter.studentCount -= 1;
 }
 }
 }
}

class AddTeacherThread extends Thread {
 public void run() {
 for (int i=0; i<10000; i++) {
 synchronized(Counter.lockTeacher) {
 Counter.teacherCount += 1;
 }
 }
 }
}

class DecTeacherThread extends Thread {
 public void run() {
 for (int i=0; i<10000; i++) {
 synchronized(Counter.lockTeacher) {
 Counter.teacherCount -= 1;
 }
 }
 }
}

不需要 `synchronized` 的操作

JVM规范定义了几种原子操作：

基本类型（long和double除外）赋值，例如：int n = m；
引用类型赋值，例如：List<String> list = anotherList。

long和double是64位数据，JVM没有明确规定64位赋值操作是不是一个原子操作，不过在x64平台的JVM是把long和double的赋值作为原子操作实现的。

单条原子操作的语句不需要同步。例如：

1
2
3
4
5


public void set(int m) {
 synchronized(lock) {
 this.value = m;
 }
}

就不需要同步。

对引用也是类似。例如：

1
2
3


public void set(String s) {
 this.value = s;
}

上述 赋值语句 并不需要同步。

但是，如果是 多行赋值语句，就必须保证是同步操作 ，例如：

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


class Point {
 int x;
 int y;
 public void set(int x, int y) {
 synchronized(this) {
 this.x = x;
 this.y = y;
 }
 }
 public int[] get() {
 synchronized(this) {
 return new int[]{x,y};
 }
 }
}

上面的读写，即( set(), get() )需要同步，在读的时候若是不同步，会造成程序的逻辑错误：

1
2
3
4
5


public int[] get() {
 int[] copy = new int[2];
 copy[0] = x;
 copy[1] = y;
 }

假定当前坐标是(100, 200)，那么当设置新坐标为(110, 220)时，上述未同步的多线程读到的值可能有：

(100, 200)：x，y更新前；
(110, 200)：x更新后，y更新前；
(110, 220)：x，y更新后。

如果读取到(110, 200)，即读到了更新后的x，更新前的y，无法保证读取的多个变量状态保持一致。

有些时候，通过一些巧妙的转换，可以把非原子操作变为原子操作。例如，上述代码如果改造成：

1
2
3
4
5
6
7


class Point {
 int[] ps;
 public void set(int x, int y) {
 int[] ps = new int[] { x, y };
 this.ps = ps;
 }
}

就不再需要写同步，因为this.ps = ps是引用赋值的原子操作。而语句：

1

int[] ps = new int[] { x, y };

这里的ps是方法内部定义的局部变量，每个线程都会有各自的局部变量，互不影响，并且互不可见，并不需要同步。

不过要注意，读方法在复制int[]数组的过程中仍然需要同步。

不可变对象无需同步

不可变对象是指创建后状态不能被修改的对象。在 Java 中，典型的不可变对象包括：

String
List.of() 创建的不可变集合（Java 9+）
基本类型的包装类（如 Integer, Long 等）

如果多线程读写的是一个不可变对象，那么无需同步，因为不会修改对象的状态：

1
2
3
4
5
6
7
8
9


class Data {
 List<String> names;
 void set(String[] names) {
 this.names = List.of(names);
 }
 List<String> get() {
 return this.names;
 }
}

注意到set()方法内部创建了一个不可变List，这个List包含的对象也是不可变对象String，因此，整个List<String>对象都是不可变的，因此读写均无需同步。

分析变量是否能被多线程访问时，首先要理清概念，多线程同时执行的是方法。对于下面这个例子：

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


class Status {
 List<String> names;
 int x;
 int y;
 void set(String[] names, int n) {
 List<String> ns = List.of(names);
 this.names = ns;
 int step = n * 10;
 this.x += step;
 this.y += step;
 }
 StatusRecord get() {
 return new StatusRecord(this.names, this.x, this.y);
 }
}

如果有A、B两个线程，同时执行是指：

可能同时执行set()；
可能同时执行get()；
可能A执行set()，同时B执行get()。

类的成员变量names、x、y显然能被多线程同时读写，但局部变量（包括方法参数）如果没有“逃逸”，那么只有当前线程可见。局部变量step仅在set()方法内部使用，因此每个线程同时执行set时都有一份独立的step存储在线程的栈上，互不影响，

局部变量ns虽然每个线程也各有一份，但后续赋值 this.names = ns 对其他线程就变成可见了。对set()方法同步时，如果要最小化synchronized代码块，可以改写如下：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


void set(String[] names, int n) {
 // 局部变量其他线程不可见:
 List<String> ns = List.of(names);
 int step = n * 10;
 synchronized(this) {
 this.names = ns;
 this.x += step;
 this.y += step;
 }
}

因此，深入理解多线程还需理解变量在栈上的存储方式，基本类型和引用类型的存储方式也不同。

场景	是否需要同步	原因
不可变对象（如 `List.of()`）	否	对象不可变，多线程只能读取，无竞态条件。
局部变量（如 `step`）	否	线程私有，栈封闭。
成员变量赋值（如 `this.names`）	是	引用可能被多线程同时修改，需同步或 `volatile`。
复合操作（如 `x += step`）	是	非原子操作（读取-修改-写入），需同步。

小结

多线程同时读写共享变量时，可能会造成逻辑错误，因此需要通过synchronized同步；

同步的本质就是给指定对象加锁，加锁后才能继续执行后续代码；

注意加锁对象必须是同一个实例；

对JVM定义的单个原子操作不需要同步。

线程同步方法

线程安全

如果一个类被设计为允许多线程正确访问，我们就说这个类就是“线程安全”的（thread-safe），Java标准库的java.lang.StringBuffer也是线程安全的。

还有一些 不变类 ，例如String，Integer，LocalDate，它们的所有成员变量都是final，多线程同时访问时只能读不能写，这些不变类也是线程安全的。

最后，类似Math这些 只提供静态方法，没有成员变量的类 ，也是线程安全的。

除了上述几种少数情况，大部分类，例如ArrayList，都是 非线程安全的类 ，我们不能在多线程中修改它们。但是，如果所有线程都 只读取，不写入 ，那么ArrayList是可以安全地在线程间共享的。

没有特殊说明时，一个类 默认是非线程安全的 。

例如下面的Counter类：

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


public class Counter {
 private int count = 0;

 public void add(int n) {
 synchronized(this) {
 count += n;
 }
 }

 public void dec(int n) {
 synchronized(this) {
 count -= n;
 }
 }

 public int get() {
 return count;
 }
}

这样一来，线程调用add()、dec()方法时，它不必关心同步逻辑，因为synchronized代码块在add()、dec()方法内部。并且，我们注意到，synchronized锁住的对象是this，即当前实例，这又使得创建多个Counter实例的时候，它们之间互不影响，可以并发执行

`synchronized` 修饰

我们再观察Counter的代码：

1
2
3
4
5
6
7
8


public class Counter {
 public void add(int n) {
 synchronized(this) {
 count += n;
 }
 }
 ...
}

当我们锁住的是this实例时，实际上可以用synchronized修饰这个方法。下面两种写法是等价的：

1
2
3
4
5


public void add(int n) {
 synchronized(this) { // 锁住this
 count += n;
 } // 解锁
}

写法二：

1
2
3


public synchronized void add(int n) { // 锁住this
 count += n;
} // 解锁

因此， 用synchronized修饰的方法就是同步方法 ，它表示整个方法都必须用this实例加锁。

对于static方法，是没有this实例的，因为static方法是针对类而不是实例。但是我们注意到任何一个类都有一个由JVM自动创建的Class实例，因此， 对static方法添加synchronized，锁住的是该类的Class实例 。上述synchronized static方法实际上相当于：

1
2
3
4
5
6
7


public class Counter {
 public static void test(int n) {
 synchronized(Counter.class) {
 ...
 }
 }
}

小结

用synchronized修饰方法可以把整个方法变为同步代码块，synchronized方法加锁对象是this；

通过合理的设计和数据封装可以让一个类变为“线程安全”；

一个类没有特殊说明，默认不是thread-safe；

多线程能否安全访问某个非线程安全的实例，需要具体问题具体分析。

死锁

可重入锁

Java的线程锁是可重入的锁。

什么是可重入的锁？我们还是来看例子：

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


public class Counter {
 private int count = 0;

 public synchronized void add(int n) {
 if (n < 0) {
 dec(-n);
 } else {
 count += n;
 }
 }

 public synchronized void dec(int n) {
 count += n;
 }
}

执行流程：

调用add(-1)：
- 获取this锁：计数器=1，持有线程=当前线程
进入add方法后调用dec(1)：
- 再次获取this锁：发现当前线程已持有，计数器增加到2
退出dec方法：
- 计数器减到1
退出add方法：
- 计数器减到0，真正释放锁

观察synchronized修饰的add()方法，一旦线程执行到add()方法内部，说明它已经获取了当前实例的this锁。如果传入的n < 0，将在add()方法内部调用dec()方法。由于dec()方法也需要获取this锁，现在问题来了：

对同一个线程，能否在获取到锁以后继续获取同一个锁？

答案是肯定的。 JVM允许同一个线程重复获取同一个锁 ，这种能被同一个线程反复获取的锁，就叫做可重入锁。

由于Java的线程锁是可重入锁，所以，获取锁的时候，不但要判断是否是第一次获取，还要记录这是第几次获取。每获取一次锁，记录+1，每退出synchronized块，记录-1，减到0的时候，才会真正释放锁。

死锁

一个线程可以获取一个锁后，再继续获取另一个锁。例如：

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


public void add(int m) {
 synchronized(lockA) { // 获得lockA的锁
 this.value += m;
 synchronized(lockB) { // 获得lockB的锁
 this.another += m;
 } // 释放lockB的锁
 } // 释放lockA的锁
}

public void dec(int m) {
 synchronized(lockB) { // 获得lockB的锁
 this.another -= m;
 synchronized(lockA) { // 获得lockA的锁
 this.value -= m;
 } // 释放lockA的锁
 } // 释放lockB的锁
}

在获取多个锁的时候，不同线程获取多个不同对象的锁可能导致死锁。对于上述代码，线程1和线程2如果分别执行add()和dec()方法时：

线程1：进入add()，获得lockA；
线程2：进入dec()，获得lockB。

随后：

线程1：准备获得lockB，失败，等待中；
线程2：准备获得lockA，失败，等待中。

此时，两个线程各自持有不同的锁，然后各自试图获取对方手里的锁，造成了双方无限等待下去，这就是死锁。

死锁发生后，没有任何机制能解除死锁，只能强制结束JVM进程。

因此，在编写多线程应用时，要特别注意防止死锁。因为死锁一旦形成，就只能强制结束进程。

那么我们应该如何避免死锁呢？答案是： 线程获取锁的顺序要一致 。即严格按照先获取lockA，再获取lockB的顺序，改写dec()方法如下：

1
2
3
4
5
6
7
8


public void dec(int m) {
 synchronized(lockA) { // 获得lockA的锁
 this.value -= m;
 synchronized(lockB) { // 获得lockB的锁
 this.another -= m;
 } // 释放lockB的锁
 } // 释放lockA的锁
}

小结

Java的synchronized锁是可重入锁；

死锁产生的条件是多线程各自持有不同的锁，并互相试图获取对方已持有的锁，导致无限等待；

避免死锁的方法是多线程获取锁的顺序要一致。

线程通信

在Java程序中，synchronized解决了多线程竞争的问题。例如，对于一个任务管理器，多个线程同时往队列中添加任务，可以用synchronized加锁：

1
2
3
4
5
6
7


class TaskQueue {
 Queue<String> queue = new LinkedList<>();

 public synchronized void addTask(String s) {
 this.queue.add(s);
 }
}

但是synchronized并没有解决多线程协调的问题。

仍然以上面的TaskQueue为例，我们再编写一个getTask()方法取出队列的第一个任务：

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


class TaskQueue {
 Queue<String> queue = new LinkedList<>();

 public synchronized void addTask(String s) {
 this.queue.add(s);
 }

 public synchronized String getTask() {
 while (queue.isEmpty()) {
 }
 return queue.remove();
 }
}

上述代码看上去没有问题：getTask()内部先判断队列是否为空，如果为空，就循环等待，直到另一个线程往队列中放入了一个任务，while()循环退出，就可以返回队列的元素了。

但实际上while()循环永远不会退出。因为线程在执行while()循环时，已经在getTask()入口获取了this锁，其他线程根本无法调用addTask()，因为addTask()执行条件也是获取this锁。

因此，执行上述代码，线程会在getTask()中因为死循环而100%占用CPU资源。

如果深入思考一下，我们想要的执行效果是：

线程1可以调用addTask()不断往队列中添加任务；
线程2可以调用getTask()从队列中获取任务。如果队列为空，则getTask()应该等待，直到队列中至少有一个任务时再返回。

因此，多线程协调运行的原则就是：当条件不满足时，线程进入等待状态；当条件满足时，线程被唤醒，继续执行任务。

`wait()`

对于上述TaskQueue，我们先改造getTask()方法，在条件不满足时，线程进入等待状态：

1
2
3
4
5
6


public synchronized String getTask() {
 while (queue.isEmpty()) {
 this.wait();
 }
 return queue.remove();
}

当一个线程执行到getTask()方法内部的while循环时，它必定已经获取到了this锁，此时，线程执行while条件判断，如果条件成立（队列为空），线程将执行this.wait()，进入等待状态。

这里的关键是：wait()方法必须在 当前获取的锁对象 上调用，这里获取的是this锁，因此调用this.wait()。

调用wait()方法后，线程进入等待状态，wait()方法不会返回，直到将来某个时刻， 线程从等待状态被其他线程唤醒后 ，wait()方法才会返回，然后，继续执行下一条语句。

有些仔细的童鞋会指出：即使线程在getTask()内部等待，其他线程如果拿不到this锁，照样无法执行addTask()，肿么办？

这个问题的关键就在于wait()方法的执行机制非常复杂。首先，它不是一个普通的Java方法，而是定义在Object类的一个native方法，也就是由JVM的C代码实现的。其次，必须在synchronized块中才能调用wait()方法， 因为wait()方法调用时，会释放线程获得的锁 ，wait()方法返回时，线程又会重新试图获得锁。

因此，只能在锁对象上调用wait()方法。因为在getTask()中，我们获得了this锁，因此，只能在this对象上调用wait()方法：

1
2
3
4
5
6
7
8


public synchronized String getTask() {
 while (queue.isEmpty()) {
 // 释放this锁:
 this.wait();
 // 重新获取this锁
 }
 return queue.remove();
}

当一个线程在this.wait()等待时，它就会释放this锁，从而使得其他线程能够在addTask()方法获得this锁。

`notify()`

现在我们面临第二个问题：如何让等待的线程被 重新唤醒 ，然后从wait()方法返回？答案是在相同的锁对象上调用notify()方法。我们修改addTask()如下：

1
2
3
4


public synchronized void addTask(String s) {
 this.queue.add(s);
 this.notify(); // 唤醒在this锁等待的线程
}

注意到在往队列中添加了任务后，线程立刻对this锁对象调用notify()方法，这个方法会唤醒一个正在this锁等待的线程（就是在getTask()中位于this.wait()的线程），从而使得等待线程从this.wait()方法返回。

我们来看一个完整的例子(这也是一个生产者消费者模型)：

 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


import java.util.*;

public class Main {
 public static void main(String[] args) throws InterruptedException {
 var q = new TaskQueue();
 var ts = new ArrayList<Thread>();
 for (int i=0; i<5; i++) {
 var t = new Thread() {
 public void run() {
 // 执行task:
 while (true) {
 try {
 String s = q.getTask();
 System.out.println("execute task: " + s);
 } catch (InterruptedException e) {
 return;
 }
 }
 }
 };
 t.start();
 ts.add(t);
 }
 var add = new Thread(() -> {
 for (int i=0; i<10; i++) {
 // 放入task:
 String s = "t-" + Math.random();
 System.out.println("add task: " + s);
 q.addTask(s);
 try { Thread.sleep(100); } catch(InterruptedException e) {}
 }
 });
 add.start();
 add.join();
 Thread.sleep(100);
 for (var t : ts) {
 t.interrupt();
 }
 }
}

class TaskQueue {
 Queue<String> queue = new LinkedList<>();

 public synchronized void addTask(String s) {
 this.queue.add(s);
 this.notifyAll();
 }

 public synchronized String getTask() throws InterruptedException {
 while (queue.isEmpty()) {
 this.wait();
 }
 return queue.remove();
 }
}

这个例子中，我们重点关注addTask()方法，内部调用了this.notifyAll()而不是this.notify()，使用notifyAll()将唤醒所有当前正在this锁等待的线程，而notify()只会 唤醒其中一个 （具体哪个依赖操作系统，有一定的 随机性）。这是因为可能有多个线程正在getTask()方法内部的wait()中等待，使用notifyAll()将 一次性全部唤醒 。通常来说，notifyAll()更安全。有些时候，如果我们的代码逻辑考虑不周，用notify()会导致只唤醒了一个线程，而其他线程可能永远等待下去醒不过来了。

但是，注意到wait()方法返回时需要重新获得this锁。假设当前有3个线程被唤醒，唤醒后，首先要等待执行addTask()的线程结束此方法后，才能释放this锁，随后，这3个线程中只能有一个获取到this锁，剩下两个将继续等待。

再注意到我们在while()循环中调用wait()，而不是if语句：

1
2
3
4
5
6


public synchronized String getTask() throws InterruptedException {
 if (queue.isEmpty()) {
 this.wait();
 }
 return queue.remove();
}

这种写法实际上是错误的，因为线程被唤醒时，需要再次获取this锁。多个线程被唤醒后，只有一个线程能获取this锁，此刻，该线程执行queue.remove()可以获取到队列的元素，然而，剩下的线程如果获取this锁后执行queue.remove()，此刻队列可能已经没有任何元素了，所以，要始终在while循环中wait()，并且每次被唤醒后拿到this锁就必须再次判断：

1
2
3


while (queue.isEmpty()) {
 this.wait();
}

小结

wait和notify用于多线程协调运行：

在synchronized内部可以调用wait()使线程进入等待状态；
必须在已获得的锁对象上调用wait()方法；
在synchronized内部可以调用notify()或notifyAll()唤醒其他等待线程；
必须在已获得的锁对象上调用notify()或notifyAll()方法；
已唤醒的线程还需要重新获得锁后才能继续执行。

生产者消费者模型

Java生产者消费者模式的实现和解析_哔哩哔哩_bilibili

下面是从B站找来的简单的生产者消费者模型的示例，并不如上面线程通信中的示例以及下面的消息队列模型示例，这三个示例我想就能拿下该模型罢

 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


public class Demo1 {
 /**
 * 交替执行两个线程
 * 一个输出“1,2,3,...”
 * 一个输出“a,b,c,...”
 */
 public static void main(String[] args) {
 Factory factory = new Factory();

 final Thread t1 = new Thread(new Runnable() {
 @Override
 public void run() {
 for(int i = 1;i <= 26;i++){
 factory.product(i);
 }
 }
 });

 final Thread t2 = new Thread(new Runnable() {
 @Override
 public void run() {
 for(int i = 'a';i <= 'z';i++){
 factory.consume((char) i);
 }
 }
 });
 t1.start();
 t2.start();
 }
}

 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


public class Factory {
 /**
 * 0: 生产者正在生成，消费者正在等待，生产者结束生产后告知消费者进行消费
 * 1: 消费者正在消费，生产者正在等待，消费者结束消费后高职生产者进行生产
 */
 private int sign = 0;	//状态值


 public synchronized void product(int n){
 if(sign == 1){
 try {
 this.wait();
 } catch (InterruptedException e) {
 e.printStackTrace();
 }
 }
 System.out.print(n);
 this.notify();
 this.sign = 1;
 }

 public synchronized void consume(char c){
 if(sign == 0){
 try {
 this.wait();
 } catch (InterruptedException e) {
 e.printStackTrace();
 }
 }
 System.out.print(c);
 this.notify();
 this.sign = 0;
 }
}

线程的运行有一定随机性，往往用户无法决定，但是生产者消费者模型，能实现两个线程的“交替”运行

注释里的内容不再概述，我们来分析一下：

假设线程 t1 先被调用，由于 sign = 0 ，所以打印字符 1 ， sign 变为1。下面有两种可能，调用线程 t1 或 t2

调用 t1 :

sign = 1 进入 try/catch
同步锁的对象 this。wait() 也就是进入 “等待” 状态
wait() 会 释放锁 ，线程 t2 执行，运行 consume()
notfiy() 唤醒 this 中等待的线程 t1
sign 被赋值0，周而复始

调用 t2 :

线程 t2 执行，运行 consume()
notify 不唤醒任一线程(因为无线程处于等待状态)
sign 被赋值0，周而复始

示例分析

下面是较复杂(贴切实际)的一种，思想和上面简单的例子差不多的

关于下面示例中 lambda 表达式创建线程的方式，需要补充几点：

new Thread() - 创建新线程

() -> {...} - Lambda表达式定义线程任务

"生产者" + i - 线程命名

.start() - 启动线程

这里通过循环来创建线程，所以用循环的参数为其命名

 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
66
67
68
69
70
71
72
73
74
75


 public static void main(String[] args) throws InterruptedException {
 MessageQueue queue = new MessageQueue(2);

 // 三个生产者向队列里存值
 for (int i = 0; i < 3; i++) {
 int id = i;
 new Thread(() -> {
 queue.put(new Message(id, "值" + id));
 }, "生产者" + i).start();
 }

 Thread.sleep(1000);

 // 一个消费者不停的从队列里取值
 new Thread(() -> {
 while (true) {
 queue.take();
 }
 }, "消费者").start();

 }
}

// 消息队列被生产者和消费者持有
class MessageQueue {
 private LinkedList<Message> list = new LinkedList<>();

 // 容量
 private int capacity;

 public MessageQueue(int capacity) {
 this.capacity = capacity;
 }
 //生产者
 public void put(Message message) {
 synchronized (list) {
 while (list.size() == capacity) {
 log.info("队列已满，生产者等待");
 try {
 list.wait();
 } catch (InterruptedException e) {
 e.printStackTrace();
 }
 }
 list.addLast(message);
 log.info("生产消息:{}", message);
 // 生产后通知消费者
 list.notifyAll();
 }
 }
 //消费者
 public Message take() {
 synchronized (list) {
 while (list.isEmpty()) {
 log.info("队列已空，消费者等待");
 try {
 list.wait();
 } catch (InterruptedException e) {
 e.printStackTrace();
 }
 }
 Message message = list.removeFirst();
 //从队列头部取出消息
 log.info("消费消息:{}", message);
 // 消费后通知生产者
 list.notifyAll();
 return message;
 }
 }
}
 // 消息
class Message {
 private int id;
 private Object value;
}

主函数:

创建了一个容量为2的消息队列MessageQueue
启动3个生产者线程，每个生产者向队列中放入一条消息
主线程休眠1秒，让生产者有足够时间开始工作
启动一个消费者线程，不断从队列中取出消息

生产者:

使用synchronized块获取list对象的锁
检查队列是否已满（while循环防止虚假唤醒）
如果队列已满，调用wait()释放锁并等待
当队列有空闲时，添加消息到队列尾部
调用notifyAll()唤醒可能正在等待的消费者线程

消费者:

使用synchronized块获取list对象的锁
检查队列是否为空（while循环防止虚假唤醒）
如果队列为空，调用wait()释放锁并等待
当队列有消息时，从队列头部取出消息
调用notifyAll()唤醒可能正在等待的生产者线程
返回取出的消息

小结

同步机制：使用synchronized保证对队列操作的原子性
等待/通知机制：使用wait()和notifyAll()实现线程间通信
循环检查条件：使用while而非if检查条件，防止虚假唤醒
容量限制：控制队列大小，防止内存耗尽

可重入锁

从Java 5开始，引入了一个高级的处理并发的java.util.concurrent包，它提供了大量更高级的并发功能，能大大简化多线程程序的编写。

我们知道Java语言直接提供了synchronized关键字用于加锁，但这种锁一是很重，二是获取时必须一直等待，没有额外的尝试机制。

java.util.concurrent.locks包提供的ReentrantLock用于替代synchronized加锁，我们来看一下传统的synchronized代码：

1
2
3
4
5
6
7
8
9


public class Counter {
 private int count;

 public void add(int n) {
 synchronized(this) {
 count += n;
 }
 }
}

如果用ReentrantLock替代，可以把代码改造为：

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


public class Counter {
 private final Lock lock = new ReentrantLock();
 private int count;

 public void add(int n) {
 lock.lock();
 try {
 count += n;
 } finally {
 lock.unlock();
 }
 }
}

因为synchronized是Java语言层面提供的语法，所以我们不需要考虑异常，而ReentrantLock是Java代码实现的锁，我们就必须先获取锁，然后在finally中正确释放锁。

顾名思义，ReentrantLock是可重入锁，它和synchronized一样，一个线程可以多次获取同一个锁。

和synchronized不同的是，ReentrantLock可以尝试获取锁：

1
2
3
4
5
6
7


if (lock.tryLock(1, TimeUnit.SECONDS)) {
 try {
 ...
 } finally {
 lock.unlock();
 }
}

上述代码在尝试获取锁的时候，最多等待1秒。如果1秒后仍未获取到锁，tryLock()返回false，程序就可以做一些额外处理，而不是无限等待下去。

所以，使用ReentrantLock比直接使用synchronized更安全，线程在tryLock()失败的时候不会导致死锁。

下面来介绍一下它的各种方法，以及一个较复杂的案例

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


// 默认非公平锁，参数传true 表示未公平锁
ReentrantLock lock = new ReentrantLock(false);
// 尝试获取锁
lock()
// 释放锁 应放在finally块中 必须执行到
unlock()
try {
 // 获取锁时可被打断,阻塞中的线程可被打断
 LOCK.lockInterruptibly();
} catch (InterruptedException e) {
 return;
}
// 尝试获取锁 获取不到就返回false
LOCK.tryLock()
// 支持超时时间 一段时间没获取到就返回false
tryLock(long timeout, TimeUnit unit)
// 指定条件变量 休息室 一个锁可以创建多个休息室
Condition waitSet = ROOM.newCondition();
// 释放锁 进入waitSet等待 释放后其他线程可以抢锁
yanWaitSet.await()
// 唤醒具体休息室的线程 唤醒后 重写竞争锁
yanWaitSet.signal()

 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
66
67


 public static void main(String[] args) {
 AwaitSignal awaitSignal = new AwaitSignal(5);
 // 构建三个条件变量
 Condition a = awaitSignal.newCondition();
 Condition b = awaitSignal.newCondition();
 Condition c = awaitSignal.newCondition();
 // 开启三个线程
 new Thread(() -> {
 awaitSignal.print("a", a, b);
 }).start();

 new Thread(() -> {
 awaitSignal.print("b", b, c);
 }).start();

 new Thread(() -> {
 awaitSignal.print("c", c, a);
 }).start();

 try {
 Thread.sleep(1000);
 } catch (InterruptedException e) {
 e.printStackTrace();
 }
 awaitSignal.lock();
 try {
 // 先唤醒a
 a.signal();
 } finally {
 awaitSignal.unlock();
 }
 }

}

class AwaitSignal extends ReentrantLock {

 // 循环次数
 private int loopNumber;

 public AwaitSignal(int loopNumber) {
 this.loopNumber = loopNumber;
 }

 /**
 * @param print 输出的字符
 * @param current 当前条件变量
 * @param next 下一个条件变量
 */
 public void print(String print, Condition current, Condition next) {

 for (int i = 0; i < loopNumber; i++) {
 lock();
 try {
 try {
 // 获取锁之后等待
 current.await();
 System.out.print(print);
 } catch (InterruptedException e) {
 
 }
 next.signal();
 } finally {
 unlock();
 }
 }
 }

流程分析：

初始化 ：
主线程创建了 AwaitSignal 对象，设置循环次数为 5。
创建了三个 Condition 对象：a、b、c，分别对应三个线程。
三个线程启动，分别调用 print("a", a, b) 、 print("b", b, c) 、 print("c", c, a) 。
主线程休眠 1 秒后，获取锁并通过 a.signal() 唤醒线程 A。
线程启动后 ：
每个线程进入 print 方法，执行 lock() 获取锁。由于 ReentrantLock 是互斥锁，同一时刻只有一个线程能持有锁。
假设线程 A 先获取锁，它调用 a.await() ，释放锁并进入等待状态（等待 Condition a 的信号）。
其他线程（B 和 C）尝试 lock() ，但锁被占用，它们会阻塞在 lock() 上。
主线程唤醒线程A ：
主线程在 try { Thread.sleep(1000); } 后执行 awaitSignal.lock() ，获取锁。
调用 a.signal() ，唤醒等待在 Condition a 上的线程 A。
主线程执行 unlock() ，释放锁。
线程A被唤醒后 ：
线程 A 从 a.await() 返回，但它需要重新获取锁才能继续执行。
因为主线程已经释放锁（ unlock() ），线程 A 成功重新获取锁。
线程 A 打印 “a”，然后调用 b.signal() 唤醒线程 B。
线程 A 执行 unlock() ，释放锁。
线程B被唤醒后 ：
线程 B 在 b.await() 上等待，收到 b.signal() 后被唤醒。
线程 B 尝试重新获取锁。由于线程 A 已释放锁，线程 B 获取锁成功。
线程 B 打印 “b”，调用 c.signal() 唤醒线程 C，然后释放锁。

小结

ReentrantLock可以替代synchronized进行同步；

ReentrantLock获取锁更安全；

必须先获取到锁，再进入try {...}代码块，最后使用finally保证释放锁；

可以使用tryLock()尝试获取锁。

线程池

（线程池感觉都写的不是很明白）

Java语言虽然内置了多线程支持，启动一个新线程非常方便，但是，创建线程需要操作系统资源（线程资源，栈空间等），频繁创建和销毁大量线程需要消耗大量时间。

如果可以复用一组线程：

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


┌─────┐ execute ┌──────────────────┐
│Task1│─────────▶│ThreadPool │
├─────┤ │┌───────┐┌───────┐│
│Task2│ ││Thread1││Thread2││
├─────┤ │└───────┘└───────┘│
│Task3│ │┌───────┐┌───────┐│
├─────┤ ││Thread3││Thread4││
│Task4│ │└───────┘└───────┘│
├─────┤ └──────────────────┘
│Task5│
├─────┤
│Task6│
└─────┘
 ...

那么我们就可以把很多小任务让一组线程来执行，而不是一个任务对应一个新线程。这种能接收大量小任务并进行分发处理的就是线程池。

简单地说，线程池内部维护了若干个线程，没有任务的时候，这些线程都处于等待状态。如果有新任务，就分配一个空闲线程执行。如果所有线程都处于忙碌状态，新任务要么放入队列等待，要么增加一个新线程进行处理。

Java标准库提供了ExecutorService接口表示线程池，它的典型用法如下：

1
2
3
4
5
6
7
8


// 创建固定大小的线程池:
ExecutorService executor = Executors.newFixedThreadPool(3);
// 提交任务:
executor.submit(task1);
executor.submit(task2);
executor.submit(task3);
executor.submit(task4);
executor.submit(task5);

因为ExecutorService只是接口，Java标准库提供的几个常用实现类有：

FixedThreadPool：线程数固定的线程池；
CachedThreadPool：线程数根据任务动态调整的线程池；
SingleThreadExecutor：仅单线程执行的线程池。

创建这些线程池的方法都被封装到Executors这个类中。我们以FixedThreadPool为例，看看线程池的执行逻辑：

 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


// thread-pool
import java.util.concurrent.*;

public class Main {
 public static void main(String[] args) {
 // 创建一个固定大小的线程池:
 ExecutorService es = Executors.newFixedThreadPool(4);
 for (int i = 0; i < 6; i++) {
 es.submit(new Task("" + i));
 }
 // 关闭线程池:
 es.shutdown();
 }
}

class Task implements Runnable {
 private final String name;

 public Task(String name) {
 this.name = name;
 }

 @Override
 public void run() {
 System.out.println("start task " + name);
 try {
 Thread.sleep(1000);
 } catch (InterruptedException e) {
 }
 System.out.println("end task " + name);
 }
}

我们观察执行结果，一次性放入6个任务，由于线程池只有固定的4个线程，因此，前4个任务会同时执行，等到有线程空闲后，才会执行后面的两个任务。

线程池在程序结束的时候要关闭。使用shutdown()方法关闭线程池的时候，它会等待正在执行的任务先完成，然后再关闭。shutdownNow()会立刻停止正在执行的任务，awaitTermination()则会等待指定的时间让线程池关闭。

如果我们把线程池改为CachedThreadPool，由于这个线程池的实现会根据任务数量动态调整线程池的大小，所以6个任务可一次性全部同时执行。

如果我们想把线程池的大小限制在4～10个之间动态调整怎么办？我们查看Executors.newCachedThreadPool()方法的源码：

1
2
3
4
5
6


public static ExecutorService newCachedThreadPool() {
 return new ThreadPoolExecutor(
 0, Integer.MAX_VALUE,
 60L, TimeUnit.SECONDS,
 new SynchronousQueue<Runnable>());
}

因此，想创建指定动态范围的线程池，可以这么写：

1
2
3
4
5
6


int min = 4;
int max = 10;
ExecutorService es = new ThreadPoolExecutor(
 min, max,
 60L, TimeUnit.SECONDS,
 new SynchronousQueue<Runnable>());

ScheduledThreadPool

还有一种任务，需要定期反复执行，例如，每秒刷新证券价格。这种任务本身固定，需要反复执行的，可以使用ScheduledThreadPool。放入ScheduledThreadPool的任务可以定期反复执行。

创建一个ScheduledThreadPool仍然是通过Executors类：

1

ScheduledExecutorService ses = Executors.newScheduledThreadPool(4);

我们可以提交一次性任务，它会在指定延迟后只执行一次：

1
2


// 1秒后执行一次性任务:
ses.schedule(new Task("one-time"), 1, TimeUnit.SECONDS);

如果任务以固定的每3秒执行，我们可以这样写：

1
2


// 2秒后开始执行定时任务，每3秒执行:
ses.scheduleAtFixedRate(new Task("fixed-rate"), 2, 3, TimeUnit.SECONDS);

如果任务以固定的3秒为间隔执行，我们可以这样写：

1
2


// 2秒后开始执行定时任务，以3秒为间隔执行:
ses.scheduleWithFixedDelay(new Task("fixed-delay"), 2, 3, TimeUnit.SECONDS);

注意FixedRate和FixedDelay的区别。FixedRate是指任务总是以固定时间间隔触发，不管任务执行多长时间：

1
2
3


│░░░░ │░░░░░░ │░░░ │░░░░░ │░░░ 
├───────┼───────┼───────┼───────┼────▶
│◀─────▶│◀─────▶│◀─────▶│◀─────▶│

而FixedDelay是指，上一次任务执行完毕后，等待固定的时间间隔，再执行下一次任务：

1
2
3


│░░░│ │░░░░░│ │░░│ │░
└───┼───────┼─────┼───────┼──┼───────┼──▶
 │◀─────▶│ │◀─────▶│ │◀─────▶│

因此，使用ScheduledThreadPool时，我们要根据需要选择执行一次、FixedRate执行还是FixedDelay执行。

还可以思考下面的问题：

在FixedRate模式下，假设每秒触发，如果某次任务执行时间超过1秒，后续任务会不会并发执行？
如果任务抛出了异常，后续任务是否继续执行？

Java标准库还提供了一个java.util.Timer类，这个类也可以定期执行任务，但是，一个Timer会对应一个Thread，所以，一个Timer只能定期执行一个任务，多个定时任务必须启动多个Timer，而一个ScheduledThreadPool就可以调度多个定时任务，所以，我们完全可以用ScheduledThreadPool取代旧的Timer。

小结

JDK提供了ExecutorService实现了线程池功能：

线程池内部维护一组线程，可以高效执行大量小任务；
Executors提供了静态方法创建不同类型的ExecutorService；
必须调用shutdown()关闭ExecutorService；
ScheduledThreadPool可以定期调度多个任务。

在Linux(CentOS)系统上部署Minecraft服务器

Wed, 19 Mar 2025 18:48:59 +0800

笔者近日配置好了物理服务器，便想利用起来建一个我的世界服务器，经熬夜研究后成功，将本攻略分享出来，希望能帮到大家，尤其是没有公网环境的Linux用户(像我一样)

参考网站

在 RHEL 上安装并使用红帽构建的 OpenJDK 21 | Red Hat Product Documentation

SakuraFrp 启动器安装 / 使用指南 | SakuraFrp 帮助文档

CentOS | Docker Docs

Linux终端开服教程★无面板★Minecraft_哔哩哔哩_bilibili

来自B站的UP主翱翔大使，是全篇的主要思路来源

Java配置

运行我的世界需要，须对应版本的Java环境，笔者这里安装的是OpenJDK21

1
2


sudo yum install java-21-openjdk
java -version //验证是否成功安装

如果服务器有多个Java版本，可以用alternatives进行版本切换

1

alternatives --config java

如图，我们输入2并回车，就切换到了需要的版本

游戏部署

首先在下面这个网址下载Minecraft的服务器端，这里我下的是支持Fabric的Banner(1.20.1)

[MohistMC](MohistMC - 主页)

下载完成后是个类似banner-1.20.1-800-server.jar的文件，接下来打开SSH软件，在服务器上操作：

1
2
3


cd /home/username //切换到个人文件夹或者想安装的位置
mkdir Minecraft //创建存放游戏的文件夹
cd Minecraft

我们用SSH软件中的SFTP功能(或其他文件传输功能)，将刚才的游戏文件banner-1.20.1-800-server.jar拷贝到新建的文件夹/home/username/Mineraft中

接着我们来写一个服务器的启动脚本

1

nano start.sh

其中内容如下填写，但注意各参数的作用

-Xmx是最大分配内存，-Xms是最小分配内存，笔者有32GB内存，为游戏分配了6G(其实可以多分点)
banner-1.20.1-800-server.jar是刚才下载的游戏文件名

1
2


java -Xmx6144M -Xms6144m -jar banner-1.20.1-800-server.jar
stty echo

按Ctrl + O写入，Enter确认写入，Ctrl + X退出

接着为start.sh赋权，避免无权限访问的情况

1

chmod 777 start.sh

然后安装screen，简单来说，screen是帮用户创建独立会话，并可以随时恢复的工具

1

yum install screen

screen有如下几个常用命令

1
2
3


screen -S [name] //新建名为"name"的screen
screen -ls //列出所有运行中的screen的名称和端口
screen -r [port] //返回端口号为port的screen

接着，新建一个screen运行脚本

1

screen -S Minecraft

在新出现的会话中，运行start.sh

1

./start.sh

然后一路顺畅，笔者在这里没有遇到报错，最后来到...EULA...让我们同意EULA协议，输入true后回车，等待一下，游戏服务器就在25565端口上成功运行了

若想离开Minecraft的这个screen按下Ctrl+A+D即可

关于游戏规则的更改(比如”是否允许非正版玩家加入“)，需要修改server.properties的内容

关于连接，如果是云服务器，在管理界面映射一下端口，然后在客户端的Minecraft中连接域名:端口即可

但是像笔者这样的物理服务器，或者说安装了Linux的设备，个人PC，在没有公网IP的情况下，就要继续内网穿透了

内网穿透

笔者在这里使用我的世界领域中比较有名且良心的SakuraFrp进行内网穿透，其它工具也大同小异

Docker

Linux上的SakuraFrp是基于Docker运行的，所以下面我们先部署Docker，操作完全根据官方文档进行

1
2


sudo dnf -y install dnf-plugins-core
sudo dnf config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo

笔者在下面这遇到了安装速度十分缓慢，和下载失败的问题，重新执行命令再执行一次便解决了

1

sudo dnf install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

安装完毕后

1

sudo systemctl enable --now docker

1

sudo docker run hello-world

上面的这个run hello-world测试极有可能失败，下面来解决这个问题，参考了下面两篇文章：

【完全解决】Docker安装完成运行hello-world镜像失败：Unable to find image ‘hello-world:latest‘ locallylatest:_unable to find image ‘hello-world:latest’ locally-CSDN博客

Docker运行hello-world镜像失败或超时 - Paul7777 - 博客园

综合上面二者，最终是能解决问题的，先来配置daemon文件

1

nano /etc/docker/daemon.json

复制下面的内容进去

在笔者测试的时间(2025/3/19)下面的镜像源还是可用的

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


{
 "registry-mirrors": [
 "https://h59pkpv6.mirror.aliyuncs.com",
 "https://registry.docker-cn.com",
 "https://docker.mirrors.ustc.edu.cn",
 "https://hub-mirror.c.163.com",
 "https://mirror.baidubce.com",
 "https://do.nark.eu.org",
 "https://dc.j8.work",
 "https://docker.m.daocloud.io",
 "https://dockerproxy.com",
 "https://docker.nju.edu.cn"
]
}

保存 + 退出，接下来重启docker，再执行一次测试

1
2
3


sudo systemctl daemon-reload
sudo systemctl restart docker
docker run hello-world

笔者到这就已经成功安装好docker了，若是测试仍不通过，请检查daemon.json的内容，是否少了或者多了逗号和括号

SakuraFrp

SakuraFrp在Linux上的部署，官方文档给出了详细的方案

首先在终端以管理员身份运行

1

sudo bash -c ". <(curl -sSL https://doc.natfrp.com/launcher.sh)"

安装好后，应该是会自动输出日志，并需要填写访问密钥，这个(或者说接下来的操作)可以在SakuraFrp官网的管理面板找到

登录好之后就能看到其日志文件，下面是常规的启动并查看日志的操作

1
2


docker start natfrp-service
docker logs natfrp-service

如图，接下来需要用物理方式操作下服务器

打开浏览器(一般Linux自带Firefox)访问“使用”后面的网址打开WebUI

然后看到“隧道”那什么都没有，只有一个加号，这时我们在打开SakuraFrp的管理面板，找到服务下的隧道列表，新建两个隧道，如图所示：

第一个端口号为7102的是服务器上SakuraFrp的WebUI，以便远程管理

第二个端口号为25565的是Minecraft的服务器端

回到WebUI界面刷新一下就能看到刚刚创建好的两个隧道了，我们分别双击，然后回到终端的日志界面

如图的红色字符的链接，就是WebUI和Minecraft的远程访问链接，将Minecraft对应的复制到游戏中即可连接上

结语

大功告成！(笔者服务器出生地的截图 >w<)

Redis

Tue, 18 Mar 2025 15:41:00 +0800

Redis（Remote Dictionary Server）是一个高性能的开源内存数据结构存储系统，常被用作数据库、缓存和消息代理。

参考网站

知乎超强、超详细Redis入门教程

CSDN【Redis二三事】一套超详细的Redis学习教程（步骤图片+实操）—第一集

详细，附有业务场景的实例

数据结构

Redis包含五大数据类型：字符串(string), 列表(list), 哈希(hash), 集合(set), 集合(zset)

string

Redis 最基本的数据类型，每个键对应一个值，值可以是文本、数字或二进制数据，最大存储 512MB。支持字符串拼接、截取、递增递减等操作，适用于缓存数据、计数器（如访问量统计）、分布式锁等场景。

基础操作

1
2
3


set key value
get key
del key 

添加修改多个数据

1

mset key1 value1 key2 value2...

获取多个数据

1

mget key1 key2...

获取数据的字符个数

1
2
3
4
5


strlen key
//例如
set name1 nosql
strlen name1
//输出为: 5

追加信息

1
2
3
4
5


append key value
//例如
append name1 name
get name1
/*输出为: nosqlname*/

多数据操作与单数据操作

单指令执行 n 条指令需要 n次发送 + n次处理 + n次返回
多指令执行 n 条指令需要 1次发送 + n次处理 + 1次返回
数据量较大时，多指令消耗的时间远远少于单指令

扩展操作

设置数值数据增加/减少指定范围的值

1
2


incrby key increment
decrby key increment

对字符串类型进行数值操作

1
2
3
4
5
6
7
8


127.0.0.1:6379> set mynum "2"
OK
127.0.0.1:6379> get mynum
"2"
127.0.0.1:6379> incr mynum
(integer) 3
127.0.0.1:6379> get mynum
"3"

遇到数值操作，redis会自动将字符串类型转换成数值

string类型数值操作的注意事项

数据操作不成功的反馈与数据正常操作之间的差异
- 表示运行结果是否成功
  - （integer）0->false 失败
  - （integer）1->true 成功
- 表示运行结果值
  - （integer）3->3 3个
  - （integer）1->1 1个
数据未获取到
- （‘’nil’’）等同于’’null’'
数据最大存储量
- 512MB
数值计算最大范围（‘‘java’‘中的’’long’‘的最大值）
- 9223372036854775807

hash

类似于小型的键值存储，适用于存储结构化数据，如用户信息（ID、姓名、邮箱等），相比 String 类型更节省内存，因为多个字段共享同一个键。可以对字段进行单独操作，避免整体读取修改，适用于存储对象、会话信息等。

基础操作

1
2
3
4


hset key field value //添加/修改数据
hget key field //获取数据
hgetall key
hdel key field1 [field2]

添加/修改多个数据

1

hmset key field1 value1 field2 value2

获取多个数据

1

hmget key field1 field2...

获取哈希表中字段的数量

1

hlen key

获取哈希表中是否存在指定的字段

1

hexists key field

扩展操作

获取哈希表中所有字段名或字段值

1
2


hkeys key
hvals key

设置指定字段的数值数据增加指定范围的值

1

hincrby key field increment

综合示例

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


//建立哈希，并赋值
127.0.0.1:6379> HMSET user:001 username antirez password P1pp0 age 34 
OK
//列出哈希的内容
127.0.0.1:6379> HGETALL user:001 
1) "username"
2) "antirez"
3) "password"
4) "P1pp0"
5) "age"
6) "34"
//更改哈希中的某一个值
127.0.0.1:6379> HSET user:001 password 12345 
(integer) 0
//再次列出哈希的内容
127.0.0.1:6379> HGETALL user:001 
1) "username"
2) "antirez"
3) "password"
4) "12345"
5) "age"
6) "34"

hash类型数据操作的注意事项

1.hash类型下的value只能存储字符串，不允许存储其他数据类型，不存在嵌套现象。如果数据未获取到，对应的值为（nil）
2.每个hash可以存储2^23-1个键值对
3.hash类型十分贴近对象的数据存储形式，并且可以灵活添加对象属性。但hash设计初衷不是为了存储大量对象而设计的，切记不可滥用，更不可以将hash作为对象列表使用
4.hgetall操作可以获取全部属性，如果内部field过多，遍历整体数据效率就会很低，有可能成为数据访问瓶颈

list

基于双向链表实现，可以从头部（左侧）或尾部（右侧）快速插入和删除元素，同时支持指定范围的索引读取。适合实现消息队列、时间轴（如微博动态）、任务调度等应用，尤其适用于需要按照插入顺序处理数据的场景。

基础操作

添加/修改数据

1
2


lpush key value1 [value2]... //从左边进
rpush key value1 [value2]... /*从右边进*/

获取数据

关于lrange:

lrange用来获取指定范围的元素
-1 代表倒数第一个元素
列表元素索引从位置0开始

1
2
3


lrange key start stop
lindex key index
lien key

获取并移除数据

1
2


lpop key
rpop key

移除指定数据

关于lrem:

参数count
- count > 0 → 从头（左侧）开始删除count个匹配的value
- count < 0 → 从尾（右侧）开始删除count个匹配的value
- count = 0 → 删除所有匹配的value（等价于删除列表中所有该值的元素）
如果key不存在
- 返回 0
常用于去除列表中的重复元素或清理数据

1

lrem key count value

扩展操作

在规定时间内获取并移除数据

关于blpop:

参数key1 [key2...]
- 可以提供多个列表的键名，Redis 会按照顺序依次检查这些列表
参数timeout
- timeout > 0 → 如果列表为空，则最多等待 timeout 秒
- timeout < 0 → 永远阻塞，直到有数据可用
适用于任务队列、生产者-消费者模型等场景

1
2


blpop key1 [key2] timeout
brpop key1 [key2] timeout

示例

1
2
3
4
5


RPUSH list1 "a" "b" "c" // 列表内容：["a", "b", "c"]
BLPOP list1 10 // 取出 "a"，返回 ["list1", "a"]
BLPOP list1 10 // 取出 "b"，返回 ["list1", "b"]
BLPOP list1 10 // 取出 "c"，返回 ["list1", "c"]
BLPOP list1 10 /* 列表为空，阻塞最多 10 秒，若无新元素，则返回 nil */

综合示例

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


//新建一个list叫做mylist，并在列表头部插入元素"1"
127.0.0.1:6379> lpush mylist "1" 
//返回当前mylist中的元素个数
(integer) 1 
//在mylist右侧插入元素"2"
127.0.0.1:6379> rpush mylist "2" 
(integer) 2
//在mylist左侧插入元素"0"
127.0.0.1:6379> lpush mylist "0" 
(integer) 3
//列出mylist中从编号0到编号1的元素
127.0.0.1:6379> lrange mylist 0 1 
1) "0"
2) "1"
//列出mylist中从编号0到倒数第一个元素
127.0.0.1:6379> lrange mylist 0 -1 
1) "0"
2) "1"
3) "2"

list类型数据操作注意事项

1.list中保存的数据都是string类型的，数据总容量是有限的，最多2^32-1个元素
2.list具有’‘索引’‘的概念，但是操作数据时通常以’‘队列’‘的形式进行入队出队操作，或以’‘栈’‘的形式进行入栈出栈操作
3.获取全部数据操作结束索引设置为-1
4.list可以对数据进行分页操作，通常第1页的信息来自于list，第2页及更多的信息通过’‘数据库’‘的形式加载

set

由唯一无序的元素组成，支持 O(1) 时间复杂度的添加、删除和查找操作，并提供交集、并集、差集等集合运算，适用于去重、推荐系统中的共同关注、标签管理等应用。由于不允许重复元素，可以高效存储不重复的数据集合。

基础操作

添加数据

1

sadd key member1 [member2]

获取全部数据

1

smembers key

删除数据

1

srem key member1 [member2]

获取集合数据总量

1

scard key

判断集合中是否包含指定数据

1

sismember key member

进阶操作

随机获取集合中指定数量的数据

1

srandmember key [count]

随机获取集合中的某个数据并将其移出集合

1

spop key

求两个集合的交、并、差集

1
2
3


sinter key1 [key2]
sunion key1 [key2]
sdiff key1 [key2]

求两个集合的交、并、差集并存储到指定集合中

1
2
3


sinterstore destination key1 [key2]
sunionstore destination key1 [key2]
sdiffstore destination key1 [key2]

将指定数据从原始集合中移动到目标集合中

1

smove source destination member

综合示例

 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


//向集合myset中加入一个新元素"one"
127.0.0.1:6379> sadd myset "one" 
(integer) 1
127.0.0.1:6379> sadd myset "two"
(integer) 1
//列出集合myset中的所有元素
127.0.0.1:6379> smembers myset 
1) "one"
2) "two"
//判断元素1是否在集合myset中，返回1表示存在
127.0.0.1:6379> sismember myset "one" 
(integer) 1
//判断元素3是否在集合myset中，返回0表示不存在
127.0.0.1:6379> sismember myset "three" 
(integer) 0
//新建一个新的集合yourset
127.0.0.1:6379> sadd yourset "1" 
(integer) 1
127.0.0.1:6379> sadd yourset "2"
(integer) 1
127.0.0.1:6379> smembers yourset
1) "1"
2) "2"
//对两个集合求并集
127.0.0.1:6379> sunion myset yourset 
1) "1"
2) "one"
3) "2"
4) "two"

set类型数据操作的注意事项

set类型不允许数据重复，如果添加的数据在set中已经存在，将只保留一份
set虽然和hash的存储结构相同，但是无法启用hash中存储值的空间

zset

在 Set 的基础上增加了一个分数（score），并按分数排序，支持范围查询、按分数排名等操作。适用于排行榜（如游戏积分榜）、优先级队列（如定时任务）、时间排序数据存储（如文章阅读量排名）等需要按权重排序的场景。

基础操作

添加数据

1

zadd key score1 member1 [score2 member2]

获取全部数据

1
2


zrange key start stop [WITHSCORES] //按从小到大的顺序展示
zrevrange key start stop [WITHSCORES] //按从大到小的顺序展示

删除数据

1

zrem key member [member...]

按条件获取数据

1
2


zrangebyscore key min max [Withscores][limit]
zrevrangebyscore key max min [withscores]

按条件删除数据

1
2


zremrangebyrank key start stop //按索引删除
zremrangebyscore key min max 	//按范围删除

综合示例

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


//新增一个有序集合myzset，并加入一个元素baidu.com，给它赋予的序号是1：
127.0.0.1:6379> zadd myzset 1 baidu.com 
(integer) 1
//向myzset中新增一个元素360.com，赋予它的序号是3
127.0.0.1:6379> zadd myzset 3 360.com 
(integer) 1
//向myzset中新增一个元素google.com，赋予它的序号是2
127.0.0.1:6379> zadd myzset 2 google.com 
(integer) 1
//列出myzset的所有元素，同时列出其序号，可以看出myzset已经是有序的了。
127.0.0.1:6379> zrange myzset 0 -1 with scores 
1) "baidu.com"
2) "1"
3) "google.com"
4) "2"
5) "360.com"
6) "3"
//只列出myzset的元素
127.0.0.1:6379> zrange myzset 0 -1 
1) "baidu.com"
2) "google.com"
3) "360.com"

进阶操作

获取集合数据总量

1
2


zcard key
zcount key min max

集合交、并集操作

1
2


zinterstore destination numkeys key [key …]
zunionstore destination numkeys key [key …]

sorted_set类型数据操作的注意事项

score保存的数据存储空间是64位，如果是整数范围是-9007199254740992~9007199254740992 score保存的数据也可以是一个双精度的double值，基于双精度浮点数的特征，可能会丢失精度，使用时候要慎重 sorted_set底层存储还是基于set结构的，因此数据不能重复，如果重复添加相同的数据，score值将被反复覆盖，保留最后一次修改的结果

MySQL

Mon, 17 Mar 2025 20:06:34 +0800

参考网站

自学SQL网(教程视频练习全套)

学完知识就有题做

MySQL 教程 | 菜鸟教程

MySQL总结_sq连表-CSDN博客

主键 - SQL教程 - 廖雪峰的官方网站

观感最好的教程

关系模型

引用自关系模型 - SQL教程 - 廖雪峰的官方网站

主键

在关系数据库中，一张表中的每一行数据被称为一条记录。一条记录就是由多个字段组成的。例如，students表的两行记录：

id	class id	name	gender	score
1	1	小明	M	90
2	1	小红	F	95

对于关系表，有个很重要的约束，就是任意两条记录不能重复。不能重复不是指两条记录不完全相同，而是指能够通过某个字段唯一区分出不同的记录，这个字段被称为主键。

例如，假设我们把name字段作为主键，那么通过名字小明或小红就能唯一确定一条记录。但是，这么设定，就没法存储同名的同学了，因为插入相同主键的两条记录是不被允许的。

对主键的要求，最关键的一点是：记录一旦插入到表中，主键最好不要再修改，因为主键是用来唯一定位记录的，修改了主键，会造成一系列的影响。

由于主键的作用十分重要，如何选取主键会对业务开发产生重要影响。如果我们以学生的身份证号作为主键，似乎能唯一定位记录。然而，身份证号也是一种业务场景，如果身份证号升位了，或者需要变更，作为主键，不得不修改的时候，就会对业务产生严重影响。

所以，选取主键的一个基本原则是：不使用任何业务相关的字段作为主键。

因此，身份证号、手机号、邮箱地址这些看上去可以唯一的字段，均不可用作主键。

作为主键最好是完全业务无关的字段，我们一般把这个字段命名为id。常见的可作为id字段的类型有：

自增整数类型：数据库会在插入数据时自动为每一条记录分配一个自增整数，这样我们就完全不用担心主键重复，也不用自己预先生成主键；
全局唯一GUID类型：也称UUID，使用一种全局唯一的字符串作为主键，类似8f55d96b-8acc-4636-8cb8-76bf8abc2f57。GUID算法通过网卡MAC地址、时间戳和随机数保证任意计算机在任意时间生成的字符串都是不同的，大部分编程语言都内置了GUID算法，可以自己预算出主键。

对于大部分应用来说，通常自增类型的主键就能满足需求。我们在students表中定义的主键也是BIGINT NOT NULL AUTO_INCREMENT类型。

如果使用INT自增类型，那么当一张表的记录数超过2147483647（约21亿）时，会达到上限而出错。使用BIGINT自增类型则可以最多约922亿亿条记录。

小结

主键是关系表中记录的唯一标识。主键的选取非常重要：主键不要带有业务含义，而应该使用BIGINT自增或者GUID类型。主键也不应该允许NULL。

可以使用多个列作为联合主键，但联合主键并不常用。

外键

当我们用主键唯一标识记录时，我们就可以在students表中确定任意一个学生的记录：

id	name	other columns…
1	小明	…
2	小红	…

我们还可以在classes表中确定任意一个班级记录：

id	name	other columns…
1	一班	…
2	二班	…

但是我们如何确定students表的一条记录，例如，id=1的小明，属于哪个班级呢？

由于一个班级可以有多个学生，在关系模型中，这两个表的关系可以称为“一对多”，即一个classes的记录可以对应多个students表的记录。

为了表达这种一对多的关系，我们需要在students表中加入一列class_id，让它的值与classes表的某条记录相对应：

id	class_id	name	other columns…
1	1	小明	…
2	1	小红	…
5	2	小白	…

这样，我们就可以根据class_id这个列直接定位出一个students表的记录应该对应到classes的哪条记录。

小明的class_id是1，因此，对应的classes表的记录是id=1的一班；
小红的class_id是1，因此，对应的classes表的记录是id=1的一班；
小白的class_id是2，因此，对应的classes表的记录是id=2的二班。

在students表中，通过class_id的字段，可以把数据与另一张表关联起来，这种列称为外键。

外键并不是通过列名实现的，而是通过定义外键约束实现的：

1
2
3
4


ALTER TABLE students
ADD CONSTRAINT fk_class_id
FOREIGN KEY (class_id)
REFERENCES classes (id);

其中，外键约束的名称fk_class_id可以任意，FOREIGN KEY (class_id)指定了class_id作为外键，REFERENCES classes (id)指定了这个外键将关联到classes表的id列（即classes表的主键）。

通过定义外键约束，关系数据库可以保证无法插入无效的数据。即如果classes表不存在id=99的记录，students表就无法插入class_id=99的记录。

由于外键约束会降低数据库的性能，大部分互联网应用程序为了追求速度，并不设置外键约束，而是仅靠应用程序自身来保证逻辑的正确性。这种情况下，class_id仅仅是一个普通的列，只是它起到了外键的作用而已。

要删除一个外键约束，也是通过ALTER TABLE实现的：

1
2


ALTER TABLE students
DROP FOREIGN KEY fk_class_id;

注意：删除外键约束并没有删除外键这一列。删除列是通过DROP COLUMN ...实现的。

多对多

通过一个表的外键关联到另一个表，我们可以定义出一对多关系。有些时候，还需要定义“多对多”关系。例如，一个老师可以对应多个班级，一个班级也可以对应多个老师，因此，班级表和老师表存在多对多关系。

多对多关系实际上是通过两个一对多关系实现的，即通过一个中间表，关联两个一对多关系，就形成了多对多关系：

teachers表：

id	name
1	张老师
2	王老师
3	李老师
4	赵老师

classes表：

id	name
1	一班
2	二班

中间表teacher_class关联两个一对多关系：

id	teacher_id	class_id
1	1	1
2	1	2
3	2	1
4	2	2
5	3	1
6	4	2

通过中间表teacher_class可知teachers到classes的关系：

id=1的张老师对应id=1,2的一班和二班；
id=2的王老师对应id=1,2的一班和二班；
id=3的李老师对应id=1的一班；
id=4的赵老师对应id=2的二班。

同理可知classes到teachers的关系：

id=1的一班对应id=1,2,3的张老师、王老师和李老师；
id=2的二班对应id=1,2,4的张老师、王老师和赵老师；

因此，通过中间表，我们就定义了一个“多对多”关系。

一对一

一对一关系是指，一个表的记录对应到另一个表的唯一一个记录。

例如，students表的每个学生可以有自己的联系方式，如果把联系方式存入另一个表contacts，我们就可以得到一个“一对一”关系：

id	student_id	mobile
1	1	135xxxx6300
2	2	138xxxx2209
3	5	139xxxx8086

有细心的童鞋会问，既然是一对一关系，那为啥不给students表增加一个mobile列，这样就能合二为一了？

如果业务允许，完全可以把两个表合为一个表。但是，有些时候，如果某个学生没有手机号，那么，contacts表就不存在对应的记录。实际上，一对一关系准确地说，是contacts表一对一对应students表。

还有一些应用会把一个大表拆成两个一对一的表，目的是把经常读取和不经常读取的字段分开，以获得更高的性能。例如，把一个大的用户表分拆为用户基本信息表user_info和用户详细信息表user_profiles，大部分时候，只需要查询user_info表，并不需要查询user_profiles表，这样就提高了查询速度。

小结

关系数据库通过外键可以实现一对多、多对多和一对一的关系。外键既可以通过数据库来约束，也可以不设置约束，仅依靠应用程序的逻辑来保证。

索引

在关系数据库中，如果有上万甚至上亿条记录，在查找记录的时候，想要获得非常快的速度，就需要使用索引。

索引是关系数据库中对某一列或多个列的值进行预排序的数据结构。通过使用索引，可以让数据库系统不必扫描整个表，而是直接定位到符合条件的记录，这样就大大加快了查询速度。

例如，对于students表：

id	class_id	name	gender	score
1	1	小明	M	90
2	1	小红	F	95
3	1	小军	M	88

如果要经常根据score列进行查询，就可以对score列创建索引：

1
2


ALTER TABLE students
ADD INDEX idx_score (score);

使用ADD INDEX idx_score (score)就创建了一个名称为idx_score，使用列score的索引。索引名称是任意的，索引如果有多列，可以在括号里依次写上，例如：

1
2


ALTER TABLE students
ADD INDEX idx_name_score (name, score);

索引的效率取决于索引列的值是否散列，即该列的值如果越互不相同，那么索引效率越高。反过来，如果记录的列存在大量相同的值，例如gender列，大约一半的记录值是M，另一半是F，因此，对该列创建索引就没有意义。

可以对一张表创建多个索引。索引的优点是提高了查询效率，缺点是在插入、更新和删除记录时，需要同时修改索引，因此，索引越多，插入、更新和删除记录的速度就越慢。

对于主键，关系数据库会自动对其创建主键索引。使用主键索引的效率是最高的，因为主键会保证绝对唯一。

唯一索引

在设计关系数据表的时候，看上去唯一的列，例如身份证号、邮箱地址等，因为他们具有业务含义，因此不宜作为主键。

但是，这些列根据业务要求，又具有唯一性约束：即不能出现两条记录存储了同一个身份证号。这个时候，就可以给该列添加一个唯一索引。例如，我们假设students表的name不能重复：

1
2


ALTER TABLE students
ADD UNIQUE INDEX uni_name (name);

通过UNIQUE关键字我们就添加了一个唯一索引。

也可以只对某一列添加一个唯一约束而不创建唯一索引：

1
2


ALTER TABLE students
ADD CONSTRAINT uni_name UNIQUE (name);

这种情况下，name列没有索引，但仍然具有唯一性保证。

无论是否创建索引，对于用户和应用程序来说，使用关系数据库不会有任何区别。这里的意思是说，当我们在数据库中查询时，如果有相应的索引可用，数据库系统就会自动使用索引来提高查询效率，如果没有索引，查询也能正常执行，只是速度会变慢。因此，索引可以在使用数据库的过程中逐步优化。

小结

通过对数据库表创建索引，可以提高查询速度；

通过创建唯一索引，可以保证某一列的值具有唯一性；

数据库索引对于用户和应用程序来说都是透明的。

SELECT 查询

1
2
3
4
5
6
7
8


SELECT column, another_column, …
FROM mytable
WHERE condition
 AND/OR another_condition
 AND/OR …;
 
SELECT * FROM movies 
WHERE year>=2010 AND length_minutes<120;

筛选数字属性列

关键字		例
=, !=, < <=, >, ≥		col_name != 4
BETWEEN … AND …	在两个数之间	col_name BETWEEN 1.5 AND 10.5
NOT BETWEEN … AND …		col_name NOT BETWEEN 1 AND 10
IN (…)	在一个列表	col_name IN (2, 4, 6)
NOT IN (…)		col_name NOT IN (1, 3, 5)

筛选字符串属性列


=	完全等于
!= or <>	不等于
LIKE	没有用通配符等价于 =
NOT LIKE	没有用通配符等价于 !=
%	通配符	col_name LIKE “%AT%”
_(下划线)		col_name LIKE “AN_”

1
2
3
4
5
6
7


/*通配符*/
col_name LIKE "%AT%";
/*"AT""AT*...""...*AT""...*AT*..."均满足条件
 "AT"前后可以有任意字符*/
col_name LIKE "AN_";
/*"AND"可以 "AN""ANDD"均不行
 与'%'相似 但只代表一个字符*/

过滤/排序

1
2
3
4


/*用DISTINCT关键字来指定某个或某些属性列唯一返回*/
SELECT DISTINCT column, another_column, …
FROM mytable
WHERE condition(s);

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


/*让结果按一个或多个属性列做排序*/
SELECT column, another_column, …
FROM mytable
WHERE condition(s)
/* ASC 升序或 DESC 降序*/
ORDER BY column ASC/DESC
/*LIMIT来指定只返回多少行结果 
 用OFFSET来指定从哪一行开始返回*/
LIMIT num_limit OFFSET num_offset;
/*关于OFFSET 若要输出第N行(及之后)
 则OFFSET的参数须为N-1 */

例题

SELECT复习题

在查询中使用表达式

实际上AS不仅用在表达式别名上，普通的属性列甚至是表（table）都可以取一个别名，这让SQL更容易理解

1
2
3
4
5


--属性列和表取别名的例子
SELECT column AS better_column_name, …
FROM a_long_widgets_table_name AS mywidgets
INNER JOIN widget_sales
 ON mywidgets.id = widget_sales.widget_id;

1
2
3
4
5


--包含表达式的例子
SELECT particle_speed / 2.0 AS half_particle_speed --对结果做了一个除2
FROM physics_data
WHERE ABS(particle_position) * 10.0 >500
 --（条件要求这个属性绝对值乘以10大于500）;

在查询中进行统计

1
2
3


SELECT AGG_FUNC(column_or_expression) AS aggregate_description, …
FROM mytable
WHERE constraint_expression;

常用统计函数:

Function	Description
COUNT(*) COUNT(column)	计数！COUNT(*) 统计数据行数，COUNT(column) 统计column非NULL的行数
MIN(column)	找column最小的一行
MAX(column)	找column最大的一行
AVG(column)	对column所有行取平均值
SUM(column)	对column所有行求和

分组统计

GROUP BY 数据分组语法可以按某个col_name对数据进行分组，如：GROUP BY Year指对数据按年份分组，相同年份的分到一个组里。如果把统计函数和GROUP BY结合，那统计结果就是对分组内的数据统计了 GROUP BY 分组结果的数据条数，就是分组数量，比如：GROUP BY Year，全部数据里有几年，就返回几条数据，不管是否应用了统计函数

1
2
3
4
5


--用分组的方式统计
SELECT AGG_FUNC(column_or_expression) AS aggregate_description, …
FROM mytable
WHERE constraint_expression
GROUP BY column;

在 GROUP BY 分组语法中，我们知道数据库是先对数据做 WHERE ，然后对结果做分组，如果我们要对分组完的数据再筛选出几条如何办？一个不常用的语法 HAVING 语法将用来解决这个问题，他可以对分组之后的数据再做SELECT筛选

HAVING 和 WHERE 语法一样，只不过作用的结果集不一样. 在我们例子数据表数据量小的情况下可能感觉 HAVING 没有什么用，但当你的数据量成千上万属性又很多时也许能帮上大忙

JOIN 连接

数据库范式

数据库范式是数据表设计的规范，在范式规范下，数据库里每个表存储的重复数据降到最少(这有助于数据的一致性维护)同时在数据库范式下，表和表之间不再有很强的数据耦合，可以独立的增长(ie. 比如汽车引擎的增长和汽车的增长是完全独立的)

1
2
3
4
5
6
7
8


SELECT column, another_table_column, …
FROM mytable --主表
INNER JOIN another_table --要连接的表
 ON mytable.id = another_table.id 
 --想象一下刚才讲的主键连接，两个相同的连成1条
WHERE condition(s)
ORDER BY column, … ASC/DESC
LIMIT num_limit OFFSET num_offset;

本例中ON条件描述的关联关系:

`INNER JOIN` (内)连接

先将两个表数据连接到一起，两个表中如果通过ID互相找不到的数据将会舍弃。此时，你可以将连表后的数据看作两个表的合并，SQL中的其他语句会在这个合并基础上继续执行(想一下和之前的单表操作就一样了) 还有一个理解 INNER JOIN 的方式，就是把 INNER JOIN 想成两个集合的交集。

`OUTER JOIN`外连接

1
2
3
4
5
6
7
8


--用LEFT/RIGHT/FULL JOINs 做多表查询
SELECT column, another_column, …
FROM mytable
INNER/LEFT/RIGHT/FULL JOIN another_table
 ON mytable.id = another_table.matching_id
WHERE condition(s)
ORDER BY column, … ASC/DESC
LIMIT num_limit OFFSET num_offset;

在表A 连接 B， LEFT JOIN 保留A的所有行，不管有没有能匹配上B，反过来 RIGHT JOIN则保留所有B里的行。最后FULL JOIN 不管有没有匹配上，同时保留A和B里的所有行

将两个表数据1-1连接，保留A或B的原有行，如果某一行在另一个表不存在，会用 NULL来填充结果数据。

查询执行顺序

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


--这才是完整的SELECT查询
SELECT DISTINCT column, AGG_FUNC(column_or_expression), …
FROM mytable
 JOIN another_table
 ON mytable.column = another_table.column
 WHERE constraint_expression
 GROUP BY column
 HAVING constraint_expression
 ORDER BY column ASC/DESC
 LIMIT count OFFSET COUNT;

1. `FROM` 和 `JOIN`

FROM 或 JOIN 会第一个执行，确定一个整体的数据范围. 如果要JOIN不同表，可能会生成一个临时Table来用于下面的过程。总之第一步可以简单理解为确定一个数据源表（含临时表）

2. `WHERE`

我们确定了数据来源 WHERE 语句就将在这个数据源中按要求进行数据筛选，并丢弃不符合要求的数据行，所有的筛选col属性只能来自 FROM 圈定的表. AS别名还不能在这个阶段使用，因为可能别名是一个还没执行的表达式

3. `GROUP BY`

如果你用了 GROUP BY 分组，那 GROUP BY 将对之前的数据进行分组，统计等，并将是结果集缩小为分组数.这意味着其他的数据在分组后丢弃.

4. `HAVING`

如果你用了 GROUP BY 分组, HAVING 会在分组完成后对结果集再次筛选。AS别名也不能在这个阶段使用.

5. `SELECT`

确定结果之后， SELECT 用来对结果col简单筛选或计算，决定输出什么数据.

6. `DISTINCT`

如果数据行有重复 DISTINCT 将负责排重.

7. `ORDER BY`

在结果集确定的情况下， ORDER BY 对结果做排序。因为 SELECT 中的表达式已经执行完了。此时可以用AS别名.

8. `LIMIT` / `OFFSET`

最后 LIMIT 和 OFFSET 从排序的结果中截取部分数据.

结论

不是每一个SQL语句都要用到所有的句法，但灵活运用以上的句法组合和深刻理解SQL执行原理将能在SQL层面更好的解决数据问题，而不用把问题都抛给程序逻辑.

NULL

如果某个字段你没有填写到数据库，很可能就会出现 NULL 。所有一个常见的方式就是为字段设置 默认值 ,比如数字的默认值设置为0，字符串设置为 "" 字符串. 但是在一些 NULL 表示它本来含义的场景，需要注意是否设置默认值还是保持 NULL 。 (比如, 当你计算一些行的平均值的时候，如果是0会参与计算导致平均值差错，是 NULL 则不会参与计算).

还有一些情况很难避免 NULL 的出现, 比如之前说的 outer-joining 多表连接，A和B有数据差异时，必须用 NULL 来填充。这种情况，可以用 IS NULL 和 IS NOT NULL 来选在某个字段是否等于 NULL.

1
2
3
4
5


SELECT column, another_column, …
FROM mytable
WHERE column IS/IS NOT NULL
AND/OR another_condition
AND/OR …;

修改数据

部分引用自修改数据 - SQL教程 - 廖雪峰的官方网站

关系数据库的基本操作就是增删改查，即CRUD：Create、Retrieve、Update、Delete。其中，对于查询，我们已经详细讲述了SELECT语句的详细用法。

而对于增、删、改，对应的SQL语句分别是：

INSERT：插入新记录；
UPDATE：更新已有记录；
DELETE：删除已有记录。

我们将分别讨论这三种修改数据的语句的使用方法。

INSERT 插入

引用于 MySQL 插入数据 | 菜鸟教程

例如，我们向user表插入一条新记录，先列举出需要插入的字段名称，然后在VALUES子句中依次写出对应字段的值：

1
2
3
4
5


INSERT INTO table_name (column1, column2, column3, ...)
VALUES (value1, value2, value3, ...);
--
INSERT INTO users (username, email, birthdate, is_active)
VALUES ('test', 'test@runoob.com', '1990-01-01', true);

如果要插入所有列(即插入行)的数据，可以省略列名：

1
2


INSERT INTO users
VALUES (NULL,'test', 'test@runoob.com', '1990-01-01', true);

还可以一次性添加多条记录，只需要在VALUES子句中指定多个记录值，每个记录是由(...)包含的一组值，每组值用逗号,分隔：

1
2
3
4
5


INSERT INTO users (username, email, birthdate, is_active)
VALUES
 ('test1', 'test1@runoob.com', '1985-07-10', true),
 ('test2', 'test2@runoob.com', '1988-11-25', false),
 ('test3', 'test3@runoob.com', '1993-05-03', true);

UPDATE 更新

MySQL UPDATE 更新 | 菜鸟教程

1
2
3


UPDATE table_name
SET column1 = value1, column2 = value2, ...
WHERE condition;

参数说明：

table_name 是你要更新数据的表的名称。
column1, column2, … 是你要更新的列的名称。
value1, value2, … 是新的值，用于替换旧的值。
WHERE condition 是一个可选的子句，用于指定更新的行。如果省略 WHERE 子句，将更新表中的所有行。

更多说明：

你可以同时更新一个或多个字段。
你可以在 WHERE 子句中指定任何条件。
你可以在一个单独表中同时更新数据。

当你需要更新数据表中指定行的数据时 WHERE 子句是非常有用的。

1
2
3
4


--更新单个列的值
UPDATE employees
SET salary = 60000
WHERE employee_id = 101;

1
2
3
4


--更新多个列的值
UPDATE orders
SET status = 'Shipped', ship_date = '2023-03-01'
WHERE order_id = 1001;

1
2
3
4


--使用表达式更新值
UPDATE products
SET price = price * 1.1
WHERE category = 'Electronics';

1
2
3
4
5
6
7
8


--更新使用子查询的值
UPDATE customers
SET total_purchases = (
 SELECT SUM(amount)
 FROM orders
 WHERE orders.customer_id = customers.customer_id
)
WHERE customer_type = 'Premium';

在使用MySQL这类真正的关系数据库时，UPDATE语句会返回更新的行数以及WHERE条件匹配的行数。

例如，更新id=1的记录时：

1
2
3


mysql> UPDATE students SET name='大宝' WHERE id=1;
Query OK, 1 row affected (0.00 sec)
Rows matched: 1 Changed: 1 Warnings: 0

MySQL会返回1，可以从打印的结果Rows matched: 1 Changed: 1看到。

当更新id=999的记录时：

1
2
3


mysql> UPDATE students SET name='大宝' WHERE id=999;
Query OK, 0 rows affected (0.00 sec)
Rows matched: 0 Changed: 0 Warnings: 0

MySQL会返回0，可以从打印的结果Rows matched: 0 Changed: 0看到。

DELETE 删除

DELETE语句的基本语法是：

1

DELETE FROM <表名> WHERE ...;

例如，我们想删除students表中id=1的记录，就需要这么写：

1
2
3
4


-- 删除id=1的记录:
DELETE FROM students WHERE id=1;
-- 查询并观察结果:
SELECT * FROM students;

注意到DELETE语句的WHERE条件也是用来筛选需要删除的行，因此和UPDATE类似，DELETE语句也可以一次删除多条记录：

1
2
3
4


-- 删除id=5,6,7的记录:
DELETE FROM students WHERE id>=5 AND id<=7;
-- 查询并观察结果:
SELECT * FROM students;

如果WHERE条件没有匹配到任何记录，DELETE语句不会报错，也不会有任何记录被删除。例如：

1
2
3
4


-- 删除id=999的记录:
DELETE FROM students WHERE id=999;
-- 查询并观察结果:
SELECT * FROM students;

最后，要特别小心的是，和UPDATE类似，不带WHERE条件的DELETE语句会删除整个表的数据：

1

DELETE FROM students;

这时，整个表的所有记录都会被删除。所以，在执行DELETE语句时也要非常小心，最好先用SELECT语句来测试WHERE条件是否筛选出了期望的记录集，然后再用DELETE删除。

在使用MySQL这类真正的关系数据库时，DELETE语句也会返回删除的行数以及WHERE条件匹配的行数。

例如，分别执行删除id=1和id=999的记录：

1
2
3
4
5


mysql> DELETE FROM students WHERE id=1;
Query OK, 1 row affected (0.01 sec)

mysql> DELETE FROM students WHERE id=999;
Query OK, 0 rows affected (0.01 sec)

CREATE 创建

MySQL 创建数据表 | 菜鸟教程

1
2
3
4
5
6
7
8


--用户表实例
CREATE TABLE users (
 id INT AUTO_INCREMENT PRIMARY KEY,
 username VARCHAR(50) NOT NULL,
 email VARCHAR(100) NOT NULL,
 birthdate DATE,
 is_active BOOLEAN DEFAULT TRUE
);

实例解析：

id: 用户 id，整数类型，自增长，作为主键。
username: 用户名，变长字符串，不允许为空。
email: 用户邮箱，变长字符串，不允许为空。
birthdate: 用户的生日，日期类型。
is_active: 用户是否已经激活，布尔类型，默认值为 true。

以上只是一个简单的实例，用到了一些常见的数据类型包括INT, VARCHAR, DATE, BOOLEAN，可以根据实际需要选择不同的数据类型。

AUTO_INCREMENT 关键字用于创建一个自增长的列，PRIMARY KEY 用于定义主键。

如果希望在创建表时指定数据引擎，字符集和排序规则等，可以使用 CHARACTER SET 和 COLLATE 子句：

1
2
3
4


CREATE TABLE mytable (
    id INT PRIMARY KEY,
    name VARCHAR(50)
) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;

技术 on 边个濑椰的博客

从零开始配置VPS

VPS选购

安全性配置

SSH登录

稀疏向量与 SPLADE 模型

参考网站

稀疏向量与 SPLADE 模型

论文模型

排序损失

FLOPS 稀疏正则

总体损失

从求和到最大池化

SPLADE-doc 与蒸馏训练

稀疏性为什么重要

模型选择

SPLADE 和 BM25 的区别

Practical BM25

参考网站

Background

Understanding How Shards Affect Scoring

Algorithm and its variables

$q_i$

$IDF(q_i)$

$fieldLen/avgFieldLen$

$b$

$f(q_i, D)$

$k_1$

Picking $b$ and $k_1$

RAGFlow切片策略解析

RAGFlow 切片策略解析

rag/app/naive.py

__call()__

extract_tables_and_remainder()

MarkdownElementExtractor

extract_image_urls_with_lines()

load_images_from_urls()

urls_in_section = [...]

表格处理细节

chunk()

VisionFigureParser

_extract_figures_info()

__call__()

picture_vision_llm_chunk()

vision_llm_figure_describe_prompt()

sections[idx] = (...)

小结

CS224N Assignment3 NMT

CS 224n Spring 2024: Assignment #3

Neural Machine Translation with RNNs

Model description (training procedure)

Implementation and written questions

__init__()

encode

decode

step

Attention Masking

Training

Attention Comparison

Dot Product vs. Multiplicative

Additive vs. Multiplicative

Analyzing NMT Systems

BLEU

群晖NAS代理及Emby配置

v2rayA

Emby

如何在WSL2上使用本机代理

.wslconfig

v2rayN

FireWall

wsl2

清理旧设置

~/.bashrc

再不成功的解决方案

CS224N

Intro

What is this course about?

Word Vectors

How do we have usable meaning in a computer?

Word2vec

`rag/app/naive.py`

`call()`

`extract_tables_and_remainder()`

`MarkdownElementExtractor`

`extract_image_urls_with_lines()`

`load_images_from_urls()`

`urls_in_section = [...]`

`chunk()`

`VisionFigureParser`

`_extract_figures_info()`

`call()`

`picture_vision_llm_chunk()`

`vision_llm_figure_describe_prompt()`

`sections[idx] = (...)`

`init()`

`encode`

`decode`

`step`