Java参数传递不产生分配事件，本质是栈帧中局部变量表的值复制；需通过jstack看栈帧独立性、jmap查堆对象创建、jstat结合GC日志定位高频分配源头。
Java 中参数传递本身不产生可观测的“分配事件”，它只是方法调用时栈帧中局部变量表的值复制过程。监控重点不是“参数分配”，而是理解该过程在内存中的表现，并借助工具验证栈行为、排查因误解传递机制引发的问题（比如误以为能通过参数修改影响外层变量）。下面从三个实用角度展开：
看栈帧结构：确认每次调用是否真有独立副本
参数值复制发生在虚拟机栈上，每个方法调用都会创建新栈帧。你可以用 jstack 抓取线程快照，观察递归或高频调用时栈深度和帧数量变化：
- 运行
jstack，搜索目标方法名，数一数同名方法出现的次数——每层递归对应一个独立栈帧 - 若看到栈深度持续增长（如超过 1000 层）且未回落，说明局部变量（含参数）持续堆积，可能隐含无限递归或未及时返回
- 注意：jstack 不显示局部变量值，但它能证实“多份 depth 变量共存于不同帧中”这一事实
查内存分布：区分栈上参数与堆上对象引用
基本类型参数（如 int、boolean）全程只在栈上，不涉及堆；而引用类型参数（如 List、String）的“值”是地址，该地址存于栈，所指对象本身在堆。可用 jmap -histo 辅助判断：
- 执行
jmap -histo:live，关注高频出现的小对象（如 Integer、String、ArrayList）——它们常由方法内新建并作为返回值或中间变量被持有 - 若某类实例数量突增，且代码中大量出现在方法体内 new 出来（如
new ArrayList()作为参数传入又未释放），说明参数相关逻辑触发了堆分配 - 注意：参数本身不分配堆内存，但方法体内的 new 操作会——这是真正需要监控的分配点
结合 GC 日志与 jstat：定位高频分配源头
参数传递不会直接导致 GC，但若方法频繁调用且内部创建大量短期对象（如 StringBuilder、临时数组），就会推高 Eden 区消耗。这时需联动分析：
- 启动时加参数：
-XX:+PrintGCDetails -XX:+PrintTenuringDistribution - 用
jstat -gcnew观察 Eden 使用率是否秒级飙升、Minor GC 是否密集（如 2 秒一次）1000 - 若 Eden 快速填满，再查 GC 日志中
Desired survivor size和实际晋升老年代的对象量——若大量对象“跳过”Survivor 直接晋升，说明方法内创建了大对象或生命周期远超预期
不复杂但容易忽略。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
