硬件

目前使用的是天钡 WTR R1，配置如下：

• CPU: Intel N100

• 内存：16G

• 硬盘：256G 固态做系统盘，4T+16T 机械做数据盘

系统

PVE

PVE是一个可以运行在裸机上的开源虚拟机系统，基于debian和qemu/kvm，同时提供了方便的web和cli界面。官网：https://pve.proxmox.com/。

虚拟机配置

目前我的主力nas系统是一个叫做OpenMediaVault的系统，相比于命令行，它提供了一个简单的管理nas的图形界面，方便快速配置一些服务。

这里我贴上在pve里面的虚拟机配置，就不一一细讲了：

其中配置比较麻烦的是最下面的PCI设备，这是将显卡直通到了虚拟机里，需要启用IOMMU等功能，我也是一知半解地搞好了，有需要的可以搜索关键字“PVE显卡直通”查详细资料。

官网的资料：PCI(e)_Passthrough、PCI_Passthrough。

磁盘

物理磁盘上，目前我有两块机械硬盘（4T+16T），一块固态（256G），没有组raid，纯手工管理。

固态上主要用于放置虚拟系统的虚拟盘，因此其中跑的各种服务的数据库也在固态上放着，能加快服务的访问。

机械盘里面主要存数据，比如下载的电影电视、备份的照片与文件等等。

通常，使用pve时每个系统会挂在各自的硬盘，但是对我来说，各个系统之间数据共享是很重要的，例如我在群晖（单独的系统）上备份的照片，需要立即在samba、nfs、nextcloud等地方（nas系统）能看到，这就需要它们之间能够共享同一个目录。

所以最终我选择的方案是：宿主机挂载物理硬盘，然后通过9pfs/virtiofs等文件系统分享给虚拟系统。 这两个文件系统都可以实现虚拟机内外共享目录，其原理是转发虚拟机内的文件系统操作到宿主机，不过不需要走网络请求，本地传输理论上会快一些。

不过pve自身并不支持这两个方案，所以需要在conf文件中手动修改qemu的命令行参数，会有一点麻烦。

这两个使用和配置起来有些差异，最终我选择了virtiofs。

9pfs（弃用）

之前看韦易笑大佬的文章配置的，所以一开始我使用的9pfs，但是用过一段时间之后，发现有一些比较影响使用的问题：

1. 性能问题

经过一段时间的使用，发现通过9pfs挂载的目录性能很成问题，7zip解压、rsync同步等都很慢，就连nextcloud的速度也会变得很慢，可能是随机读写慢？这点有点无法接受。

2. 不支持nfs

之前预计是在虚拟机的nas系统中启用nfs和samba，但是发现9pfs不支持nfs。

3. sqlite无法读取，影响jellyfin的运行，原因是在默认的参数下，mmap无法在9pfs中调用：

通过给挂载参数中添加cache=mmap解决。

• 参考

  https://patchwork.kernel.org/project/v9fs-devel/patch/1389384004-5685-1-git-send-email-dominique.martinet@cea.fr/

  https://www.kernel.org/doc/Documentation/filesystems/9p.txt

virtio-fs（选这个）

virtiofs配置稍微麻烦一点，但性能要比9pfs好很多（同样一个zip文件，肉眼可见大概比9pfs快2-3倍左右），同时限制也更少（直接支持nfs、mmap）。

virtiofs并不是qemu内置支持的，而是需要运行一个后台进程virtiofsd。这个后台进程需要跟着虚拟机启动时开启，虚拟机关闭时关闭，所以可以通过pve的hookscript来实现：

1. 在/var/lib/vz/snippets目录下新建文件nas-hookscript.sh，添加以下内容：

#!/bin/sh

vmid=$1
phase=$2

case $phase in
    pre-start)
      echo pre-start vmid=$vmid phase=$phase
      systemd-run -G --unit=virtiofsd /usr/libexec/virtiofsd --shared-dir /mnt --socket-path /run/virtiofs-sea.sock --announce-submounts --inode-file-handles=mandatory --syslog
      ;;
esac

其中，—shared-dir参数需要替换成需要的目录。

然后通过qm set 102 --hookscript local:snippets/nas-hookscript.sh命令，将该脚本设置为虚拟机的hookscript，这里的102是虚拟机id。

这里使用systemd-run是因为hookscript需要立即退出，所以里面运行的daemon进程必须得是double-fork之后的，不能阻塞hookscript，而systemd-run默认会让进程以服务的形式运行，同时也支持将日志重定向到journald（这里通过—unit=virtiofsd选项将这条命令作为一个具名的临时服务运行了）。

virtiofsd命令会等待第一个客户端连接（也就是虚拟机启动后），第一个客户端断开连接后virtiofsd会结束进程。

2. 打开pve的conf文件，目录一般在/etc/pve/qemu-server中，文件名是$虚拟机ID.conf，在里面添加如下一行：

args: -chardev socket,id=char0,path=/run/virtiofs-sea.sock -device vhost-user-fs-pci,queue-size=1024,chardev=char0,tag=sea -object memory-backend-file,id=mem,size=6G,mem-path=/dev/shm,share=on -numa node,memdev=mem -m 6G

其中，两个6G按照需要设置，它们的大小其实就是你要给虚拟机的内存大小（-m会覆盖pve的设置）。

/run/virtiofs-sea.sock是上面virtiofs监听的sock文件。

还有一点是这里要用/dev/shm做共享内存，/dev/shm默认是物理内存的一半，可能会不够用，可以在fstab中添加一行tmpfs /dev/shm tmpfs defaults,size=8G 0 0适当增加shm的大小。

至于为什么要配置这一大堆内存相关的东西（numa、shm之类的）我目前不太清楚，官方文档暂时是这样推荐的，后面在慢慢了解吧。

3. 添加完之后重启虚拟机即可。不出意外的话，通过systemctl status virtiofsd可以看到daemon正常启动了，日志里面也会有Client connected, servicing requests的提示。这时候就可以进入虚拟机系统挂载文件系统了，在fstab中添加：

sea /mnt virtiofs rw 0 0 # 这里的sea是在qemu命令中设置的tag名

执行mount -a进行挂载即可。

这里要注意tag不能是mnt，会导致各种报错，不确定什么原因……

• 参考

  https://virtio-fs.gitlab.io/howto-qemu.html

  https://forum.proxmox.com/threads/virtiofsd-in-pve-8-0-x.130531/

OpenMediaVault

OpenMediaVault是一个开源的nas系统，同样是基于debian。使用一段时间下来发现它提供的主要功能就是一个图形化的web界面，在里面可以快速配置邮箱、定时任务、nfs、samba等服务，也能查看监控等，更多其余的服务还是得自己配置docker。

(下面会把OpenMediaVault简写为omv。）

问题

这里记录一下使用时遇到的几个问题。

1. /dev/dri权限问题

omv中默认的dri目录内的权限是660，非root非render组的用户无法访问，但是由于我的很多服务都没有直接使用root账户跑，在docker里面也不方便加组，所以就需要改下udev的规则，将/dev/dri/的权限改为666。

修改文件/lib/udev/rules.d/50-udev-default.rules，在其中找renderD*字样，将那一行的MODE改为"0666"，然后重启即可：

2. （使用9pfs时遇到，virtiofs不会遇到）omv里面的qbittorrent/nextcloud等服务提示打开文件过多，一开始以为是omv里面的ulimit设置的太小，只有1024，但是后面排查下来，发现只有通过9pfs挂载的目录会出现这个问题，所以去查了pve的ulimit，也只有1024，同时查看当前虚拟机的kvm进程的打开文件数量，刚好到了1024，所以实际的原因是9pfs要使用的文件描述符不够了。

需要在pve宿主机上面增加ulimit数量：

1. 打开/etc/security/limits.conf，加两行内容：

```text
root - nofile 128000
* - nofile 128000
```

2. 打开/etc/systemd/system.conf，添加一行内容：

```纯文本
DefaultLimitNOFILE=128000:524288
```

然后重启pve即可。

软件

接下来简单介绍下系统中部署的软件与服务。

关于数据存放

目前大部分服务都是在docker中部署的，docker容器需要保存的数据一般不会太大，目前跑的8个容器，需要保存和备份的数据总共也就4G，其中大头是nextcloud和jellyfin的数据库，所以将这些数据都放到固态上，不会有多少存储压力，还能显著提高这些服务的访问速度。

至于媒体文件、网盘内容文件等，则放到机械盘上面，速度通常不会影响太多。

nginx和域名

• 跑在docker中，代理omv的主页。 omv默认有自己的nginx，不过是在omv宿主机上，不方便管理，因此我把omv的nginx监听到了其他端口上，然后单独跑了个nginx容器，用容器里面的nginx做主服务器，nextcloud、jellyfin以及omv等服务跑在这个服务后面。

certbot/ddns

• 自己用python造的轮子，支持阿里的dns服务，定时检查来实现ddns。
• 证书更新则使用certbot-cli的hook完成dns-challenge，运行一遍之后，certbot可以自己记下命令，特别方便。

root@nas ~/d/ddns cat certbot-cert.sh | tail -n 10
sudo certbot -d $DOMAIN --manual \
    --preferred-challenges dns \
    --renew-by-default \
    certonly \
    --manual-auth-hook "$PWD/certbot-hook.py -c $ALI_CONFIG" \
    --manual-cleanup-hook "$PWD/certbot-hook.py -c $ALI_CONFIG" \
    --cert-name $DOMAIN \
    --non-interactive \
    --agree-tos --email xxx

root@nas ~/d/ddns cat certbot-hook.py | tail -n 15 | head -n 11
    init_ali_client(config['access_key'], config['access_key_secret'])

    is_cleanup = os.environ.get('CERTBOT_AUTH_OUTPUT', None) is not None
    domain = '_acme-challenge.' + os.environ['CERTBOT_DOMAIN']
    value = os.environ['CERTBOT_VALIDATION']
    if not is_cleanup:
        update_dns_record(domain, value, allow_add=True, type_='TXT')
        print(f'updated record for domain {domain}')
    else:
        delete_dns_record(domain=domain, type_='TXT')
        print(f'deleted record for domain {domain}')

PT服务：qbittorrent

媒体库：Jellyfin Plex

文件管理与共享：samba + nfs + nextcloud

文件同步

• Syncthing

Email

• 阿里云邮箱+自定义域名

监控：graphite采集数据，grafana展示数据

• 部署到另外一台虚拟机上，避免nas系统挂掉的问题

备份

定时备份

• rsync备份命令：~~~~rsync -r --links /root/docker /mnt/sea/docker-backup/ --exclude 'docker/qbittorrent/data/config/qBittorrent/ipc-socket'~~~~，将命令添加到crontab中即可。备份所需要的时间比较长，通常得四五分钟的样子。备份期间，CPU占用大概在10%-20%，主要应该是rsync在校验数据。考虑到目前设置的每周执行一次，这个速度与CPU使用率还可以接受。
• zip备份命令：zip -ryq /mnt/sea/docker-backup.zip /root/docker/ -x 'docker/qbittorrent/data/config/qBittorrent/ipc-socket'。切换到zip的原因是方便上传到对象存储、网盘等地方，同时也能压缩一次，减小一些体积。而且使用时发现zip的-f选项增量更新时，速度要比rsync快不少，大概30s左右就可以结束运行，不过运行时的CPU使用率就比较高，大概在50%左右。理论上，如果使用-0选项，也就是不压缩的话，速度应该可以更快一些。

需要备份的数据

• docker数据

网络

• openwrt

使用Firefox替换Chrome

前段时间有点忙，经常出现好几个Chrome窗口的标签页拥挤到只能看到图标和几个字的情况。之前看到同事使用Edge的纵向标签页，纵向布局能比较好地处理这种情况，无论多么拥挤，至少标题能看得清楚。但是实在不太喜欢Edge的满满营销味道，因此在一番调研之后，决定尝试切换到Firefox。

之前其实用过一段时间的Firefox，并非由特别强烈的需求驱动，主要是为了逃离Chrome。不过刚入职那会由于飞书以及很多公司内平台对Firefox的支持不太好，导致又换回了Chrome。而这次切换到Firefox是冲着用着舒服来的，同时在使用了一段时间后，发现竟有一些意外之喜。不出问题的话，在很长时间内，我的主力浏览器都会是Firefox。

这里总结下目前发现的Firefox的一些优势。

一、树状标签页

首先就是前面提到的纵向标签页了。

Firefox的纵向标签页主要是通过Tree Style Tab这个插件提供的（商店链接）。先上目前的效果图：

可以看到，这个插件提供的并不只有纵向标签页，而是“树状”标签页，这也是它名字的由来。这个标签树的基本创建逻辑为：如果点击页面A的某个链接，打开了新页面B，那么B就是A的子标签。

这样的树结构最大的好处在于，相关的标签页通常都会自动放到同一个树枝下面，也就是相关的任务会被自动分到一组。这一点在大量查资料的时候特别好用，可以随时看到整体查询的路径，在某条查询路径不需要之后，也可以一起折叠或者关掉。

毕竟我们通常在浏览器查询的过程都是一个树形的工作路径，伴随着链接一层层打开，标签页也就不断变多了。线性的标签管理会把这些层级拍平，相当于做了个拓扑排序，这点其实与人的思路是有所冲突的；而树状标签管理可以做到不破坏这些层级，一定程度上可以对工作时的思维结构起到辅助作用。

标签页的结构一定程度上体现的是工作学习中的思维结构，比如“正在做几件事”、“事情A涉及到哪些平台”、“事情B如何细分”、“事情B和C的关系”等等，这些通常都有对应的浏览器标签页。

总之，一开始我只是想找个纵向标签页，结果却发现了树状标签页，算是意外之喜之一。

二、定制UI

如果只是装上上面提到的树状标签页插件，你会发现旧的Firefox自带的标签页仍旧存在，这会导致界面信息的冗余，以及难以养成使用树状标签的习惯（习惯性地使用顶部标签页）。

好在Firefox提供了特别强大的定制能力，可以利用这个定制能力把标题栏给隐藏掉。其实Firefox的主界面本质上就是个H5页面，因此可以通过定制的js/css调整几乎任意一处细节。

这个定制能力一般称作userChrome.css，可以参考这个网站（至于为什么Firefox的功能名里面包含Chrome，这我就不是很清楚了😃）

具体来说，要实现这样的效果（隐藏原有Tab栏、隐藏标题栏）：

只需要在userChrome.css中添加如下代码：

/* 这段CSS请仅在Linux上使用（KDE/Gnome等），Windows和Mac的Firefox表现不太一样。 */

#tabbrowser-tabs, #sidebar-header {
  visibility: collapse !important;
}

#TabsToolbar {
  display: none;
}

这些CSS会同时隐藏Tab栏和标题栏，因此最小化、最大化、关闭按钮也没了，因为我发现我在日常使用中，这三个按钮并不是必要的：

• 关闭全部的按钮用的时候并不多，可以用Ctrl-Shift-W或者右键任务栏关闭来替代。
• 最小化几乎不会用到，一般会通过新增桌面来实现清理桌面的效果。
• 最大化可以通过拖动贴边（我配置了按住Alt可以直接拖动），或者双击空白处来实现（可以看到我在地址栏旁边加了一段空白）。

如果你需要对Firefox界面的元素进行自定义，你可能需要找到某个元素对应的CSS类或ID，那么可以使用Firefox Browser Toolbox这个工具，它可以让你像调试网页一样调试主界面。

定制UI算是意外之喜之二。

三、同步服务

另外一个意外之喜就是同步服务了。

即使是在路由器透明代理的情况下，Chrome同步服务的稳定性仍旧差得要命（可能是我的梯子不稳）。但Firefox完全不用担心，随时随地都可以多设备同步。

我在导航区域放置了一个同步菜单的入口，点击即可看到其他设备的标签页：

问题

当然，与Chrome相比，Firefox还是会有一些问题。

兼容性

首先就是兼容性。

在Chrome作为浏览器龙头的当下，很多网址只会在Chrome下进行完整的测试，尤其是公司内的平台，因此经常会看到这样的提示：

实际上，在我这段时间使用之后，发现大多数网站其实九成左右的功能都是可以正常工作的，因此我通常会将这个横幅用广告屏蔽器屏蔽掉。

当然，还是会有问题，比如飞书多维表格以及飞书文档中的表格的编辑体验就很差劲，会出现莫名返回顶部、不显示光标的问题。不过这些场景目前我使用的不是很多，暂时可以接受，但还是需要一个Chromium作为备用，以防不时之需。

稳定性与Bug

另外一个是问题是稳定性。

• Firefox偶尔会有标签页不加载的问题，不过几率很低，目前只遇到一两次。
• Firefox播放B站视频会在最后一两秒卡住，然后重播一次。
• Firefox有时会出现比较严重的内存泄漏，能吃掉10G+的内存，需要关掉全部标签页之后才能恢复。

  2023.7.16更新：
  目前使用的开发版 Firefox 116.0b2 版本似乎已经解决掉这个问题了，没再出现。

总之就是有一些小问题，目前影响不是很大，暂时可以接受，等后续更新修复。

简介

FFmpeg是目前使用最广泛的开源音视频处理库，大多数的多媒体应用都会或多或少、直接或间接使用到FFmpeg。

FFmpeg是一个C写的项目，通常是被按需编译成.so，然后在代码中引用。

除了编程使用，FFmpeg项目也提供了三个特别好用的命令行工具：ffmpeg、ffprobe和ffplay。这次主要是介绍其中的ffmpeg命令。

（下文小写的ffmpeg指的是命令行工具，开头大写的FFmpeg指的是FFmpeg项目）

基本概念

在介绍之前，先简单介绍下一些音视频/FFmpeg的基本概念。

• 像素、图像、视频、音频。

  这些都是大家所熟知的概念。

  广义上来讲，所有的光学信号都可以称为图像。计算机世界的图像是离散的，因而一张图像由许多像素组成，每个像素有自己的颜色。

  在时间维度上将一系列图像串联起来就形成了视频，所以原始的视频数据往往存储为连续的、一块一块的像素数据。

  音频则是在时间维度上将一系列震动串联起来，所以原始的音频数据往往存储为PCM数据，也就是每一时刻的震动幅度。

• 编码（encode）和解码（decode）。

  这些原始的视频和音频数据量是很大的，可以使用一些算法来利用其中的一些重复信息，从而减小数据量，这个压缩过程就是编码；反过来还原这些重复信息，得到原始的视频和音频，用于播放和处理，这个过程功能就是解码。

  一些编解码算法计算量很大，很是耗费CPU，因而SOC或者显卡会使用专用的硬件单元实现一些常见算法，使用这些硬件能极大加速编解码过程，适合音视频播放等场景。

  但硬件实现的可配置性较低，CPU编解码的好处在于可以对编解码的过程进行更为精细的控制。

• 封装（mux）和解封装（demux）。

  有了多个媒体资源，将他们组合起来的过程通常叫做“封装”（mux）；反过来的过程叫做“解封装”（demux）。我们平时接触到的各种音视频文件，往往都是多个资源“混合”之后的产物，比如一个电影文件可能包含：视频、多声道和多语言的音频、字幕，以及一些额外数据，如封面图、标题、年份等等。

  “封装”的方法往往和文件格式对应，常见的比如mov文件、mp4文件、mp3文件、ogg文件等，它们都可以理解为用来存储媒体数据的容器。

  注意和编解码区分开，编解码指的是对一段媒体数据的压缩、解压过程，“封装”指的是对多个媒体数据打包的过程，往往是不带压缩能力的。就比如一个mp4文件，它的视频数据有可能是h264编码的，也有可能是h265/hevc编码的；虽然编码和封装有一些常见的对应关系，但它们并非一回事。

• 过滤器（filter）。

  这是FFmpeg的一个概念。

  对音视频的处理往往是从文件中读取作为输入，处理之后然后输出。这个数据处理过程经常有一些惯用法，比如缩放、位移、拼接、剪切，或是调整音频音量等等，FFmpeg把这些惯用的操作做成一个个的filter，每个filter可以实现一个单一的功能，通过拼接这些filter就可以实现比较复杂的功能。

安装

FFmpeg提供了三个工具，分别是：

• ffmpeg 最主要的工具，用于音视频的处理；
• ffplay 用于播放音视频文件；
• ffprobe 用于探测音视频的格式和编码等信息。

在Mac上，可以通过brew安装：brew install ffmpeg。完成后即可使用上述三个命令。

其中ffplay和ffprobe比较简单，后面直接加文件名就行。例如命令行下输入ffplay 1.mp4就可以播放一个视频，ffprobe 1.mp4就可以查看文件的信息。

这里主要讲一下ffmpeg命令的使用方式。

参数结构

ffmpeg的工作方式大致上是将输入的媒体文件按照指定的方式处理，然后输出新的媒体文件（这里的文件也包含网络流等）。

相应地，它的参数也主要由三部分构成：输入参数、输出参数和全局参数。

全局参数

其中，全局参数控制ffmpeg的一些全局行为，比如日志级别、版本信息、内存限制等等。

输入参数

输入参数用来指定输入文件，以及告知ffmpeg输入文件的一些信息。FFmpeg支持几乎所有媒体格式，一般情况下，ffmpeg会通过文件的扩展名（.mp4、.mp3等）来确定文件的封装格式，进而读取内容以获取编码方式、分辨率、通道数、像素格式、采样率等信息，再基于这些信息进行解码。

比如上图的命令，指定-i input.mp4之后，ffmpeg会把input.mp4作为输入，同时根据它的后缀.mp4得知他是一个mp4封装的文件。

ffmpeg也支持多个输入，例如我们现在有一个视频input.mp4和一个音频input.mp3，要将它俩合到一起，就可以同时指定两个文件作为输入ffmpeg -i input.mp4 -i input.mp3，这样在后续的输出参数中，就可以操作和合成这两个输入。

对每一个输入文件，都有一些参数可以控制输入行为。

例如，ffmpeg -t 3s -i input.mp4 -t 2s -i input.mp3，其中-i input.mp4前面的参数用来控制input.mp4这个输入文件，即-t 3s的作用是让ffmpeg只读取该文件的前3秒；同理，-i input.mp3前面的-t 2s会使得ffmpeg只读取该音频文件的前两秒。

输入序列帧

如果输入并非普通文件，扩展名不正确或不能直接使用，或者是文件中不包含这些信息（如raw格式、序列帧等），就需要我们使用一些额外的输入参数，自行指定编码、宽高、像素格式、帧率等信息。

比如对于一串序列帧，名称分别为0001.png、0002.png、...0100.png，如果要将这个序列帧作为输入，可以使用通配的方法：ffmpeg -r 20 -i %04d.png，这样的话这个序列帧就会被当作一个视频输入；序列帧自身不包含帧率信息，这行命令中的-r 20参数就手动指定了该序列帧的帧率。

输出参数

输入参数告诉了ffmpeg如何读取和解码媒体文件，解码之后就得到了原始的音视频流；接下来需要我们告诉ffmpeg如何处理这些音视频流，以及如何输出结果，这些由输出参数指定。

输入文件需要指定-i开关，输出文件则不用，直接在命令最后加上需要输出的文件就行，例如：ffmpeg -i input.mp4 output.mov就可以将mp4文件转为mov文件。

ffmpeg解析输出参数的逻辑是：在所有-i xxx结束之后，每个不带开关的参数（通常被称做Positional参数）都是输出文件；每个输入文件之前的所有开关和参数都是属于这个输入文件的。

例如，ffmpeg -i input.mp4 -i input2.mp4 -r 20 output.mov -f mp4 output.mp4，其中-r 20就是output.mov的参数，用于指定该输出文件帧率为20；而-f mp4就属于output.mp4，用于指定该输出文件的封装格式为mp4。

一些常见的参数

了解了ffmpeg的参数结构，接下来介绍一些常用的参数；这些参数很大一部分既可以作为输入参数，也可以作为输出参数。

参数还有很多，可以通过man ffmpeg或者官方文档按需查看。

Filter

除了格式、帧率这些输出参数，最特殊的参数就是-filter和-filter_complex，这两个参数可以用来指定该输出文件要使用的filter。

刚才简单介绍过，filter可以对音视频原始数据做一些常见的处理。

ffmpeg自带了大量的filter，比如我电脑上的5.0版本，就有470+个filter（可以通过ffmpeg -filters来列出所有的filter）。这些filter提供了各种各样的功能，小到缩放、剪切，大到物体识别，甚至于可以在其中插入GPU代码，总之五花八门。

我们可以通过-filter参数指定一个filter，来实现需要的功能。

例如，ffmpeg -i i.mp4 -filter scale=100x100 o.mp4就可以将i.mp4缩放到100x100的大小。

filter的语法是这样的：filter名=参数，其中filter名是scale这些，每个filter可以接受不同的参数，参数之间由:分开；上面的scale=100x100也可以写成scale=w=100:h=100。

filter中也可以访问一些变量，例如scale=iw/2:ih/2就可以将原视频宽高都缩小为原来的1/2，其中的iw/ih是filter可以访问的变量，iw指的是输入文件的宽度，ih指的是高度。

可以通过ffmpeg -filters命令来查看所有的filter；ffmpeg -h filter=scale命令可以查看某个filter的详细说明，包括介绍、参数等。或者可以去官网上查看网页版本的filter文档。

-filter参数只能指定一条“链状”的filter，而-filter_complex参数则可以组合多个filter，形成树状，组合起来的filter一般称作filter graph。

例如：

ffmpeg -i i.mp4 -filter_complex \
  'split[v1][v2];[v1]scale=iw/2:ih/2[v1];[v2][v1]overlay' o.mp4

每个filter用;分开；每个filter都有输入和输出，在filter后加上[abc]可以将输出命名为abc；在filter的前面加上[abc]则可以将abc作为输入；通过这种命名的方法，可以实现很复杂的功能。

上面这个命令分开来看的话有三个filter：

• split``[v1][v2] 将输入文件复制成两份，分别命名为v1和v2（未指定输入的话默认选用上一个输入，在这里就是-i选项指定的文件）；
• [v1]``scale``=``iw/2``:``ih/2``[v1] 将v1缩放为原来的一半，同时将结果再次命名为v1；
• [v2][v1]``overlay overlay用于将v1和v2堆叠起来，v1位于v2上方。

经过这个命令之后，对于这样的输入：

会得到这样的输出：

示例

图片处理

除了音视频，ffmpeg处理图片当然也不在话下，例如ffmpeg -i input.png output.webp就可以将png转为webp。

Webp动图

处理webp的时候要注意，如果要从视频或者序列帧生成webp动图，需要指定编码为libwebp_anim，例如ffmpeg -i i.mp4 -c libwebp_anim o.webp，直接使用webp编码会出现播放花屏的情况。

PNG压缩

由于PNG是个无损压缩的格式，体积往往比较大，大家平时可能用到TinyPNG这个网站来压缩一些图片，它的原理是将通常每像素24位、64位的PNG图像修改为每像素8位的。

之所以能压缩成8位这么小，是因为它用了pal8这种像素格式，这是一种基于色板的像素格式，在用它对一张图片进行“编码”的时候，需要先指定一张“色板”：这张色板上只有256种颜色，每种颜色有个编号。通过这个色板对一张图片进行“编码”的时候，需要给这张图片上的每个像素在色板上找一个最相近的颜色，然后在该像素处只需要存储这个颜色对应的色板序号就行。最终在封装的时候，把色板也封装到里面，解码的时候就可以大致还原原图。这种方式适合一些色彩不是特别丰富的图像。

比如，一张图片的某一个像素是蓝色#0000FF，通常存储它需要3*8=24位，而如果色板上有这个颜色的话，存储它只需要一个字节，也就是该颜色对应的色板序号。

知道了原理，这个操作通过ffmpeg也很容易完成：

ffmpeg -i 0001.png \
  -filter_complex '[0]palettegen=transparency_color=#00000000[p];[0][p]paletteuse' \
  o.png

其中的关键部分在于中间这两个filter：palettegen和paletteuse，一个用来生成色板，一个用来使用色板。（色板其实也就是一张16x16的图片，也就是这里的[p]）

通过这行命令，就可以得到一张和TinyPNG“压缩”效果差不多的图片（有时候会差很多）。

FFmpeg的色板生成算法比较简单，这方面有些人做了更为深入的探索，有兴趣的同学可以看下PngQuant这个项目。

为音乐添加封面

通常，从音乐网站或音乐app上面下载的音乐文件都会带有封面，在本地播放器播放、或者文件管理器预览时，可以看到该封面，例如使用ffplay：

ffplay with_pic.mp3

这个封面的原理是在文件中保存一个图片通道，可以通过ffprobe看到：

ffprobe with_pic.mp3

假设现在有个不带有封面的mp3音乐文件no_pic.mp3，和一个封面图片pic.png，那么可以通过ffmpeg向其中添加一个视频静态的通道：

ffmpeg \
  -i pic.png `# 输入图片` \
  -i nopic.mp3 `# 输入mp3` \
  -codec copy `# 使用copy编码器，不对数据做处理` \
  -map 0:v:0 `# 将第0个输入文件的视频通道，输出到第0个输出文件中` \
  -map 1:a:0 `# 将第1个输入文件的音频通道，输出到第0个输出文件中` \
  output.mp3

这里的关键是-map选项，可以用它来操作文件或filter中的通道。

使用ffprobe检查output.mp3，或者使用ffplay播放该文件，就可以看到填充进去的封面了。

获取视频缩略图

通过以下命令，可以从视频中获取一帧并保存成图片：

ffmpeg -y -ss 00:10:00 -i Sherlock.S01E01.2010.mkv -frames 1 thumbnail.png

其中的关键是-ss 00:10:00和-frames 1两个参数：

• -ss参数用于指定输入文件的偏移时间，这里指定的是十分钟的位置。
• -frames 1参数用于指定输出文件的帧数，只需要一帧。

官方文档对此也有个简单的介绍，可以参考Seeking - FFmpeg。

基于此可以为视频生成一个简单的抽帧预览的小视频：

用到的python脚本如下：

#!/usr/bin/env python3
from os import system
from pathlib import Path

Path('thumbnails/').mkdir(exist_ok=True)

for i in range(10):
    min = str(i * 5).zfill(2) # 每五分钟一张图片
    name = str(i).zfill(2)
    system(f"ffmpeg -y -ss 00:{min}:40 -i 'Sherlock.S01E01.2010.mkv' -frames 1 'thumbnails/{name}.png'")

# 输入一秒一帧，输出时补充为25帧
system(f"ffmpeg -y -r 1 -i 'thumbnails/%02d.png' -r 25 thumbnails/preview.mp4")

Alpha视频

最后简单说一下一个比较复杂的例子，串联一下上述知识。

假设我们有一串序列帧，0001.png、0002.png、...0100.png，

现在想要把它转换成Alpha视频，也就是这样的：

RGB通道在右侧，Alpha通道按照灰度图的形式在左侧。

转换前后

首先来看下转换前后的异同。

转换前的序列帧是PNG格式的，拥有RGBA四个通道，上图魔方的其余部分都是空白的。

转换后的格式为mp4，mp4不支持Alpha通道。

转换后的视频右侧部分，其实就是原序列帧的RGB通道，同时原序列帧的Alpha通道值为0的像素要显示为黑色。

左侧部分其实是将Alpha通道单独提取出来，然后将其转成灰度图，也就是将Alpha通道的值分别赋给RGB三个通道（例如#FF123456就变成了#FFFFFFFF，完全透明的部分就变成了黑色，完全不透明的部分就变成了白色）。

实现

那我们可以使用这行命令：

ffmpeg -r 25 -i '%04d.png' \
  -filter_complex 'split[rgb][mask];[mask]colorchannelmixer=0:0:0:1:0:0:0:1:0:0:0:1:0:0:0:1[mask];[rgb]split[fg][bg];[bg]drawbox=t=fill:color=black[bg];[bg][fg]overlay[rgb];[mask]pad=iw*2:ih[mask];[mask][rgb]overlay=w:0' \
  o.mp4

将其中的filter拆开可以得到许多个步骤，分别介绍一下：

• split[mask][rgb];

  将输入复制成两份，名字为mask和rgb，最终分别会用作左边的遮罩部分和右边的彩色部分；

• [mask]colorchannelmixer=0:0:0:1:0:0:0:1:0:0:0:1:0:0:0:1[mask];

  colorchannelmixer这个filter用于重组rgba通道，这里通过将rgba通道的值都设置为alpha通道的值，来得到左边的遮罩，也就是将alpha通道转化为灰度图。

  

• [rgb]split[fg][bg];

  把另外一份再次复制为两份，bg和fg；

• [bg]drawbox=t=fill:color=black[bg];

  bg作为右侧的背景，所以使用drawbox在其上绘制一个黑色的区域将其盖住；

• [bg][fg]overlay[rgb];

  然后通过overlay将fg盖在bg上方；

• [mask]pad=iw*2:ih[mask];

  将遮罩宽度*2，也就是给它右侧增加一块空白；

• [mask][rgb]overlay=w:0

  最后将rgb放到mask的右侧。

  这里之所以先绘制一个黑色底色，是因为有的软件导出的PNG图片，在Alpha通道为0像素上，RGB三个通道的值可能是随机数；如果不做底色的话，ffmpeg会直接将这些随机数显示出来，就会导致类似于这样的图像：

  

经过上面几步，就可以完成这个转换。

另外，其中的-r 25选项用来控制序列帧的帧率为25fps。

通过filter反向还原序列帧也是可行的，思路差不多。

获取帮助

如果要对ffmpeg、ffplay、ffprobe这些命令有更详细的认识，有两种方式：

1. 在Mac或者Linux上使用包管理器安装FFmpeg之后，默认会带上FFmpeg的所有文档，可以通过命令行下执行man ffmpeg、man ffmpeg-all、man ffplay、man ffprobe来查看，里面有完整的参数信息。
2. 或者查看官网上面的在线文档，会更方便一些：ffmpeg Documentation。

如果在使用过程中，需要某个编解码器或者filter的文档，也随时可以通过命令行查看：

# 查看所有解码器
ffmpeg -decoders
# 查看所有编码器
ffmpeg -encoders
# 查看所有muxer
ffmpeg -muxers
# 查看所有demuxer
ffmpeg -demuxers
# 查看所有filter
ffmpeg -filters

# 获取某个解码器的文档
ffmpeg -h decoder=hevc
# 获取某个编码器的文档
ffmpeg -h encoder=hevc
# 查看某个muxer的文档
ffmpeg -h muxer=mp4
# 查看某个demuxer的文档
ffmpeg -h demuxer=mp4
# 获取某个filter的文档
ffmpeg -h filter=pad

这些帮助信息中，大多数时候包含了encoder/decoder/muxer/demuxer的可配置参数的解释，或是filter的功能、输入输出、参数类型和说明等。

同样的，也可以去官网上面查：Documentation。

例如，如果想要调节输出webp动图的质量，但是不知道怎么调节，可以使用ffmpeg -h encoder=libwebp_anim命令来查看这个编码器支持的参数，会发现其中有一个参数，

因此可以通过这个参数来指定webp质量，例如：

ffmpeg -i i.mp4 -c libwebp_anim -quality 30 o.webp

源码

FFmpeg是一个用C写的项目，它的代码结构很清晰，整体被分成了几个大的模块：

• libavcodec 编解码器
• libavformat 封装、解封装库
• libavfilter Filter库，用于对媒体数据做中间处理
• libavdevice 用于支持在各个平台上访问媒体硬件（如摄像头、麦克风、屏幕等）
• libswscale 高性能的图像缩放和色彩空间转换库
• libswresample 高性能的音频重采样库
• libavutil 一些通用的工具函数

这些模块都可以编译成.so，如果是要在代码中使用，可以直接引用这些.so。

问题和方案

半年前买了个网件4300路由器，挺好用的。后来因为PicoVR的PC串流需要Wifi6，换成了小米ax3000，ax3000到手后才发现不能刷openwrt，所以现在内网里面的DNS还是用的网件4300。

前段时间不知道干了啥，经过一次停电之后，4300就再也启动不起来了，一直无限重启，tftp刷机模式也进不去。在网上看到4300有个UART接口，这个接口可以通过USB转接头来串口连接到电脑上，连上之后可以进入到uboot来恢复系统。

物理连接

USB转接头在淘宝上买的，十几块钱一个，大概长这样（淘宝搜索“USB TTL”大概就能搜到）：

然后把路由器拆开，在一个角落会有四个露出来的引脚：

把这些引脚放到左下角，引脚朝上，那这四个引脚从上到下的顺序分别是：OPEN、TX、RX、GND（这里的OPEN脚这次用不到）。

然后可以用杜邦线把转接头和UART引脚连接起来，连接方式为GND-GND、RX-TX、TX-RX，OPEN脚不连。这里连的时候一定要注意，两边的RX和TX是反着的。

连好之后把USB插到电脑上就可以下一步了。

连接串口

这一步主要是在电脑上配置，网上目前Windows平台的教程居多，这次我摸索着在Linux弄好了。

（这种方法比较麻烦，如果想省事可以看下面的 连接串口 - picocom 一节）

首先是需要几个程序：

• screen：也就是GNU Screen，用来连接tty设备
• baud：这个是为了修改波特率的

连接tty

USB接口连到电脑上之后，会出现一个新的tty设备/dev/ttyUSB0，通过对这个设备进行读写，我们就可以和路由器进行交流。这需要借助一些终端软件，这次我使用的是screen。

用法也很简单，sudo screen /dev/ttyUSB0即可。

如果需要断开，可以使用ctrl-a K然后按y的组合键来关闭screen。

修改波特率

打开screen之后启动路由器，这时候会发现终端里面可能是乱码的，这是因为波特率没有设置好。

参考这篇文章，4300这个芯片在引导的时候（uboot阶段），波特率需要是116600~126300之间的值，这里我们用117200。

如果有乱码，确定杜邦线本身没坏，针脚没接错，那一般情况是波特率的问题，测波特率要用示波器。我操作到这一步时就是乱码，但是我没有示波器，某电商网站上的报价是一两千块钱一台，我这一台二手路由器才百元左右，为它买个示波器不值啊。于是乎，借助万能的搜索引擎和自己的尝试，我发现波特率设置为116600~126300之间的值时，是不会乱码的，取个117200，OK。

在Linux下设置波特率一般使用stty命令，但是117200不是一个标准波特率，没法用stty设置。我在github上面找到了一个小程序可以自定义波特率，看了下原理然后自己再写了一份，加了查看波特率以及错误检查之类的，也放到了github上面，如果有需要的话可以下载下来自行编译。

这里设置非标准波特率的具体方法也很简单，就是使用了struct termios2这个结构，这个结构可以自定义波特率；而stty用的是旧的struct termios，只支持一些预定义的波特率。Python的termios标准库也是一样，没办法自定义。

struct termios2的说明可以通过man ioctl_tty查看，搜索termios2即可。

解决问题

不出意外的话，调整波特率之后重启路由器就可以看到不乱码的输出了。

从这里的输出就可以看到无限重启的原因是一个mtd分区挂载失败，导致内核崩溃了。截图我忘记留了，但是和openwrt社区的这个帖子几乎一模一样：Kernel Panic - not syncing: VFS，可以作为参考。

解决方式就是帖子二、三楼的老哥说的，需要从openwrt的initramfs重新格式化一下分区。

进入uboot命令行

在系统启动过程中，会出现这样一串字符：

这里会倒计时三秒，在三秒期间按回车就可以而进入uboot的命令行，这里的ath> 就是提示符。

tftpboot

接下来我们需要通过uboot的tftp启动到openwrt的initramfs里头，首先需要从这里下载镜像，找netgear_wndr4300-v2-initramfs-kernel.bin这个文件即可。

然后在uboot中输入tftpboot，就可以看到它已经在等待tftp服务器了：

根据这里的提示，我们需要在ip为192.168.1.101的设备上通过tftp服务提供一个叫做0101A8C0.img的文件。

首先设置网络，通过网线将路由器的lan口（四个黑色中的一个）和电脑连上，然后在电脑上配置静态路由，ip为192.168.1.101，网关为192.168.1.1，设置好之后确保可以ping通192.168.1.1。

然后开启tftp服务，这里我用的是uftpd。uftpd -n -o ftp=0,tftp=69 .即可，需要注意最后一个参数指定的路径里面要有一个名字为0101A8C0.img的文件，这个文件就是之前下载的initramfs-kernel.bin重命名之后得来的。

一切顺利的话，这时候查看uboot那边，路由器应该已经在下载镜像了。下载完成之后，输入bootm就可以启动到openwrt里，这个环境可以理解为一个类似PE/LiveCD的维护环境。

（提示：除了tftpboot，应该也可以通过bootm命令来等待tftp客户端传递镜像，这样子电脑上只需要tftp客户端就可以了，会更好操作一些。）

这时候我发现现有的117200波特率会导致无法正确输入，所以又需要通过上面那个程序把波特率改成标准的115200。这里我推测是内核启动起来之后，波特率就需要变成115200，而uboot中都需要使用117200。这一点很坑，弄了很长时间。

sysupgrade

在这个维护环境中，我们可以通过sysupgrade命令安装真实的openwrt镜像。

首先在openwrt的网件4300v2的页面上下载最新版本的镜像包，得到squashfs-sysupgrade.bin文件。

然后可以在路由器的openwrt中通过scp把电脑上的文件复制过来，当然前提还是路由得先配置好，检查下电脑和路由器是否能ping通。

文件复制到之后，sysupgrade xxx-squashfs-sysupgrade.bin就可以开始写入镜像了，这个过程会把所有分区都重新格式化，因此可以解决上面mtd挂载失败的问题。等待完成后自动重启，一切就大功告成了，就算路由器重启也不会再出现崩溃了。

连接串口 - picocom

（这一节作为上面连接串口的补充。）

上面提供的screen+baud的方式总的来说比价麻烦，后来我发现了picocom这个工具，支持自定义波特率。安装之后只需要picocom -b 117200 /dev/ttyUSB0一行命令即可，其中的-b参数就是指定波特率的，之后任意波特率。

参考

• https://forum.openwrt.org/t/wndr4500v3-kernel-panic-not-syncing-vfs/68815
• https://zhuanlan.zhihu.com/p/76589656
• https://blog.csdn.net/x272202307/article/details/120244050
• https://openwrt.org/toh/netgear/wndr4300_v2
• https://wiki.archlinux.org/title/TFTP#uftpd
• https://github.com/jbkim/Linux-custom-baud-rate

UPDATING...

异步与协程

异步计算的两个基本原语可以归结为暂停和继续，所以所有的异步计算模式都是围绕着如何暂停一个任务和如何继续已暂停的任务两个问题来的。

过程和挂起点

异步计算的两个基本元素是过程和挂起点。过程指的是一个任务的执行流程，体现在编程中就是完成某个任务的代码的集合。过程中可以有挂起点，指的是过程在执行时可以使其自身暂停运行的点。不可中断过程是指不包含挂起点的过程。一个过程往往是由一系列的挂起点和不可中断过程按顺序组合起来的，不可中断过程的前后一定是挂起点。

过程并不与函数对应，它所表达的是一个任务，理解这一点是至关重要的。当我们在描述一个任务是异步的时，只是强调这个任务是可以被分为多个步骤来执行的，并未规定这个任务看起来的表象是如何的，所以上述我对“过程”的定义只是“一些代码的集合”，至于这些代码如何组织，放到多个函数还是一个函数中之类的问题，就是各种异步模式所考虑的事情了。

挂起点拥有挂起过程的能力，但并不是说过程运行到挂起点就一定会被挂起，只有该挂起点被接受了，过程才会挂起。不同的异步模式会有不同的挂起方法，也就是创建挂起点的手段：

其中，前两者是基于等待的挂起，后两者是基于回调的挂起，这是两种截然不同的过程组织方式。

挂起的时机

在语言级别的异步计算的中，一个过程的挂起点往往是有限的，一般只在与IO等待、定时器等待、用户输入等待等相关的地方可挂起。而在操作系统的线程调度中，线程的每条汇编都是一个不可中断过程，每条汇编之间都是挂起点，但是线程的挂起点只有少数会被接受。

过程之间的等待

另外，要实现一个可用的异步计算框架，异步过程之间的嵌套调用机制必不可少。过程的嵌套调用本质上是对多个挂起点的归一化。

之所以状态机经常会成为实现协程的方案，一是因为状态机能够很好地表达挂起和继续，二是状态机拥有表达协程所需要的多次平级挂起的能力。

状态机的互相等待。

过程序列的线性表达

协程是对可分过程序列的线性表达，因而只要可以实现过程、线性序列两个功能的都可以实现协程。函数模型本就是一种可分过程的线性模型，其底层的指令集也是一样，又比如Promise[]、Asyncify。

异步的优势

单独一个任务没必要讲异步不异步，只有当多个任务并发执行时，异步任务才能体现出优势：计算资源不必阻塞于等待某个任务的某个资源的就绪，而是可以转而执行另外的任务，减少了计算资源的阻塞。
这个优势可以从不同角度来理解：

• 从任务的角度：任务不需要一直占据计算资源，只是在必要的时候被执行，因而可以同时执行多个任务；
• 从资源的角度：因为可能有多个任务被同时挂起，计算资源得以同时等待多个耗时资源。

今天看到github发布了github-cli，想去试一下，结果在用cli登录的时候被GFW挡住了。尝试使用proxychains发现这个cli是用go写的，用不了。所以决定去网上找找其他能做透明代理的工具，于是就找到了一个国人写的graftcp。因为平时用类似的工具较多，所以简单再次对比一下。

原理及差异

二者的基本思路大同小异，都是通过截获子进程的socket相关的系统调用，偷偷地与代理建立连接，最后在connect调用中返回代理的socket。

但是在具体实现上，二者用了不同的方案。

proxychains

proxychains使用了LD_PRELOAD环境变量。系统调用都会经过glibc的包装，所以在c中写个connect实际上调用的是glibc的库函数。而LD_PRELOAD环境变量向用户提供了覆盖库函数的能力，proxychains正是利用了这一点。

在其源码中可以看到，它一共截获了6个函数：

connect_t true_connect;
gethostbyname_t true_gethostbyname;
getaddrinfo_t true_getaddrinfo;
freeaddrinfo_t true_freeaddrinfo;
getnameinfo_t true_getnameinfo;
gethostbyaddr_t true_gethostbyaddr;

其中，截获connect函数是为了与代理服务器进行连接，也就是执行主要的功能；而其他的几个函数是为了使用socks5的远程DNS功能，能够解决DNS污染的问题（这个思路启发了我，解决了我的一个业余项目里面关于DNS污染的问题，之后有时间了我会写一下。感谢）。

简单说下之后的过程（不考虑远程DNS）。在截获connect之后，proxychains会拿到其参数中的目标ip；然后与代理服务器建立连接，并请求其代理该ip地址；成功之后，便将受到代理的socket描述符返回给应用。至此，透明代理建立完成。

graftcp

graftcp的思路则是通过ptrace调用来截获子进程的connect连接，这是二者最大的不同，也直接影响到二者的适用情况。另外有一点不同的是，graftcp并非自己处理与代理服务器的连接，而是将此任务交给了一个叫做graftcp-local的进程去做，目前我尚不清楚为何要分开。

graftcp的README里面有个简单的架构图：

+---------------+             +---------+         +--------+         +------+
|   graftcp     |  dest host  |         |         |        |         |      |
|   (tracer)    +---PIPE----->|         |         |        |         |      |
|      ^        |  info       |         |         |        |         |      |
|      | ptrace |             |         |         |        |         |      |
|      v        |             |         |         |        |         |      |
|  +---------+  |             |         |         |        |         |      |
|  |         |  |  connect    |         | connect |        | connect |      |
|  |         +--------------->| graftcp +-------->| SOCKS5 +-------->| dest |
|  |         |  |             | -local  |         |  or    |         | host |
|  |  app    |  |  req        |         |  req    | HTTP   |  req    |      |
|  |(tracee) +--------------->|         +-------->| proxy  +-------->|      |
|  |         |  |             |         |         |        |         |      |
|  |         |  |  resp       |         |  resp   |        |  resp   |      |
|  |         |<---------------+         |<--------+        |<--------+      |
|  +---------+  |             |         |         |        |         |      |
+---------------+             +---------+         +--------+         +------+

优缺点

相比之下，proxychains最大的优点就是支持远程DNS了，但由于LD_PRELOAD的一些限制，导致了它：

• 不能以root权限用户使用
• 不能给静态编译的程序使用（比如所有的go程序）
• 不能在不使用库函数进行DNS查询的程序中使用远程DNS（比如java）

相反的，graft并不限制用户和程序，适用性更广泛一点，虽然无法解决DNS污染的问题，但是这个问题可以通过更换DNS解决。

2021.3.30 更新

最近搞明白了graftcp为什么要多出来一个graftcp-local进程了。

与proxychains很大的一点不同在于，graftcp与被代理的程序并非在同一个进程中运行，而是父子进程的关系，父子进程并不共享文件描述符表，这就导致graft不能向proxychains一样“自己”去连接代理服务器并将文件描述符直接由connect返回了，因为graft创建的只能是自己进程内的描述符，不能直接交给子进程使用。（这可以理解为：ptrace原语相比于LD_LIBRARY原语失去了“有效修改connect返回的文件描述符”的能力，因此无法直接使用之前的方法。）

针对这个问题，graft的做法是建立一个单独的服务器graftcp-local，相当于“代理服务器的代理”，并将子进程发起的connect的目的地址改为该服务器的地址，让子进程发起向graftcp-local的连接。

但是这又引出了另一个问题：从graftcp-local的角度来看，它接到一个新的连接之后，并不知道这个连接实际上是要连接哪里的，因为connect请求并没有携带原目的地址信息。

这时候又需要graftcp进程了，在graftcp使用ptrace追踪到原connect请求之后，他会将原目的地址以及子进程pid发送给graftcp-local，这样graftcp-local就有了一个从pid到目的地址的映射表，在它得到新连接之后，可以通过查询/proc/net/tcp文件取得新连接所在的进程pid，从而得知它的真实目的地址。至此，graftcp-local就可以建立完整的代理连接了。

另外，我也想到了一种使用ptrace、但不需要graftcp-local这样的双重代理的方法。其原理在于socket的控制消息接口：sendmsg和recvmsg，这个接口可以将进程的文件描述符通过socket发送给另一个进程。ptrace配合上这个接口，就拥有了“有效修改connect返回的文件描述符”的能力，因此应该可以像proxychains那样实现透明代理了。

基本的思路大概为：ptrace截获socket()调用，在enter-stop的时候，由父进程调用socket()创建套接字描述符，然后通过sendmsg()发送给子进程，再将当前的socket()调用修改为recvmsg()调用（这一步是因为消息队列长度有限，避免子进程不进行recvmsg()造成消息阻塞），继续子程序；等到exit-stop的时候，新的文件描述符已经在子进程中可用了，通过查看子进程recvmsg()收到的内容，得到描述符的值，并将其设置为该系统调用的返回值。至此，就创建了一个父子进程共用的套接字描述符，等到子进程调用了connect时，父进程就可以通过这个套接字来初始化代理连接。（理论上，所有的创建文件描述符的系统调用都可以通过这种方法来实现父子进程共享，而不需要在exec()之前用dup()准备好。）

思路有了，具体的实现正在写。最近好多事情，毕设、驾照、重修、考试，五月份还要去实习，可是一件都不想做。

面向对象是对面向过程的总结与约束。

面向对象的出现是必然的，这一点从人类理性的工作方式就可以得到解释。
在面向过程的范式中，函数是最基本的“动态”抽象元素，这是通过对汇编的总结和约束得来的。
实际上，面向对象也一样，函数，或者说方法也同样是最基本的元素，因为我们完全可以将字段当作隐式调用的方法。
所以说，面向过程与面向对象都是以方法为核心的范式，它们之间的不同之处在于方法的组合方式上，面向过程的所有方法平铺在一层上面，而面向对象通过各种手段（类的区分、重载、重写等）使得方法的组合有了层次，这种组合方式的不同也正体现了面向对象的抽象层次更高。更直观的看，它们二者的不同之处在于方法的查找方式上，正是通过查找方式的不同才实现了组合方式的不同。
在面向过程中，函数被“函数名”唯一确定，或者说，只需要函数名这一个宗量就可以确定一个函数。而面向对象则使用更多的宗量才能确定一个函数（方法）。但只从这一点来看，它仍未获得面向过程所不拥有的特征，它们本质上是一样的。经历了以下过程，面向对象的世界才算建立起来。这种通过宗量查找函数的过程称为函数分派。

只有当为宗量赋予更多特殊意义时，面向对象中的各种概念才真正出现。这个赋予意义的过程也正是我们将自己对世界的理解融入其中的过程。
我们为第一个宗量赋予“对象名”的意义，对象的概念便出现了，因为我们通过第一个宗量将方法“捏成”一簇一簇。
我们从面向过程那里保留了“函数名”这个宗量，也就出现了对象中的方法。
我们将函数参数也作为宗量，这才出现了对象内的函数重载。
继承的出现使得方法的组合更为灵活，对象之间有了垂直方向上的联系。继承本质上是特征的沿用、拓展与修改，特征则体现为方法。
多态的出现则引出了“实际类型”和“外观类型”两个概念。这是因为在多态中，有些地方需要子类实例以父类实例的身份出现，那么这个对象就同时拥有了两重身份，我们需要表达这两者，这两个概念也就应运而生。“实际类型”是对象生来就有的，它表达了一个对象所拥有的所有特性，而“外观类型”是多变的，它表达了对一个对象所拥有特性的截取。
虽然“外观类型”使得对象看起来像是个父类的实例，但实际上它仍表现出子类的特性，也就是说，分派过程中不能看到一个A的实例就去查询A类的函数，这相当于增加了一个不确定的宗量。也正是这一点，导致了面向对象中函数分派方式分为两种：以“外观类型”分派和以“实际类型”分派。以实际类型进行分派的函数我们称为“虚函数”，以外观类型分派的则是“非虚函数”。

面向对象的三大特征：抽象、继承、多态。其中，抽象使得方法组合成为一个个概念，继承使得它们得以复用，这两者实际上是创建概念的过程，而真正使得拥有继承关系的概念有所联系、共同工作的，实际上只有多态。

寒假都过了好久了。上学期有操作系统课程，我参加了试点班，试点班有好多实验要做，最后一个实验我分到的实验是MiniOS的缺页中断处理程序。
MiniOS是这个试点班历代同学共同写的一个简单的操作系统，基于x86架构。每一届同学会在之前的基础上进行开发，增加或者增强功能。
今年我和另一个同学一起，负责设计和编写MiniOS的缺页中断处理函数。下面是我的实验报告，也是我整体的思路和一些想法。
设计不算巧妙，也缺少深思熟虑，仅供学习参考。

什么是内存管理？对计算机的一般用户来说，内存的是一条条价值不菲的内存条，他们的内存管理是对内存条的管理，这关系到他们的钱包；对于应用程序开发者来说，得益于进程概念的广泛普及，内存管理是对自己所写程序的进程空间的管理，他们不必关心其他进程的存在；而这种抽象一定离不开的则是操作系统，对于一个现代操作系统来说，内存管理四个字则意味着，充分利用有限的内存资源，统筹规划，做好精准的管理与合理的抽象，为进程提供一个良好的“生存环境”。

操作系统的任何操作都离不开硬件的支持，i386为我们提供了很多硬件层面的内存管理的机制，得益于这些机制，进行某些抽象才成为可能。这些机制比如：分段、分页、中断，这三者、尤其是后面两个，让操作系统拥有进程的概念成为可能。

分页机制将内存分为一个一个4K大小的页，同时在物理地址的基础上建立了线性地址的概念。线性地址是一种虚拟的地址，它和物理地址不同，不会直接从CPU通过地址总线送至内存，但它与物理地址一样都是32位的，分页机制就是用来完成这种虚拟的线性地址到实际物理地址的映射。虽说线性地址是虚拟的，但关键在于CPU可以识别线性地址，这个地址会在硬件中自动转化为物理地址这个过程对进程完全是透明的，正是有了这种映射，操作系统可以为进程提供统一的内存模型。

分页机制还拥有很多其他功能，比如权限控制、读写控制等，其中就包括了我们最近在做的缺页中断。

分页机制其实就是建立一张张表，操作系统只需要向表中填写合适的值，就可以完成想要的32位地址到32位地址的转换。这套机制最大的一个好处是，我们不需要将所有的页表和页面在一开始就分配好，可以将页表或者页目录的某一项暂时置为空，也就不用分配实际的物理地址，等到了真正需要访问某个地址时，分页机制通过中断来告知操作系统，这个中断就是我们所说的缺页中断。页表项和页目录项的最后一位就表示了这一页是否存在，如果这一位为0，而CPU试图访问这一页的某个地址，那么硬件就会触发缺页中断。

在现代操作系统的内存管理中，有一个贯彻始终的理念，就是所有的分配都是拖到不能再拖才进行，也就是所谓的“懒加载”、“延迟分配”。因为操作系统不是为一个两个进程服务的，它要尽可能保证自己能应付更多的任务，这时候“懒惰”就换来了整个系统的“勤快”。在i386机器上，内存管理实现“懒加载”所利用的基本硬件机制就是分页提供的缺页中断。

基于“延迟分配”的基本理念，我们为MiniOS提出了一套内存管理的抽象，整体思路是站在进程的角度上，围绕着缺页中断，完善其周围各组件的管理与协调。

这是我们的架构图。

我们首先确定的一个概念是“页”。这里借鉴了Linux的设计。对一个进程来说，它所拥有的页是与物理内存无关的，页指的是数据，是进程线性结构中的一部分。进程的线性区指的就是我们为进程提供的一种抽象，让进程看起来自己拥有全部的4G内存。

与此同时，我们将实际内存中的物理空间称为“页框”。将页与页框分开来看是很重要的，页框指的是一个地方，它能容纳一个页。

在这套架构中，页框属于“页容器”的一种。页容器指的是能够存放页数据的容器，比如上述的页框，又比如这里的swap文件、映射文件。Swap文件是硬盘上的一块保留的区域，可以在系统内存不足的时候，将页框中的页面放入其中以节省内存。而映射文件指文件系统中的普通文件，只不过这些文件的一部分与进程线性地址中的一部分关联起来了。

页容器中的单位空间我们称为“页空间”。每种页容器都有能够标识其中一块页空间的id。对于物理内存来说，这个id是4K对齐的物理地址；对于swap文件来说，id是按4K划分的块的序号；映射文件的id则是一个三元组：文件描述符、文件偏移以及大小。

页容器的概念可以将这三者统一起来。根据每种页容器特性与用途，它们又有一些不同的属性，比如能否写回、页与页空间的大小关系等等。

页框其实是一种特殊的页容器。因为CPU架构的原因，所有需要访问的数据最终都必须放到内存中，也就是页框中，页框也就成为了整个架构的一个重心。

有了这个架构，我们来试着用这个架构完成一下我们的懒加载机制。

懒加载实际上可以根据进程线性区域不同性质以及其他因素被分成几个相对独立的功能：代码段（文本段）和数据段的懒加载、栈段的懒加载以及页面的交换。

第一个功能，代码段和数据段的懒加载。我们要运行一个程序，首先需要把代码段和数据段加载进内存中，而这两个段的内容是位于文件系统当中的，这刚刚好与上图的映射文件页容器对应。

第二个功能，栈段的懒加载。栈段是不存在程序相关的初始化数据的，因此我们只需要为页面在物理内存中寻找一块空间即可，这与上图页框页容器对应。

第三个功能，页面的交换。当系统物理内存不足时，将页面从页框中拿出来放到swap页容器中，等到需要的时候，再取回来即可。

到这里，我们的懒加载机制就完成了，还顺便引入了页面的换入换出。

这一整套架构的实现依靠的就是缺页中断，所以我之前说我们是围绕着缺页中断做的内存管理，所有的分配与加载都是在缺页中断中真正完成的。

缺页中断具体流程是这样的。

我们先来看看数据结构的部分。

这里主要的思路是在进程的PCB中维护当前进程的所有存在于线性区中的页的信息，比如页的线性地址、页的类型、在交换分区中的索引、在文件中的位置。这是我们的页描述符结构体，这里的flag字段表明了这个页当前的类型，每种类型表明下面某个字段有效。在发生缺页中断的时候，就可以查询这张表。同时，为了权限控制以及快速定位某一页，我们把这个链表根据线性区拆成多个链表，串联起每个线性区中的页描述符。

另外，swap的管理使用了struct swapfile 这个结构体，其中维护了一个位图，表明swap分区或文件中的某一个页空间是可用的。

有了这些数据结构，就可以完成这个缺页中断处理函数了。

可以看出，每个页容器都有着自己的操作函数，使用者只需要使用它们的id与他们进行交流即可。

为了配合缺页中断处理函数，我们对系统的exec进行了改造，思路也很简单，就是在读取elf头之后，把各段的页面设置为不存在，并在页描述符表中添加相应的项，等到这个进程被调度到，就会触发缺页中断，上面的处理函数能够获取到足够的信息以解决这个缺页问题。

Swap的实现也很相似。因为我们没有时间去做一个换入换出算法，所以我们只保留了接口函数swapout和swapin，通过这两个函数就可以对进程的页面进行换入换出，至于其中的实现是对上层隐藏的，之后如果要写换入换出算法的话，就可以利用这两个函数。

最近想在服务器上搭建一个git服务，原因是平时写的一些小项目往github上推送不太合适，但是又想在各设备之间同步，网盘什么的还是太麻烦了，搭个git就很方便了。

其实很早之前都有这个想法了，但是一直没有动手，因为当时知道的开源的git服务项目只有gitlab，而gitlab对我来说太大了，服务器现在也接近饱和了，跑个gitlab我的杂七杂八的服务就得关掉了。直到前几天，有个学弟问我关于把gitea往外网转发的问题，我才发现gitea这个东西。试了一下还挺好用，今天晚上就搞了一下。

问题

搭建没啥好说的，docker-compose就行了，这也是官方推荐的搭建方法。（说实话，容器技术能让人感到运维也不是那么枯燥的事情，用起来有一种说不出的舒服）。
docker跑起来之后，有个令我很难受的地方：git自身有利用ssh克隆的方法，所以像gitea、gitlab、github之类的解决方案也都提供了ssh克隆的功能，gitea容器里也自己跑了一个sshd，问题在于，宿主机有自己的sshd，所以这个sshd不能监听在宿主机的22端口上，在外面克隆的时候就得用类似ssh://git@git.ykai.top:5001/xxx/yyy.git这样的url，虽然无伤大雅，而且gitea也会帮你自动生成，但还是感到不舒服。

所以我就想着，能不能有个办法，让容器内外的sshd共享22端口。想了想，感觉最容易实现的方式就是把让宿主机的sshd将一些特定的ssh登录请求转发给容器里面，这样宿主机就透明了。

首先我注意到，在gitea的文档中，有一部分就是介绍转发ssh请求的，SSH Container Passthrough，但是我一时搞不懂他是什么原理，也就没有动手。

然后我就去网上搜索ssh forwarding、ssh forwarding to another host之类的，不幸的是，搜出来都是用ssh做端口转发的。就在我快要不知道怎么继续的时候，我搜了个docker share port 22 with host，出来了一篇国外老兄写的文章。这篇文章介绍地稍微详细一些，我理解大概意思之后，一阵捣鼓，也算是弄出来了。

前置知识

ssh的authorized_keys文件

ssh验证过程中，有个~/.ssh/authorized_keys文件是用来保存已信任主机的公钥的，要连接的主机通过了验证就能登录上。这个文件的一般格式是这样的：

ssh-rsa 客户机的公钥 xxx@xxx

实际上，这个文件还可以在前面加上选项，以使得在登录过程中执行某个命令，比如：

command="ls" ssh-rsa 客户机的公钥 xxx@xxx

这样子的话，在这个客户机登录的时候就会执行ls命令了。同时，ssh会把客户端原本想要执行的命令放在SSH_ORIGINAL_COMMAND环境变量里面，将上面的ls改为env命令就能看到了。

想想这意味这什么。这个功能给我们提供了一种能力，让我们可以在sshd执行客户端命令之前截获这条命令，相当于一个beforeExecute的钩子。

我们可以用这个功能来实现一个简单的ssh登录转发功能。

先在服务器上用docker跑一个sshd，监听在5000端口上，可以先不设置密钥登录，简单的密码登录就可以了，用户名为inner。然后在宿主机上面新建一个用户，比如叫outer，在outer的家目录下建立.ssh/authorized_keys文件，向文件中写上你自己电脑的公钥，然后在公钥前面加上登陆到docker内的命令。最终的文件内容大概是这样：

command="ssh -p 5000 inner@localhost" ssh-rsa 你的公钥 你的主机名

这时候可以尝试在你的电脑上面执行ssh outer@服务器ip，会发现提示输入密码，这个密码就是登录进容器内sshd的密码。输入正确的密码，就可以登录到容器内部的sshd了。

至此，已经实现了一个简易的ssh登录转发的功能了。看上去，宿主机和容器内共享了同一个22端口。

但还没完，想一想，我们现在的思路是，本地机器连接宿主机，然后宿主机连接向docker内，这个过程中是有两个验证过程的，但我们最终想要达到的是宿主机透明。怎么做呢。其实也很简单，所谓的透明就是只需要进行一次验证，相当于我们要把两扇门改为一扇门，思路是这样的：让宿主机的outer用户使用容器内inner的authorized_keys文件（使得可以通过第二扇门的也可以通过第一扇门），然后让outer可以密钥登录进inner（让第二扇门敞开）。

所以我们首先使用mount --bind /path/to/inner/.ssh /home/outer/.ssh达成第一点，然后为outer使用ssh-keygen，并将公钥加入到authorized_keys中，达成第二点。

现在，如果容器内有个进程向inner的authorized_keys文件中加入了一项（需要带有command），从容器外访问outer就可以直接登录进inner了。

需要注意的几点：

1. docker容器内外共享uid和gid，sshd会检查文件的uid，所以需要保证outer和inner的uid是一样的，我使用的镜像是有uid设置的功能的；
2. .ssh目录和.ssh/authorized_keys的权限要注意，都不允许其他用户（包括组内用户）有可写权限，所以一般权限给744和644就行（我给的700和600）；
3. 那位老兄的文章中使用的软链接实现共享.ssh目录，但我试了下，没成功，主要还是权限问题，sshd检测权限的机制还不是很清楚，所以我就使用了简单易行的mount --bind。

git通过ssh来拉取仓库的原理

git有个git-upload-pack命令，这个命令可以将一个仓库的数据发送到stdout中。在使用git clone git@git.ykai.top:xxx/yyy.git的时候，git就会通过ssh到git@git.ykai.top来执行git-upload-pack xxx/yyy.git，这样仓库的数据就会通过ssh发送到客户端了。在这个过程中，ssh充当了一个建立连接的角色。git push差不多也是同样的原理。（思路是这样，至于具体的通讯协议暂时不用了解。）

其实，有了这个功能，我们已经可以实现一个简易的git服务了。

假设我的服务器是ykai.top，用户名是kkk，同时用户kkk的家目录下有个目录为xxx/yyy.git的git仓库，那么我就可以直接使用git clone kkk@ykai.top:xxx/yyy.git来克隆这个仓库了。

但这么原始的一个服务肯定不满足我们的要求，我们还需要一整套的解决方案，好在gitlab、gitea之类的项目已经做好了，还提供给了我们一个易用的web端和丰富的功能。

gitea的工作方式

其实git从gitea、gitlab上通过ssh克隆一个项目时候，大概就是将上面两个功能结合起来。

我们先来看看gitea容器内/data/gitea/git/.ssh/authorized_keys里面的内容（这个文件是容器内的ssh验证文件）：

# gitea public key
command="/app/gitea/gitea --config='/data/gitea/conf/app.ini' serv key-1",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-rsa 用户的公钥 tag

用户每在gitea的web端增加一个公钥，这个文件就会增加类似这样的一项。这样，某个用户使用ssh登陆的时候，就会执行/app/gitea/gitea --config='/data/gitea/conf/app.ini' serv key-1，这个是gitea的一个命令，这个命令可以通过key-n来得知是哪个用户发起的请求，同时，还可以通过SSH_ORIGINAL_COMMAND环境变量来得知用户需要进行哪些操作，比如git-upload-pack，然后gitea就可以进行自己的逻辑了，比如判断用户是否有权限对该仓库进行操作、记录用户拉取记录等等。

让gitea和宿主机共享22端口

听起来跟上面说的ssh登陆转发差不多。启动gitea的容器，ssh开在宿主机的5001端口，然后在宿主机上建立一个git用户，如发炮制，把请求转发进容器。

操作过程中就会发现有问题了，现在authorized_keys中的command不是我们能控制的，是gitea写死到里面的。

这个情况的处理办法也算是个奇技淫巧。因为现在容器内外共享验证文件，所以从外面登录进宿主机的时候执行的也是/app/gitea/gitea --config='/data/gitea/conf/app.ini' serv key-1，那我们可以在宿主机上也建立一个/app/gitea/gitea的脚本，在这个脚本里面完成我们需要的操作就好了。

在宿主机上新建脚本/app/gitea/gitea，内容为：

#! /bin/sh

ssh -p 5001 git@127.0.0.1 \
    "SSH_ORIGINAL_COMMAND=$(printf "%q" "$SSH_ORIGINAL_COMMAND")" "$0" "$@"

加上执行权限，这样就又能够把登录转发到容器内部了。

这个脚本也很简单，没啥说的，要注意的是中间的那个printf，其中的%q是为了转义变量中的特殊字符，这个东西搞了我好长时间。还有后面的$0和$@，是为了把命令重新传递给容器内的gitea。

好了，大功告成，再也不用忍受奇怪的url了。

参考

• Share port 22 between Gogs inside Docker & the local system
• SSH Container Passthrough

简而言之，Python全局解释器锁，或者说GIL，其实是互斥锁，它保证只有一个线程拥有Python解释器的控制权。

这意味着，在任何时间点上，只有一个线程可以处于执行状态。GIL的影响对于单线程程序的开发者来说是不可见的，但是它可能成为CPU密集型和多线程代码的性能瓶颈。

由于即使是在拥有超过多个CPU的多线程架构下，GIL还是只允许一个线程同时运行，因此GIL也作为Python中的一个“臭名昭著”的特性而闻名。

在这篇文章中，你将了解到GIL是如何影响到你的Python程序的性能的，以及如何减小它对你的代码造成的影响。

GIL为Python解决了什么问题？

Python在内存管理中使用了引用计数，这就意味着在Python中创建的对象拥有一个引用计数变量，这个变量追踪着指向这个对象得到引用数量。当这个引用计数下降到0时，这个对象所占有的内存就会被释放。

下面这段简单的代码演示了引用计数是如何工作的：

>>> import sys
>>> a = []
>>> b = a
>>> sys.getrefcount(a)
3

在上面这个例子中，空列表对象的引用计数是3，它分别被a、b和传递给sys.getrefcount()的参数所引用。

回到GIL。现在的问题在于，这个引用计数变量需要保护，以防止两个线程同时增加或减小其值的竞态条件。如果这个问题出现了，那就可能导致内存泄漏而永不释放（内存），更糟糕的情况下，它会导致在仍然存在对对象的引用的时候，进行错误的内存释放，这可能导致你的Python程序崩溃或者其他“奇怪的”bug。

可以通过为线程间共享的数据结构加锁，以使得他们不会被同时更改，以此保证这个引用计数变量的安全。

但是为每个对象或是一组对象加锁就意味着会同时存在多个锁，这就可能导致另一个问题：死锁（死锁只可能在存在多个锁的情况下出现）。另一个副作用是重复的请求和释放锁会导致性能的降低。

GIL是解释器自身的单一锁，它添加了一个规则，即任何Python字节码的执行都需要获取这个解释器锁。这样子就避免了死锁（因为只有一个锁），并且不会导致太多的性能开销，但是实际上也造成了任何CPU密集型的Python程序都变成了单线程的。

虽然其他语言的解释器也用到了GIL（比如Ruby），但这并非这个问题的唯一解决方案。一些语言使用不同与引用计数的方法（比如垃圾回收），避免了在线程安全的内存管理上使用GIL。

另一方面，这就意味着这些语言往往需要添加其他的性能提升功能（比如JIT编译器）来弥补GIL的单线程性能优势的损失。

为什么选择GIL作为解决方案？

那为什么Python使用了这种看起来如此困难的方法？这是Python开发人员的错误决定吗？

用Larry Hastings的话来说，GIL的设计决定是使得Python今天如此流行的原因之一。

在操作系统还没有线程的概念的时候，Python就已经存在了。Python被设计成易于使用的，以加快开发速度，因此越来越多的开发人员开始使用它。

Python需要很多现有的C库提供的功能，（所以开发人员）为这些C库写了很多的扩展。为了避免不一致的更改，这些C扩展需要GIL提供的线程安全的内存管理。

GIL实现起来很简单，也很容易被加入到Python之中。因为只需要管理一个锁，所以它会使得单线程程序的性能有所提升。

线程不安全的C库变得很容易迁移，也正是因为这些C扩展，Python才会被不同的社区欣然接受。

如你所见，GIL是CPython开发人员在早期Python中面临的一个难题的务实的解决方案。

对多线程Python程序影响

当你查看一个典型的Python程序或是与此相关任何其他程序时，就会发现CPU密集型程序与IO密集型的性能差异。

所谓CPU密集型的程序是指最大化利用CPU的程序，包括做数学运算（比如矩阵乘法）、搜索、图片处理等等。

而IO密集型的程序是指那些花费时间去等待来自用户、文件、数据库或者网络等的输入或输出的程序。由于在输入输出准备好之前，资源可能需要做一些处理，所以IO密集型程序有时候必须等待很长的时间，直到它们获取到了他们想要的资源。例如，用户思考向输入提示符中输入什么，或者数据库在自己的进程中运行的查询过程。

我们来看看一个执行递减的简单的CPU密集型程序：

# single_threaded.py
import time
from threading import Thread

COUNT = 50000000

def countdown(n):
    while n>0:
        n -= 1

start = time.time()
countdown(COUNT)
end = time.time()

print('Time taken in seconds -', end - start)

在我的四核机器上运行得到输出：

$ python single_threaded.py
Time taken in seconds - 6.20024037361145

现在我改动一点代码，让两个线程并行地做相同的递减：

# multi_threaded.py
import time
from threading import Thread

COUNT = 50000000

def countdown(n):
    while n>0:
        n -= 1

t1 = Thread(target=countdown, args=(COUNT//2,))
t2 = Thread(target=countdown, args=(COUNT//2,))

start = time.time()
t1.start()
t2.start()
t1.join()
t2.join()
end = time.time()

print('Time taken in seconds -', end - start)

当我再次运行时：

$ python multi_threaded.py
Time taken in seconds - 6.924342632293701

如你所见，两个版本花费了近乎一样的时间来完成。在多线程的版本里，GIL阻止了CPU密集型线程并行执行。

在IO密集型的程序中，GIL不会造成太大的影响，因为在线程等待IO的时候，它们共享GIL。

但是所有线程都是完全的CPU密集型的程序（比如用多线程处理一张图片的多个部分）不仅会因为GIL而变成单线程的，并且执行时间也会变长，比如上面的例子中，（多线程版本）与完全单线程版本的比较。

执行时间变长的原因是GIL导致的锁的获取与释放。

为什么GIL还没有被移除？

Python的开发者经常收到对此的抱怨，但是像Python这样流行的语言，不可能在引入删除GIL这么重大的改动时还不产生向后兼容性问题。

GIL看似可以被移除，但是这样的尝试开发者和研究人员们过去已经进行了多次，而所有的尝试都破坏了已存在的C扩展，因为这些C扩展都严重依赖GIL所提供的解决方案。

当然，也有其他的一些方法可以解决GIL所解决的问题，但是其中一些方案降低了单线程和多线程下的IO密集型程序的性能，而另一些则太过困难。毕竟你不想让你的Python代码在新版本上跑的反而更慢了，不是吗？

Python之父、“仁慈的终身独裁者”，Guido van Rossum，在它的2007年九月份的文章“[It isn't Easy to remove the GIL]”上给了社区答案：

只有在单线程（以及多线程IO密集型）程序的性能不下降的情况下，我才能欢迎向Py3k打上一系列补丁。

而此后的所有尝试都没有满足这个条件。

为什么不在Python3中移除它？

Python3的确有机会从头开始很多新功能，在此过程中，破坏一些存在的C扩展，让它们更新以适配Python3，这就是为什么Python3的早期版本被社区适配缓慢的原因。

但是为什么GIL没有被同时删除呢？

移除GIL将会使得Python3在单线程性能上比Python2还要慢，你可以想象一下这会导致什么，GIL的单线程性能优势是无可辩驳的，这就导致了Python3中也有GIL。

但是Python3也的确为已存在的GIL带来了很大的提升：

我们讨论过GIL对于“纯CPU密集型”和“纯IO密集型”多线程程序的影响，但是对于一部分线程是IO密集型而另一部分线程是CPU密集型的程序来说呢？

众所周知，在这样的程序里，Python的GIL会由于不给IO密集型线程从CPU密集型线程中获取锁的机会而饿死IO密集型线程。

这是因为Python内部的一种机制，它会强制线程在连续使用固定的间隔之后释放掉GIL，如果没有人请求GIL则会继续执行当前线程。

>>> import sys
>>> # The interval is set to 100 instructions:
>>> sys.getcheckinterval()
100

这个机制的问题是，大多是时间里，CPU密集型的线程将会在其他线程获取之前重新获取到GIL。David Beazley的研究和可视化可以在这里找到。

这个问题在2009年的Python3.2中被Antoine Pitrou修复，他加入了一个机制，检查其他线程的GIL获取请求，不允许当前的线程在其他线程有机会运行之前重新获取到GIL。

如何处理Python的GIL？

如果GIL为你带来了问题，这有一些你可以尝试的办法：

1. 多进程vs多线程

最常见的方法就是使用多进程而不是多线程。每个Python进程有它自己的Python解释器和内存空间，所以GIL就不是问题了。Python有multiprocessing模块可以让我们像这样很容易地创建进程：

from multiprocessing import Pool
import time

COUNT = 50000000
def countdown(n):
    while n>0:
        n -= 1

if __name__ == '__main__':
    pool = Pool(processes=2)
    start = time.time()
    r1 = pool.apply_async(countdown, [COUNT//2])
    r2 = pool.apply_async(countdown, [COUNT//2])
    pool.close()
    pool.join()
    end = time.time()
    print('Time taken in seconds -', end - start)

在我的系统上运行输出如下：

$ python multiprocess.py
Time taken in seconds - 4.060242414474487

相对于多线程地版本有了像样地性能提升是吧？

运行时间并非我们想象中的下降一半，因为进程管理需要它自己的开销。多进程比多线程要更重一点，所以，记住这有可能是一个不断扩大的瓶颈。

2. 其他的Python解释器

Python有很多的解释器实现，常见的有CPython、Jython、IronPython以及PyPy，分别用C语言、Java、C#和Python写的。GIL只在原生的Python实现CPython中存在。如果你的程序和它所使用的库在其他的实现上可以运行，那你也可以尝试一下。

3. 再等一等

尽管很多用户正在享受着GIL的单线程性能优势，多线程的开发者也不需要沮丧，因为Python的社区中有很多聪明的头脑正在为移除CPython中的GIL而努力，比如Gilectomy。

总结

Python的GIL常常被认为是一个疑惑和困难的话题，但是请记住，作为一个Pythonista（译者：指使用Python的人），只有当你写C扩展或者是在程序中使用了CPU密集型的多线程时，你才会受他影响。

在这种情况下，这篇文章应该为你提供了解GIL是什么以及如何在你的项目中处理它所需的一切。如果你想要理解GIL底层的内部过程，我推荐你去观看David Beazley讲的Understanding the Python GIL。

原文链接：What is the Python Global Interpreter Lock (GIL)?

译者记

这篇文章从务实的角度出发，讲述了Python的GIL的产生和发展，以及它的意义。

其实在我的理解中，线程概念的出现本就是为了方便将任务抽象成多个子任务，而抽象必不可少的就要付出代价，所以我们需要各种各样的锁，也就是线程管理一定需要开销。因此，大概是不存在一种两全其美的办法，既能方便编写程序，又能让性能毫无损失。从时间复杂度上来说，我们只能够不断地逼近1+1=2，而实际上只会是1+1>2。

哈，又扯远了。有时候我也在想，存不存在一种抽象，它能够完美地概括所有的形式，也就是毫无损失的抽象。大概很难吧，或者说不可能，人的思维的工作方式就决定了它的不可能。

有没有想过Python是如何在背后处理你的数据的？你的变量是如何存放在内存中的？他们什么时候被删除？

在这篇文章中，我们将深入研究Python的内部原理，来了解他是如何进行内存管理的。

通过这篇文章，你将会：

• 学习更多关于底层计算的知识，尤其是内存相关；
• 理解Python是如何抽象底层操作的；
• 学习Python的内部内存管理算法。

理解Python的内部原理还可以让你更好地理解Python的一些行为，也希望你对Python能有更好地认识。在Python的背后发生了很多的事情，以确保你的程序能运行地与你预想的一致。

内存是一本空白的书

首先，你可以将计算机的内存当作一本用来写短篇小说的空白书本，但是开始时上面还没有任何内容，而最终会有不同的作者不断出现，每个作者都想要一些空间来写上他们的故事。

因为不允许覆写，所以每个人都需要注意自己写入的页。在开始写入自己的故事之前，他们会咨询这本书的管理员，管理员会决定他们可以往哪里写入。

由于这本书存在了很长时间，因此其中的许多故事都已经不再适用。当不再有人去读或者参考这些故事的时候，它们将会被移除，来为新的故事腾出空间。

本质上（In essence），计算机内存就像这样一本书。实际上，计算机通常会调用固定长度的连续内存页，（就像书页一样），所以这样的比喻很是恰当。

那些作者们就像是不同的应用和进程，它们需要空间去存储数据。那个决定哪里可以写入的管理员，就扮演了各种内存管理器的角色。而那个删除旧的故事，为新的故事腾出空间的人，就是垃圾回收器。

内存管理：从硬件到软件

内存管理实际上是各种应用读写数据的过程，内存管理器会决定往哪里放置应用的数据。就像比喻中的有限的书页，内存块页是有限的，因此内存管理器必须找到空闲的空间来提供给应用。这个过程一般称作内存分配。

在另一边，当一段数据不再需要的时候，它们就可以被删除，或者说被释放。但是释放到哪里呢？这些“内存”是哪里来的呢？

在你运行你的Python程序的时候，在你的电脑的某个地方，有一个物理设备存储着你的数据。但是在对象实际到达硬件之前，Python代码要经过很多层的抽象。

这些硬件（比如内存或者硬盘）上的抽象层中最主要的一层就是操作系统，由它来执行（或者拒绝）对内存的读写请求。

在操作系统之上就是应用程序，比如默认的Python实现。你的Python代码的内存管理是由这个Python程序来处理的，其中用到的算法和数据结构就是这篇文章的重点。

默认的Python实现

CPython是默认的Python实现，它实际上是由C语言写的。

当我第一次听到这一点的时候很惊讶，一个语言竟然是用另一个语言写的？好吧，不全是，但是有一点。

Python语言定义在用英文写的参考手册中（译者：现在大部分的Python文档都已经有了中文翻译，在官网文档的左上角选择简体中文即可看到）。然而这个手册自身并非万能，你需要一些东西，来按照手册中的规则解释你所写的代码，另外还需要一些东西来在计算机上执行解释后的代码。默认的Python实现满足了这两点需求：它将你的Python代码转换成指令，然后再一个虚拟机上运行这些指令。

提示：虚拟机类似物理机器，但是使用软件实现的。它们一般处理类似汇编指令的基础指令。

Python是一个解释型的语言，你的代码实际上被编译成字节码，它们是更容易被计算机识别的指令，这些指令会在运行时被一个虚拟机解释。

你是否看到过.pyc文件或者__pycache__目录？那就是被虚拟机解释的字节码。

需要注意的一点是，除了CPython，还有很多不同的实现。IronPython（将Python代码）编译成微软的通用语言运行时；Jython编译成Java的字节码以在JVM上运行；还有PyPy，但这值得一整篇文章来写了，所以在这里我只是顺带一提。

出于本文的目的，我将重点介绍Python的默认实现：CPython的内存管理。

免责声明：尽管本文的大多数内容会保留到新版本的Python中，但未来情况仍有可能变化。这篇文章的参考版本是当前的最新版Python 3.7。

好的，现在我们明白了CPython是用C语言写的，并且它解释Python的字节码。那这与内存管理有什么关系呢？好吧，内存管理的算法和数据结构存在于CPython的实现代码中，那是用C语言写的。为了理解Python的内存管理，你必须首先对CPython自身有起码的了解。

CPython是用C写的，而C语言并非原生地支持面向对象编程。因此，在CPython的实现中有一些有意思的设计。

你可能听说过在Python中一切都是对象，包括int和str之类的类型，在CPython的实现级别上来说的确如此，有一个称为PyObject的结构体，CPython中所有其他对象都会使用这个结构。

这个PyObject是Python中所有对象的祖父，其中包含了两个东西：

• ob_refcnt：引用计数
• ob_type：另一个类型的指针

引用计数在垃圾回收时被使用，另外还有一个指针，它指向实际的对象类型，这个对象类型实际上也是另一个结构，用来描述一个Python对象（比如dict或者int）。

每个对象有它自己的对象内存分配器，它知道如何获取内存来存储这个对象。每个对象也有一个特定于对象内存释放器，它会在对象不再需要的时候“释放”掉内存。

然而，在所有关于内存分配和释放的讨论中，有一个重要的因素：内存时计算机中的共享资源，如果两个进程尝试去同时写入同一个地方就糟糕了。

全局解释器锁（GIL）

GIL就是处理共享资源的常见问题（比如计算机的内存）的一个解决方案。当两个线程同时尝试更改同一个资源时，他们可能踩到对方的脚趾头。最终的结果可能很混乱，两个线程都没有得到他们想要的结果。

再想一想那个书本的比喻。假设有两个作者固执地认为该他们写了，并且两个人想要同时向同一个书页中写入。

他们都忽略了对方的创作故事的企图，然后开始了向页面的写入。最终的结果就是两个故事互相重叠，导致整个页面完全无法阅读。

这个问题的解决方案之一是，当线程与共享资源（书页）进行交互时，在解释器上进行的单个全局锁定。换句话说，同时只有一个作者可以写入。

Python的GIL通过锁定整个解释器来实现这一点，这意味着另一个线程不可能抢占当前的线程。当CPython处理内存的时候，它利用GIL来保证操作的安全。

这种方式有利有弊，在Python社区中CIL受到了很大的质疑。要想了解更多关于CIL的内容，我建议阅读What is the Python Global Interpreter Lock (GIL)?

垃圾回收

我们再来回顾那个书本的比喻。假设书中有一些故事已经很老了，没有人正在阅读和引用这些故事了，这时候你就可以丢掉它们来为新的故事腾出空间了。

那些旧的、不再被引用的故事可以与Python中引用计数降为0的对象作类比。记住Python中的每个对象都有一个引用计数和指向类型的指针。

引用计数会因为不同的原因而增长。比如，当你将一个对象赋给另一个变量的时候，引用计数就会加一：

numbers = [1, 2, 3]
## 引用计数 = 1
more_numbers = numbers
## 引用计数 = 2

把一个对象作为参数传递的时候，引用计数也会增加：

total = sum(numbers)

最后一个例子是，当一个对象包含在一个列表中，它的引用计数也会增加：

matrix = [numbers, numbers, numbers]

Python允许通过sys模块来某个对象检查当前的引用计数，你可以使用sys.getrefcount(numbers)来获取，但是记住把对象传递给getrefcount()函数会使引用计数增加1。

无论那种情况，如果一个对象仍然被你的代码需要，它的引用计数就会大于0。一旦它降到0，这个对象对应的释放函数将会被调用，“释放”内存来让其他的对象使用。

但是“释放”内存是什么意思呢？其他的对象如何使用它？让我们进入CPython的内存管理。

CPython的内存管理

我们将深入CPython的内存架构和算法，系好安全带！

就像之前提到的那样，从硬件到CPython之间有很多层的抽象。操作系统抽象物理内存，并创建应用程序（包括Python）可访问的虚拟内存层。

操作系统的虚拟内存管理器为Python的进程分配了一大块内存。下面这张图片中的灰色区域正在被Python进程所拥有。

Python将一部分内存用于内部使用和非对象内存，另一部分用于对象的存储（你的int，dict等等）。注意这是被简化之后的，如果你想要完整的图片，你可以查看CPython的源代码，那里可以看到所有的内存管理过程。

CPython有一个对象分配器，它的职责是在上述的对象内存区域（译者：绿色区域）中分配内存。这个对象分配器是大多数逻辑发生的地方，每当一个新的对象需要空间或者被删除的时候它就会被调用。

一般地，像list和int这样的对象，在加入或者删除数据的时候不会同时涉及到大量数据，所以这个分配其的设计是在一次处理少量数据的时候工作良好，同时，不到万不得已，它也会尽可能地尝试不去分配内存。

在源代码里的注释描述这个分配器为：一个专用于小块内存分配的快速分配器，基于通用目的的malloc分配器。其中，malloc是C语言标准库的内存分配函数．

现在我们来看看CPython的内存分配策略。首先我们讨论三个主要的部分以及它们之间的关系。

arena是内存中最大块，它会对齐到内存页的边界。页边界是操作系统所使用的定长连续内存块的边缘，Python假设系统页大小是256K字节。

区块内部是pool，pool是一种虚拟的内存页（4K字节）。就像我们的比喻中的书页，这些pool被分割成较小的内存块（block）。

给定pool中的所有的block都有着相同的大小级别。给定一定大小的请求数据，对应的大小级别就指定了固定的block大小。下面这张表来自源代码的注释：

例如，如果请求42字节的数据，这些数据将会被放置在48字节大小的块中。

Pools

Pool是由相同大小级别的block组成的，每个pool维护了一个双向链表，连接到其他相同大小级别的pool，因此算法可以很容易地为所需的块大小找到可用的空间，即使是在不同的pool里面。

usedpools链表跟踪有一定空间可用的各个级别的pool，当请求某个块大小时，算法会在这个usedpools列表中检查这个块大小的pool列表。

pool会处于三种状态：used，full和empty。used状态的pool有着空闲的block来存储数据；full状态的pool中所有的block都已被分配出去，并且包含着数据；empty状态的pool中没有数据，在需要的时候，可以分配任何大小级别的块。

freepools链表跟踪着所有的empty状态的pool，什么时候empty pool会被使用呢？

假设你的代码需要8字节的内存块，如果在usedpools中没有8字节大小级别的pool，一个新的empty pool就会被初始化，来存储8字节的块，这个pool会被加入到usedpools列表中以便之后的分配请求。

full状态的pool由于一些内存不再需要而释放了一些块，那这个pool就会被重新加入到usedpools列表中。

现在你可以看到pool（以及大小级别）是如何在各个状态间转移的了。

Block

就像上图所述，pool中包含了一个指向其中空闲块的指针。其实这和实际的情况有所差别，根据源代码中的注释，这个内存分配器会“在各个层级上，不到万不得一不去动用内存”。

这意味着一个pool中的block可以拥有三种状态，如下：

• untouched：从未被分配过的内存；
• free：曾被分配过，但之后被CPython“释放”掉了，不再包含有效的数据；
• allocated：实际包含有效数据的内存。

freeblock指针指向了一个free状态的block的单链表。换句话说，一个可以存储数据的地方的列表。如果需要更多free block，分配器就会从pool中获取一些untouched状态的块。

当内存分配器“释放”掉一些块之后，这些free block会被加入到freeblock列表的头部，（所以）这个列表可能是内存中不连续的块，就像第一个图所示。可能像是下面这张图：

Arena

arena包含了pool，这些pool的状态可能是used、full或者empty，而arena自身并没有这些明确的状态。

相反，arena被组织到一个称为usable_arenas的双向链表中，这个链表根据其中可用的空pool的数量排序，空pool越少，就越靠近列表的前方。

这就意味着，在存储新数据的时候，包含最多数据的arena将会被选中。为什么不是反过来的？为什么不把数据放在有最多空闲空间的地方？

这就引出了“释放内存”的真实意义。你会注意到我说“释放”的时候一直带着引号，原因就是block只是被认为“释放”掉了，实际上这些内存并没有返还给操作系统，Python进程保留着这些内存，之后会用它存储新的数据。真正的释放内存会将其返回给操作系统。

arena是唯一一个可以被实际释放的东西，所以有理由认为，应该允许那些更接近空的arena变成完全的空，这样的话，其中的内存就可以被实际释放掉，以减少Python程序的整体内存占用。

结论

内存管理是计算机中不可或缺的一部分，不论结果好坏，Python几乎将所有的内存管理都在幕后处理。

在这篇文章中，你学到了：

• 什么是内存管理以及它的重要性；
• 默认的Python实现CPython是如何用C语言写的；
• CPython内存管理中的算法和数据结构是如何处理你的数据的。

Pyhton抽象了许多计算机的严格细节，这就使你有能力在更高的层级上开发，而不用因为担心如何、在哪存储你的字节而头痛。

原文链接：Memory Management in Python

译者记

从整体来说，这篇文章是比较容易，适合对内存相关概念比较模糊的新手看；从Python的角度来说，大概讲述了关于Python内存管理中的一些概念、数据结构和算法，不太细致但作为入门了解也是挺好的。

这学期有了操作系统课程，并且加入了试点班。试点班的任务还挺实在的，一上来就是从硬件的引导，也就是在操作系统加载之前的MBR中代码的执行。

因为对于汇编不熟，所以代码里面有些细节还不太清楚，这篇文章主要记录一下引导的大致过程，承载引导信息与代码MBR，以及MBR之后的分区与文件系统。

由于水平有限，无法做到细节俱到，只是在此记录我对于整体过程的理解。
另外，这里只介绍MBR+MBR硬盘启动方式，并未考虑到UEFI+GPT硬盘的方案。

存储设备、分区与文件系统

存储设备

什么是一个存储设备？（这里并非指易失性存储，主存、缓存等）

在这里，我不想像学院派的计算机体系一样，将其只是作为对主存的辅助，因为在当今的计算机世界，硬盘与内存完全是两个角色，虽然这有可能是工业制造技术的原因，但至少这是事实；我也不想像一个硬件厂商那样，将存储设备细分为软盘、硬盘、USB设备等等，这些设备其实本质是相同的，我们在此需要考虑的是它们之间的“共相”，并非差异，它们的差异或许只在于硬件接口实现与历史遗留问题，不要让这些称为自己理解的累赘。

对我们来说，对一块存储设备，无论是软盘硬盘还是U盘，最本质的抽象是一个数组。将它们统统都当做数组，暂且忽略掉差异。与数组相伴而生的，就是数组的索引方式，对应的是存储设备中的寻址方式。接受了这个抽象，存储设备就成为了你理念世界中的一个个小方块了。

文件系统

对于一块硬盘，我们最直觉的感受是什么？是它能存储文件。想一想，一边是一个数组，另一边是一堆目录与文件，这两个东西怎么联系起来呢？用文件系统。如果考虑到文件也是一块字节串，那么文件系统本质上就是实现这个功能的： 在一块数组上，完成对一系列字节块的组织与操作。“组织”是数据结构，“操作”是算法，两个合起来就是文件系统。 我们在“格式化”一个“硬盘”的时候，做的就是“初始化数据结构”的工作，初始化后的数据结构就放在硬盘这个数组内部。之后，如果用户要存储文件，只要按照规定的算法，合理地操作这些数据结构，将自己要存的东西写进该写的地方就可以了。查询文件也是一样。

我们尝试体验一下这个过程。假设要实现存放文件的功能，不考虑性能。我们用最简单的方式来做：将整个数组分成大小相同的块，比如每块512个字节，每块存一个文件，每块的第一个字节存储这个块有没有被使用过，之后的七个字节存储这个块存的文件的文件名；要存储文件的时候，就从头以此寻找尚且没有被占用的块，查找的时候，就以此找对应的文件名。这样，一个简陋的、支持文件大小有限的、支持文件名非常短的文件系统就完成了。在初始化之后，我们只需要一段能跑起来的代码就可以使用它了。

虽然很简陋，但是大概也能说明问题。

分区

文件系统理解了，那分区的概念就没什么好说的了。

我们不满足于将一整块硬盘当做一个文件系统用，所以我们搞了一张表，叫做分区表，一般就在硬盘的开头。这个表的作用很简单，里面有四项，每一项对应一个分区，记录两个字段：分区的开始与结尾。这样子，整块硬盘就被分为了四个块，称作四个分区，也就是四个数组，我们在每个数组上都建立文件系统，就可以分块使用这个硬盘了。

以上描述中，硬盘一词可以替换为软盘、U盘等等。

分区表存储的位置见下面所述的MBR。

MBR与引导

在我们的个人电脑经过硬件加电、自检完成之后，它就要进行一些预备活动来给用户提供可使用的交互接口了，个人电脑上这个交互接口就是操作系统，而预备我们称之为引导。

引导时期会做什么事情呢？

1. 加载
   首先，硬件发现一个存储设备，如果我们将存储设备看做一个很大的数组，那么硬件就会将这个数组的前512个字节加载到内存的0000:7c00处；
   这512个字节的内容就是我们说的主引导记录（Master Boot Record，MBR），按照约定，这里面大致包含了一个三个内容：引导代码、分区表、可启动标志。

   描述	长度
   代码区	446
   分区表	64
   可启动标志	2
   	512

2. 检查
   之后，硬件去检查加载进来的内容的最后两个字节的内容，也就是可启动标志，如果是0x55aa，那么表明这个设备是一个可启动设备，否则，转而尝试其他设备；

3. 运行
   确定该设备可启动之后，硬件就会尝试执行之前加载的MBR中的代码。这时候，系统的控制权就交给了引导代码，也就是我们写的代码。

上述过程很简单，在这个过程中需要注意的：

• 512个字节长的MBR都是由我们自己在代码里面写的，也就是说，我们的汇编代码里面不止需要有可执行的代码，还需要填充好其余的字节，比如启动标志和分区表。这也就是为什么我们需要在代码的末尾写上times 512-($-$$)，以及为什么最后要有0xaa55的原因，但由于暂时不需要分区表，所以分区表并没有被填充。
• MBR并非被加载到0地址处，而是7C00处，也就是说，我们的代码最终执行的时候起点会在内存的7C00处，这时候就需要注意了，如果在代码里我们用到了跳转指令等，那么汇编器在生成机器代码的时候，需要如何填充跳转目标呢？如果汇编器认为代码的起始地址是0，那么跳转指令的操作码就会是以0为基准计算得来的了，很显然会出问题，所以我们需要在代码最开始用org伪指令告诉汇编器程序的起点，这样，在通过偏移量计算绝对位置的时候，生成的代码才会不出问题。当然，如果代码里面没有用到通过偏移计算的，比如全是mov指令，那么无论如何都不会出问题。

处理好开头与结尾，剩下的就是如何写代码了。

参考：

• 维基百科：主引导记录
• WikiPedia: Master Boot Record

一门语言做的事情，其实是为硬件赋予思维对象，建立一种对硬件的抽象，或者说是对某些基本形式的假设与总结；
一门语言做到类型完备，只是语言做的抽象达到了完备，它的“功能”并未被提升，甚至一定会减弱；
当做出抽象时，一定会为原本自由、难以被人类驾驭的基本形式做出假设和约束，这种约束使得形式能在思维的领域被应用，但同时，这种约束也使得原本随意自由的形式变得固化，也因此会丧失一些功能；
能实现的功能由其抽象中仍然保留的形式决定，但易用性则由抽象时对形式做的假设总结的合理性决定，这些假设总结越是符合人类的习惯，就越是易用；
当抽象出现的时候，其实也创建了新的形式，或者说“发现”了新的形式，这种新的形式在原本的基本形式中很难被人类发现；

因此，几乎所有语言都无法做到比汇编语言“更多”，而只能做到“更好”，语言层面的各种模型与概念，决定了它有多好用、多“强大”。

这种由约束形成易用性的形式在计算机的世界到处都是，所谓“增加一层就能解决问题”大多数时候都指的是这种情况。

这种现象也能为了解直觉与思维的关系提供一些启示。人类的直觉是强大又弱小的，强大是因为这个词语是在思维范畴中作用的，而直觉作为思维的源泉必定难以、或者说无法描述直觉，所以会感到“强大”；而弱小是因为，人类的直觉能告诉我们的形式太少了，我们大多数时候能做到的，只是“发现简单的形式，然后做出抽象，进一步发现抽象出来的形式”，因为直觉做不到，所以我们需要作为理性的思维来辅助我们感知因果。从上述的过程中，我们可以发现，思维其实是理性为弱小的人类提供的工具，但因为其根本是抽象，抽象的过程是假设和总结的过程，所以思维也会称为我们的桎梏，这种现象与我之前描述的“当我拿起锤子，就不再能用手指拿捏”是一个道理。也正是因为这种现象，时常工作在创造性的直觉活动中的爱因斯坦会觉得“越符合直觉的东西就越是难以思考”。
思维带来的，是我们对形式的更敏锐的感知，它能带来更多的直觉可用的客体，因此能够扩充我们的直觉，但这种直觉客体不够纯粹，它一定已经被某种程度地特化了。
有了更多的直觉，我们就可以将它们用于对客体的改造上，我们就能够有机会获得更强的意志。

信号用于进程间信息的传递，对信号的处理属于异步过程，同时会中断进程当前的执行，类似硬件中总线的中断机制，所以信号也叫作“软件中断”。

信号的生成与传递时机

• 从进程的角度来说：信号一般为异步产生，程序无法预测信号何时到来；但有个例外，使用raise、kill向进程自身发送的信号是同步的，即在这些调用返回时，信号必定已经传递到。
• 从内核的角度看：信号会在由内核态转为用户态时被处理：要么进程被重新调度，要么进程从系统调用中返回。所以，在信号处理函数中进行的系统调用有可能导致另一个信号处理函数的调用。

信号处理函数

大多数信号可以有用户自定义函数，这些函数在信号到来时被调用，使用signal或者sigaction系统调用来设置。

由于信号处理函数调用时机的特殊性，信号处理函数的要求比较严格，必须为“异步信号可重入”函数，以保证访问的安全。“异步信号可重入”函数被定义为：一个函数要么可重入，要么不可被信号中断。UNIX的几个标准（POSIX、SUS）定义了一个异步信号可重入的系统调用的列表，但Linux并未完全实现这些函数的可重入性。

信号处理函数的嵌套调用

如上所述：如果在A信号处理函数中没有阻塞某个信号B，那么在A的处理函数中，如果有系统调用，那么在系统调用返回时信号B的到来是会打断A的处理函数的执行，而去执行B的处理函数。注意，此时A的处理函数仍未执行完，在信号A上设置的阻塞掩码仍未被撤销，信号B的处理函数中的掩码是AB掩码的与。

信号处理函数中要注意的几点

• 要么不使用不是“异步信号可重入”的函数，要么在程序不安全的地方中阻塞该信号（这里的不安全的地方指：程序中使得该函数变得“不可重入”的部分）；
• 由于信号处理函数在当前线程执行，因此errno变量也就变为不安全的了，所以，一般会在信号处理函数的出口和入口备份恢复errno的值；
• 在信号处理函数中使用longjmp进行非本地跳转时，需要注意的是，不是所有UNIX系统都保证longjmp跳转出去时会取消对当前信号的阻塞（进入信号处理函数前会阻塞对应的信号），因此，需要使用sigsetjmp和siglongjmp函数进行非本地跳转；

特殊信号的特殊表现

1. SIGKILL和SIGSTOP信号均无法阻塞或者忽略，尝试修改默认行为则会出错；
2. SIGCONT信号可以被阻塞或者忽略，但是即使这样，被暂停的进程仍然会被唤醒。同时，进程收到SIGCONT信号后，会将正处于等待状态的SIGSTOP信号清除掉；同样的，收到SIGSTOP会将等待的SIGCONT信号清除；
3. SIGCHLD信号，默认在子进程结束或停止时触发。如果指定SA_NOCLDSTOP标志，子进程因信号被停止（STOP）的时候，不会触发该信号；如果指定SA_NOCLDWAIT标志，子进程结束后会被系统直接清理，不会产生僵尸进程，但仍会触发父进程的信号处理函数；
4. 显式的将SIGCHLD信号忽略（SIG_IGN）也可以达到第三点所述的效果。

实时信号

实时信号是标准信号以后的信号，大多数没有特定的意义，供程序自身使用。实时信号与标准信号相比，提供了队列化管理，具有特定顺序，并且可以附带少量数据（一个整型或一个指针）。实时信号最大和最小值定义为SIGRTMIN、SIGRTMAX。

信号的同步等待

sigsuspend, sigwaitinfo, signalfd相关的系统调用提供了将信号同步处理的功能，详细介绍见下。

相关系统调用

signal

简单设置信号处理函数

sigaction

为一个信号设置信号处理函数，但是支持更多功能。

比如，支持在执行对应信号处理函数前自动阻塞信号自身与一组指定的信号，并在处理函数返回之后自动清除阻塞。与在信号处理函数中手动阻塞所需函数不同，sigaction所做的阻塞是在处理函数被执行之前（或许是内核态时），所以可以保证阻塞操作的有效性不会受到信号异步性的影响。比如：

void
handler(int sig)
{
    sigprocmask(SIG_SETMASK, &mask, &prevmask);  // block some signal
    /* DO SOMETHING*/
    sigprocmask(SIG_SETMASK, &prevmask, NULL);   // restore
}

如果要被阻塞的信号在第四行前来到，那么第四行就没起到它应有的作用。

另外，sigaction还支持自动重启被中断的系统调用、不将子进程转为僵尸进程、使用自定义的栈执行信号处理函数等等功能。

sigprocmask

该系统调用用于设置和查看“阻塞信号列表”。

内核为进程（线程）维护了一组被阻塞的信号列表，处于该列表中的信号不会被进程接收到，而是等待进程停止阻塞。信号被阻塞时，对新到的信号处理方式有排队和不排队两种，标准信号不排队，实时信号排队。

sigpenging

用于查看由于阻塞而正在等待的信号。

sigsuspend

在更改信号掩码的之后，挂起进程直到新的信号到达，信号处理函数返回后，自动还原信号掩码。

有时候实现这样的功能：信号原本被阻塞，现在需要取消阻塞，直到第一个信号到达，也就是希望同步等待一个信号。如果按照如下方式写：

sigprocmask(SIG_SETMASK, &mask, &prevmask);
pause();
sigprocmask(SIG_SETMASK, &prevmask, NULL);

看起来能实现所需的功能：先设置新的阻塞掩码，然后等待信号到达，最后恢复。但是如果信号在pause调用之前、第一个sigprocmask之后到达，那么程序的表现就不正确了，之后的pause返回并不是因为信号的第一次到达。实质上，这是一个竞态问题，竞态的双方为主程序和信号的处理函数。

sigsuspend就可以解决这个问题，这个系统调用将上面三个操作封装成一个原子操作，以解决这里的竞态问题。如果sigsuspend被信号打断（完成目标），则返回-1，errno设置为EINTR。

sigwaitinfo

这是类似sigsuspend的一个调用，也是实现信号的同步等待。通过参数mask来指定需要等待的信号。

但是与sigsuspend不同之处在于：

1. sigwaitinfo并不会去调用信号处理函数，而是直接返回信号的编号和一个siginfo_t结构体；
2. sigwaitinfo的参数mask并不是用来替换当前的mask的，而是指定需要等待的信号，相反，sigsuspend的mask参数会被用来替换当前进程的mask。

需要注意的是，在sigwaitinfo一个信号前，需要显式地将这个信号阻塞（阻塞之后sigwaitinfo仍然可以接收到信号的传递）；如果sigwaitinfo的时候没有对相应的信号进行阻塞，sigwaitinfo的结果未定义。通常会在sigwaitinfo之前阻塞所有的信号。

sigwaitinfo有可能被其他未阻塞的信号打断，此时errno为EINTR。

signalfd

这也是用来使信号同步接收的一个调用，这个调用为信号的接受创建了一个文件描述符，当新的信号到达时，文件描述符变为可读状态。可以配合select等完成同步。

sigset_t

信号集的数据类型，用于描述一组信号，实现方式取决于具体实现，可能为整型、数组或者结构体。

以下为glibc提供的信号集操作函数：

• sigemptyset 清空
• sigfillset 填满
• sigaddset 添加
• sigdelset 删除
• sigismember 查询

代码块

Python的程序由代码块组成，模块、函数、类定义都属于代码块。代码块作为一个单元被解释器运行，代码块可以拥有独立的作用域。

代码块在执行帧中被执行。 一个帧会包含某些管理信息（用于调试）并决定代码块执行完成后应前往何处以及如何继续执行。

变量

Python中的变量，本质上是内存中对象的名称绑定。能够创建绑定的语句有：等号赋值、函数传参、import、类定义、函数定义、for、with和except的as。

变量作用域

作用域指的是变量能被访问到的范围，是一个范围，可分为：全局作用域、本地作用域、非本地作用域、内置作用域。全局作用域（global）指整个模块内；本地作用域（local）指当前代码块内；非本地作用域（nonlocal）指本地作用域以上，全局作用域以下的范围；内置作用域（builtin）是一个特定的作用域，内含一些内置变量。

变量按照作用域区分，共有三种：全局变量、局部变量、自由变量。

• 全局变量：拥有全局作用域
• 局部变量：拥有本地作用域
• 自由变量：作用域未确定

作用域的确定

变量的作用域并非在运行期确定的，而是在预编译期确定。在预编译时，编译器会：

1. 扫描非全局代码块中的绑定语句，并将该语句所创建的名称作为该代码块的局部变量；
2. 将在模块层级（全局）创建的名称绑定当做全局变量；
3. 将代码块中使用但未定义的变量当做自由变量；
4. 将使用global和nonlocal关键字定义的变量分别会当做对全局和非本地作用域内的绑定。

这些都在运行前决定，谨记。

命名空间

命名空间是一个字典，表示一个代码块所拥有的名称绑定，代码块每次执行时都会生成新的命名空间。可以通过globals()和locals()函数分别访问全局和本地命名空间。使用global和nonlocal关键字时，会将指定的变量放到当前代码块的命名空间内。

对变量的绑定（创建）

在代码块中遇到绑定语句时，会在代码块对应的命名空间字典中添加对应的键值对，这时才完成了对变量的绑定。

对变量的引用（使用）

在运行期，对一个变量进行引用（使用）时，实际上就是要找到变量所绑定的对象。情况分为：

• 如果是模块内的全局变量，在全局命名空间内查找名称绑定；
• 如果是局部变量，则在当前代码块的命名空间内查找绑定；
• 如果是自由变量，则从当前代码块的命名空间开始层层向上查找，直到找到一个绑定。

可以看出，闭包现象就是由自由变量的访问机制产生的。

此处所述只是语言表现，并非实现细节，对自由变量的引用可能并非直接在命名空间内搜索，而是在预编译期确定上层命名空间是否有对应的绑定。 例如，最常见的闭包：

def outer():
    a = 10
    def inner():
        print(a)
    return inner

print(outer().__closure__)   # (<cell at 0x7f379c12c828: int object at 0x7f379ca7b600>,)

可以看出，内部函数对a的访问会被直接绑定到inner对象上，而不会去在命名空间重新查找。

实例

请看如下代码：

a = 10 	# global
def foo():
    print(a)
foo() 	# 10, no error

没有问题，因为a属于自由变量，会向上查找。

如果变成这样：

a = 10 	# global
def foo():
    a = 5
    print(a)
foo() 	# 5, no error

此时，a在预编译期被确定为局部变量，因此在foo代码块中隐藏了全局的a。

但是，如果变成这样：

a = 10 	# global
def foo():
    print(a)
    a = 5
foo() 	# UnboundLocalError: local variable 'a' referenced before assignment

出错了！正是因为foo中有对a的绑定（赋值语句），a被当做局部变量，但是在第三行print(a)的时候，赋值仍未执行，绑定也就未完成，因此抛出异常。这里就体现出了变量作用域的决定是在预编译期确定这一现象造成的影响。