背景摘要本文通过分析某合约交易系统批量下单接口的高频调用链识别出三处关键堆分配优化点1消除中间参数载体 record节省 560 bytes/调用2集合按实际大小预分配3Log Guard 内消除重复 Getter 调用。优化后该路径 Young Gen 短命垃圾从 6.33 MB/s 降至 0.99 MB/s每秒减少 5.34 MB 分配压力。文章详细介绍了分析方法、优化实现、量化收益及对象大小估算方法强调编译期确定性优化优于依赖 JIT 标量替换。某合约交易系统的机器人批量下单接口在高峰期承受1 万次调用/秒每次携带 10 笔订单。通过对调用链逐层做堆分配分析发现多处可消除的冗余分配优化后将此路径的 Young Gen 短命垃圾从6.3 MB/s 降至 1.0 MB/s。分析方法对调用链每一层方法重复 5 步签名/入参区分栈分配原始类型与堆分配对象引用逐行分配点标注每个new、装箱、字符串拼接7 类隐藏分配日志装箱、Builder 临时对象、Lambda 捕获、Iterator、泛型装箱、Optional/Stream、异常对象下层调用递归向下分析逃逸分析对象是否逃逸方法边界——不逃逸的对象 JIT 有机会栈分配调用链全景简化BatchOrderBiz.batchCreate(param) ← RPC 入口 └── OrderValidator.validate(param) ← 校验通过返回 null零分配 └── OrderService.batchCreate(param) ← 主流程 ├── ContractConfig.get(contractId) ← 外部缓存 ├── prepareContext(uid, ...) ← 准备上下文 └── for each SimpleOrder in param: ← 热循环 ├── IdempotentService.check(clientOrderId) └── RequestBuilder.buildBatch(...) ← 构建撮合请求 ├── CommonOrderParams.fromBatch(...) ← ⚠️ 中间 record每笔分配一次 └── buildCommon(params) ← 填充最终请求对象热点分配源 TOP 5排名分配源估算/笔是否必要1CommonOrderParams中间 record~56 bytes否可消除2最终请求对象传给撮合引擎~300 bytes是3ArrayList扩容中间数组视批量大小否可预分配4日志参数Object[] int 装箱~32 bytes/条否guard 可覆盖5RPC 返回值包装对象~48 bytes是三项优化优化 1消除中间参数载体 record核心问题每次buildBatch调用都先构造一个 15 字段的CommonOrderParamsrecord~56 bytes仅用于向下传参随即成为垃圾// Before每笔订单在循环内分配一个临时 recordpublicstaticPlaceOrderRequestbuildBatch(...){PlaceOrderRequestreqbuildCommon(CommonOrderParams.fromBatch(batchParam,simpleOrder,symbol,feeRate));// ↑ 56 bytes生命周期 1 方法调用req.setOrderId(orderId);returnreq;}// After内联消除直接访问原始参数publicstaticPlaceOrderRequestbuildBatch(...){PlaceOrderRequestreqnewPlaceOrderRequest();byteorderTypebatchParam.getType();// 直接读 batchParamreq.setSide(simpleOrder.getSide());// 直接读 simpleOrderreq.setPrice(simpleOrder.getPrice());// ... 其余字段同样直接填充无中间对象returnreq;}为什么不依赖 JIT 标量替换JIT C2 的逃逸分析EA理论上可以对不逃逸的对象做标量替换scalar replacement消除堆分配。但以下任一条件都会阻止它buildCommon字节码超过内联限制-XX:MaxInlineSize默认 35 字节内联失败 → EA 无法跨方法传播冷启动阶段未达到 C2 编译阈值默认 10,000 次均为解释执行调用图复杂度超出 EA 分析范围手动消除让优化从「JIT 可能做」变为「编译期确定」冷启动同样受益。优化 2集合按实际大小预分配// Before两个列表均懒分配默认容量 10且 orders 赋值顺序靠后ListStringduplicatedIdsnewArrayList();ListRequestrequestListnewArrayList();ListOrderordersparam.getOrders();// AfterListOrderordersparam.getOrders();intnorders.size();ListStringduplicatedIdsnewArrayList();// ← 保持懒分配ListRequestrequestListnewArrayList(n);// ← 预分配关键细节——两个列表策略不同requestList预期承载 ~n 个元素 → 按 n 预分配避免扩容duplicatedIds重复订单是异常情况正常路径为空。new ArrayList()的 backing array 是类级共享静态数组零额外堆分配若改为new ArrayList(n)反而在正常路径多分配16 4nbytesN20 时requestList不预分配的扩容代价Object[10]56B → Object[15]76B → Object[22]104B 累计分配 236B / 132B 成垃圾 / 2 次 arraycopy预分配后Object[20]96B一次到位。优化 3Log Guard 内消除重复 Getter 调用// BeforegetOrders() 调用两次if(logConfig.isEnabled(uid,contractId)){intcountparam.getOrders()null?0:param.getOrders().size();log.info(entry uid{} count{},uid,count);}// Afterif(logConfig.isEnabled(uid,contractId)){varordersparam.getOrders();intcountordersnull?0:orders.size();log.info(entry uid{} count{},uid,count);}无内存影响消除一次冗余方法调用属代码质量修复。量化收益场景1 万次调用/秒每批 10 笔订单每次调用每秒优化前改动涉及部分664 bytes6.33 MB/s优化后改动涉及部分104 bytes0.99 MB/s节省560 bytes5.34 MB/s节省来源拆解N10改动节省/调用占比消除CommonOrderParams× 10560 bytes100%requestList预分配0 bytesN10 恰等于默认容量 100%重复 Getter 修复0 bytes0%requestList预分配对 N10 无收益N 10 开始产生收益N50 时可额外节省 664 bytes/调用。Young Gen 压力每秒消除 10 万个CommonOrderParams短命对象56 bytes 级别对应5.34 MB/sYoung Gen 短命垃圾。以 Eden 200 MB 估算仅此路径的填充速率从 5.34 MB/s 降至接近 0minor GC 频率相应降低。对象大小估算方法以 HotSpot JDK 21、compressed oops堆 32 GB为基准Object 大小公式对象大小 12 bytesheader 字段大小按类型对齐→ 上取整到 8 bytes字段类型大小compressed oops引用Object ref4 bytesint / float4 byteslong / double8 bytesbyte / boolean1 byteObject header12 bytesArrayList 内存布局ArrayList 对象 24 bytesheader 12 size 4 modCount 4 ref 4 Object[] 数组 16 bytesheader 4 bytes × capacity new ArrayList() backing array 懒分配首次 add 才分配 Object[10] new ArrayList(n)立即分配 Object[n]CommonOrderParamsrecord15 字段header 12 bytes 6 个引用字段 24 bytes 2 个 int 字段 8 bytes 7 个 byte 字段 8 bytes含对齐 padding 合计 52 → 对齐到 56 bytes经验总结1. 中间参数载体是热路径隐性成本Builder、VO、record 用作参数传递时若在循环内调用且生命周期极短优先考虑内联消除不依赖 JIT。2. 集合预分配要区分语义集合语义策略预期有 N 个元素正常路径new ArrayList(n)通常为空异常路径new ArrayList()懒分配盲目预分配所有集合可能在正常路径反而多分配。3. JIT 标量替换不是底线代码优化应在编译期确定JIT 是锦上添花。内联限制、冷启动、EA 传播失败都会让「JIT 应该能优化」的假设落空。4. 热路径日志 guard 要彻底isEnabled()guard 内部的重复计算同样需要消除即便是看似廉价的 getter在高频路径下也值得审查。5. 量化是排优先级的前提「5.34 MB/s 短命垃圾」这个数字决定了此改动是否值得做。没有量化的优化讨论无法取得共识。