分类 软件开发 下的文章

在本系列的 上一篇文章 中,我们回顾了人工智能的历史,然后详细地讨论了矩阵。在本系列的第三篇文章中,我们将了解更多的矩阵操作,同时再介绍几个人工智能 Python 库。

在进入主题之前,我们先讨论几个人工智能和机器学习中常用的重要术语。 人工神经网络 artificial neural network (通常简称为 神经网络 neural network ,NN)是机器学习和深度学习的核心。顾名思义,它是受人脑的生物神经网络启发而设计的计算模型。本文中我没有插入神经网络模型的图片,因为在互联网上很容易找到它们。我相信任何对人工智能感兴趣的人应该都见过它们,左边是输入层,中间是一个或多个隐藏层,右边是输出层。各层之间的边上的 权重 weight 会随着训练不断变化。它是机器学习和深度学习应用成功的关键。

监督学习 supervised learning 和 无监督学习 unsupervised learning 是两个重要的机器学习模型。从长远来看,任何立志于从事人工智能或机器学习领域工作的人都需要学习它们,并了解实现它们的各种技术。这里我认为有必要简单说明两种模型之间的区别了。假设有两个人分别叫 A 和 B,他们要把苹果和橘子分成两组。他们从未见过苹果或橘子。他们都通过 100 张苹果和橘子的图片来学习这两种水果的特征(这个过程称为模型的训练)。不过 A 还有照片中哪些是苹果哪些是橘子的额外信息(这个额外信息称为标签)。这里 A 就像是一个监督学习模型,B 就像是无监督学习模型。你认为在是识别苹果和橘子的任务上,谁的效果更好呢?大多数人可能会认为 A 的效果更好。但是根据机器学习的理论,情况并非总是如此。如果这 100 张照片中只有 5 张是苹果,其它都是橘子呢?那么 A 可能根本就不熟悉苹果的特征。或者如果部分标签是错误的呢?在这些情况下,B 的表现可能比 A 更好。

在实际的机器学习应用中会发生这样的情况吗?是的!训练模型用的数据集可能是不充分的或者不完整的。这是两种模型都仍然在人工智能和机器学习领域蓬勃发展的众多原因之一。在后续文章中,我们将更正式地讨论它们。下面我们开始学习使用 JupyterLab,它是一个用于开发人工智能程序的强大工具。

JupyterLab 入门

在本系列的前几篇文章中,为了简单起见,我们一直使用 Linux 终端运行 Python 代码。现在要介绍另一个强大的人工智能工具——JupyterLab。在本系列的第一篇文章中,我们对比了几个候选项,最终决定使用 JupyterLab。它比 Jupyter Notebook 功能更强大,为我们预装了许多库和包,并且易于团队协作。还有一些其它原因,我们将在后续适时探讨它们。

在本系列的第一篇文章中,我们已经学习了如何安装 JupyterLab。假设你已经按文中的步骤安装好了 JupyterLab,使用 jupyter lab 或 jupyter-lab 命令在会默认浏览器(如 Mozilla Firefox、谷歌 Chrome 等)中打开 JupyterLab。(LCTT 译注:没有安装 JupyterLab 也不要紧,你可以先 在线试用 JupyterLab)图 1 是在浏览器中打开的 JupyterLab 启动器的局部截图。JupyterLab 使用一个名为 IPython(交互式 Python)的 Python 控制台。注意,IPython 其实可以独立使用,在 Linux 终端运行 ipython 命令就可以启动它。

图 1:JupyterLab 启动器

现阶段我们使用 JupyterLab 中的 Jupyter Notebook 功能。点击图 1 中用绿框标记的按钮,打开 Jupyter Notebook。这时可能会要求你选择内核。如果你按照本系列第一篇的步骤安装 JupyterLab,那么唯一的可选项就是 Python 3(ipykernel)。请注意,你还可以在 JupyterLab 中安装其它编程语言的内核,比如 C++、R、MATLAB、Julia 等。事实上 Jupyter 的内核相当丰富,你可以访问 Jupyter 内核清单 了解更多信息。

图 2:Jupyter Notebook 窗口

下面我们快速了解一下 Jupyter Notebook 的使用。图 2 显示的是一个在浏览器中打开的 Jupyter Notebook 窗口。从浏览器标签页的标题可以看出,Jupyter Notebook 打开的文件的扩展名是 .ipynb。

在图 2 处可以看到有三个选项,它们表示 Jupyter Notebook 中可以使用的三种类型的单元。“Code”(绿色框) 表示代码单元,它是用来执行代码的。“Markdown” 单元可用于输入说明性的文本。如果你是一名计算机培训师,可以用代码单元和 Markdown 单元来创建交互式代码和解释性文本,然后分享给你的学员。“Raw”(红色框)表示原始数据单元,其中的内容不会被格式化或转换。

和在终端中不同,在 Jupyter Notebook 中你可以编辑并重新运行代码,这在处理简单的拼写错误时特别方便。图 3 是在 Jupyter Notebook 中执行 Python 代码的截图。

图 3:在 Jupyter Notebook 中执行 Python 代码

要在执行代码单元中的代码,先选中该单元格,然后点击蓝框标记的按钮。图 3 中用红框标记的是 Markdown 单元,用绿框标记的是代码单元,用黄框标记的执行代码的输出。在这个例子中,Python 代码输出的是 π 的值。

前面提到,JupyterLab 默认安装了许多库和包,我们不用自己安装了。你可以使用 import 命令将这些库导入到代码中。使用 !pip freeze 命令可以列出 JupyterLab 中目前可用的所有库和包。如果有库或包没有安装,大多数情况下都可以通过 pip install <全小写的库或者包的名称> 来安装它们。例如安装 TensorFlow 的命令是 pip install tensorflow。如果后面有库的安装命令不遵循这个格式,我会进行特别说明。随着本系列的继续,我们还会看到 Jupyter Notebook 和 JupyterLab 更多强大的功能。

复杂的矩阵运算

通过下面的代码,我们来了解一些更复杂的矩阵运算或操作。为了节省空间,我没有展示代码的输出。

import numpy as np
A = np.arr ay([[1,2,3],[4,5,6],[7,8,88]])
B = np.arr ay([[1,2,3],[4,5,6],[4,5,6]])
print(A.T)
print(A.T.T)
print(np.trace(A))
print(np.linalg.det(A))
C = np.linalg.inv(A)
print(C)
print(A@C)

下面我逐行来解释这些代码:

  1. 导入 NumPy 包。
  2. 创建矩阵 A。
  3. 创建矩阵 B。
  4. 打印矩阵 A 的 转置 transpose 。通过比较矩阵 A 与 A 的转置,你用该可以大致理解转置操作到底做了什么。
  5. 打印 A 的转置的转置。可以看到它和矩阵 A 是相同的。这又提示了转置操作的含义。
  6. 打印矩阵 A 的 迹 trace 。迹是矩阵的对角线(也称为主对角线)元素的和。矩阵 A 的主对角线元素是 1、5 和 88,所以输出的值是 94。
  7. 打印 A 的 行列式 determinant 。当执行代码的结果是 -237.00000000000009(在你的电脑中可能略有区别)。因为行列式不为 0,所以称 A 为 非奇异矩阵 non-singular matrix 。
  8. 将矩阵 A 的 逆 inverse 保存到矩阵 C 中。
  9. 打印矩阵 C。
  10. 打印矩阵 A 和 C 的乘积。仔细观察,你会看到乘积是一个 单位矩阵 identity matrix ,也就是一个所有对角线元素都为 1,所有其它元素都为 0 的矩阵。请注意,输出中打印出的不是精确的 1 和 0。在我得到的答案中,有像 -3.81639165e-17 这样的数字。这是浮点数的科学记数法,表示 -3.81639165 × 10 -17, 即小数的 -0.0000000000000000381639165,它非常接近于零。同样输出中的其它数字也会有这种情况。我强烈建议你了解计算机是怎样表示浮点数的,这对你会有很大帮助。

根据第一篇文章中的惯例,可以将代码分成基本 Python 代码和人工智能代码。在这个例子中,除了第 1 行和第 9 行之外的所有代码行都可以被看作是人工智能代码。

现在将第 4 行到第 10 行的操作应用到矩阵 B 上。从第 4 行到第 6 行代码的输出没有什么特别之处。然而运行第 7 行时,矩阵 B 的行列式为 0,因此它被称为 奇异矩阵 singular matrix 。运行第 8 行代码会给产生一个错误,因为只有非奇异矩阵才存在逆矩阵。你可以尝试对本系列前一篇文章中的 8 个矩阵都应用相同的操作。通过观察输出,你会发现矩阵的行列式和求逆运算只适用于方阵。

方阵就是行数和列数相等的矩阵。在上面的例子中我只是展示了对矩阵执行各种操作,并没有解释它们背后的理论。如果你不知道或忘记了矩阵的转置、逆、行列式等知识的话,你最好自己学习它们。同时你也应该了解一下不同类型的矩阵,比如单位矩阵、对角矩阵、三角矩阵、对称矩阵、斜对称矩阵。维基百科上的相关文章是不错的入门。

现在让我们来学习 矩阵分解 matrix decomposition ,它是更复杂的矩阵操作。矩阵分解与整数的因子分解类似,就是把一个矩阵被写成其它矩阵的乘积。下面我通过图 4 中整数分解的例子来解释矩阵分解的必要性。代码单元开头的 %time 是 Jupyter Notebook 的 魔法命令 magic command ,它会打印代码运行所花费的时间。** 是 Python 的幂运算符。基本的代数知识告诉我们,变量 a 和 b 的值都等于 (6869 x 7873) 100。但图 4 显示计算变量 b 的速度要快得多。事实上,随着底数和指数的增大,执行时间的减少会越来越明显。

图 4:Python 代码的执行耗时

在几乎所有的矩阵分解技术技术中,原始矩阵都会被写成更稀疏的矩阵的乘积。 稀疏矩阵 sparse matrix 是指有很多元素值为零的矩阵。在分解后,我们可以处理稀疏矩阵,而不是原始的具有大量非零元素的 密集矩阵 dense matrix 。在本文中将介绍三种矩阵分解技术——LUP 分解、 特征分解 eigen decomposition 和 奇异值分解 singular value decomposition (SVD)。

为了执行矩阵分解,我们需要另一个强大的 Python 库,SciPy。SciPy 是基于 NumPy 库的科学计算库,它提供了线性代数、积分、微分、优化等方面的函数。首先,让我们讨论 LUP 分解。任何方阵都能进行 LUP 分解。LUP 分解有一种变体,称为 LU 分解。但并不是所有方阵都能 LU 分解。因此这里我们只讨论 LUP 分解。

在 LUP 分解中,矩阵 A 被写成三个矩阵 L、U 和 P 的乘积。其中 L 是一个 下三角矩阵 lower triangular matrix ,它是主对角线以上的所有元素都为零的方阵。U 是一个 上三角矩阵 upper triangular matrix ,它是主对角线以下所有元素为零的方阵。P 是一个 排列矩阵 permutation matrix 。这是一个方阵,它的每一行和每一列中都有一个元素为 1,其它元素的值都是 0。

现在看下面的 LUP 分解的代码。

import numpy as np
import scipy as sp
A=np.array([[11,22,33],[44,55,66],[77,88,888]])
P, L, U = sp.linalg.lu(A)
print(P)
print(L)
print(U)
print(P@L@U)

图 5 显示了代码的输出。第 1 行和第 2 行导入 NumPy 和 SciPy 包。在第 3 行创建矩阵 A。请记住,我们在本节中会一直使用矩阵 A。第 4 行将矩阵 A 分解为三个矩阵——P、L 和 U。第 5 行到第 7 行打印矩阵 P、L 和 U。从图 5 中可以清楚地看出,P 是一个置换矩阵,L 是一个下三角矩阵,U 是一个上三角矩阵。最后在第 8 行将这三个矩阵相乘并打印乘积矩阵。从图 5 可以看到乘积矩阵 P@L@U 等于原始矩阵 A,满足矩阵分解的性质。此外,图 5 也验证了矩阵 L、U 和 P 比矩阵 A 更稀疏。

图 5:用 SciPy 进行 LUP 分解

下面我们讨论特征分解,它是将一个方阵是用它的 特征值 eigenvalue 和 特征向量 eigenvector 来表示。用 Python 计算特征值和特征向量很容易。关于特征值和特征向量的理论解释超出了本文的讨论范围,如果你不知道它们是什么,我建议你通过维基百科等先了解它们,以便对正在执行的操作有一个清晰的概念。图 6 中是特征分解的代码。

图6:用 SciPy 进行特征分解

在图 6 中,第 1 行计算特征值和特征向量。第 2 行和第 3 行输出它们。注意,使用 NumPy 也能获得类似的效果,Lambda, Q = np.linalg.eig(A)。这也告诉我们 NumPy 和 SciPy 的功能之间有一些重叠。第 4 行重建了原始矩阵 A。第 4 行中的代码片段 np.diag(Lambda) 是将特征值转换为对角矩阵(记为 Λ)。对角矩阵是主对角线以外的所有元素都为 0 的矩阵。第 4 行的代码片段 sp.linalg.inv(Q) 是求 Q 的逆矩阵(记为 Q -1)。最后,将三个矩阵 Q、Λ、Q -1 相乘得到原始矩阵 A。也就是在特征分解中 A=QΛQ -1。

图 6 还显示了执行的代码的输出。红框标记的是特征值,用绿框标记的是特征向量,重构的矩阵 A 用蓝框标记。你可能会感到奇怪,输出中像 11.+0.j 这样的数字是什么呢?其中的 j 是虚数单位。11.+0.j 其实就是 11.0+0.0j,即整数 11 的复数形式。

现在让我们来看奇异值分解(SVD),它是特征分解的推广。图 7 显示了 SVD 的代码和输出。第 1 行将矩阵 A 分解为三个矩阵 U、S 和 V。第 2 行中的代码片段 np.diag(S) 将 S 转换为对角矩阵。最后,将这三个矩阵相乘重建原始矩阵 A。奇异值分解的优点是它可以对角化非方阵。但非方阵的奇异值分解的代码稍微复杂一些,我们暂时不在这里讨论它。

图 7:用 SciPy 进行 奇异值分解

其它人工智能和机器学习的 Python 库

当谈到人工智能时,普通人最先想到的场景可能就是电影《终结者》里机器人通过视觉识别一个人。 计算机视觉 computer vision 是人工智能和机器学习技术被应用得最广泛的领域之一。下面我将介绍两个计算机视觉相关的库:OpenCV 和 Matplotlib。OpenCV 是一个主要用于实时计算机视觉的库,它由 C 和 C++ 开发。C++ 是 OpenCV 的主要接口,它通过 OpenCV-Python 向用户提供 Python 接口。Matplotlib 是基于 Python 的绘图库。我曾在 OSFY 上的一篇早期 文章 中详细介绍了 Matplotlib 的使用。

前面我一直在强调矩阵的重要性,现在我用一个实际的例子来加以说明。图 8 展示了在 Jupyter Notebook 中使用 Matplotlib 读取和显示图像的代码和输出。如果你没有安装 Matplotlib,使用 pip install matplotlib 命令安装 Matplotlib。

图 8:用 Matplotlib 读取和显示图像

在图 8 中,第 1 行和第 2 行从 Matplotlib 导入了一些函数。注意你可以从库中导入单个函数或包,而不用导入整个库。这两行是基本的 Python 代码。第 3 行从我的计算机中读取标题为 OSFY-Logo.jpg 的图像。我从 OSFY 门户网站的首页下载了这张图片。此图像高 80 像素,宽 270 像素。第 4 行和第 5 行在 Jupyter Notebook 窗口中显示图像。请注意图像下方用红框标记的两行代码,它的输出告诉我们变量 image 实际上是一个 NumPy 数组。具体来说,它是一个 80 x 270 x 3 的三维数组。

数组尺寸中的 80 x 270 就是图片的大小,这一点很容易理解。但是第三维度表示什么呢?这是因计算机像通常用 RGB 颜色模型来存储的彩色图。它有三层,分别用于表示红绿蓝三种原色。我相信你还记得学生时代的实验,把原色混合成不同的颜色。例如,红色和绿色混合在一起会得到黄色。在 RGB 模型中,每种颜色的亮度用 0 到 255 的数字表示。0 表示最暗,255 表示最亮。因此值为 (255,255,255) 的像素表示纯白色。

现在,执行代码 print(image), Jupyter Notebook 会将整个数组的一部分部分打印出来。你可以看到数组的开头有许多 255。这是什么原因呢?如果你仔细看 OSFY 的图标会发现,图标的边缘有很多白色区域,因此一开始就印了很多 255。顺便说一句,你还可以了解一下其他颜色模型,如 CMY、CMYK、HSV 等。

现在我们反过来从一个数组创建一幅图像。首先看图 9 中所示的代码。它展示了如何生成两个 3 x 3 的随机矩阵,它的元素是 0 到 255 之间的随机值。注意,虽然相同的代码执行了两次,但生成的结果是不同的。这是通过调用 NumPy 的伪随机数生成器函数 randint 实现的。实际上,我中彩票的几率都比这两个矩阵完全相等的几率大得多。

图 8:两个随机矩阵

接下来我们要生成一个形状为 512 x 512 x 3 的三维数组,然后将它转换为图像。为此我们将用到 OpenCV。注意,安装 OpenCV 命令是 pip install opencv-python。看下面的代码:

import cv2
img = np.random.randint(0, 256, size=(512, 512, 3))
cv2.imwrite('img.jpg', img)

第 1 行导入库 OpenCV。注意导入语句是 import cv2,这与大多数其他包的导入不同。第 3 行将矩阵 img 转换为名为 img.jpg 的图像。图 10 显示了由 OpenCV 生成的图像。在系统中运行这段代码,将图像将被保存在 Jupyter Notebook 的同一目录下。如果你查看这张图片的属性,你会看到它的高度是 512 像素,宽度是 512 像素。通过这些例子,很容易看出,任何处理计算机视觉任务的人工智能和机器学习程序使用了大量的数组、向量、矩阵以及线性代数中的思想。这也是本系列用大量篇幅介绍数组、向量和矩阵的原因。

图 10:OpenCV 生成的图像

最后,考虑下面显示的代码。image.jpg 输出图像会是什么样子?我给你两个提示。函数 zeros 在第 4 行和第 5 行创建了两个 512 x 512 的数组,其中绿色和蓝色填充了零。第 7 行到第 9 行用来自数组 red、green 和 blue 的值填充三维数组 img1。

import numpy as np
import cv2
red = np.random.randint(0, 256, size=(512, 512))
green = np.zeros([512, 512], dtype=np.uint8)
blue = np.zeros([512, 512], dtype=np.uint8)
img1 = np.zeros([512,512,3], dtype=np.uint8)
img1[:,:,0] = blue
img1[:,:,1] = green
img1[:,:,2] = red
cv2.imwrite(‘image.jpg’, img1)

本期的内容就到此结束了。在下一篇文章中,我们将开始简单地学习 张量 tensor ,然后安装和使用 TensorFlow。TensorFlow 是人工智能和机器学习领域的重要参与者。之后,我们将暂时放下矩阵、向量和线性代数,开始学习概率论。概率论跟线性代数一样是人工智能的重要基石。

(题图:MJ/ec8e9a02-ae13-4924-b6cb-74ef96ab8af9)


via: https://www.opensourceforu.com/2023/07/ai-a-few-more-useful-python-libraries/

作者:Deepu Benson 选题:lujun9972 译者:toknow-gh 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

你好!我一直在投入写作一本关于 Git 的小册,因此我对 Git 分支投入了许多思考。我不断从他人那里听说他们觉得 Git 分支的操作方式违反直觉。这使我开始思考:直觉上的分支概念可能是什么样,以及它如何与 Git 的实际操作方式区别开来?

在这篇文章中,我想简洁地讨论以下几点内容:

  • 我认为许多人可能有的一个直觉性的思维模型
  • Git 如何在内部实现分支的表示(例如,“分支是对提交的指针”)
  • 这种“直觉模型”与实际操作方式之间的紧密关联
  • 直觉模型的某些局限性,以及为何它可能引发问题

本文无任何突破性内容,我会尽量保持简洁。

分支的直观模型

当然,人们对分支有许多不同的直觉。我自己认为最符合“苹果树的一个分支”这一物理比喻的可能是下面这个。

我猜想许多人可能会这样理解 Git 分支:在下图中,两个红色的提交就代表一个“分支”。

我认为在这个示意图中有两点很重要:

  1. 分支上有两个提交
  2. 分支有一个“父级”(main),它是这个“父级”的分支

虽然这个观点看似合理,但实际上它并不符合 Git 对于分支的定义 — 最重要的是,Git 并没有一个分支的“父级”的概念。那么,Git 又是如何定义分支的呢?

在 Git 里,分支是完整的历史

在 Git 中,一个分支是每个过去提交的完整历史记录,而不仅仅是那个“分支”提交。因此,在我们上述的示意图中,所有的分支(main 和 branch)都包含了 4 次提交。

我创建了一个示例仓库,地址为:https://github.com/jvns/branch-example。它设置的分支方式与前图一样。现在,我们来看看这两个分支:

main 分支包含了 4 次提交:

$ git log --oneline main
70f727a d
f654888 c
3997a46 b
a74606f a

mybranch 分支也有 4 次提交。最后两次提交在这两个分支里都存在。

$ git log --oneline mybranch
13cb960 y
9554dab x
3997a46 b
a74606f a

因此,mybranch 中的提交次数为 4,而不仅仅是 2 次“分支”提交,即 13cb960 和 9554dab。

你可以用以下方式让 Git 绘制出这两个分支的所有提交:

$ git log --all --oneline --graph
* 70f727a (HEAD -> main, origin/main) d
* f654888 c
| * 13cb960 (origin/mybranch, mybranch) y
| * 9554dab x
|/
* 3997a46 b
* a74606f a

分支以提交 ID 的形式存储

在 Git 的内部,分支会以一种微小的文本文件的形式存储下来,其中包含了一个提交 ID。这就是我一开始提及到的“技术上正确”的定义。这个提交就是分支上最新的提交。

我们来看一下示例仓库中 main 和 mybranch 的文本文件:

$ cat .git/refs/heads/main
70f727acbe9ea3e3ed3092605721d2eda8ebb3f4
$ cat .git/refs/heads/mybranch
13cb960ad86c78bfa2a85de21cd54818105692bc

这很好理解:70f727 是 main 上的最新提交,而 13cb96 是 mybranch 上的最新提交。

这样做的原因是,每个提交都包含一种指向其父级的指针,所以 Git 可以通过追踪这些指针链来找到分支上所有的提交。

正如我前文所述,这里遗漏的一个重要因素是这两个分支间的任何关联关系。从这里能看出,mybranch 是 main 的一个分支——这一点并没有被表明出来。

既然我们已经探讨了直观理解的分支概念是如何不成立的,我接下来想讨论的是,为何它在某些重要的方面又是如何成立的。

人们的直观感觉通常并非全然错误

我发现,告诉人们他们对 Git 的直觉理解是“错误的”的说法颇为流行。我觉得这样的说法有些可笑——总的来说,即使人们关于某个题目的直觉在某些方面在技术上不精确,但他们通常会有完全合理的理由来支持他们的直觉!即使是“不正确的”模型也可能极其有用。

现在,我们来讨论三种情况,其中直觉上的“分支”概念与我们实际在操作中如何使用 Git 非常相符。

变基操作使用的是“直观”的分支概念

现在,让我们回到最初的图片。

当你在 main 上对 mybranch 执行 变基 rebase 操作时,它将取出“直观”分支上的提交(只有两个红色的提交)然后将它们应用到 main 上。

执行结果就是,只有两次提交(x 和 y)被复制。以下是相关操作的样子:

$ git switch mybranch
$ git rebase main
$ git log --oneline mybranch
952fa64 (HEAD -> mybranch) y
7d50681 x
70f727a (origin/main, main) d
f654888 c
3997a46 b
a74606f a

在此,git rebase 创建了两个新的提交(952fa64 和 7d50681),这两个提交的信息来自之前的两个 x 和 y 提交。

所以直觉上的模型并不完全错误!它很精确地告诉你在变基中发生了什么。

但因为 Git 不知道 mybranch 是 main 的一个分叉,你需要显式地告诉它在何处进行变基。

合并操作也使用了“直观”的分支概念

合并操作并不复制提交,但它们确实需要一个“ 基础 base ”提交:合并的工作原理是查看两组更改(从共享基础开始),然后将它们合并。

我们撤销刚才完成的变基操作,然后看看合并基础是什么。

$ git switch mybranch
$ git reset --hard 13cb960  # 撤销 rebase
$ git merge-base main mybranch
3997a466c50d2618f10d435d36ef12d5c6f62f57

这里我们获得了分支分离出来的“基础”提交,也就是 3997a4。这正是你可能会基于我们的直观图片想到的提交。

GitHub 的拉取请求也使用了直观的概念

如果我们在 GitHub 上创建一个拉取请求,打算将 mybranch 合并到 main,这个请求会展示出两次提交:也就是 x 和 y。这完全符合我们的预期,也和我们对分支的直观认识相符。

我想,如果你在 GitLab 上发起一个合并请求,那显示的内容应该会与此类似。

直观理解颇为精准,但它有一定局限性

这使我们的对分支直观定义看起来相当准确!这个“直观”的概念和合并、变基操作以及 GitHub 拉取请求的工作方式完全吻合。

当你在进行合并、变基或创建拉取请求时,你需要明确指定另一个分支(如 git rebase main),因为 Git 不知道你的分支是基于哪个分支的。

然而,关于分支的直观理解有一个比较严重的问题:你直觉上认为 main 分支和某个分离的分支有很大的区别,但 Git 并不清楚这点。

所以,现在我们要来讨论一下 Git 分支的不同种类。

主干和派生分支

对于人类来说,main 和 mybranch 有着显著的区别,你可能针对如何使用它们,有着截然不同的意图。

通常,我们会将某些分支视为“ 主干 trunk ”分支,同时将其他一些分支看作是“派生”。你甚至可能有派生的派生分支。

当然,Git 自身并没有这样的区分(“派生”是我刚刚构造的术语!),但是分支的种类确实会影响你如何处理它。

例如:

  • 你可能会想将 mybranch 变基到 main,但你大概不会想将 main 变基到 mybranch —— 那就太奇怪了!
  • 一般来说,人们在重写“主干”分支的历史时比短期存在的派生分支更为谨慎。

Git 允许你进行“反向”的变基

我认为人们经常对 Git 感到困惑的一点是 —— 由于 Git 并没有分支是否是另一个分支的“派生”的概念,它不会给你任何关于何时合适将分支 X 变基到分支 Y 的指引。这一切需要你自己去判断。

例如,你可以执行以下命令:

$ git checkout main
$ git rebase mybranch

或者

$ git checkout mybranch
$ git rebase main

Git 将会欣然允许你进行任一操作,尽管在这个案例中 git rebase main 是极其正常的,而 git rebase mybranch 则显得格外奇怪。许多人表示他们对此感到困惑,所以我提供了一个展示两种变基类型的图片以供参考:

相似地,你可以进行“反向”的合并,尽管这相较于反向变基要正常得多——将 mybranch 合并到 main 和将 main 合并到 mybranch 都有各自的益处。

下面是一个展示你可以进行的两种合并方式的示意图:

Git 对于分支之间缺乏层次结构感觉有些奇怪

我经常听到 “main 分支没什么特别的” 的表述,而这令我感到困惑——对于我来说,我处理的大部分仓库里,main 无疑是非常特别的!那么人们为何会称其为不特别呢?

我觉得,重点在于:尽管分支确实存在彼此间的关系(main 通常是非常特别的!),但 Git 并不知情这些关系。

每当你执行如 git rebase 或 git merge 这样的 git 命令时,你都必须明确地告诉 Git 分支间的关系,如果你出错,结果可能会相当混乱。

我不知道 Git 在此方面的设计究竟“对”还是“错”(无疑它有利有弊,而我已对无休止的争论感到厌倦),但我认为,这对于许多人来说,原因在于它有些出人意料。

Git 关于分支的用户界面也同样怪异

假设你只想查看某个分支上的“派生”提交,正如我们之前讨论的,这是完全正常的需求。

下面是用 git log 查看我们分支上的两次派生提交的方法:

$ git switch mybranch
$ git log main..mybranch --oneline
13cb960 (HEAD -> mybranch, origin/mybranch) y
9554dab x

你可以用 git diff 这样查看同样两次提交的合并差异:

$ git diff main...mybranch

因此,如果你想使用 git log 查看 x 和 y 这两次提交,你需要用到两个点(..),但查看同样的提交使用 git diff,你却需要用到三个点(...)。

我个人从来都记不住 .. 和 ... 的具体用意,所以我通常虽然它们在原则上可能很有用,但我选择尽量避免使用它们。

在 GitHub 上,默认分支具有特殊性

同样值得一提的是,在 GitHub 上存在一种“特殊的分支”:每一个 GitHub 仓库都有一个“默认分支”(在 Git 术语中,就是 HEAD 所指向的地方),具有以下的特别之处:

  • 初次克隆仓库时,默认会检出这个分支
  • 它作为拉取请求的默认接收分支
  • GitHub 建议应该保护这个默认分支,防止被强制推送,等等。

很可能还有许多我未曾想到的场景。

总结

这些说法在回顾时看似是显而易见的,但实际上我花费了大量时间去搞清楚一个更“直观”的分支概念,这是因为我已经习惯了技术性的定义,“分支是对某次提交的引用”。

同样,我也没有真正去思索过如何在每次执行 git rebase 或 git merge 命令时,让 Git 明确理解你分支之间的层次关系——对我而言,这已经成为第二天性,并没有觉得有何困扰。但当我反思这个问题时,可以明显看出,这很容易导致某些人混淆。

(题图:MJ/a5a52832-fac8-4190-b3bd-fec70166aa16)


via: https://jvns.ca/blog/2023/11/23/branches-intuition-reality/

作者:Julia Evans 选题:lujun9972 译者:ChatGPT 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

为何选择文字用户界面(TUI)?

许多人每日都在使用终端,因此, 文字用户界面 Text User Interface (TUI)逐渐显示出其价值。它能减少用户输入命令时的误差,让终端操作更高效,提高生产力。

以我的个人使用情况为例:我每日会通过家用电脑远程连接到我使用 Linux 系统的实体 PC。所有的远程网络连接都通过私有 VPN 加密保护。然而,当我需要频繁重复输入命令进行连接时,这种经历实在令人烦躁。

于是,我创建了下面这个 Bash 函数,从而有所改进:

export REMOTE_RDP_USER="myremoteuser"
function remote_machine() {
  /usr/bin/xfreerdp /cert-ignore /sound:sys:alsa /f /u:$REMOTE_RDP_USER /v:$1 /p:$2
}

但后来,我发现自己还是频繁地执行下面这条命令(在一行中):

remote_pass=(/bin/cat/.mypassfile) remote_machine $remote_machine $remote_pass

这太烦了。更糟糕的是,我的密码被明文存储在我的电脑上(我虽然使用了加密驱动器,但这点依然令人不安)。

因此,我决定投入一些时间,编写一个实用的脚本,从而更好地满足我的基本需求。

我需要哪些信息才能连接到远程桌面?

实际上,要连接到远程桌面,你只需提供少量信息。这些信息需要进行结构化处理,所以一个简单的 JSON 文件就能够满足要求:

{"machines": [
  {
  "name": "machine1.domain.com",
  "description": "Personal-PC"
  },
  {
  "name": "machine2.domain.com",
  "description": "Virtual-Machine"
  }
  ],
"remote_user": "MYUSER@DOMAIN",
"title" : "MY COMPANY RDP connection"
}

尽管在各种配置文件格式中,JSON 并非最佳选择(例如,它不支持注解),但是 Linux 提供了许多工具通过命令行方式解析 JSON 内容。其中,特别值得一提的工具就是 jq。下面我要向你展示如何利用它来提取机器列表:

/usr/bin/jq --compact-output --raw-output '.machines[]| .name' \
  $HOME/.config/scripts/kodegeek_rdp.json) \
  "machine1.domain.com" "machine2.domain.com"

jq 的文档可以在 这里 找到。另外,你也可以直接将你的 JSON 文件复制粘贴到 jq play,试用你的表达式,然后在你的脚本中使用这些表达式。

既然已经准备好了连接远程计算机所需的所有信息,那现在就让我们来创建一个美观实用的 TUI 吧。

Dialog 的帮助

Dialog 是那些你可能希望早些认识的、被低评估的 Linux 工具之一。你可以利用它构建出一个井然有序、简介易懂,并且完美适用于你终端的用户界面。

比如,我可以创建一个包含我喜欢的编程语言的简单的复选框列表,且默认选择 Python:

dialog --clear --checklist "Favorite programming languages:" 10 30 7\
  1 Python on 2 Java off 3 Bash off 4 Perl off 5 Ruby off

我们通过这条命令向 dialog 下达了几个指令:

  • 清除屏幕(所有选项都以 -- 开头)
  • 创建一个带有标题的复选框(第一个位置参数)
  • 决定窗口尺寸(高度、宽度和列表高度,共 3 个参数)
  • 列表中的每条选项都由一个标签和一个值组成。

惊人的是,仅仅一行代码,就带来了简洁直观和视觉友好的选择列表。

关于 dialog 的详细文档,你可以在 这里 阅读。

整合所有元素:使用 Dialog 和 JQ 编写 TUI

我编写了一个 TUI,它使用 jq 从我的 JSON 文件中提取配置详细信息,并且使用 dialog 来组织流程。每次运行,我都会要求输入密码,并将其保存在一个临时文件中,脚本使用后便会删除这个临时文件。

这个脚本非常基础,但它更安全,也使我能够专注于更重要的任务 ?

那么 脚本 看起来是怎样的呢?下面是代码:

#!/bin/bash
# Author Jose Vicente Nunez
# Do not use this script on a public computer. It is not secure...
# https://invisible-island.net/dialog/
# Below some constants to make it easier to handle Dialog
# return codes
: ${DIALOG_OK=0}
: ${DIALOG_CANCEL=1}
: ${DIALOG_HELP=2}
: ${DIALOG_EXTRA=3}
: ${DIALOG_ITEM_HELP=4}
: ${DIALOG_ESC=255}
# Temporary file to store sensitive data. Use a 'trap' to remove
# at the end of the script or if it gets interrupted
declare tmp_file=$(/usr/bin/mktemp 2>/dev/null) || declare tmp_file=/tmp/test$$
trap "/bin/rm -f $tmp_file" QUIT EXIT INT
/bin/chmod go-wrx ${tmp_file} > /dev/null 2>&1
:<<DOC
Extract details like title, remote user and machines using jq from the JSON file
Use a subshell for the machine list
DOC
declare TITLE=$(/usr/bin/jq --compact-output --raw-output '.title' $HOME/.config/scripts/kodegeek_rdp.json)|| exit 100
declare REMOTE_USER=$(/usr/bin/jq --compact-output --raw-output '.remote_user' $HOME/.config/scripts/kodegeek_rdp.json)|| exit 100
declare MACHINES=$(
    declare tmp_file2=$(/usr/bin/mktemp 2>/dev/null) || declare tmp_file2=/tmp/test$$
    # trap "/bin/rm -f $tmp_file2" 0 1 2 5 15 EXIT INT
    declare -a MACHINE_INFO=$(/usr/bin/jq --compact-output --raw-output '.machines[]| join(",")' $HOME/.config/scripts/kodegeek_rdp.json > $tmp_file2)
    declare -i i=0
    while read line; do
        declare machine=$(echo $line| /usr/bin/cut -d',' -f1)
        declare desc=$(echo $line| /usr/bin/cut -d',' -f2)
        declare toggle=off
        if [ $i -eq 0 ]; then
            toggle=on
            ((i=i+1))
        fi
        echo $machine $desc $toggle
    done < $tmp_file2
    /bin/cp /dev/null $tmp_file2
) || exit 100
# Create a dialog with a radio list and let the user select the
# remote machine
/usr/bin/dialog \
    --clear \
    --title "$TITLE" \
    --radiolist "Which machine do you want to use?" 20 61 2 \
    $MACHINES 2> ${tmp_file}
return_value=$?
# Handle the return codes from the machine selection in the
# previous step
export remote_machine=""
case $return_value in
  $DIALOG_OK)
    export remote_machine=$(/bin/cat ${tmp_file})
    ;;
  $DIALOG_CANCEL)
    echo "Cancel pressed.";;
  $DIALOG_HELP)
    echo "Help pressed.";;
  $DIALOG_EXTRA)
    echo "Extra button pressed.";;
  $DIALOG_ITEM_HELP)
    echo "Item-help button pressed.";;
  $DIALOG_ESC)
    if test -s $tmp_file ; then
      /bin/rm -f $tmp_file
    else
      echo "ESC pressed."
    fi
    ;;
esac

# No machine selected? No service ...
if [ -z "${remote_machine}" ]; then
  /usr/bin/dialog \
        --clear  \
        --title "Error, no machine selected?" --clear "$@" \
        --msgbox "No machine was selected!. Will exit now..." 15 30
  exit 100
fi

# Send 4 packets to the remote machine. I assume your network
# administration allows ICMP packets
# If there is an error show  message box
/bin/ping -c 4 ${remote_machine} >/dev/null 2>&1
if [ $? -ne 0 ]; then
  /usr/bin/dialog \
        --clear  \
        --title "VPN issues or machine is off?" --clear "$@" \
        --msgbox "Could not ping ${remote_machine}. Time to troubleshoot..." 15 50
  exit 100
fi

# Remote machine is visible, ask for credentials and handle user
# choices (like password with a password box)
/bin/rm -f ${tmp_file}
/usr/bin/dialog \
  --title "$TITLE" \
  --clear  \
  --insecure \
  --passwordbox "Please enter your Windows password for ${remote_machine}\n" 16 51 2> $tmp_file
return_value=$?
case $return_value in
  $DIALOG_OK)
    # We have all the information, try to connect using RDP protocol
    /usr/bin/mkdir -p -v $HOME/logs
    /usr/bin/xfreerdp /cert-ignore /sound:sys:alsa /f /u:$REMOTE_USER /v:${remote_machine} /p:$(/bin/cat ${tmp_file})| \
    /usr/bin/tee $HOME/logs/$(/usr/bin/basename $0)-$remote_machine.log
    ;;
  $DIALOG_CANCEL)
    echo "Cancel pressed.";;
  $DIALOG_HELP)
    echo "Help pressed.";;
  $DIALOG_EXTRA)
    echo "Extra button pressed.";;
  $DIALOG_ITEM_HELP)
    echo "Item-help button pressed.";;
  $DIALOG_ESC)
    if test -s $tmp_file ; then
      /bin/rm -f $tmp_file
    else
      echo "ESC pressed."
    fi
    ;;
esac

你从代码中可以看出,dialog 预期的是位置参数,并且允许你在变量中捕获用户的回应。这实际上使其成为编写文本用户界面的 Bash 扩展。

上述的小例子只涵盖了一些部件的使用,其实还有更多的文档在 官方 dialog 网站上。

Dialog 和 JQ 是最好的选择吗?

实现这个功能可以有很多方法(如 Textual,Gnome 的 Zenity,Python 的 TKinker等)。我只是想向你展示一种高效的方式——仅用 100 行代码就完成了这项任务。

确实,它并不完美。更具体地讲,它与 Bash 的深度集成使得代码有些冗长,但仍然保持了易于调试和维护的特性。相比于反复复制粘贴长长的命令,这无疑是一个更好的选择。

最后,如果你喜欢在 Bash 中使用 jq 处理 JSON,那么你会对这个 jq 配方的精彩集合 感兴趣的。

(题图:MJ/a9b7f60a-02ec-4d3f-88ae-2321f49ac0e1)


via: https://fedoramagazine.org/writing-useful-terminal-tui-on-linux-with-dialog-and-jq/

作者:Jose Nunez 选题:lujun9972 译者:ChatGPT 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

这 12 项基本原则能够帮助团队快速高效地构建高度可扩展的应用程序

12-Factor 应用方法论 为在短时间内构建应用程序并使其具有可扩展性提供了指导。它由 Heroku 的开发人员创建,用于软件即服务(SaaS)应用程序、网络应用程序以及可能的通信平台即服务(CPaaS)。在有效组织项目和管理可扩展应用程序方面,12 要素应用程序方法论对开源开发具有强大的优势。

12-Factor 应用方法论的原则

12-Factor 应用方法论的规则非常严格,也是开发和部署 SaaS 应用程序的基石,并且不受任何编程语言或数据库的限制。

1:一份基准代码,多份部署

 title=

每个应用程序都应该有一个具有多个不同环境/部署的代码库。

开发人员不应仅仅为了在不同环境中设置而开发另一个代码库。不同的环境代表不同的状态,但这些不同的环境应该共享同一个代码库。

在许多开源项目都存储在 GitLab 这样的版本控制系统中的情况下,一个环境可以被视为一个分支。例如,你可以在任何中央版本控制系统中为名为 VoIP-app 的云 VoIP 应用程序创建一个单独的存储库,然后创建两个分支:开发分支(development)和暂存分支(staging),并将主分支(master)作为发布分支。

2:明确声明和隔离依赖关系

应声明所有依赖关系。你的应用程序可能会依赖外部系统工具或库,但不应对系统工具或库有任何 隐含的 依赖。你的应用程序必须始终明确声明所有依赖关系及其正确版本。

在代码库中包含依赖关系可能会产生问题,特别是在开源项目中,外部库的更改可能会将错误引入代码库。例如,代码库可能会使用一个外部库,但没有明确声明该依赖关系或版本。如果外部库更新到更新的、未经测试的版本,这可能会与你的代码产生兼容性问题。如果明确声明了依赖关系及其正确版本,你的代码库就不会出现这种问题。

根据技术栈的不同,最好使用软件包管理器,通过读取代表依赖库名称和版本的依赖库声明清单,在各自的系统上下载依赖库。

3:在环境中存储配置

当需要支持多个环境或客户端时,配置就成了应用程序的重要组成部分。不同部署之间的配置应存储在环境变量中。这样就可以在部署之间轻松更改配置,而无需更改代码。

对于闭源应用程序来说,这一原则是有益的,因为你不会希望数据库连接信息或其他秘密数据等敏感信息被公开。然而,在开放源代码开发中,这些细节都是公开的。在这种情况下,好处是你不需要反复修改代码。你只需这样设置变量,只需改变环境,就能让代码完美运行。

4:把后端服务当作附加资源

所有后备服务(如数据库、外部存储或消息队列)都被视为附加资源,由执行环境附加或分离。根据这一原则,如果这些服务的位置或连接细节发生变化,仍无需更改代码。这些细节可以在配置中找到。

备份服务可以从部署中快速附加或分离。例如,如果基于云的电子表格的数据库无法正常工作,开发人员应该能够创建一个从最近备份恢复的新数据库服务器,而无需对代码库进行任何更改。

5:严格分离构建和运行

12-Factor 应用方法论要求严格区分构建、发布和运行阶段。

  • 第一阶段是 构建 阶段。在这一阶段,源代码被组装或编译成可执行文件,同时加载依赖关系并创建资产。每次需要部署新代码时,构建阶段就会开始。
  • 第二阶段是 发布 阶段。在此阶段,构建阶段生成的代码与部署的当前配置相结合。最终发布的版本包含构建和配置,可在执行环境中立即执行。
  • 第三个阶段是 运行 阶段,也是最后阶段:应用程序在执行环境中运行。该阶段不应被其他任何阶段打断。

通过严格区分这些阶段,我们可以避免代码中断,使系统维护更加易于管理。

6:以一个或多个无状态进程运行应用

应用程序作为一个或多个进程的集合在执行环境中执行。这些进程是无状态的,其持久化数据存储在数据库等后台服务中。

这对开源非常有用,因为使用某版本应用程序的开发人员可以在其云平台上创建多节点部署,以实现可扩展性。数据不会在其中持久化,因为如果其中任何一个节点崩溃,数据就会丢失。

7:通过端口绑定提供服务

你的应用程序应作为独立的服务,独立于其他应用程序。它它应该能通过URL供其他服务访问,以服务形式存在。这样,你的应用程序就可以在需要时作为其他应用程序的资源。利用这一概念,你可以构建 REST API。

8:通过进程模型进行扩展

该原则也称为并发原则,它表明应用程序中的每个进程都应能够自我扩展、重启或克隆。

开发人员可以创建多个进程,并将应用程序的负载分配给这些进程,而不是将一个进程变大。通过这种方法,你可以将每种工作负载分配给一个进程类型,从而构建能处理不同工作负载的应用程序。

9:快速启动和优雅终止以增强健壮性

你的应用应当基于简单的进程构建,因此开发者可以放大进程的同时还能在发生问题时重启它们。这使得应用的进程易于丢弃。

根据这一原则构建应用程序意味着代码的快速部署、快速弹性扩展、更灵活的发布流程以及稳健的生产部署。所有这些在开源开发环境中都非常有用。

10:尽可能的保持开发、预发布、生产环境相同

同一项目的团队应使用相同的操作系统、支持服务和依赖关系。这样可以降低出现错误的可能性,减少开发所需的时间。

由于开源项目的开发人员分散在各地,他们可能无法就所使用的系统、服务和依赖关系进行 沟通 ,因此将这一原则付诸实践对于开源项目来说可能是一个挑战。减少这些差异的一种可能性是制定开发指南,建议使用何种操作系统、服务和依赖关系。

11:把日志当作事件流

日志对于排除生产问题或了解用户行为至关重要。但是,12-Factor 应用方法论并不适合处理日志的管理。

相反,应将日志条目作为事件流,写入标准输出,并将其发送到单独的服务进行分析和存档。机器人流程自动化(RPA)技术可作为处理和分析日志的第三方服务。执行环境将决定如何处理该数据流。这为反省应用程序的行为提供了更大的灵活性和能力。

12:后台管理任务当作一次性进程运行

这一原则实际上与开发无关,而是与应用程序管理有关。管理进程应在与应用程序常规长期运行进程相同的环境中运行。在本地部署中,开发人员可以直接使用应用程序签出目录内的 Shell 命令来执行一次性管理进程。

结论

使用 12-Factor 应用方法论开发应用程序,可以提高效率,加快发布速度。在开源开发中,偏离某些指导原则可能是有意义的,但最好还是尽可能严格遵守这些指导原则。

开源的 12-Factor 应用是可能的。一个很好的例子是 Jitsi, (一个开源视频会议平台), 在疫情期间扩展了 100 倍的规模,取得了巨大成功,它就是采用 12-Factor 应用方法论构建的。

(题图:MJ/4bc8b463-49d0-4702-8ad3-6a07a718d5d9)


via: https://opensource.com/article/21/11/open-source-12-factor-app-methodology

作者:Richard Conn 选题:lujun9972 译者:trisbestever 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

大家好!几天前,我尝试向其他人解释 Git 遴选(git cherry-pick)的工作原理,结果发现自己反而更混淆了。

我原先以为 Git 遴选是简单地应用一个补丁,但当我真正这样尝试时,却未能成功!

因此,接下来我们将谈论我原来以为的遴选操作(即应用一个补丁),这个理解为何不准确,以及实际上它是如何执行的(进行“三路合并”)。

尽管本文的内容有些深入,但你并不需要全部理解才能有效地使用 Git。不过,如果你(和我一样)对 Git 的内部运作感到好奇,那就跟我一起深入探讨一下吧!

遴选操作并不只是应用一个补丁

我先前理解的 git cherry-pick COMMIT_ID 的步骤如下:

  • 首先是计算 COMMIT_ID 的差异,就如同执行 git show COMMIT_ID --patch > out.patch 这个命令
  • 然后是将补丁应用到当前分支,就如同执行 git apply out.patch 这个命令

在我们详细讨论之前,我想指出的是,虽然大部分情况下这个模型是正确的,如果这是你的认知模型,那就没有问题。但是在一些细微的地方,它可能会错,我觉得这个疑惑挺有意思的,所以我们来看看它究竟是如何运作的。

如果我在存在合并冲突的情况下尝试进行“计算差异并应用补丁”的操作,下面我们就看看具体会发生什么情况:

$ git show 10e96e46 --patch > out.patch
$ git apply out.patch
error: patch failed: content/post/2023-07-28-why-is-dns-still-hard-to-learn-.markdown:17
error: content/post/2023-07-28-why-is-dns-still-hard-to-learn-.markdown: patch does not apply

这一过程无法成功完成,它并未提供任何解决冲突或处理问题的方案。

而真正运行 git cherry-pick 时的实际情况却大为不同,我遭遇到了一处合并冲突:

$ git cherry-pick 10e96e46
error: could not apply 10e96e46... wip
hint: After resolving the conflicts, mark them with
hint: "git add/rm <pathspec>", then run
hint: "git cherry-pick --continue".

因此,看起来 “Git 正在应用一个补丁”这样的理解方式并不十分准确。但这里的错误信息确实标明了 “无法应用 10e96e46”,这么看来,这种理解又不完全是错的。这到底是怎么回事呢?

那么,遴选到底是怎么执行的呢?

我深入研究了 Git 的源代码,主要是想了解 cherry-pick 是如何工作的,最终我找到了 这一行代码:

res = do_recursive_merge(r, base, next, base_label, next_label, &head, &msgbuf, opts);

所以,遴选实际上就是一种……合并操作?这有些出乎意料。那具体都合并了什么内容?如何执行这个合并操作的呢?

我意识到我对 Git 的合并操作并不是特别理解,于是我上网搜索了一下。结果发现 Git 实际上采用了一种被称为 “三路合并” 的合并方式。那这到底是什么含义呢?

Git 的合并策略:三路合并

假设我要合并下面两个文件,我们将其分别命名为 v1.py 和 v2.py。

def greet():
    greeting = "hello"
    name = "julia"
    return greeting + " " + name
def say_hello():
    greeting = "hello"
    name = "aanya"
    return greeting + " " + name

在这两个文件间,存在两处不同:

  • def greet() 和 def say_hello
  • name = "julia" 和 name = "aanya"

我们应该选择哪个呢?看起来好像不可能有答案!

不过,如果我告诉你,原始的函数(我们称之为 base.py)是这样的:

def say_hello():
    greeting = "hello"
    name = "julia"
    return greeting + " " + name

一切似乎变得清晰许多!在这个基础上,v1 将函数的名字更改为 greet,v2 将 name = "aanya"。因此,合并时,我们应该同时做出这两处改变:

def greet():
    greeting = "hello"
    name = "aanya"
    return greeting + " " + name

我们可以命令 Git 使用 git merge-file 来完成这次合并,结果正是我们预期的:它选择了 def greet() 和 name = "aanya"。

$ git merge-file v1.py base.py v2.py -p
def greet():
    greeting = "hello"
    name = "aanya"
    return greeting + " " + name⏎

这种将两个文件与其原始版本进行合并的方式,被称为 三路合并。

如果你想在线上试一试,我在 jvns.ca/3-way-merge/ 创建了一个小实验场。不过我只是草草制作,所以可能对移动端并不友好。

Git 合并的是更改,而非文件

我对三路合并的理解是 —— Git 合并的是更改,而不是文件。我们对同一个文件做出两种不同的更改,Git 试图以合理的方式将这两种更改结合到一起。当两个更改都对同一行进行操作时,Git 可能会遇到困难,此时就会产生合并冲突。

Git 也可以合并超过两处的更改:你可以对同一文件有多达 8 处不同的更改,Git 会尝试将所有更改协调一致。这被称为八爪鱼合并,但除此之外我对其并不了解,因为我从未执行过这样的操作。

Git 如何使用三路合并来应用补丁

接下来,让我们进入到一个有些出乎意料的情境!当我们讨论 Git “应用补丁”(如在变基 —— rebase、撤销 —— revert 或遴选 —— cherry-pick 中所做的)时,其实并非是生成一个补丁文件并应用它。相反,实际执行的是一次三路合并。

下面是如何将提交 X 作为补丁应用到你当前的提交,并与之前的 v1、v2 和 base 设置相对应:

  1. 在你当前提交中,文件的版本是 v1。
  2. 在提交 X 之前,文件的版本是 base。
  3. 在提交 X 中,文件的版本是 v2。
  4. 执行 git merge-file v1 base v2 以合并它们(实际上,Git 并不直接执行 git merge-file,而是运行一个实现这个功能的 C 函数)。

总的来说,你可以将 base 和 v2 视为“补丁”,它们之间的差异就是你想要应用到 v1 上的更改。

遴选如何运作

假设我们有如下提交图,并且我们打算在 main 分支上遴选提交 Y:

A - B (main)
  \ 
   \ 
    X - Y - Z

那么,如何将此情景转化为我们前面提过的 v1、v2 和 base 组成的三路合并呢?

  • B 是 v1
  • X 是 base,而 Y 是 v2

所以,X 和 Y 共同构成了这个“补丁”。

其实,git rebase 无非就是重复多次执行 git cherry-pick 的过程。

撤销如何运作

现在,假如我们希望在如下的提交图上执行 git revert Y:

X - Y - Z - A - B
  • B 是 v1
  • Y 是 base,而 X 是 v2

这个过程反映的实际上就是遴选的情况,不过 X 和 Y 的位置颠倒了。我们需要这样做因为我们期望生成一个“反向补丁”。在 Git 中,撤销和遴选关系如此的紧密,它们甚至在同一个文件中实现:revert.c。

“三路补丁”是一个非常棒的技巧

使用三路合并将提交作为补丁应用的这个技巧非常巧妙且酷炫,我很惊讶之前从未听说过!我并未听过一个特定的名字来描述这种方法,但我更倾向于称之为“三路补丁”。

“三路补丁”的理念在于,你可以通过两个文件来定义补丁:在应用补丁前后的文件(在我们这篇文章中称之为 base 和 v2)。

因此,总体来看有三个文件被涉及到:一个是原文件,另外两个构成了补丁。

最重要的是,与普通补丁相比,三路补丁是一个更加高效的补丁方案,因为在有两个完整文件的情况下,你拥有更丰富的上下文信息来进行合并。

以下是我们例子中的常规补丁的大致情况:

@@ -1,1 +1,1 @@:
- def greet():
+ def say_hello():
    greeting = "hello"

而下面这就是一个三路补丁。不过,需要提醒的是这个“三路补丁”并不是一个真正的文件格式,这只是我自己提出的一种概念。

BEFORE: (the full file)
def greet():
    greeting = "hello"
    name = "julia"
    return greeting + " " + name
AFTER: (the full file)
def say_hello():
    greeting = "hello"
    name = "julia"
    return greeting + " " + name

《Building Git》 中提到了这点

James Coglan 的书籍 《Building Git》 是我在 Git 源码之外唯一找到的地方,他解释了 git cherry-pick 是如何在底层运用三路合并的(我原以为《Pro Git》可能会提及这个,但我并没能找到此话题的内容)。

我购买完这本书后发现,我早在 2019 年时就已经买过了,这对我来说真的是个很好的参考。

Git 中的合并实际上比这更复杂

在 Git 中,合并不限于三路合并 —— 还有一种我不太理解的叫做“递归合并”,还有许多具体处理文件删除和移动的细节,同时也有多种合并算法。

如果想要了解更多相关知识,我最好的建议是阅读《Building Git》,尽管我还未完全阅读这本书。

Git 应用到底做了什么?

我也参阅了 Git 的源代码,试图理解 git apply 的功能。它似乎(不出意外地)在 apply.c 中实现。这段代码解析了一个补丁文件,并通入目标文件来寻找应该在何处应用补丁。核心逻辑似乎在 这里:思路好像是从补丁建议的行数开始,然后向前向后找寻。

    /*
     * There's probably some smart way to do this, but I'll leave
     * that to the smart and beautiful people. I'm simple and stupid.
     */
    backwards = current;
    backwards_lno = line;
    forwards = current;
    forwards_lno = line;
    current_lno = line;
for (i = 0; ; i++) {
     ...

这个处理过程不禁让人觉得非常直白、与之前的期望相符。

Git 三路应用的工作方式

git apply 命令中也有一个 --3way 参数,可以实现三路合并。因此,我们实际上可以通过如下方式,使用 git apply 来大体实现 git cherry-pick 的功能:

$ git show 10e96e46 --patch > out.patch
$ git apply out.patch --3way
Applied patch to 'content/post/2023-07-28-why-is-dns-still-hard-to-learn-.markdown' with conflicts.
U content/post/2023-07-28-why-is-dns-still-hard-to-learn-.markdown

但要注意,参数 --3way 并不只用到了补丁文件的内容!补丁文件开始的部分是:

index d63ade04..65778fc0 100644

d63ade04 和 65778fc0 是旧/新文件版本在 Git 对象数据库中的 ID,因此 Git 可以用这些 ID 来执行三路补丁操作。但如果有人将补丁文件通过邮件发送给你,而你并没有新/旧版本的文件,就无法执行这个操作:如果你缺少 blob,将会出现如下错误:

$ git apply out.patch
error: repository lacks the necessary blob to perform 3-way merge.

三路合并有点历史了

有一部分人指出,三路合并比 Git 的历史还要久远,它起源于 70 年代末期左右。有一篇 2007 年的 论文 对此进行了讨论。

就说这么多!

我真的对于我对于 Git 内部应用补丁的核心方法其实理解得并不深入这一点感到非常吃惊——学习这一点真的很酷!

虽然我对 Git 用户界面存在 诸多不满,但是这个特定问题并不包含在内。三路合并似乎是统一解决一系列不同问题的优雅方式,它对于人们来说也很直观(“应用一个补丁”这个想法是许多编程者都习以为常的思考模式,而它底层实现为三路合并的细节,实际上没有人真正需要去思考)。

我顺便快速推荐一下:我正在写一部有关 Git 的 zine,如果你对它的发布感兴趣,你可以注册我非常不频繁的 公告邮件列表。

(题图:MJ/321bc2c9-4363-4661-802a-c74fb6a721b2)


via: https://jvns.ca/blog/2023/11/10/how-cherry-pick-and-revert-work/

作者:Julia Evans 选题:lujun9972 译者:ChatGPT 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

通过理解解释、即时编译和预先编译之间的区别,有效地使用它们。

Java 是一种跨平台的编程语言。程序源代码会被编译为 字节码 bytecode ,然后字节码在运行时被转换为 机器码 machine code 。 解释器 interpreter 在物理机器上模拟出的抽象计算机上执行字节码指令。 即时 just-in-time (JIT)编译发生在运行期,而 预先 ahead-of-time (AOT)编译发生在构建期。

本文将说明解释器、JIT 和 AOT 分别何时起作用,以及如何在 JIT 和 AOT 之间权衡。

源代码、字节码、机器码

应用程序通常是由 C、C++ 或 Java 等编程语言编写。用这些高级编程语言编写的指令集合称为源代码。源代码是人类可读的。要在目标机器上执行它,需要将源代码转换为机器可读的机器码。这个转换工作通常是由 编译器 compiler 来完成的。

然而,在 Java 中,源代码首先被转换为一种中间形式,称为字节码。字节码是平台无关的,所以 Java 被称为平台无关编程语言。Java 编译器 javac 将源代码转换为字节码。然后解释器解释执行字节码。

下面是一个简单的 Java 程序, Hello.java:

//Hello.java
public class Hello {
    public static void main(String[] args) {
         System.out.println("Inside Hello World!");
    }
}

使用 javac 编译它,生成包含字节码的 Hello.class 文件。

$ javac Hello.java
$ ls
Hello.class  Hello.java

现在,使用 javap 来反汇编 Hello.class 文件的内容。使用 javap 时如果不指定任何选项,它将打印基本信息,包括编译这个 .class 文件的源文件、包名称、公共和受保护字段以及类的方法。

$ javap Hello.class
Compiled from "Hello.java"
public class Hello {
    public Hello();
    public static void main(java.lang.String[]);
}

要查看 .class 文件中的字节码内容,使用 -c 选项:

$ javap -c Hello.class
Compiled from "Hello.java"
public class Hello {
  public Hello();
        Code:
           0: aload_0
           1: invokespecial #1                      // Method java/lang/Object."<init>":()V
           4: return

  public static void main(java.lang.String[]);
        Code:
           0: getstatic         #2                      // Field java/lang/System.out:Ljava/io/PrintStream;
           3: ldc               #3                      // String Inside Hello World!
           5: invokevirtual #4                      // Method    
java/io/PrintStream.println:(Ljava/lang/String;)V
           8: return
}

要获取更详细的信息,使用 -v 选项:

$ javap -v Hello.class

解释器,JIT 和 AOT

解释器负责在物理机器上模拟出的抽象计算机上执行字节码指令。当使用 javac 编译源代码,然后使用 java 执行时,解释器在程序运行时运行并完成它的目标。

$ javac Hello.java
$ java Hello
Inside Hello World!

JIT 编译器也在运行期发挥作用。当解释器解释 Java 程序时,另一个称为运行时 分析器 profiler 的组件将静默地监视程序的执行,统计各部分代码被解释的次数。基于这些统计信息可以检测出程序的 热点 hotspot ,即那些经常被解释的代码。一旦代码被解释次数超过设定的阈值,它们满足被 JIT 编译器直接转换为机器码的条件。所以 JIT 编译器也被称为分析优化的编译器。从字节码到机器码的转换是在程序运行过程中进行的,因此称为即时编译。JIT 减少了解释器将同一组指令模拟为机器码的负担。

AOT 编译器在构建期编译代码。在构建时将需要频繁解释和 JIT 编译的代码直接编译为机器码可以缩短 Java 虚拟机 Java Virtual Machine (JVM) 的 预热 warm-up 时间。(LCTT 译注:Java 程序启动后首先字节码被解释执行,此时执行效率较低。等到程序运行了足够的时间后,代码热点被检测出来,JIT 开始发挥作用,程序运行效率提升。JIT 发挥作用之前的过程就是预热。)AOT 是在 Java 9 中引入的一个实验性特性。jaotc 使用 Graal 编译器(它本身也是用 Java 编写的)来实现 AOT 编译。

以 Hello.java 为例:

//Hello.java
public class Hello {
    public static void main(String[] args) {
        System.out.println("Inside Hello World!");
    }
}


$ javac Hello.java
$ jaotc --output libHello.so Hello.class
$ java -XX:+UnlockExperimentalVMOptions -XX:AOTLibrary=./libHello.so Hello
Inside Hello World!

解释和编译发生的时机

下面通过例子来展示 Java 在什么时候使用解释器,以及 JIT 和 AOT 何时参与进来。这里有一个简单的程序 Demo.java :

//Demo.java
public class Demo {
    public int square(int i) throws Exception {
        return(i*i);
    }


    public static void main(String[] args) throws Exception {
        for (int i = 1; i <= 10; i++) {
            System.out.println("call " + Integer.valueOf(i));
            long a = System.nanoTime();
            Int r = new Demo().square(i);
            System.out.println("Square(i) = " + r);
            long b = System.nanoTime();
            System.out.println("elapsed= " + (b-a));
            System.out.println("--------------------------------");
        }
    }
}

在这个程序的 main() 方法中创建了一个 Demo 对象的实例,并调用该实例的 square()方法,然后显示 for 循环迭代变量的平方值。编译并运行它:

$ javac Demo.java
$ java Demo
1 iteration
Square(i) = 1
Time taken= 8432439
--------------------------------
2 iteration
Square(i) = 4
Time taken= 54631
--------------------------------
.
.
.
--------------------------------
10 iteration
Square(i) = 100
Time taken= 66498
--------------------------------

上面的结果是由谁产生的呢?是解释器,JIT 还是 AOT?在目前的情况下,它完全是通过解释产生的。我是怎么得出这个结论的呢?只有代码被解释的次数必须超过某个阈值时,这些热点代码片段才会被加入 JIT 编译队列。只有这时,JIT 编译才会发挥作用。使用以下命令查看 JDK 11 中的该阈值:

$ java -XX:+PrintFlagsFinal -version | grep CompileThreshold
 intx CompileThreshold     = 10000                                      {pd product} {default}
[...]
openjdk version "11.0.13" 2021-10-19
OpenJDK Runtime Environment 18.9 (build 11.0.13+8)
OpenJDK 64-Bit Server VM 18.9 (build 11.0.13+8, mixed mode, sharing)

上面的输出表明,一段代码被解释 10,000 次才符合 JIT 编译的条件。这个阈值是否可以手动调整呢?是否有 JVM 标志可以指示出方法是否被 JIT 编译了呢?答案是肯定的,而且有多种方式可以达到这个目的。

使用 -XX:+PrintCompilation 选项可以查看一个方法是否被 JIT 编译。除此之外,使用 -Xbatch 标志可以提高输出的可读性。如果解释和 JIT 同时发生,-Xbatch 可以帮助区分两者的输出。使用这些标志如下:

$ java -Xbatch  -XX:+PrintCompilation  Demo
         34        1        b  3           java.util.concurrent.ConcurrentHashMap::tabAt (22 bytes)
         35        2         n 0           jdk.internal.misc.Unsafe::getObjectVolatile (native)   
         35        3        b  3           java.lang.Object::<init> (1 bytes)
[...]
        210  269         n 0           java.lang.reflect.Array::newArray (native)   (static)
        211  270        b  3           java.lang.String::substring (58 bytes)
[...]
--------------------------------
10 iteration
Square(i) = 100
Time taken= 50150
--------------------------------

注意,上面命令的实际输出太长了,这里我只是截取了一部分。输出很长的原因是除了 Demo 程序的代码外,JDK 内部类的函数也被编译了。由于我的重点是 Demo.java 代码,我希望排除内部包的函数来简化输出。通过选项 -XX:CompileCommandFile 可以禁用内部类的 JIT:

$ java -Xbatch -XX:+PrintCompilation -XX:CompileCommandFile=hotspot_compiler Demo

在选项 -XX:CompileCommandFile 指定的文件 hotspot_compiler 中包含了要排除的包:

$ cat hotspot_compiler
quiet
exclude java/* *
exclude jdk/* *
exclude sun/* *

第一行的 quiet 告诉 JVM 不要输出任何关于被排除类的内容。用 -XX:CompileThreshold 将 JIT 阈值设置为 5。这意味着在解释 5 次之后,就会进行 JIT 编译:

$ java -Xbatch -XX:+PrintCompilation -XX:CompileCommandFile=hotspot_compiler \
-XX:CompileThreshold=5 Demo
        47      1       n 0     java.lang.invoke.MethodHandle::linkToStatic(LLLLLL)L (native)   
           (static)
        47      2       n 0     java.lang.invoke.MethodHandle::invokeBasic(LLLLL)L (native)   
        47      3       n 0     java.lang.invoke.MethodHandle::linkToSpecial(LLLLLLL)L (native)   
           (static)
        48      4       n 0     java.lang.invoke.MethodHandle::linkToStatic(L)I (native)   (static)
        48      5       n 0     java.lang.invoke.MethodHandle::invokeBasic()I (native)   
        48      6       n 0     java.lang.invoke.MethodHandle::linkToSpecial(LL)I (native)   
           (static)
[...]
        1 iteration
        69   40         n 0     java.lang.invoke.MethodHandle::linkToStatic(ILIIL)I (native)   
           (static)
[...]
Square(i) = 1
        78   48         n 0     java.lang.invoke.MethodHandle::linkToStatic(ILIJL)I (native)   
(static)
        79   49         n 0     java.lang.invoke.MethodHandle::invokeBasic(ILIJ)I (native)   
[...]
        86   54         n 0     java.lang.invoke.MethodHandle::invokeBasic(J)L (native)   
        87   55         n 0     java.lang.invoke.MethodHandle::linkToSpecial(LJL)L (native)   
(static)
Time taken= 8962738
--------------------------------
2 iteration
Square(i) = 4
Time taken= 26759
--------------------------------

10 iteration
Square(i) = 100
Time taken= 26492
--------------------------------

好像输出结果跟只用解释时并没有什么区别。根据 Oracle 的文档,这是因为只有禁用 TieredCompilation 时 -XX:CompileThreshold 才会生效:

$ java -Xbatch -XX:+PrintCompilation -XX:CompileCommandFile=hotspot_compiler \
-XX:-TieredCompilation -XX:CompileThreshold=5 Demo
124     1       n       java.lang.invoke.MethodHandle::linkToStatic(LLLLLL)L (native)   (static)
127     2       n       java.lang.invoke.MethodHandle::invokeBasic(LLLLL)L (native)   
[...]
1 iteration
        187   40        n       java.lang.invoke.MethodHandle::linkToStatic(ILIIL)I (native)   (static)
[...]
(native)   (static)
        212   54        n       java.lang.invoke.MethodHandle::invokeBasic(J)L (native)   
        212   55        n       java.lang.invoke.MethodHandle::linkToSpecial(LJL)L (native)   (static)
Time taken= 12337415
[...]
--------------------------------
4 iteration
Square(i) = 16
Time taken= 37183
--------------------------------
5 iteration
        214   56        b       Demo::<init> (5 bytes)
        215   57        b       Demo::square (16 bytes)
Square(i) = 25
Time taken= 983002
--------------------------------
6 iteration
Square(i) = 36
Time taken= 81589
[...]
10 iteration
Square(i) = 100
Time taken= 52393

可以看到在第五次迭代之后,代码片段被 JIT 编译了:

--------------------------------
5 iteration
        214   56        b       Demo::<init> (5 bytes)
        215   57        b       Demo::square (16 bytes)
Square(i) = 25
Time taken= 983002
--------------------------------

可以看到,与 square() 方法一起,构造方法也被 JIT 编译了。在 for 循环中调用 square() 之前要先构造 Demo 实例,所以构造方法的解释次数同样达到 JIT 编译阈值。这个例子说明了在解释发生之后何时 JIT 会介入。

要查看编译后的代码,需要使用 -XX:+PrintAssembly 标志,该标志仅在库路径中有反汇编器时才起作用。对于 OpenJDK,使用 hsdis 作为反汇编器。下载合适版本的反汇编程序库,在本例中是 hsdis-amd64.so,并将其放在 Java_HOME/lib/server 目录下。使用时还需要在 -XX:+PrintAssembly 之前增加 -XX:+UnlockDiagnosticVMOptions 选项。否则,JVM 会给你一个警告。

完整命令如下:

$ java -Xbatch -XX:+PrintCompilation -XX:CompileCommandFile=hotspot_compiler \ -XX:-TieredCompilation -XX:CompileThreshold=5 -XX:+UnlockDiagnosticVMOptions \ -XX:+PrintAssembly Demo
[...]
5 iteration
        178   56        b       Demo::<init> (5 bytes)
Compiled method (c2)    178   56                Demo::<init> (5 bytes)
 total in heap  [0x00007fd4d08dad10,0x00007fd4d08dafe0] = 720
 relocation     [0x00007fd4d08dae88,0x00007fd4d08daea0] = 24
[...]
 handler table  [0x00007fd4d08dafc8,0x00007fd4d08dafe0] = 24
[...]
 dependencies   [0x00007fd4d08db3c0,0x00007fd4d08db3c8] = 8
 handler table  [0x00007fd4d08db3c8,0x00007fd4d08db3f8] = 48
----------------------------------------------------------------------
Demo.square(I)I  [0x00007fd4d08db1c0, 0x00007fd4d08db2b8]  248 bytes
[Entry Point]
[Constants]
  # {method} {0x00007fd4b841f4b0} 'square' '(I)I' in 'Demo'
  # this:       rsi:rsi   = 'Demo'
  # parm0:      rdx     = int
  #             [sp+0x20]  (sp of caller)
[...]
[Stub Code]
  0x00007fd4d08db280: movabs $0x0,%rbx          ;   {no_reloc}
  0x00007fd4d08db28a: jmpq   0x00007fd4d08db28a  ;   {runtime_call}
  0x00007fd4d08db28f: movabs $0x0,%rbx          ;   {static_stub}
  0x00007fd4d08db299: jmpq   0x00007fd4d08db299  ;   {runtime_call}
[Exception Handler]
  0x00007fd4d08db29e: jmpq   0x00007fd4d08bb880  ;   {runtime_call ExceptionBlob}
[Deopt Handler Code]
  0x00007fd4d08db2a3: callq  0x00007fd4d08db2a8
  0x00007fd4d08db2a8: subq   $0x5,(%rsp)
  0x00007fd4d08db2ad: jmpq   0x00007fd4d08a01a0  ;   {runtime_call DeoptimizationBlob}
  0x00007fd4d08db2b2: hlt    
  0x00007fd4d08db2b3: hlt    
  0x00007fd4d08db2b4: hlt    
  0x00007fd4d08db2b5: hlt    
  0x00007fd4d08db2b6: hlt    
  0x00007fd4d08db2b7: hlt    
ImmutableOopMap{rbp=NarrowOop }pc offsets: 96
ImmutableOopMap{}pc offsets: 112
ImmutableOopMap{rbp=Oop }pc offsets: 148 Square(i) = 25
Time taken= 2567698
--------------------------------
6 iteration
Square(i) = 36
Time taken= 76752
[...]
--------------------------------
10 iteration
Square(i) = 100
Time taken= 52888

我只截取了输出中与 Demo.java 相关的部分。

现在再来看看 AOT 编译。它是在 JDK9 中引入的特性。AOT 是用于生成 .so 这样的库文件的静态编译器。用 AOT 可以将指定的类编译成 .so 库。这个库可以直接执行,而不用解释或 JIT 编译。如果 JVM 没有检测到 AOT 编译的代码,它会进行常规的解释和 JIT 编译。

使用 AOT 编译的命令如下:

$ jaotc --output=libDemo.so Demo.class

用下面的命令来查看共享库的符号表:

$ nm libDemo.so

要使用生成的 .so 库,使用 -XX:+UnlockExperimentalVMOptions 和 -XX:AOTLibrary:

$ java -XX:+UnlockExperimentalVMOptions -XX:AOTLibrary=./libDemo.so Demo
1 iteration
Square(i) = 1
Time taken= 7831139
--------------------------------
2 iteration
Square(i) = 4
Time taken= 36619
[...]
10 iteration
Square(i) = 100
Time taken= 42085

从输出上看,跟完全用解释的情况没有区别。为了确认 AOT 发挥了作用,使用 -XX:+PrintAOT:

$ java -XX:+UnlockExperimentalVMOptions -XX:AOTLibrary=./libDemo.so -XX:+PrintAOT Demo
         28        1         loaded        ./libDemo.so  aot library
         80        1         aot[ 1]   Demo.main([Ljava/lang/String;)V
         80        2         aot[ 1]   Demo.square(I)I
         80        3         aot[ 1]   Demo.<init>()V
1 iteration
Square(i) = 1
Time taken= 7252921
--------------------------------
2 iteration
Square(i) = 4
Time taken= 57443
[...]
10 iteration
Square(i) = 100
Time taken= 53586

要确认没有发生 JIT 编译,用如下命令:

$ java -XX:+UnlockExperimentalVMOptions -Xbatch -XX:+PrintCompilation \ -XX:CompileCommandFile=hotspot_compiler -XX:-TieredCompilation \ -XX:CompileThreshold=3 -XX:AOTLibrary=./libDemo.so -XX:+PrintAOT Demo
         19        1         loaded        ./libDemo.so  aot library
         77        1         aot[ 1]   Demo.square(I)I
         77        2         aot[ 1]   Demo.main([Ljava/lang/String;)V
         77        3         aot[ 1]   Demo.<init>()V
         77        2         aot[ 1]   Demo.main([Ljava/lang/String;)V   made not entrant
[...]
4 iteration
Square(i) = 16
Time taken= 43366
[...]
10 iteration
Square(i) = 100
Time taken= 59554

需要特别注意的是,修改被 AOT 编译了的源代码后,一定要重新生成 .so 库文件。否则,过时的的 AOT 编译库文件不会起作用。例如,修改 square() 方法,使其计算立方值:

//Demo.java
public class Demo {

    public int square(int i) throws Exception {
        return(i*i*i);
    }

    public static void main(String[] args) throws Exception {
        for (int i = 1; i <= 10; i++) {
          System.out.println("" + Integer.valueOf(i)+" iteration");
          long start = System.nanoTime();
          int r= new Demo().square(i);
          System.out.println("Square(i) = " + r);
          long end = System.nanoTime();
          System.out.println("Time taken= " + (end-start));
          System.out.println("--------------------------------");
        }
    }
}

重新编译 Demo.java:

$ java Demo.java

但不重新生成 libDemo.so。使用下面命令运行 Demo:

$ java -XX:+UnlockExperimentalVMOptions -Xbatch -XX:+PrintCompilation -XX:CompileCommandFile=hotspot_compiler -XX:-TieredCompilation -XX:CompileThreshold=3 -XX:AOTLibrary=./libDemo.so -XX:+PrintAOT Demo
         20        1         loaded        ./libDemo.so  aot library
         74        1         n           java.lang.invoke.MethodHandle::linkToStatic(LLLLLL)L (native)   (static)
2 iteration
sqrt(i) = 8
Time taken= 43838
--------------------------------
3 iteration
        137   56        b            Demo::<init> (5 bytes)
        138   57        b            Demo::square (6 bytes)
sqrt(i) = 27
Time taken= 534649
--------------------------------
4 iteration
sqrt(i) = 64
Time taken= 51916
[...]
10 iteration
sqrt(i) = 1000
Time taken= 47132

可以看到,虽然旧版本的 libDemo.so 被加载了,但 JVM 检测出它已经过时了。每次生成 .class 文件时,都会在类文件中添加一个指纹,并在 AOT 库中保存该指纹。修改源代码后类指纹与旧的 AOT 库中的指纹不匹配了,所以没有执行 AOT 编译生成的原生机器码。从输出可以看出,现在实际上是 JIT 在起作用(注意 -XX:CompileThreshold 被设置为了 3)。

AOT 和 JIT 之间的权衡

如果你的目标是减少 JVM 的预热时间,请使用 AOT,这可以减少运行时负担。问题是 AOT 没有足够的数据来决定哪段代码需要预编译为原生代码。相比之下,JIT 在运行时起作用,却对预热时间有一定的影响。然而,它将有足够的分析数据来更高效地编译和反编译代码。

(题图:MJ/ed3e6e15-56c7-4c1d-aff1-84a225faeeeb)


via: https://opensource.com/article/22/8/interpret-compile-java

作者:Jayashree Huttanagoudar 选题:lkxed 译者:toknow-gh 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出