结论先行

• 应该根据内存使用的生命周期，选择合适的内存空间
• 应该尽量使用连续内存
• 如果不想在设计封装性上付出太多代价，全部放入全局空间也比较可取

空间类型	特点
全局空间	生命周期最久，空间连续，变量分配紧致，但存在浪费物理内存的风险
栈空间	临时生命周期，但仍具有类似全局空间连续内存、变量分配紧致的优势 。不过，空间大小受限
堆空间	建议临时生命周期使用，但在连续内存视角上存在劣势，易形成碎片。不过，如果空间类型使用正确，碎片问题并不大
	临时生命周期内存，在不超过栈空间约束的情况下，可以考虑直接用栈空间

缘由

近段几乎有一股魔怔，想将全局空间内的某些大内存变量，给尽量放入栈空间、或次之放入堆空间，以利于全局空间仅有少部分共享数据。

此种想法，从系统以少量全局信息开始自举，以及设计上的封装性来看是非常好的，避免全局变量空间成为一个垃圾场，充满各种杂乱无章和飞线乱飞，让代码更容易被理解、维护。

但是，后来细细想想、根据已掌握的内存使用知识梳理了一下，这样做的实用价值并不算太大！

那么，让我们来聊聊这个问题 😃

推演

白话理论

• 机器结构倾向于临近访问，以利于CPU缓存、避免缺页处理

• • 缓存设计深入的、进一步的要求，则需要区分读写，进行读写分离，将读、写分块、分区存放，使得读内存区域具有cache友好性

---

• 无论全局空间、还是堆空间、栈空间，均在内存被真实访问的时间，才转化为物理内存占用

• • 无论哪种空间使用方式，在内存使用生命周期大致相同的情况下，真实占用物理内存差距并不大，而真实内存才是最宝贵的
• • 根据临时性的内存的生命周期，选择栈空间，或堆空间，相比较于全局空间，在真实内存占用量这块存在一定优势

---

• 虚拟内存空间与物理内存之间存在页表映射，倾向于页表数量比较少，甚至在必要场合使用巨页技术

• • 要尽量减少页表，最直接的要求就是申请量要少，甚至使用巨页技术

可以看到，以上内存使用约束带来的影响不同的，不见得都是正相关

如果变量全部在全局空间会怎么样

如果极端地变量使用内存全部存放在全局空间，那么除了设计上的劣势外，会具有一些什么好处呢？

• 空间连续，页表减少
• 变量分配紧致、内存碎片可能较少
• 在预防内存不足的场景具有相对优势

甚至由于在程序启动时，全局空间已由OS系统分配完毕，也就给OS在全局内存空间占用较多的时间，达到系统优化阈值之后，使用巨页的自动优化留下了空间。

不过，OS对全局空间占用比较大的场景，是否透明地采用巨页技术，仅是猜测，未经考证，但存在此种可能，看OS系统的进取心了！

补充劣势： 全局变量空间较大，笔者曾遇到valgrind检测失败的情况

---

栈空间

栈空间在线程创建时即进行申请，根据ulimit -s的限定，相当于一块连续的大内存，也拥有全局空间的优势和变量分配的紧致，但却是临时生命周期内存空间的乐园。

• 使用技巧：在main函数或Thread Entry函数入口处栈空间，与全局变量几乎具有同等的生命周期，而且具有良好的封装性

堆空间

因为堆空间内存申请、释放的时机，与内存大小的随机性，比较大可能存在内存碎片，建议对于典型、已知应用场景，使用拥有连续内存的用户自定义的内存分配器，进行管理。

内存碎片对于在堆空间存活时间长的内存空间比较敏感，如果内存空间都很临时，其实碎片的可能性也大为减小。

但，峰值场景值得警惕！

根据这个原则，开发者应对内存生命周期比较长的内存使用转化为全局空间，或用户自定义内存管理器所开辟的空间，避免形成内存碎片。

最后说点

虽然说针对于C 语言程序探讨问题，但我想因为C语言对于机器的优秀建模，所以，其它编程语言也大差不差。

对于此问题的认识来源于分析的方法：

• 抛出一个简单模型观察、观察
• 推演其极致情况，看看究竟
• 在理解和把握前两者之后，对混合情况进行分析、分析