这么好用？！99%开发者从未听说过的堆栈模型（加量增强版）

【说在前面的话】

朋友：

你知道如何设置栈最安全么？

你知道如何不写一行汇编代码就能设置栈的大小么？

你知道如何在链接脚本中使用宏和头文件么？

你知道如何在代码中随时随地检查栈的最大使用情况么？

本文从理论到实践，从知其然到知其所以然，一杯奶茶的功夫就给你讲得明明白白。

在中文嵌入式环境中，时不时的总能看到不少朋友”堆”“栈“傻傻分不清楚，我很早之前在文章《漫谈C变量——夏虫不可语冰》介绍过二者的区别，这里就不再深入展开，总之：

栈（Stack）“是我们用来分配局部变量、实现函数调用和在异常响应时保存被打断代码上下文的地方——具体细节不重要，在本文的讨论中，我们只需要记住以下信息：

• Cortex-M系统栈的生长方向是自上而下的，也就是随着更多内容被压入（PUSH）栈中，栈顶指针的地址值是越来越小的——也就是从地址值较大的位置向地址值较小的位置移动。
• Cortex-M的栈顶指针指向的是“栈顶部的空位”。
• 从最大兼容性角度考虑，Cortex-M架构下栈存储空间必须对齐到8字节。

“堆（Heap）”是我们使用 malloc 申请动态存储空间时所必须用到的一种数据结构——通常由C语言的系统库提供。

• 堆本身只是一个内存管理的算法，它所要管理的RAM空间需要用户通过某种手段将指定大小的RAM空间交到Heap算法手里。
• 与栈不同，堆的生长方向其实完全由具体的管理算法决定，而堆的算法数量虽然不能说是灿若星辰，至少一双手肯定数不过来——但一般来说我们可以大体认为堆的生长方向是“自下而上的”——也就是从地址值较小的位置延伸到地址值较大的位置。
• 堆的对齐要求一般是4字节起步，8字节更好，情况不明的直接就32个字节吧。

【常见的堆栈模型】

从单纯从我不负责任的经验来看，由很多GCC领衔使用的“对向生长”模型可能是嵌入式领域最常见的”大聪明模型“，没有之一。如下图所示：

先说优点吧：

• 该模型栈和堆共用同一块连续的地址区间
• 配置时不需要操心具体栈有多大、堆有多大
• 配置方法简单：只需要指定这一整块”堆栈“区域的起始地址，以及这一整块堆栈区域的大小
• 堆和栈的最大可用大小是此消彼长的，理论上可以在某种最优的情况下达到动态的”此消彼长“，可以获得理想状下最大的空间复用效率。

缺点也很明显：

• 堆和栈的最大可用大小是此消彼长的，在真实场景中，由于”你长我也长谁怕谁”的情况居多，发生随机性的“双向奔赴”从而进行“负距离”的互动可能性从理论上就不可避免，因而是系统稳定性的“一生之敌”。
• 实验室里7x24小时完美通过，一去客户那里就随机性宕机的“挖坑之王”。

为了提高系统稳定性，人们简单地将“堆”和“栈”拆开来单独配置，就获得了常见的“两段式堆栈模型”：

可以看到，相较之前的模型，虽然仍然是“对向生长”，但由于栈和堆有了自己固定空间，因此可以方便地根据实际用量调整它们的大小（比如留下足够的余量），从而降低彼此入侵带来的稳定性风险。

更有甚者，在二者的边界上引入一个特殊值（比如0xDEADBEEF）所充当的溢出检测”金丝雀（Canary）”——一旦发现这个值与预设的不同，基本就可以断定发生了溢出。

【最安全的“两面包夹芝士”模型】

将“栈（Stack）”和"堆(Heap)"独立配置的“两段式”模型配合边界金丝雀，为预防和检测堆栈溢出提供了可能。但对金丝雀的检测总归有种“事后诸葛亮”的感觉，而且很多时候，我们是想不起来去检查金丝雀的，比如：栈曾经一度跨越雷池入侵到了堆空间，但由于此时堆恰巧分配出去的RAM不多，没有与栈发生实质性的重叠，因而整个系统“安然无恙”——这只能说是运气好，而风险肯定是存在的——正由于系统“安然无恙”，因此我们在系统开发阶段可能不会想起来去检查一下金丝雀（有自动检查机制的RTOS除外），那么这类溢出就有可能被隐藏。

基于上述原因，有没有一种方法可以：

• 彻底避免栈/堆入侵对系统的破坏
• 在栈/堆入侵的瞬间就立即表现出来——方便我们在调试阶段立即发现

答案是肯定的，这就是“两面包夹芝士”模型（此前又叫“三明治”模型）：

从上图很容易看出：

• 该模型属于“两段式模型”的变种
• 与过去堆和栈的“相向生长”不同，该模型采用了“背向生长”的方式——避免了栈与堆的相互伤害
• 栈被放在了SRAM的起始位置（Cortex-M从架构上鼓励将SRAM放置在从0x2000-0000开始的地址上），这样一旦发生栈溢出，指针就会指向SRAM存储器以外的无效位置——这在大部分芯片上会触发“Bus Fault”，从而产生故障异常——这就实现了对栈溢出的当场捕获，并且不依赖MPU或者“栈底地址限制检测（Stack Limit Checking）”之类的架构特性。

当然有些芯片设计者可能会选择“隐藏这类错误”，不仅不会触发异常，而且会当做无事发生，具体表现为：对无效地址的写入操作将被无视，对无效地址的读取操作将会返回0值。具体可以参考芯片手册，或者干脆做个实验。

• 堆被放置在了RAM的最后，中间夹着存放静态/全局变量的“RW/ZI区域”，这也是“两面包夹芝士”模型（或者“三明治”模型）名称的由来。这样的安排也彻底杜绝了栈和堆对“RW/ZI区域”发生入侵的可能。当堆溢出时，与栈类似，对大部分芯片来说都会触发故障异常，从而在开发调试阶段第一时间被我们所捕获。

• 通过链接脚本（比如Arm Compiler的Scatter Script或者gcc、clang的ld）的一些运算功能，我们甚至可以做到“将剩下的空间全留给HEAP”，从而简化系统的配置。

【Arm官方低调推荐的”新“方法】

其实，Arm Compiler 在很久之前就逐步淘汰了“大聪明的单段对向生长模型”，而“两段模型”早已成为主流。比如，我们在汇编启动文件中经常可以见到这样的代码片段：

这就是“两段式”模型的证据。实际上，在启动代码的尾部，汇编程序通过：

IMPORT __use_two_region_memory

选择了对两段式模型提供支持的libc库：

看过我前面一期文章《【嵌入式秘术】Cortex-M静态链接库——从入坑到入土》的小伙伴一定会眼前一亮——“原来是这样啊，我们其实是手动选择了对应两段式堆栈模型的库版本呢”。

问题是，我们要如何在Arm Compiler环境下实现“两面包夹芝士”模型呢？我们需要写汇编代码么？

不用担心，即便你的启动文件是汇编的，具体操作方法也非常简单。步骤如下：

步骤一：准备阶段

注意：此步骤只针对使用汇编启动文件的情况。如果你的启动文件是C，则可跳过该步骤。

在工程管理器中找到你的汇编启动文件，它通常以

startup_<芯片型号>.s

的形式命名：

找到配置栈和堆大小的部分（红框标注的部分）：

将其整体删除（或者注释掉）。

注意：请保留这里的 PRESERVE8和THUMB部分。

继续移动到汇编文件的尾部，找到如下的代码：

同理，将其删除（或者注释掉）。

注意：这里要保留 END 。

移动到中断向量表的定义处：

将红框中所标注的代码选中：

__Vectors       DCD      __initial_sp

替换为如下内容：

                IMPORT   |Image$$ARM_LIB_STACK$$ZI$$Limit|

__Vectors       DCD      |Image$$ARM_LIB_STACK$$ZI$$Limit|

即：

保存启动文件。

此时，如果你着急编译，当你当你开启了microLib时，很可能会看到如下的链接错误：

即：

Error: L6218E: Undefined symbol __initial_sp (referred from entry2.o).

或者你没有开启 microLib，则会看到一个不同的错误：

即：

Error: L6915E: Library reports error: The semihosting __user_initial_stackheap cannot reliably set up a usable heap region if scatter loading is in use

这都是正常的，不必惊慌。这类错误会在完成后面的步骤后自然消失。

步骤二：获取链接脚本（Scatter Script）

打开工程配置窗口“Options for Target”，切换到“Linker”选项卡：

首先，一定要确保你勾选了图中的“Use Memory Layout from Target Dialog”选项。在这一前提下，再次取消对它的勾选：

我们会看到，MDK基于当前的Memory Layout，为我们在Out目录下生成了一个与工程同名的链接脚本（比如图中的工程名叫example，因此生成的链接脚本为 example.sct）。

单击 Edit 按钮，可以看到脚本的内容：

先别着急半路开香槟——该文件是系统自动生成的，如果我们不移动它的位置，那么只要哪次手抖勾选了“Use Memory Layout from Target Dialog”，它的内容就会立即被覆盖掉——意味着我们在后续步骤中所做的修改就会付诸东流。

为了避免该问题，应该将它从 Out 目录中移动到工程目录下。具体步骤为，右键单击脚本文件名：

选择“Open Container Folder”来打开文件所在目录：

找到Scatter Script脚本文件后，将其拷贝到上一级目录下（也就是工程目录）：

重新打开工程配置窗口：

确保我们“没有”选中“Use Memory Layout from Target Dialog”选项，并在Scatter File文本框中直接填写我们刚刚拷贝出来的脚本文件名（由于我们直接放在工程目录下，因此这里直接用相对路径"./example.scat"或者"example.scat"就行）。单击OK保存配置。

步骤三：在链接脚本中部署堆和栈

在编辑器中打开我们的脚本文件：

图中选中的部分实际上包含了RAM中的所有内容，包括静态变量、全局变量、栈和堆：

是的，你的猜测没错：当我们没有特别说明时，Stack和Heap都以ZI的形式存在于上述空间内，其位置任由Linker摆布——这当然也带来了很多不确定性。

接下来我们要做的就是按照我们的设计——“两面包夹芝士”来明确的指定栈和队列的大小和位置：

我们要做的是首先将一个名为ARM_LIB_STACK 的execution region放置到RAM的起始位置：

  ARM_LIB_STACK 0x20000000 ALIGN 8 EMPTY 0x800 {}

这里：

• 起始地址是 0x20000000
• STACK的大小是 0x800
• ALIGN 8 指定对齐是8个字节
• EMPTY是必须要保留的，它用来说明 ARM_LIB_STACK 是一个大数组，里面默认填充了0。
• 如果你想修改填充的内容还可以通过关键字 FILL <填充值> 来指定填充的32bit数值，比如：

 ARM_LIB_STACK 0x20000000 ALIGN 8 FILL 0xDEADBEEF EMPTY 0x800 {}

它实现了往0x20000000开始的0x800（2KB）大小的栈空间中填充0xDEADBEEF的功能：

熟悉“水印法”测量栈用量的小伙伴一定大喜。

为了让ZI/RW紧随其后——放在STACK的后面，我们需要对 RW_IRAM1 的描述进行修改，即从：

RW_IRAM1 0x20000000 0x00020000  {

修改为：

RW_IRAM1 +0  {

即：

这里，我们在原本放置地址0x20000000的位置用"+0"表示“紧随其后”，并删除了原本的大小0x00020000——这样做就是告诉编译器“RW_IRAM1”不限制大小。

接下来，我们要用类似的方法紧随 RW_IRAM1 之后放置名为 ARM_LIB_HEAP 的execution region——用来指定堆的位置和大小：

ARM_LIB_HEAP +0 ALIGN 8 EMPTY 0x200 {}

可以看到，这里与栈的设置方式几乎一样，而“+0”则同样告诉linker：请将ARM_LIB_HEAP紧邻前面的 RW_IRAM1 放置。最终的效果如下：

LR_IROM1 0x00000000 0x00040000  {    
  ER_IROM1 0x00000000 0x00040000  {  
   *.o (RESET, +First)
   *(InRoot$$Sections)
   .ANY (+RO)
   .ANY (+XO)
  }

  ARM_LIB_STACK 0x20000000 ALIGN 8 EMPTY 0x800 {}

  ;RW_IRAM1 0x20000000 0x00020000  {  ; RW data
  RW_IRAM1 +0  {  ; RW data
   .ANY (+RW +ZI)
  }

  ARM_LIB_HEAP +0 ALIGN 8 EMPTY 0x200 {}
}

还记得我们前面删除了原本对RW_IRAM1的尺寸限制（也就是0x0002000）么？这意味着，现阶段的脚本文件对我们实际使用的RAM空间是没有任何限制的——换句话说，如果超出了芯片实际的SRAM大小，编译器也是不会报告错误的。为了重新加入这一限制，我们可以在 ARM_LIB_HEAP的后面加入下面的语句：

ScatterAssert(ImageLimit(ARM_LIB_HEAP) <= 0x20000000 + 0x20000)

这里：

• ScatterAssert() 是让linker对括号中的内容进行检查
• ImageLimit() 是在编译时刻获得括号内指定 execution region 的终止地址
• 0x20000000+0x20000 是例子中整个RAM的终止地址（这里假设RAM从0x20000000开始，大小是0x20000）
• 综合来说，上述代码的作用是在linker的链接阶段计算HEAP的终止地址，确认它是否落在了RAM的有效范围内。

如果超出了范围，我们就会看到如下的编译错误：

Error: L6388E: ScatterAssert expression (ImageLimit(ARM_LIB_HEAP) <= 0x20000000 + 0x20000) failed on line 22 : (0x20001220 <= 0x20020000)

最终效果如下：

对应的“两面包夹芝士”图示如下：

编译工程：

【“虽迟但到”的宏和头文件】

是的，你猜得没错，我们可以在链接脚本中使用编译预处理，这意味着：

• 我们可以使用宏
• 我们可以include头文件
• 我们可以进行条件编译

具体方法并不难，只需要在链接脚本的“第一行”，注意一定要是第一行（Number One）——前面不能有任何内容，空行或者注释都不行——放置如下的内容：

#! armclang --target=arm-arm-none-eabi -mcpu=cortex-m0 -E -xc

然后我们就可以在脚本文件中愉快地使用宏和include了。看到脚本中这么多的常数了么？地址啊、大小啊，这下都可以用宏替代了。比如：

#define RAM1_SIZE    0x00020000
#define RAM1_BASE    0x20000000
#define RAM1_LIMIT   (RAM1_BASE + RAM1_SIZE)

#define STACK_SIZE   0x800
#define HEAP_SIZE    0x200

其实我们还可以把宏的定义部分放置到专门的配置头文件中——通过#include来包含——从而真正做到一个配置头文件定天下。

至于宏可以有哪些骚操作，感兴趣的小伙伴可以关注【裸机思维】公众号后，发送关键字“宏”来获取相关文章，这里就不再赘述。

需要注意的是：

• 在较新版本的MDK中，上述方法“应该”同时支持Arm Compiler 5（armcc）和Arm Compiler 6（armclang）。你可以关注【裸机思维】公众号后，发送关键字“MDK”来获取最新的MDK。

对于某些较老的MDK来说，如果你使用的是 Arm Compiler 5，则需要把添加在 scatter script 第一行的命令行修改为：

#! armcc --cpu Cortex-M0 -E
...

以解决可能出现的编译错误。

• 如果你的头文件并没有“直接”放置在工程目录下，而是存在一个相对路径，则可以通过在上述命令行中追加 -I <路径> 的形式来告知编译器去哪里搜索我们的头文件。比如：

#! armclang --target=arm-arm-none-eabi -mcpu=cortex-m0 -E -xc -I ../../cfg

或者

#! armcc --cpu Cortex-M0 -E -I ../../cfg

则是告诉编译器从相对路径 "../../cfg" 下去搜索头文件。

• 当你通过修改头文件的方式来更新scatter script的内容后，第一次编译，请务必一定要以“Rebuild All”的形式进行，否则你的修改不会生效。

别说我没提醒过你哦！

【如何把剩余的空间都留给堆】

很多时候，把剩余空间都留给堆是一个不错的想法，这样“两面包夹芝士”模型就获得了和“单段相向生长”模型一样的优势——配置简单。由于我们已经有了宏的帮助，借助 ImageLimit() 我们可以将 HEAP_SIZE 的宏定义修改为：

#define HEAP_SIZE    (RAM1_LIMIT - ImageLimit(RW_IRAM1))

它的意思是：用RAM1的终止地址减去 RW_IRAM1的终止地址，获得中间的差额，其图示如下：

看似完美，有的小伙伴一编译就会报告如下的错误：

即：

Error: L6388E: ScatterAssert expression (ImageLimit(ARM_LIB_HEAP) <= (0x20000000 + 0x20000)) failed on line 29 : (0x20020004 <= 0x20020000)

奇怪，我们的计算公式应该没错啊——Heap的尺寸应该就是使用整个 RAM的终止地址减去 RW_IRAM1 的终止地址啊，为什么提示差4个字节呢？

聪明的小伙伴一定已经注意到了，我们在 ARM_LIB_HEAP 的定义中，指定了其首地址的对齐为8字节：

ARM_LIB_HEAP +0 ALIGN 8 EMPTY HEAP_SIZE {}

而 RW_IRAM1 的尺寸不一定是8的整倍数，当它只是“4的整倍数”而不满足“8的整倍数”这一条件时，ImageLimit(RW_IRAM1) 的后面与 ARM_LIB_HEAP的起始地址之间就会产生一个4字节的气泡：

要解决这一问题也很简单，我们可以使用 scatter script 脚本为我们提供的一个专门来进行地址对齐的函数：

AlignExpr(<地址数值>,<对齐要求>)

比如：

AlignExpr(ImageLimit(RW_IRAM1), 8)

就表示对 RW_IRAM1 的终止地址进行 8 字节对齐。借助它的帮助，我们可以修改脚本如下：

#define HEAP_SIZE    \
    (RAM1_LIMIT - AlignExpr(ImageLimit(RW_IRAM1), 8))

即：

再编译时，已然没有问题。

【如何随时随地的了解栈的最大使用情况】

水印法是实现“最大栈用量统计”的最有效方式。其原理也不复杂：

1. 先用指定的水印常数（比如 0xDEADBEEF）将整个栈填满；
2. 从栈空间的最初顶部（栈存储空间的终止地址）向下开始搜索之前填充的水印常数——一旦碰到水印，就将当前已经经历过的RAM总量作为栈的最大深度（最大用量）；

对于步骤1来说，可以通过前面介绍的 FILL 关键字来完成对栈空间的填充：

ARM_LIB_STACK 0x20000000 ALIGN 8 FILL 0xDEADBEEF EMPTY STACK_SIZE
{
}

然后借助下面的代码完成统计工作：

#if defined(__clang__)
#   pragma clang diagnostic push
#   pragma clang diagnostic ignored "-Wdollar-in-identifier-extension"
#   pragma clang diagnostic ignored "-Wdouble-promotion"
#endif
uint32_t calculate_stack_usage_topdown(void)
{
    extern uint32_t Image$$ARM_LIB_STACK$$Limit[];
    extern uint32_t Image$$ARM_LIB_STACK$$Length;

    uint32_t *pwStack = Image$$ARM_LIB_STACK$$Limit;
    uint32_t wStackSize = (uintptr_t)&Image$$ARM_LIB_STACK$$Length / 4;
    uint32_t wStackUsed = 0;


    do {
        if (*--pwStack == 0xDEADBEEF) {
            break;
        }
        wStackUsed++;
    } while(--wStackSize);
    
    
    printf("\r\nStack Usage: [%d/%d] %2.2f%%\r\n", 
            wStackUsed * 4, 
            (uintptr_t)&Image$$ARM_LIB_STACK$$Length,
            (   (float)wStackUsed * 400.0f 
            /   (float)(uintptr_t)&Image$$ARM_LIB_STACK$$Length));

    return wStackUsed * 4;
}
#if defined(__clang__)
#   pragma clang diagnostic pop
#endif

这里有几点需要说明一下：

• armlink 为我们提供了通用的语法来获取 execution region 的起始地址、大小和终止地址：

extern uint32_t Image$$<execution region name>$$Base[];
extern uint32_t Image$$<execution region name>$$Length;
extern uint32_t Image$$<execution region name>$$Limit[];

这里，Base和Limit被定义成了不定长数组的形式，因此我们可以直接把它们当做常量指针来使用——获取所需的地址。Length被定义成了一个普通的uint32_t型的变量，按照官方文档的要求，虽然很反直觉，但如果要获取它的值——也就是对应execution region的大小，必须要对其进行&操作，并随后强制转化为整形数值。这么说也许有点抽象，不妨对照前面的代码来看：

#include <stdint.h>
...
extern uint32_t Image$$ARM_LIB_STACK$$Limit[];
extern uint32_t Image$$ARM_LIB_STACK$$Length;

uint32_t *pwStack = Image$$ARM_LIB_STACK$$Limit;
uint32_t wStackSize = (uintptr_t)&Image$$ARM_LIB_STACK$$Length / 4;

ARM_LIB_STACK

• 普通情况下，在变量名中使用 “$” 会在Arm Compiler 6引发警告：

warning: '$' in identifier [-Wdollar-in-identifier-extension]

为了让编译器闭嘴，我们临时对函数 calculate_stack_usage_topdown() 在编译时刻做了屏蔽warning的操作：

#if defined(__clang__)
#   pragma clang diagnostic push
#   pragma clang diagnostic ignored "-Wdollar-in-identifier-extension"
#   pragma clang diagnostic ignored "-Wdouble-promotion"
#endif
uint32_t calculate_stack_usage_topdown(void)
{
    ...
}
#if defined(__clang__)
#   pragma clang diagnostic pop
#endif

而 -Wdouble-promotion 则是由printf中的百分比运算引起的，一并屏蔽即可。

在任意时刻，当我们想要知道当前系统的最大栈用量时，可以直接调用函数 calculate_stack_usage_topdown()，比如：

int main(void)
{
    ...
    calculate_stack_usage_topdown();
    ...
}

一个可能的执行结果如下：

自上而下统计栈用量的方法优点是：当栈空间很大而实际栈用量较小时，可以较快的完成统计；缺点是：如果恰好栈里因为任何原因（比如用户定义了一个局部变量，然后恰好给他赋予了我们的水印常数），就会造成统计错误——没能实际获得最大深度。

针对这一问题，我们可以修改搜索策略，从占空间的起始地址（也就是基地址）处向上搜索“非水印常数”——一旦碰到，就可以用已知的栈空间尺寸减去已经经历过的RAM总量作为栈的最大深度（最大用量）。

该方法的优点是：不容易发生误判；缺点是：当栈空间很大而实际栈用量较小时往往较为耗时。对应的代码如下：

#if defined(__clang__)
#   pragma clang diagnostic push
#   pragma clang diagnostic ignored "-Wdollar-in-identifier-extension"
#   pragma clang diagnostic ignored "-Wdouble-promotion"
#endif
uint32_t calculate_stack_usage_bottomup(void)
{
    extern uint32_t Image$$ARM_LIB_STACK$$Base[];
    extern uint32_t Image$$ARM_LIB_STACK$$Length;

    uint32_t *pwStack = Image$$ARM_LIB_STACK$$Base;
    uint32_t wStackSize = (uintptr_t)&Image$$ARM_LIB_STACK$$Length;
    uint32_t wStackUsed = wStackSize / 4;

    do {
        if (*pwStack++ != 0xDEADBEEF) {
            break;
        }
    } while(--wStackUsed);
    
    printf("\r\nStack Usage: [%d/%d] %2.2f%%\r\n", 
            wStackUsed * 4, 
            wStackSize,
            ((float)wStackUsed * 400.0f / (float)wStackSize));

    return wStackUsed * 4;
}
#if defined(__clang__)
#   pragma clang diagnostic pop
#endif

【后记】

在这篇文章中，我们介绍了栈和堆在存储器中的常见排布模型，比较了它们的优劣，并提出了一种被称为“两面包夹芝士”的两段式模型。该模型：

• 可以有效避免堆栈溢出破坏常规变量
• 溢出发生时可以在大部分芯片中第一时间触发异常——被我们捕捉到

后面，我们以MDK为例介绍了如何在Arm Compiler环境下应用这一模型，并引入了使用宏对其进行进一步拓展的方法。

值得说明的是，这一方法对Arm Compiler 5（armcc）和Arm Compiler 6（armclang）同样适用。支持MicroLib和非MicroLib的情况。无论启动文件是否为汇编，都可以正常工作。

实际上，使用链接脚本而非汇编启动文件来对两段式堆栈模型进行配置是Arm公司一直以来所提倡的。随着Arm Compiler 6的逐步普及，更多的芯片公司正在追随Arm的脚步将原本的汇编启动文件替换为 CMSIS 目录下所提倡的纯C语言启动文件。

作为【反复横跳】系列的一部分，我希望通过这篇文章能帮助大家扫清从Arm Compiler 5向Arm Compiler 6过渡图中与栈相关的障碍。希望对你有所帮助。

原创不易，

如果你喜欢我的思维、觉得我的文章对你有所启发，