最近在解一个bug，其在退出的时候会出现崩溃，这种崩溃全部指向析构。经过定位，发现如果QT的对象存在父子关系，是不能够在析构中强行delete这种对象，否则就会出现循环析构，这种循环析构就会导致应用崩溃。本文基于此问题分析，强调一下QT关于对象的编程注意事项
# 为什么会出现循环析构
关于为什么会出现循环析构，其理论出现的路径应该是如下：

1. 首先，编写代码时将对象进行申请，并为其绑定了父对象
2. 然后，某一次统一的内存泄漏合规性排查，发现其new和free不成对，但是忽略了QT本身的对象内存管理机制
3. 于是乎为了满足表面语义的内存泄漏，强行在析构中进行内存删除
4. 此时，代码看似内存申请和释放对称了，也就解决了内存泄漏问题

可以看到，在常规QT的编程中，如果代码编写者对QT内存对象管理不是很清晰的话，这种情况非常常见。

那么发现循环析构的方法也很明确，本例中，gdb调试的堆栈如下
```
(gdb) bt
#0  UKUITaskBar::~UKUITaskBar (this=0x558c9a0310, __in_chrg=<optimized out>) at ./plugin-taskbar/ukuitaskbar.cpp:214
#1  0x00000055717f6764 in UKUITaskBar::~UKUITaskBar (this=0x558c9a0310, __in_chrg=<optimized out>) at ./plugin-taskbar/ukuitaskbar.cpp:214
#2  0x00000055718067ac in UKUITaskBarPlugin::~UKUITaskBarPlugin (this=0x558c987700, __in_chrg=<optimized out>) at ./plugin-taskbar/ukuitaskbarplugin.cpp:42
#3  0x00000055718067dc in UKUITaskBarPlugin::~UKUITaskBarPlugin (this=0x558c987700, __in_chrg=<optimized out>) at ./plugin-taskbar/ukuitaskbarplugin.cpp:40
#4  0x00000055717f64b4 in UKUITaskBar::~UKUITaskBar (this=0x558c9a0310, __in_chrg=<optimized out>) at ./plugin-taskbar/ukuitaskbar.cpp:230
#5  0x00000055717f6764 in UKUITaskBar::~UKUITaskBar (this=0x558c9a0310, __in_chrg=<optimized out>) at ./plugin-taskbar/ukuitaskbar.cpp:214
#6  0x00000055718067ac in UKUITaskBarPlugin::~UKUITaskBarPlugin (this=0x558c987700, __in_chrg=<optimized out>) at ./plugin-taskbar/ukuitaskbarplugin.cpp:42
#7  0x00000055718067dc in UKUITaskBarPlugin::~UKUITaskBarPlugin (this=0x558c987700, __in_chrg=<optimized out>) at ./plugin-taskbar/ukuitaskbarplugin.cpp:40
#8  0x00000055717f64b4 in UKUITaskBar::~UKUITaskBar (this=0x558c9a0310, __in_chrg=<optimized out>) at ./plugin-taskbar/ukuitaskbar.cpp:230
#9  0x00000055717f6764 in UKUITaskBar::~UKUITaskBar (this=0x558c9a0310, __in_chrg=<optimized out>) at ./plugin-taskbar/ukuitaskbar.cpp:214
#10 0x00000055718067ac in UKUITaskBarPlugin::~UKUITaskBarPlugin (this=0x558c987700, __in_chrg=<optimized out>) at ./plugin-taskbar/ukuitaskbarplugin.cpp:42
#11 0x00000055718067dc in UKUITaskBarPlugin::~UKUITaskBarPlugin (this=0x558c987700, __in_chrg=<optimized out>) at ./plugin-taskbar/ukuitaskbarplugin.cpp:40
......
```
此时，第一时间发现这样的堆栈肯定很疑惑，明明代码只是如下操作，而为什么对象反复在析构呢？
```
    if (m_allFrame) {
        delete m_allFrame;
        m_allFrame = nullptr;
    }
    if (m_placeHolder) {
        delete m_placeHolder;
        m_placeHolder = nullptr;
    }
```
这个其实就是QT的默认对象管理
* 当某个对象声明了父对象，则其内存声明周期由父对象管理，只有父对象删除时，其本身对象才会得到删除。

上述的含义反过来理解就是
* 如果父对象尚未销毁时，子对象被强行删除，那么当父对象销毁时，会寻找子对象进行销毁

此时子对象会销毁两次，问题也就出现了。

但是通常一个代码工程中，例子不可能这么简单，如果qt的对象绑定的父子关系比较深，那么在析构过程中，就会全部在同一个函数堆栈上析构，那么这样就看到了上图的函数堆栈。
```
#0  UKUITaskBar::~UKUITaskBar (this=0x558c9a0310, __in_chrg=<optimized out>) at ./plugin-taskbar/ukuitaskbar.cpp:214
```
# 解决问题
根据堆栈可以很明显找到代码位置为类UKUITaskBar的析构，那么定位代码非常容易，下面梳理一下对象关系

首先m_placeHolder是继承的QWidget，父对象是当前类，如下
```
m_placeHolder(new QWidget(this))
```
而m_placeHolder绑定了父对象是m_allFrame
```
m_allFrame->addWidget(m_placeHolder);
```
这里出现m_allFrame的父对象也是当前类
```
m_allFrame = new QWidget(this);
```
当前类是UKUITaskBar。

下面梳理一下父对象关系
```
UKUITaskBar--->m_placeHolder
UKUITaskBar--->m_allFrame--->m_placeHolder
```
这种父子关系，意味着m_placeHolder和m_allFrame都可以不主动delete。那么一切正常。

如果我们在`~UKUITaskBar`中主动调用如下
```
delete m_placeHolder
delete m_allFrame
```
那么可以梳理其回收的流程有几条线如下
1. 默认走QT的对象管理，由QT处理每个对象释放(情况比较复杂)
2. delete m_allFrame会主动释放m_allFrame和其子对象m_placeHolder
3. delete m_placeHolder会主动释放自身

那么从m_placeHolder的角度，这样的代码m_placeHolder释放了3次。而在实际工程中，如果对象的嵌套比较深，这种双重释放会更加严重。

最后，解决问题很简单，只要理清楚了对象的关系，直接删除不必要的释放即可。

# 总结
这个例子本身很简单，但是问题又很容易出现。本文明确出来能够很好的提醒自己这类细节问题。

QT有父子关系对象的双重释放问题

分享一个有意思的故事，它和现在热门的话题息息相关。原文如下
# 原文
```
Once upon a time, a man with a dirty lab coat and long, uncombed hair
showed up at the town police station, demanding to see the chief of
police.  "I've done it!" he exclaimed.  "I've built the perfect
criminal-catching robot!"

The police chief was skeptical, but decided that it might be worth
the time to see what the man had invented.  Also, he secretly thought,
it might be a somewhat unwise move to completely alienate the mad
scientist and his army of hunter robots.

So, the man explained to the police chief how his invention could tell
the difference between a criminal and law-abiding citizen using a
series of heuristics.  "It's especially good at spotting recently
escaped prisoners!" he said.  "Guaranteed non-lethal restraints!"

Frowning and increasingly skeptical, the police chief nevertheless
allowed the man to demonstrate one robot for a week.  They decided that
the robot should patrol around the jail.  Sure enough, there was a
jailbreak a few days later, and an inmate digging up through the
ground outside of the prison facility was grabbed by the robot and
carried back inside the prison.

The surprised police chief allowed the robot to patrol a wider area.
The next day, the chief received an angry call from the zookeeper.
It seems the robot had cut through the bars of one of the animal cages,
grabbed the animal, and delivered it to the prison.

The chief confronted the robot's inventor, who asked what animal it
was.  "A zebra," replied the police chief.  The man slapped his head and
exclaimed, "Curses!  It was fooled by the black and white stripes!
I shall have to recalibrate!"  And so the man set about rewriting the
robot's code.  Black and white stripes would indicate an escaped
inmate UNLESS the inmate had more than two legs.  Then it should be
left alone.

The robot was redeployed with the updated code, and seemed to be
operating well enough for a few days.  Then on Saturday, a mob of
children in soccer clothing, followed by their parents, descended
on the police station.  After the chaos subsided, the chief was told
that the robot had absconded with the referee right in the middle of
a soccer game.

Scowling, the chief reported this to the scientist, who performed a
second calibration.  Black and white stripes would indicate an escaped
inmate UNLESS the inmate had more than two legs OR had a whistle on
a necklace.

Despite the second calibration, the police chief declared that the robot
would no longer be allowed to operate in his town.  However, the news
of the robot had spread, and requests from many larger cities were
pouring in.  The inventor made dozens more robots, and shipped them off
to eager police stations around the nation.  Every time a robot grabbed
something that wasn't an escaped inmate, the scientist was consulted,
and the robot was recalibrated.

Unfortunately, the inventor was just one man, and he didn't have the
time or the resources to recalibrate EVERY robot whenever one of them
went awry.  The robot in Shangri-La was recalibrated not to grab a
grave-digger working on a cold winter night while wearing a ski mask,
and the robot in Xanadu was recalibrated not to capture a black and
white television set that showed a movie about a prison break, and so
on.  But the robot in Xanadu would still grab grave-diggers with ski
masks (which it turns out was not common due to Xanadu's warmer climate),
and the robot in Shangri-La was still a menace to old televisions (of
which there were very few, the people of Shangri-La being on the average
more wealthy than those of Xanadu).

So, after a few years, there were different revisions of the
criminal-catching robot in most of the major cities.  In some places,
a clever criminal could avoid capture by wearing a whistle on a string
around the neck.  In others, one would be well-advised not to wear orange
clothing in certain rural areas, no matter how close to the Harvest
Festival it was, unless one also wore the traditional black triangular
eye-paint of the Pumpkin King.

Many people thought, "This is lunacy!"  But others thought the robots
did more good than harm, all things considered, and so in some places
the robots are used, while in other places they are shunned.

The end.
```
# 个人感悟
有一天和朋友沟通，他说现在无论招聘，面试，工作，编码，AI都能完成。自动驾驶不用人开(遥遥领先~)，机器人自主之类之类的。  

我很认真的思考了一下，难道国内不都是在做寓言里面的事情么？

这个问题答案很开放，有不同于我想法的可以指教解惑。












一个有意思的故事/寓言

ai的大部分评估和测试都是基于python的，使用python的第一步就是安装conda，然后配置开发环境，这里介绍一下配置conda的步骤
# miniconda下载安装
嵌入式平台更推荐miniconda，本文基于miniconda来安装
```
mkdir -p ~/miniconda3

wget https://repo.anaconda.com/miniconda/Miniconda3-latest-Linux-aarch64.sh -O ~/miniconda3/miniconda.sh

~/miniconda3/miniconda.sh -b -u -p ~/miniconda3
```
# 初始化conda
```
cd miniconda3
./bin/conda init 
```
完成之后，终端可以关闭了，此时默认情况下激活的是base的conda环境。如下

![image.png](/static/img/a411ca18b8d4512ac7b04c28aa8ede7c.image.webp)

但是此时的base环境下的python是基于最新的，当前是3.13.5，如下
```
# python3 
Python 3.13.5 | packaged by Anaconda, Inc. | (main, Jun 12 2025, 16:17:47) [GCC 11.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> 
```
而 nano 默认匹配的开发环境基于3.10 ，所以我们需要额外激活一下3.10的环境
```
conda create -n virtual python=3.10
conda activate virtual 
```
然后此时可以看到python3的环境回到了系统的3.10上。如下
```
# python3 
Python 3.10.18 (main, Jun  5 2025, 13:08:10) [GCC 11.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> 
```
配置完成之后，默认将conda的自动启动关闭，如下
```
conda config --set auto_activate_base false
```
然后设置默认的venv快捷指令，如下
```
vim /etc/profile
alias venv='conda activate virtual'
```
后面每次进入conda环境的时候，直接敲venv即可。

# 安装pytorch
首先我们进入系统，激活conda环境如下
```
venv
```
根据指引，我们可以直接下载如下的whl包

![image.png](/static/img/4149a9dacd96ff95c696b9c5c1d2e313.image.webp)

运行依赖的安装
```
apt-get install python3-pip libopenblas-base libopenmpi-dev libomp-dev
pip3 install 'Cython<3'
pip3 install numpy torch-2.3.0-cp310-cp310-linux_aarch64.whl 
```

但是安装之后发现，此版本与当前安装的jetpack版本整体sdk已经不匹配了，其依赖的是cudnn8，而系统安装的是cudnn9，所以上述方法实际不可用。需要更新的pytorch。
```
pip3 uninstall pytorch
```

下面基于最新的pytorch来进行安装， 以适配自己安装的整体环境。

根据文档说明，如果pytorch在24.06版本或以后，则需要安装cusparselt
在
> https://docs.nvidia.com/deeplearning/frameworks/install-pytorch-jetson-platform/index.html

提到了如下安装
```
wget 
raw.githubusercontent.com/pytorch/pytorch/5c6af2b583709f6176898c017424dc9981023c28/.ci/docker/
common/install_cusparselt.sh 
export CUDA_VERSION=12.1 # as an example   
bash ./install_cusparselt.sh
```
这个方法现在也不能安装了，因为install_cusparselt.sh未更新，我们vim可以看到如下片段代码
```
if [[ ${CUDA_VERSION:0:4} =~ ^12\.[1-4]$ ]]; then
    arch_path='sbsa'
    export TARGETARCH=${TARGETARCH:-$(uname -m)}
    if [ ${TARGETARCH} = 'amd64' ] || [ "${TARGETARCH}" = 'x86_64' ]; then
        arch_path='x86_64'
    fi
    CUSPARSELT_NAME="libcusparse_lt-linux-${arch_path}-0.5.2.1-archive"
    curl --retry 3 -OLs https://developer.download.nvidia.com/compute/cusparselt/redist/libcusparse_lt/linux-${arch_path}/${CUSPARSELT_NAME}.tar.xz
elif [[ ${CUDA_VERSION:0:4} == "11.8" ]]; then
    CUSPARSELT_NAME="libcusparse_lt-linux-x86_64-0.4.0.7-archive"
    curl --retry 3 -OLs https://developer.download.nvidia.com/compute/cusparselt/redist/libcusparse_lt/linux-x86_64/${CUSPARSELT_NAME}.tar.xz
fi
```
从代码可以看到其跳转了如下链接
```
https://developer.download.nvidia.com/compute/cusparselt/redist/libcusparse_lt/linux-aarch64
```
然后安装libcusparse_lt-linux-aarch64-0.5.2.1-archive.tar.gz。而现在的版本已经最高到0.7.1了，地址如下

![image.png](/static/img/34f4d73e8eb15390edefe18c3437b406.image.webp)

所以我直接从`https://docs.nvidia.com/cuda/cusparselt/index.html`安装cuSPARSELt，如下
```
wget https://developer.download.nvidia.com/compute/cusparselt/0.7.1/local_installers/cusparselt-local-tegra-repo-ubuntu2204-0.7.1_1.0-1_arm64.deb
sudo dpkg -i cusparselt-local-tegra-repo-ubuntu2204-0.7.1_1.0-1_arm64.deb
sudo cp /var/cusparselt-local-tegra-repo-ubuntu2204-0.7.1/cusparselt-*-keyring.gpg /usr/share/keyrings/
sudo apt-get update
sudo apt-get -y install libcusparselt0 libcusparselt-dev
```
下载pytorch的方式按照如下拼接
```
https://developer.download.nvidia.com/compute/redist/jp/v$JP_VERSION/pytorch/$PYT_VERSION
```
因为不确定JP_VERSION怎么填写，可以直接登录如下
> https://developer.download.nvidia.com/compute/redist/jp/

直接寻找最新的即可

![image.png](/static/img/c2f80989f32f36733a23cda74a74d187.image.webp)

安装完成之后，发现numpy需要小于2版本的，日志如下。
```
>>> import torch

A module that was compiled using NumPy 1.x cannot be run in
NumPy 2.2.6 as it may crash. To support both 1.x and 2.x
versions of NumPy, modules must be compiled with NumPy 2.0.
Some module may need to rebuild instead e.g. with 'pybind11>=2.12'.

If you are a user of the module, the easiest solution will be to
downgrade to 'numpy<2' or try to upgrade the affected module.
We expect that some modules will need time to support NumPy 2.
```
此时强行安装小版本的numpy即可
```
pip3 install numpy==1.26.1
```
成功之后，简单测试如下
```
>>> import torch 
>>> print(torch.__version__)
2.5.0a0+872d972e41.nv24.08
>>> print('CUDA available: ' + str(torch.cuda.is_available()))
CUDA available: True
>>> print('cuDNN version: ' + str(torch.backends.cudnn.version()))
cuDNN version: 90300
>>> print(torch.empty((1, 2), device=torch.device("cuda")))
tensor([[0., 0.]], device='cuda:0')
```
到这里，torch安装完成了，现在继续安装 torchaudio 和 torchvision

# 安装torchaudio
安装构建工具
```
pip install cmake ninja
```
安装系统依赖包
```
sudo apt install ffmpeg libavformat-dev libavcodec-dev libavutil-dev libavdevice-dev libavfilter-dev
```
编译
```
git clone https://github.com/pytorch/audio && cd audio
```
此时我们应该留意torch和tourchaudio的版本应该要一致，我们安装torch的版本是2.5.0a0+872d972e41.nv24.08，此时audio的版本应该相同，如下
```
# git branch -a
remotes/origin/release/2.5
# git checkout remotes/origin/release/2.5 -b 2.5
```
此时需要注意的是，需要尽可能要保证使用统一的开发环境，所以这里使用的是miniconda创建的python3.10的虚拟环境，故一切开发都基于此环境即可。如下
```
root@ubuntu:~# venv
(virtual)root@ubuntu:~# 
```
然后再去直接构建
```
USE_CUDA=1 pip install -v -e . --no-use-pep517
```
值得注意的是，因为torchaudio编译占用内存较大，需要关闭图像桌面，如下
```
systemctl stop gdm
```
在编译过程中，会出现如下错误
```
....../ctc_prefix_decoder_kernel_v2.cu(154): error: identifier "FLT_MAX" is undefined
            ptable[idout] = -FLT_MAX;
```
这个错误很明显，FLT_MAX没有定义，根据直觉，这种简单的错误肯定社区修过了，所以找github的pr，查看如下
> https://github.com/pytorch/audio/pull/3811

![image.png](/static/img/80c06e0396aa305326014ddf3bc235bf.image.webp)

所以添加如下改动
```
diff --git a/src/libtorchaudio/cuctc/src/ctc_prefix_decoder_kernel_v2.cu b/src/libtorchaudio/cuctc/src/ctc_prefix_decoder_kernel_v2.cu
index 4ca8f1bf..0787f999 100644
--- a/src/libtorchaudio/cuctc/src/ctc_prefix_decoder_kernel_v2.cu
+++ b/src/libtorchaudio/cuctc/src/ctc_prefix_decoder_kernel_v2.cu
@@ -23,6 +23,7 @@
 // OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
 // (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
 // OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+#include <float.h>
 #include <algorithm>
 #include "ctc_fast_divmod.cuh"
 #include "cub/cub.cuh"
```
修复之后继续编译，得到如下信息
```
    Installed /root/github/audio/src
Successfully installed torchaudio
```
可以发现torchaudio编译完成了，检查pip的安装情况
```
# pip list
torchaudio        2.5.1a0+1661daf
```
检查安装是否成功
```
>>> import torchaudio
>>> print(torchaudio.__version__)
2.5.1a0+1661daf
>>> torchaudio.utils.ffmpeg_utils.get_build_config()
"--prefix=/usr --enable-nvv4l2dec --enable-libv4l2 --enable-shared --extra-libs='-L/usr/lib/aarch64-linux-gnu/tegra -lv4l2 -lnvbufsurface -lnvbufsurftransform' --extra-cflags=-I/usr/src/jetson_multimedia_api/include/ --extra-version=1ubuntu0.1 --toolchain=hardened --libdir=/usr/lib/aarch64-linux-gnu --incdir=/usr/include/aarch64-linux-gnu --arch=arm64 --enable-gpl --disable-stripping --enable-gnutls --enable-ladspa --enable-libaom --enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --enable-libcdio --enable-libcodec2 --enable-libdav1d --enable-libflite --enable-libfontconfig --enable-libfreetype --enable-libfribidi --enable-libgme --enable-libgsm --enable-libjack --enable-libmp3lame --enable-libmysofa --enable-libopenjpeg --enable-libopenmpt --enable-libopus --enable-libpulse --enable-librabbitmq --enable-librubberband --enable-libshine --enable-libsnappy --enable-libsoxr --enable-libspeex --enable-libsrt --enable-libssh --enable-libtheora --enable-libtwolame --enable-libvidstab --enable-libvorbis --enable-libvpx --enable-libwebp --enable-libx265 --enable-libxml2 --enable-libxvid --enable-libzimg --enable-libzmq --enable-libzvbi --enable-lv2 --enable-omx --enable-openal --enable-opencl --enable-opengl --enable-sdl2 --enable-pocketsphinx --enable-librsvg --enable-libdc1394 --enable-libdrm --enable-libiec61883 --enable-chromaprint --enable-frei0r --enable-libx264 --enable-shared"
```
一切正常，下面开始安装torchvison
# 安装torchvision
安装torchvision也是通过源码的方式安装，因为nvidia没有及时的提供你预编译的二进制，但是在编译torchvision之前，我们需要确认一下版本问题。  
首选需要进入源码链接确认和torch的对应关系，如下

![image.png](/static/img/9f95004c29508f1eb1cf1cd7e95e7eb1.image.webp)

这里当前版本的机器是jetpack 6.2.2，python3是3.10 安装的torch是2.5 ，根据图的对应关系，我们应该安装0.20的版本。 我们首先下载代码，如下
```
git clone https://github.com/pytorch/vision.git
```
然后根据拿到的信息切换对应的分支上，如下
```
git checkout remotes/origin/release/0.20 -b 0.20 
```
此时构建之前需要注意的是，我们应该关闭机器的图形桌面
```
systemctl stop gdm
```
然后确认一下依赖包是否安装完成
```
apt-get install libjpeg-dev libpng-dev libtiff-dev
```
torchvision的编译需要内存比较大，所以首先要按照我之前文章设置一下《Linux内存调节总结》，这种情况需要额外新增一个较大大的swap空间，如下
```
fallocate -l 16G swapfile
mkswap swapfile
swapon swapfile
```
然后再根据我之前的文章来匹配此场景设置一下

注意这种swap设置和内存的设置都是临时的，主要为了让大型工程编译通过。下次重启后会自动恢复。

最后直接编译即可
```
jetson_clocks
python3 setup.py install
```
编译完成之后，可以通过如下查询是否安装成功
```
# pip list
torchvision       0.20.1a0+3ac97aa
```
下面检查测试torchvision是否正常使用，如下
```
import torch
import torchvision

print("Torch Version:", torch.__version__)
print("TorchVision Version:", torchvision.__version__)
print("CUDA Available:", torch.cuda.is_available())

if torch.cuda.is_available():
print("CUDA Device:", torch.cuda.get_device_name(0))
```
运行日志如下
```
>>> print("Torch Version:", torch.__version__)
Torch Version: 2.5.0a0+872d972e41.nv24.08
>>> print("TorchVision Version:", torchvision.__version__)
TorchVision Version: 0.20.1a0+3ac97aa
>>> print("CUDA Available:", torch.cuda.is_available())
CUDA Available: True
>>> print("CUDA Device:", torch.cuda.get_device_name(0))
CUDA Device: Orin
```
可以看到torchvision正常编译出来bing完成基本验证了。

# 总结
本文作为orin的基础上手篇，相当于实战了如何安装torch相关开发包。使得后续使用torch更加方便。  
同样的，jetson系列的torch二进制可以发现nvidia的关注度并不是很够，所有没有给你预装的二进制，这种情况下，知道如何从源码构建至关重要。

同样的，本文教会了初学者如何配置基础环境并完成torchaudio和torchvision的源码构建。这样后面即使nvidia不发布预编译的二进制，也能自己动手丰衣足食了。

# 参考资料
> https://www.cytron.io/tutorial/p-conda-on-jetson-orin-nano-super  
> https://forums.developer.nvidia.com/t/pytorch-for-jetson/72048/3  
> https://docs.nvidia.com/cuda/cusparselt/index.html
> https://docs.pytorch.ac.cn/audio/stable/build.jetson.html













Jetson-Orin-Nano-Super(4) 安装python系列开发环境

在实时程序的应用场景中，为了代码运行的低延迟和确定性，针对栈区，也是有一定的优化小技巧的。

# 栈预热
程序可能因为分配栈区内存的响应延迟导致的性能颠簸，从而导致实时任务的延迟抖动。

针对此问题，在实时程序关键任务未运行之前，提前访问栈区地址空间，从而触发缺页异常，分配物理页面，并函数返回。然后当实时程序在运行关键任务的函数调用和栈区变量分配时，由于之前栈区已经被预热过了，再次访问时，无需触发缺页异常，也就不会出现因为分配内存导致的性能颠簸了。

# 实施栈预热
对于栈区内存，预热的办法可以提供一个栈预热函数，函数内完成如下三个步骤
1. 分配一个很大的临时变量，占领栈区
2. 访问这个临时变量，触发页面申请
3. 函数返回

经过这三步，相当于强行访问了栈区的内存，提前进行了内存申请，此时如果后面的函数为实时程序关键任务，那么其再进行函数调用或者栈区变量访问时，不会触发缺页异常。从而不会产生性能颠簸。

# 测试程序
我们编写一个测试程序验证和说明这一点。
```
#include <stdlib.h>
#include <stdio.h>
#include <time.h>
#include <string.h>

#define ITERATIONS 10000
#define STACK_SIZE 1024 * 1024

static long long get_time() {
    struct timespec ts;
    clock_gettime(CLOCK_MONOTONIC, &ts);
    return ((long long)ts.tv_sec * 1000000000LL + (long long)(ts.tv_nsec)) / 1000;
}

void test_stack_prefetch() {
    char stack[STACK_SIZE];
    memset(stack, 0x0, STACK_SIZE);
    return ;
}

void test_stack(int use_warmup) {
    double times[ITERATIONS];
    double start, elapsed;
    char stack[STACK_SIZE];

    if(use_warmup)
        test_stack_prefetch();

    for (int i = 0; i < ITERATIONS; i++) {
        start = get_time();
        test_stack_prefetch();
        times[i] = get_time() - start;
    }

    double max, min;
    max = min = times[0];
    for (int i = 1; i < ITERATIONS; i++) {
        if (times[i] < min) min = times[i]; // Min
        if (times[i] > max) max = times[i]; // Max
    }

    printf("  Min time: %.2f us\n", min);
    printf("  Max time: %.2f us\n\n", max);

    return ;
}

int main(int argc, char *argv[]) {
    int use_warmup = 0;

    if (argc == 2) {
        use_warmup = atoi(argv[1]);;
    }

    printf("Stack size: %d bytes, Iterations: %d Warmup: %d\n", STACK_SIZE, ITERATIONS, use_warmup);

    test_stack(use_warmup);

    return 0;
}
```
这里函数test_stack_prefetch通过stack申请了STACK_SIZE大小的局部变量，这个变量存放在栈区，用来实施和模拟栈区的使用。

然后再通过memset将其全部设置为0，相当于全部访问了STACK_SIZE内的栈区内存，触发了缺页异常。

最后函数返回。

经过此函数的运行，从test_stack_prefetch函数的开始栈区sp 到 stack 变量地址 加上 STACK_SIZE 大小的栈区，都被访问过。

因为 test_stack_prefetch 函数会返回，栈指针会缩小，下次运行函数时，其访问的栈区地址 在上述 栈区地址范围内，因为上述 栈区地址已经提前访问过了，所以代码不会因为内存产生性能颠簸。

下面查看运行日志
```
# ./stack_prefetch 0
Stack size: 1048576 bytes, Iterations: 2 Warmup: 0
  Min time: 79.00 us
  Max time: 692.00 us
```
可以看到，对于申请1M的栈空间，如果不经过预热，那么首次申请的时间是 692 us。
如果使用预热，那么根据上面的日志分析，应该是100us左右，下面运行验证
```
# ./stack_prefetch 1
Stack size: 1048576 bytes, Iterations: 2 Warmup: 1
  Min time: 102.00 us
  Max time: 103.00 us
```

# 总结
至此，我们通过这么一个小技巧，可以保证在实时程序处理关键任务时，不会因为栈的内存分配问题导致实时任务抖动。此方法通常可以用于在实时任务运行之前进行预热，或者定期对整个栈区范围进行定期预热。
