不能通过JVM参数直接评估ForkJoinTask单个递归栈帧内存开销，因其由JVM方法调用机制决定，取决于参数类型、局部变量数及操作数栈深度；可借助javap -v、jstack和禁用JIT等手段间接估算。
不能通过 JVM 参数直接评估 ForkJoinTask 中单个递归栈帧的物理内存开销。
栈帧开销不由 ForkJoinTask 控制，而由 JVM 方法调用机制决定
ForkJoinTask 本身是堆上对象，其执行仍依赖线程栈；真正产生栈帧的是它内部 compute() 方法的递归调用（或子任务的 invoke()、fork()/join() 链），而非 ForkJoinTask 实例本身。JVM 参数如 -Xss 控制的是整个线程栈容量，无法拆分到“每个 compute 调用占多少字节”这种粒度。
栈帧大小在方法编译为字节码时就已静态确定，取决于：
- 参数个数与类型（每个 long/double 占 2 个 Slot，其余占 1 个）
- 局部变量表中声明的变量数量（含隐式 this、方法参数、显式变量）
- 操作数栈最大深度（由字节码指令流决定，如嵌套表达式、多维数组访问会推高）
可间接估算单帧大小的实操方法
没有运行时 API 返回某帧精确字节数，但可通过组合手段逼近：
- 用 javap -v 查看字节码：关注 LocalVariableTable 条目数和 max_stack 值，二者共同决定最小栈帧空间（Slot 数 × 4B 或 8B + 操作数栈预留）
- 用 jstack 定位深度趋势：对同一 ForkJoinTask 子类的 compute() 方法，在 jstack 输出中统计连续出现次数（如 327 次），再结合 -Xss1m 得出平均帧≈3KB；若换用 -Xss512k 后崩溃在 160 层，则反推单帧≈3.2KB
- 禁用 JIT 编译对比：加 -XX:-TieredStopAtLevel1 强制解释执行，排除内联优化对栈帧合并的影响，使递归调用链更“真实”地反映原始帧结构
注意 ForkJoinPool 带来的特殊干扰
ForkJoinTask 的 fork/join 不是传统方法调用，但 compute() 内部递归仍压栈。常见误区：
- 以为用 ForkJoinPool 就“没栈溢出风险”——错，compute() 里写
if (n > 0) compute(n-1);一样会 StackOverflowError - 以为 virtual thread + ForkJoinPool 能消除栈压力——错，虚拟线程仍绑定 carrier 线程栈，默认也是 1MB，只是初始栈小（约256B），扩容后同样受限于 -Xss
- 大量创建 ForkJoinTask 实例本身吃堆内存，但不直接影响栈帧大小；不过若 task 对象持有大数组引用，可能让局部变量表膨胀，间接增大对应栈帧
真正可控的调优点不在参数，而在代码结构
与其纠结单帧几字节，不如从源头压缩：
- 把递归逻辑改为循环 + 显式栈（如用 ArrayDeque 存参数），完全脱离 JVM 栈限制
- 在 compute() 中避免声明大对象（如 new byte[1024]）、长字符串拼接、未关闭的 Stream
- 用 @SuppressWarnings("unchecked") 替代泛型强转，减少桥接方法生成的额外栈帧
- 对深度可控场景，加 depth 参数并校验：
if (depth > 1024) throw new RuntimeException("Recursion too deep");
