零装箱规范是在微服务关键链路中主动规避非必要自动装箱/拆箱，依据基本类型与包装类在默认值、空安全性、内存开销和比较语义上的差异，按数据角色划分使用边界，并通过压测验证与工程工具保障落地。
零装箱规范不是消灭装箱，而是在微服务关键链路中主动规避非必要自动装箱/拆箱。核心依据是基本类型（如 int、long、boolean）与对应包装类（如 Integer、Long、Boolean）在默认值、空安全性、内存开销和比较语义上的本质差异。
聚焦高频场景识别装箱风险点
压测中暴露的隐性瓶颈，常不在数据库或网络，而在高频对象创建与 GC 压力——自动装箱正是典型诱因。例如：
- 一个每秒 5000 次调用的订单接口，若 DTO 中用 Integer status 接收参数，每次都会触发 Integer.valueOf()，可能新建对象；
- 后续逻辑中写 if (status == 1) 或 status + 1，又会隐式拆箱；
- 压测时 Young GC 频次陡增，Stop-The-World 时间拉长，RT 波动剧烈，但代码里找不到显式 new。
按数据角色划分使用边界
不靠经验判断，而是依据字段语义与生命周期特征做硬性约束：
- RPC 入参/出参 DTO、DB 实体类（POJO）属性 → 必须用包装类（Integer/Long/Boolean），保障 null 安全，兼容 JSON null 和数据库 NULL；
- 方法内临时变量、循环索引、状态标记位（如 retryCount、isProcessed）→ 强制用基本类型（int/long/boolean），避免任何装箱开销；
- 跨服务传递的 ID、金额、时间戳等强业务字段 → 在网关或 Feign 拦截器中“预解包”：接收用包装类，入口校验非空后转为基本类型，后续全程使用基本类型运算。
用压测数据验证规范有效性
同一接口两种写法，性能差距显著。以「商品库存扣减」为例：
- 有装箱版：DTO 含 private Long skuId; private Integer quantity;，接口内直接 if (quantity > 0) → 每次调用至少 2 次装箱/拆箱；
- 零装箱版：DTO 不变，但加校验 Objects.requireNonNull(req.getQuantity())，立刻转 int qty = req.getQuantity()，后续所有计算用 qty；
- 压测结果：QPS 提升 18%，Young GC 次数下降约 40%，99 线 RT 波动收敛明显。
配套工程实践保障落地
规范需工具链支撑才能持续生效：
- 静态检查：用 SonarQube 或自定义 Checkstyle 规则拦截“包装类参与算术运算”“基本类型用于 DTO 属性”等反模式；
- 监控告警：在 JVM 监控中接入 java.lang:type=MemoryPool,name=PS Eden Space 的 GC 频次与对象分配速率，设置阈值告警；
- 文档沉淀：将每类 DTO 字段的类型选择理由写入接口文档注释，例如 “quantity 使用 Integer：需支持前端不传该字段（即 null）语义”。
