Java参数传递是值传递，仅复制基本类型值或引用类型地址，开销极小且固定；参数增多会增加栈帧局部变量表slot数量，增大单帧体积，深度递归时易触发StackOverflowError。
不是成正比，但存在明确的线性关系——参数数量越多，局部变量表占用的 slot 越多，栈帧初始开销越大；而值传递本身不引发额外内存复制，只复制参数值（基本类型是值本身，引用类型是地址值），所以开销极小且固定。
栈帧中参数存储的本质是 slot 分配，不是“复制内存块”
Java 方法调用时，JVM 为每个参数在栈帧的局部变量表中分配一个或多个 slot（每个 slot 宽度为 32 位）。例如：
- int、short、char、boolean、float、reference：各占 1 个 slot；
- long、double：各占 2 个连续 slot；
- 参数顺序从索引 0 开始排列，this（非 static 方法）占第 0 个 slot。
这属于栈上空间预留，是轻量级的指针/值写入操作，不是堆内存拷贝，也不涉及对象内容复制。
值传递的“复制”仅限于值本身，成本恒定且极低
Java 所有参数都是值传递，但复制内容取决于类型：
立即学习“Java免费学习笔记（深入）”；
- 基本类型（如 int、boolean）：复制的是 4 字节或 1 字节的原始值；
- 引用类型（如 String、List）：复制的是 4 字节（32 位 JVM）或 8 字节（64 位 JVM，通常开启压缩指针后仍为 4 字节）的对象地址值；
- 无论对象本身有多大（比如一个 10MB 的 byte[]），传递时只复制那个地址值，不复制对象内容。
真正影响性能的不是参数个数，而是栈帧总大小与递归深度
参数多 → 局部变量表变长 → 单个栈帧体积增大 → 在深度递归或高并发场景下，更容易触发 StackOverflowError。但这和“内存复制量”无关，而是：
- 栈空间总量有限（默认 -Xss1m）；
- 每个栈帧需连续分配，碎片不影响，但总深度受限；
- 方法体内部声明的局部变量也会占用 slot，和参数共同决定栈帧大小。
优化建议：关注设计，而非过度担忧参数复制
实际开发中无需为“参数多导致复制慢”焦虑，但应理性控制参数数量：
- 超过 5–7 个参数时，考虑封装为参数对象（POJO 或 record），提升可读性与可维护性；
- 避免在递归方法中堆砌大量参数，优先用不变状态 + 尾递归思想（虽 Java 不支持尾调用优化，但逻辑更清晰）；
- 若真遇到栈溢出，优先检查递归终止条件或调整 -Xss，而不是删参数——因为删参数对栈空间节省微乎其微，关键在帧总数和帧大小平衡。
参数传递机制本身高效稳定，问题往往出在方法职责过重或调用结构不合理。
