Java中数组拼接的空间开销主要由输出数组分配决定，两段代码均创建相同大小的int[2*n]堆对象，理论空间复杂度同为O(n)；实测微小差异（44.42 MB vs 44.72 MB）源于JVM运行时非确定性行为（如GC时机、内存对齐、栈帧布局），而非算法本身的空间设计优劣。
java中数组拼接的空间开销主要由输出数组分配决定，两段代码均创建相同大小的`int[2*n]`堆对象，理论空间复杂度同为o(n)；实测微小差异（44.42 mb vs 44.72 mb）源于jvm运行时非确定性行为（如gc时机、内存对齐、栈帧布局），而非算法本身的空间设计优劣。
在LeetCode等在线判题平台中，开发者常被“内存使用量”排行榜误导，误将毫秒级波动的运行时指标当作算法空间效率的可靠依据。以本题两个实现为例：
-
Code (1) 使用双循环逻辑（通过
i = -1和count控制两次遍历），含额外变量k、count及分支判断； -
Code (2) 采用简洁的单循环+取模运算：
arr[i] = nums[i % n]。
表面看，Code (1) 控制流更复杂、局部变量更多，理应消耗更多栈空间；但实测其内存占用（44.42 MB）反而略低于Code (2)（44.72 MB）。这一现象恰恰揭示了Java内存分析的核心前提：不能脱离JVM运行时机制空谈“代码复杂度→内存开销”。
▶ 真正决定空间复杂度的是什么？
根据《Java虚拟机规范》，方法执行所需内存分为两类：
-
栈内存（Stack）：存储局部变量、操作数栈、动态链接与方法出口。Code (1) 多2个
int变量（k,count），理论上栈帧略大，但现代JVM会进行栈帧压缩与标量替换（Scalar Replacement），若变量未逃逸，甚至可能完全消除栈空间占用； -
堆内存（Heap）：存放所有对象实例。两段代码均执行
new int[2*n]，这是唯一主导空间复杂度的显式分配，时间复杂度O(1)、空间复杂度O(n)，二者完全一致。
✅ 结论：两者渐进空间复杂度均为 Θ(n)，无优劣之分。44.42 MB 与 44.72 MB 的差异属于JVM运行时噪声，不可作为算法评估依据。
立即学习“Java免费学习笔记（深入）”；
▶ 为什么实测值会有微小差异？
该差异反映的是JVM内存管理的工程现实：
-
内存对齐策略：JVM按8字节边界对齐对象，不同编译路径可能导致
arr起始地址偏移不同，影响页内碎片； - GC触发时机：Code (1) 执行稍慢（多分支跳转），可能恰在Minor GC前完成分配，而Code (2) 运行更快，触发GC后重分配，导致统计口径不一致；
-
JIT编译器优化差异：HotSpot对简单循环（Code 2）可能激进内联，但取模运算
i % n在某些场景下需调用Math.floorMod辅助函数，引入临时对象；而Code (1) 的显式索引虽冗余，却规避了取模开销。
可通过以下代码验证规模效应：
// 测试1MB数组（n=250_000） int[] nums = new int[250_000]; for (int i = 0; i < nums.length; i++) nums[i] = i; // 分别运行两种getConcatenation → 观察内存波动是否收敛
当n从10³增至10⁶，两方案内存差值通常稳定在±0.1 MB内——证明差异与输入规模无关，纯属运行时抖动。
▶ 工程实践建议
- 拒绝迷信平台内存排名：LeetCode的“Memory Usage”是单次JVM进程快照，应关注多次运行的中位数或标准差；
-
优先保障可读性与正确性：Code (2) 逻辑清晰、无状态副作用，符合Java编码规范，维护成本远低于Code (1) 的
i = -1魔改； -
深度性能分析需专业工具：使用
jstat -gc监控GC行为，或-XX:+PrintGCDetails日志，配合JProfiler/VisualVM定位真实内存瓶颈。
归根结底，算术密集型（arithmetic-heavy）代码在Java中并不天然导致更高内存占用——内存消耗由对象分配主导，而计算密度影响的是CPU缓存命中率与执行时间。若真追求极致性能，应转向System.arraycopy()的底层JNI优化（如Arrays.copyOf(nums, 2*nums.length)），它利用硬件DMA直接搬运内存，零Java层循环开销。
真正的“高效”，永远始于对抽象层级的清醒认知：在JVM之上写代码，要敬畏规范，而非挑战统计噪声。
