实现“零垃圾产生”的关键是逻辑分层与解耦：1. 分离内存生命周期与业务语义，由契约层统一管理池化对象；2. 服务层封装无状态行为，参数用只读视图或池化引用；3. 模板化执行路径，输入输出强制使用固定容器；4. 上下文隔离+线程本地缓存，禁用动态集合与临时对象。
要让高频率调用的业务代码实现“零垃圾产生”，关键不在禁用GC，而在于让每一块内存的生命周期完全可控——这必须通过逻辑分层与解耦来达成。只有当数据的创建、使用、复用和释放被严格绑定到明确的职责边界上，才能避免随机分配、隐式拷贝、临时对象泛滥等典型垃圾来源。
1. 分离内存生命周期与业务语义
高频场景（如行情解析、订单匹配）中，90%以上的垃圾来自“为一次调用临时构造对象”。解耦的第一步，是把谁决定内存何时存在和谁决定业务如何执行彻底分开：
- 业务逻辑层只处理“做什么”——例如解析一条报文、计算一个指标、校验一个状态；它不负责 new 对象，也不持有原始 buffer
- 数据契约层统一管理内存——它预分配固定大小的结构体池（如 OrderPool、TickBuffer），并按需发放/回收；业务逻辑仅通过接口获取已初始化的实例引用
- 调用方（如网络IO线程）负责将原始字节流送入契约层，由契约层决定复用旧对象还是启用新槽位，而非交由业务函数内部判断
2. 服务层封装可复用行为，杜绝临时封装
避免在每次 HTTP 请求或消息回调里重复构造 DTO、VO、Request 类型。这些类型一旦脱离上下文即成垃圾：
- 定义无状态的服务函数，如
processTick(TickView view)，参数是只读视图（view）或池化对象引用，不接受原始 JSON 或 Map - 所有输入数据由网关层/适配器层完成解析与对象绑定，并复用池中实例；服务层不感知“从哪来”，只专注“怎么算”
- 输出也走契约约定：返回结构体指针、状态码、或写入预分配结果缓冲区，而非 new 一个 Result
3. 模板化执行路径，消除隐式中间态
高频逻辑常伴随条件分支、循环聚合、多阶段转换——这些是隐式对象产生的温床。用模板约束执行边界：
- 每个模板只做一件事：如“传感器原始数据 → 标准化浮点数组”，不叠加清洗、告警、存储逻辑
- 模板输入/输出强制使用池化容器（如 FixedSizeFloatArray、RingBuffer
），禁止返回 List 、Map 等动态集合 - 异常不抛出新对象，而是复用全局错误码枚举 + 预留日志槽位（log_id, timestamp, slot_index）
4. 上下文隔离 + 线程本地缓存
跨调用共享状态是高频场景中最隐蔽的垃圾源。解耦需配合运行时策略：
- 每个工作线程独占一组内存池（thread_local OrderPool），避免锁竞争导致的分配延迟或 fallback 到 malloc
- HTTP 路由、Agent Loop、定时任务等入口，统一注入 ContextHandle（非 Request 对象），其中只含 thread_id、tick_id、buffer_ref 等轻量元信息
- 禁止在 handler 中 new HashMap 存临时聚合结果；改用预分配的 HashTable
，容量固定、无扩容逻辑
