从 GCC 到 JVM：编译期 vs 运行时，一次彻底讲透（体系篇）

一、从一个问题开始

在上一篇
为什么 C++ 要改函数名？一文讲透 gcc / g++ / C/C++ 混编本质
我们讲了：

• C++ 为什么要改函数名（name mangling）
• C/C++ 混编为什么会报错
• extern "C" 到底解决了什么

👉 但其实，这些问题背后，还有一个更大的问题：

为什么 C/C++ 的问题都发生在“编译阶段”， 而 Java / Android 的问题却常常发生在“运行时”？

二、核心答案（先给结论）

所有技术的本质，都在做一个选择：

• 把事情放在“编译期”做
• 还是放在“运行时”做

三、什么是编译期 vs 运行时？

✅ 编译期（Compile Time）

程序还没运行，编译器正在处理代码的阶段

👉 比如：

• gcc / g++ 编译
• 类型检查
• 函数符号确定
• 模板展开

✅ 运行时（Runtime）

程序已经运行，正在执行代码的阶段

👉 比如：

• JVM 执行字节码
• GC 回收内存
• JIT 动态优化
• 反射 / AOP

四、一个最关键的对比

编译期：提前做决定 运行时：延迟做决定

👉 用一句话总结：

提前 → 性能高 延迟 → 更灵活

五、两大世界：GCC vs JVM

1️⃣ GCC / C++ 世界（编译期为主）

源码 → 编译 → 机器码 → 直接执行

👉 特点：

• 函数调用关系在编译期确定
• 内存布局提前确定
• 没有运行时系统（几乎）

👉 举个例子：

int a = 1 + 2;

👉 编译后：

直接变成 3

👉 ✔️ 这就是：

把工作提前做完

2️⃣ JVM / Java 世界（运行时为主）

源码 → 字节码 → JVM执行

👉 特点：

• 方法调用运行时决定（多态）
• 类加载动态完成
• 有 GC / JIT

👉 举个例子：

Animal a = new Dog(); a.run();

👉 JVM 在运行时决定：

调用 Dog.run()

这就是：把决策推迟到运行时

六、为什么会有两种设计？

GCC（C/C++）的设计目标

👉 极致性能 + 可控性

👉 所以：

• 尽量在编译期解决一切
• 减少运行时开销
• 接近硬件

JVM（Java）的设计目标

👉 跨平台 + 灵活性 + 安全性

👉 所以：

• 推迟到运行时
• 动态优化（JIT）
• 支持反射 / 插件 / 热加载

七、核心取舍（一定要理解）

八、一个非常重要的理解模型

世界上所有语言，都在这条轴上： 编译期 ←──────────→ 运行时

👉 举例：

C → 极端编译期 C++ → 偏编译期 Java → 偏运行时 Python → 极端运行时

九、现代系统：不再“二选一”

现在的趋势是：

👉 编译期 + 运行时 混合

Android（ART）

安装时：AOT（编译期） 运行时：JIT（运行时）

☕ Java

编译：class 运行：JIT优化

🔧 C++

模板：编译期 虚函数：运行时

👉 ✔️ 本质：

把两种世界“融合”

十、回到上一篇的问题

❓ 为什么 C++ 会改函数名？

因为要在编译期区分函数（支持重载）

❓ 为什么要 extern "C"？

让函数回到“简单模式”（不改名）

👉 👉 本质：

都是编译期行为

十一、终极总结（建议记住）

编译期：提前做决定 → 性能 运行时：延迟做决定 → 灵活 C/C++：尽量编译期解决 Java：尽量运行时解决 现代系统：两者结合

这一篇我们建立了一个核心认知：

👉 编译期 vs 运行时

👉 下一篇我们来看一个更具体的系统：

AOSP（Android）为什么是“编译期 + 运行时”的混合系统？

写在最后

很多技术看起来完全不一样：

• gcc / g++
• JVM / ART
• C++ / Java

👉 但本质其实只有一件事：

👉 决策是在编译期做，还是在运行时做

一旦理解这个，你会发现：

👉很多复杂问题都会变简单