运行时系统概述
说到编译器，很多人只盯着前端语法分析和后端代码生成。但我做了这么多年编译器，发现一个残酷的事实——不懂运行时系统，你写的编译器就是个半成品。运行时系统，说白了就是程序跑起来之后，背后那个默默支撑一切的「隐形管家」。
我个人习惯把运行时系统比作一个剧场的后台。前台是用户看到的程序逻辑，后台呢？演员怎么上场、道具怎么摆放、灯光什么时候亮——这些都是运行时系统在管。今天我们就来拆开这个后台，看看里面到底藏着什么。
核心观点：编译时做的是「规划」，运行时做的是「执行」。两者必须协同设计，否则就会出现「编译时觉得没问题，一跑就崩」的尴尬局面。
运行时系统的概念
运行时系统，英文叫 runtime system。它不是某个具体的软件，而是一整套支撑程序执行的机制。包括内存管理、类型检查、异常处理、垃圾回收等等。
你想想看，C 语言编译出来的程序，运行时系统其实很小——基本上就是 libc 库加上一些启动代码。但 Java 呢？JVM 本身就是一个庞大的运行时系统。为什么会有这种差异？
嗯，这里要注意：运行时系统的复杂度，直接取决于语言在设计时做了多少「运行时决策」。静态类型语言在编译时就把很多事情定死了，运行时只需要按部就班。动态语言呢？很多检查只能留到运行时去做。
我在项目中遇到过一件事：有个同事写了一个脚本语言，编译时完全不考虑运行时内存布局。结果跑起来之后，变量访问慢得像蜗牛。后来我帮他重新设计了运行时数据结构，性能提升了 10 倍。这就是典型的「编译时偷懒，运行时还债」。
运行时环境：栈、堆、静态区
运行时环境的核心，就是程序运行时的内存布局。一般来说，分为三个区域：栈（Stack）、堆（Heap）、静态区（Static Area）。每个区域都有自己的脾气，用错了就会出问题。
栈（Stack）
栈是函数调用的舞台。每次调用一个函数，系统就会在栈上分配一块空间，叫栈帧（stack frame）。里面放着局部变量、参数、返回地址这些东西。
栈的特点是什么？自动分配，自动释放。函数进去的时候压栈，出来的时候弹栈，干净利落。速度快，但空间有限。
我曾经踩过一个坑：在嵌入式系统里写递归函数，递归深度稍微大一点，栈就溢出了。程序直接崩溃，连个错误提示都没有。从那以后，我对递归就特别谨慎——能用循环解决的问题，绝不用递归。
避坑指南：栈空间通常只有几 MB。如果你在栈上分配大数组（比如 10MB 的局部变量），程序大概率会挂。我曾经见过一个新手把整个图片数据放在栈上，结果程序启动就崩——这就是典型的「栈溢出」。
堆（Heap）
堆是动态内存的仓库。你什么时候需要内存，就什么时候去堆上申请。用完了记得还回去（释放），否则就会内存泄漏。
堆的管理比栈复杂得多。需要记录哪些内存是空闲的，哪些被占用了，还要处理碎片问题。所以堆的分配速度比栈慢一个数量级。
我个人习惯：能用栈就不用堆。但有些场景没办法——比如数据大小在编译时不确定，或者需要在函数返回后继续存在，那就必须用堆。
| 特性 | 栈 | 堆 |
|---|---|---|
| 分配速度 | 快（移动指针即可） | 慢（需要查找空闲块） |
| 生命周期 | 函数调用期间 | 手动控制（或 GC 管理） |
| 空间大小 | 有限（通常几 MB） | 较大（可达 GB 级别） |
| 碎片问题 | 无 | 有（需要碎片整理） |
静态区（Static Area）
静态区存放的是全局变量、静态变量、字符串常量这些「从程序开始到结束一直存在」的数据。它在编译时就确定了大小和位置，运行时不会改变。
静态区又分两块：已初始化数据区和未初始化数据区（BSS）。BSS 段在程序加载时自动清零，所以全局变量默认是 0。
这里有个小细节：字符串常量通常放在静态区的只读部分。如果你试图修改它，程序会崩溃。我刚开始学 C 语言时就犯过这个错——char *p = "hello"; p[0] = 'H'; 然后程序就挂了。嗯，血的教训。
运行时数据表示
数据在运行时怎么表示？这个问题看似简单，但里面门道很多。不同的语言、不同的编译器，表示方式可能天差地别。
基本类型
基本类型（整数、浮点数、字符等）的表示相对直接。整数用补码，浮点数用 IEEE 754 标准，字符用 ASCII 或 Unicode。这些是硬件层面就定好的事情，编译器基本没有发挥空间。
但有一个坑：字节序（Endianness）。大端和小端的问题，在跨平台编程时特别容易出问题。我做过一个网络协议解析的项目，就是因为没注意字节序，解析出来的数据全是反的。调试了一整天才发现。
小技巧：如果你在写跨平台代码，可以用 union 来检测当前平台的字节序。或者直接用 htons、ntohl 这些函数做转换，省心省力。
复合类型
复合类型包括数组、结构体、联合体等。它们的表示就复杂多了。
数组在内存中是连续存放的。所以 arr[i] 的地址就是 base + i * sizeof(element)。这个计算在编译时就能完成，运行时只需要做一次加法。
结构体就麻烦了。因为内存对齐的存在，结构体成员之间可能有填充字节。为什么要有对齐？因为 CPU 访问对齐的数据更快。这是硬件层面的限制，编译器只能遵守。
我记得有一次优化一个网络包解析的代码，发现结构体的大小比预期大了不少。一查，原来是成员顺序没排好，导致填充字节太多。调整了一下顺序，结构体大小直接减少了 30%。
// 不好的顺序：有填充
struct Bad {
char a; // 1 字节
int b; // 4 字节，需要从 4 字节对齐地址开始
char c; // 1 字节
}; // 实际大小：12 字节（有 3 字节填充）
// 好的顺序：无填充
struct Good {
int b; // 4 字节
char a; // 1 字节
char c; // 1 字节
}; // 实际大小：8 字节（无填充）
对象模型
面向对象语言的运行时表示，是运行时系统设计中最有挑战的部分。核心问题有三个：方法分发、继承、多态。
以 C++ 为例，每个有虚函数的类都有一个虚函数表（vtable）。对象的内存布局中，第一个成员通常是一个指向 vtable 的指针。调用虚函数时，先通过 vptr 找到 vtable，再通过偏移找到具体的函数地址。
这个机制在编译时就已经规划好了。编译器会为每个类生成 vtable，并在构造函数中初始化 vptr。运行时只需要按照这个约定去查找即可。
Java 的对象模型更复杂一些。除了 vtable，还有对象头（mark word）、类指针、实例数据等。对象头里存了锁信息、GC 状态等运行时数据。这也是为什么 Java 对象比 C++ 对象更「重」的原因。
我做过一个 JVM 的简化实现，深刻体会到对象模型设计的重要性。一个糟糕的对象模型，会导致内存浪费严重，GC 效率低下，甚至影响整个程序的性能。
关键点：对象模型的设计，本质上是「编译时约定」和「运行时查找」的平衡。约定越多，运行时开销越小，但灵活性越差。反之亦然。
运行时系统的核心逻辑
说了这么多，我们来画一张图，把运行时系统的核心逻辑串起来。
这张图展示了运行时系统的核心脉络。编译时负责规划和生成，运行时负责执行和调度。两者通过代码段、数据段、元数据这些「契约」来协同工作。
说白了，编译时和运行时不是割裂的两个阶段，而是一个整体。编译时的决策直接影响运行时的效率，运行时的反馈也会影响编译时的优化策略。这就是为什么我们要把它们放在一起讲。
好了，运行时系统的概念、内存布局、数据表示，这些基础内容就讲到这里。下一节我们会深入具体的运行时机制，看看内存管理、异常处理、类型检查这些模块是怎么实现的。
公众号:蓝海资料掘金营，微信deep3321