局部变量表大小在编译期确定，由javac统计参数、局部变量及隐式临时变量所需slot数（32位类型占1个，long/double占2个，非静态方法首slot为this），写入code属性的maximum local variables字段，运行时不可修改。
局部变量表的大小在编译期就完全确定，它不随运行时数据变化，也不受多线程并发影响——但它的容量会间接制约方法嵌套深度和栈空间占用，从而影响高并发场景下的线程创建效率与栈溢出风险。
局部变量表的大小怎么在编译期定死
Java编译器（javac）在生成字节码时，会扫描方法体内的所有参数、显式声明的局部变量，以及编译器隐式插入的临时变量（如for循环索引、try-catch中的异常引用等），统计所需变量槽（Slot）总数：
- 每个boolean、byte、char、short、int、float、reference、returnAddress占1个Slot
- long和double占2个连续Slot（因64位宽度）
- 非静态方法的第一个Slot固定分配给this引用
- 最终结果写入方法Code属性的maximum local variables字段
这个值不可运行时修改。用javap -v反编译类文件，就能直接看到LocalVariableTable和max locals数值。
它为什么和“方法并发性能”有关联
局部变量表本身不参与线程竞争（它是线程私有栈帧的一部分），但它决定单个栈帧的体积，进而影响以下两个关键点：
- 线程栈总容量固定时（如-Xss512k），局部变量表越大 → 单个栈帧越宽 → 同一栈能容纳的嵌套调用层数越少 → 深递归或链式调用容易触发
StackOverflowError - 高并发场景下大量线程启动时，每个线程默认分配独立栈空间；若方法普遍使用大量局部变量，会导致单线程栈占用上升 → 在有限内存中可创建的线程数下降 → 表现为线程池饱和、请求排队、吞吐量下降
- 局部变量表是GC Roots之一：只要变量槽还持有对象引用，该对象就不会被回收；过度缓存或长生命周期引用会延缓对象释放，增加GC压力
实际优化建议
不是要删变量，而是有意识地控制局部变量表膨胀：
- 避免在方法内声明大量临时对象，尤其大数组或集合；考虑提取为成员变量（需注意线程安全）或复用对象
- 减少不必要的中间变量，例如
String s = obj.getName(); return s.toUpperCase();可简化为return obj.getName().toUpperCase();（编译器未必能完全优化掉Slot） - 对高频调用的小方法（如工具类、getter/setter），检查是否引入了隐式变量（如自动装箱、lambda捕获、try-with-resources生成的附加引用）
- 用
-XX:+PrintGCDetails和jstack辅助分析：若频繁出现java.lang.Thread.State: RUNNABLE但CPU不高，可能是栈空间争抢或深调用阻塞
局部变量表不是性能瓶颈本身，而是栈资源消耗的“刻度尺”。看清它怎么被算出来，才能在架构设计和代码审查中提前规避线程栈相关的隐性成本。
