将数组作为类成员变量而非递归参数传递，虽能减少每次调用的参数压栈开销，但对整体性能影响微乎其微；真正决定性能的是算法复杂度、内存局部性与实际运行时行为，而非参数传递方式本身。
在归并排序这类深度递归算法中，是否将 int[][] arr 从方法参数提升为类字段（即“封装”），常被开发者视为一种“性能优化”。我们来客观分析其实际影响。
✅ 理论上：参数传递开销确实存在，但极小
Java 中，数组是引用类型，mergeSort(int[][] arr, ...) 传递的只是一个 4 字节（32 位 JVM）或 8 字节（64 位 JVM，未开启压缩指针）的引用地址，并非整个数组拷贝。因此，每次递归调用压入栈的仅是一个指针值。以深度为 O(log n) 的归并排序为例，总栈空间节省量仅为 O(log n) × 8 字节 —— 对于百万级数组，也不过几十字节，可忽略不计。
❌ 封装带来的隐性代价更值得关注
将 arr 提升为实例字段后，代码将面临以下问题：
- 线程不安全：MergeSort 实例不再可重入。若多个线程共用同一实例调用 mergeSort()，会因共享 arr 导致数据污染或 NullPointerException；
- 状态耦合增强：对象生命周期与数组绑定，无法复用同一实例对不同数组排序；
- 测试与维护成本上升：需显式构造 + 设置数组，违背“函数即操作”的清晰契约。
// ❌ 不推荐：有状态、不可重入 MergeSort sorter = new MergeSort(); sorter.arr = myArray; // 显式赋值易出错 sorter.mergeSort(0, myArray.length); // ✅ 推荐：无状态、纯函数式风格 MergeSort.sort(myArray, 0, myArray.length); // 静态方法，输入即确定输出
✅ 更有效的性能优化方向
若真实关注归并排序性能，应优先考虑：
- 避免重复创建临时数组：在递归前一次性分配 temp[] 并复用；
- 引入插入排序阈值：对长度 ≤ 10 的子数组改用插入排序（减少递归开销）；
- 使用迭代版归并排序：彻底消除递归调用栈（适用于超深递归风险场景）；
- 启用 JVM 逃逸分析：现代 HotSpot 可能将短生命周期数组栈上分配（无需 GC），但依赖运行时分析，不建议主动依赖。
✅ 总结：设计优先于过早优化
参数封装不是性能瓶颈，而是设计权衡。Java 的设计理念强调清晰性、可维护性与安全性。牺牲这些去换取几乎为零的栈空间收益，是典型的“过早优化”。应坚持：
? 优先使用静态工具方法（无状态、线程安全）；
? 若需封装，确保实例为 stateless 或明确标注 @ThreadSafe；
? 性能瓶颈务必通过 JMH 基准测试验证，而非直觉猜测。
真正的高性能代码，始于正确的抽象，而非微观的参数位置。
