2、内存模型基础：堆内存与栈内存、对象生命周期、GC对路由引擎的影响
聊路由引擎的内存优化，咱们得先搞清楚一个最基础的问题：你的对象到底住在哪？
我见过不少团队，一上来就怼各种缓存策略、压缩算法，结果发现性能瓶颈根本不在那。说白了，很多人连堆和栈都没分清楚，就开始调优了。这就像修车不看发动机，光擦轮毂——白费劲。
2.1 堆内存 vs 栈内存：两个世界
Java虚拟机把内存分成了两大块：堆（Heap）和栈（Stack）。这两个地方，管理方式完全不同。
| 对比维度 | 堆内存 | 栈内存 |
|---|---|---|
| 存储内容 | 对象实例、数组 | 局部变量、方法调用帧 |
| 生命周期 | 由GC管理，不确定 | 方法结束即释放 |
| 分配速度 | 较慢（需要GC） | 极快（压栈出栈） |
| 线程共享 | 所有线程共享 | 每个线程私有 |
| 大小限制 | 可配置，通常较大 | 固定，通常较小 |
你想想看，路由引擎里最频繁的操作是什么？是查表。每次查表，我们都会创建一些临时对象——比如路由键、匹配结果。这些对象如果全扔到堆里，GC压力会非常大。
核心原则：能用栈就别用堆。能复用就别新建。
我个人习惯，在路由引擎的热路径代码里，尽量用基本类型（int、long）代替包装类（Integer、Long）。为什么？因为包装类对象在堆上分配，而基本类型直接存在栈里。一次路由匹配可能涉及几十个字段，积少成多，差距就出来了。
2.2 对象生命周期：从生到死
一个Java对象，从new出来到被GC回收，大致经历这几个阶段：
- 创建：分配堆内存，执行构造函数
- 使用：被引用，参与业务逻辑
- 不可达：没有任何引用指向它
- 可回收：GC标记为垃圾
- 回收：内存被释放
嗯，这里要注意：对象不是一不可达就立刻被回收的。GC有自己的节奏。我遇到过一个问题：路由引擎在高峰期突然卡顿，一查发现是大量临时路由对象堆积在新生代，触发了频繁的Minor GC。
避坑指南：我曾经在路由引擎里用了一个HashMap来缓存临时匹配结果，每次请求都new一个新的Map。结果呢？新生代GC每秒触发几十次。后来改成ThreadLocal复用，GC频率直接降到了个位数。
对象生命周期对路由引擎的影响，主要体现在三个方面：
- 短命对象：路由匹配过程中的临时变量，最好控制在方法内部，让它们在栈上分配
- 长命对象：路由表本身、索引结构，这些应该尽量驻留在老年代，避免被频繁移动
- 中间对象：比如路由结果集，生命周期介于两者之间，需要合理控制大小
2.3 GC对路由引擎的影响
GC（垃圾回收）是Java的自动内存管理机制。听起来很美好，但实际用起来，GC是路由引擎性能的头号杀手。
为什么会这样？因为路由引擎对延迟极其敏感。一次路由匹配，通常要求在毫秒级甚至微秒级完成。而GC发生时，所有线程都会暂停（STW，Stop-The-World）。哪怕只暂停几十毫秒，对于高并发系统来说，可能就是一场灾难。
我画了一张图，帮你理解GC在路由引擎中的影响路径：
这张图想表达的核心逻辑很简单：GC一旦触发，路由引擎就得停。停多久？取决于GC算法和堆大小。CMS、G1、ZGC各有优劣，但不管哪种，都会产生暂停。
警告：千万别在路由引擎的热路径上频繁创建大对象。比如每次请求都new一个byte[1024]做缓冲区，这会让GC压力剧增。我见过一个案例，就因为这么一个小习惯，导致系统在流量高峰时GC暂停超过200ms，直接触发了熔断。
2.4 路由引擎的内存优化策略
基于上面的分析，我们可以总结出几条实用的优化策略：
- 对象池化：复用路由匹配过程中的临时对象，比如路由上下文、匹配结果容器
- 逃逸分析：尽量让对象不逃逸出方法，这样JIT可以把它分配到栈上
- 减少包装类：能用int就别用Integer，能用long就别用Long
- 控制对象大小：路由表中的每个节点，尽量紧凑排列，减少内存碎片
- 选择合适的GC：低延迟场景用ZGC或Shenandoah，吞吐量场景用G1
一个小技巧：我习惯在路由引擎启动后，手动触发一次Full GC，把初始化过程中产生的临时对象清理掉。这样运行时的GC压力会小很多。当然，生产环境要谨慎使用，最好配合-XX:+DisableExplicitGC参数来控制。
说白了，内存优化的本质就是管好对象的生和死。生的时候少分配，死的时候少回收。路由引擎这种对延迟敏感的系统，尤其要注意这一点。
嗯，关于内存模型的基础，我们就聊到这。记住一句话：堆是舞台，栈是道具间，GC是清洁工。想让演出流畅，就得让清洁工少干活。
公众号:蓝海资料掘金营，微信deep3321