高吞吐Java REST服务：多对象实例与静态工具类实现选型

每秒数千请求的量级下，两种写法的性能差异小到可以完全忽略，不要为了臆想的GC开销牺牲代码可维护性，优先选择结构清晰、易测试的面向对象实现即可。

1. 你担心的“大量对象创建”开销，实际几乎可以忽略 #

很多人对JVM的对象分配、GC机制有过时的认知，实际上：

• 你写的Sample类是只有两个引用字段的小对象，64位JVM开启指针压缩的情况下，一个实例连对象头带字段总共才24字节，内存占用极小。
• 这种短生命周期的小对象，JVM会优先在线程本地分配缓冲区（TLAB）上分配内存，分配过程只需要移动栈指针，开销是纳秒级的，比一次最简单的字符串拼接还快。
• 这种用完即弃的短命对象会在Young GC阶段被回收，不管是G1、ZGC还是传统的Parallel GC，对这类对象的回收效率都极高。按每秒1万请求算（比你说的数千QPS还高几倍），每秒创建1万个Sample实例总内存才240KB，连1MB都不到，根本碰不到GC的压力阈值。我见过不少QPS十万级的线上服务，大量使用按请求新建上下文对象的写法，从来没在这块出现过性能问题。

2. 静态工具类写法没有你想的那么“赚”，反而有额外成本 #

你同事给出的参考代码本身就有语法问题：静态方法process不能直接调用非静态的processHelper，真要跑通得把所有辅助方法都改成静态，所有中间计算状态全靠参数层层传递：

• 一旦业务逻辑复杂、辅助方法多、中间状态多，参数列表会快速膨胀，代码可读性会直线下降。
• 静态方法和类强绑定，没法做接口抽象、没法继承重写、也没法Mock做单元测试，后续要加策略变种、做逻辑拆分的时候改造成本极高。
• 抠到底层性能的话，现代JVM的JIT编译器会对高频执行的实例方法做内联优化，实例方法和静态方法的调用开销几乎没有差异。而且你省下来的仅仅是Sample这个外壳对象的创建，业务逻辑里someComputation()生成的params对象、请求本身的SampleObject该创建还是要创建，根本省不下多少内存。

3. 这个场景的最优实践 #

• 不要做过早优化。性能瓶颈永远靠压测、靠JFR这类运行时诊断工具找，不要靠直觉猜。99%的REST服务性能瓶颈都在数据库IO、序列化、网络传输上，这种小对象创建的开销连性能瓶颈的前10名都排不上。
• 如果确实想做结构优化，可以把类里的无状态逻辑和请求上下文拆分：不随请求变化的通用逻辑抽成单例组件或者静态方法，每个请求独有的上下文（sampleObject、中间计算的params）要么保留现在的实例字段写法，要么作为参数传递即可，两种写法性能差异感知不到。
• 真要极端抠性能的话，也别用全静态方法的工具类，可以考虑对象池复用Sample实例，但对于几千QPS的场景来说，对象池的维护开销反而比直接新建对象还高，完全得不偿失。

补充一个常见误区：不是用了静态方法就不占内存，你把字段从对象实例挪到方法参数上，数据只是存在了虚拟机栈而不是堆里，内存占用一点没少，只是分配位置变了而已，这点差异对于业务服务来说没有任何实际价值。

内容的提问来源于stack exchange，提问作者Pankaj