jstack用于查看Java进程线程堆栈，基本命令为jstack ，支持-l（显示锁详情）、-F（强制dump）、-m（混合模式）等参数；可定位死锁、高CPU线程及响应缓慢问题。
怎么确认当前-Xss值是否真不够用
直接看StackOverflowError堆栈不是判断依据——它只说明“这次爆了”，但可能是代码 bug（比如 equals 里误调自己），也可能是线程栈真不够。先做两件事：
用 jstack 抓活跃线程，重点看报错线程的栈帧数（通常超 2000 层就值得怀疑）；
加 -XX:+PrintGCDetails -XX:+PrintConcurrentLocks 启动，排除 GC 或锁竞争干扰；
检查日志框架、AOP、JSON 序列化（如 Jackson 的 ObjectMapper）、正则表达式（尤其带回溯的）这些“隐式深调用”高发区。
Linux 64 位下-Xss常见安全取值范围
OpenJDK 17+ 在 Linux 64 位默认是 -Xss1m，但这只是保守值，不是最优值：
纯 HTTP 请求处理（Spring Boot + Tomcat/NIO）、无深度递归、局部变量少 → -Xss256k 多数够用；
含 JSON/XML 解析、模板渲染、复杂规则引擎 → 建议从 -Xss512k 起步；
明确有树形遍历或编译器类逻辑 → 可试 -Xss1m，但必须同步压测；
绝对不要设 -Xss4m 以上，除非你只跑单线程且已验证调用链深度稳定超 8000 层；
注意：Docker 容器里要同步配 --ulimit stack=262144:262144，否则内核会拒绝小栈启动。
调小-Xss后突然出现StackOverflowError怎么办
这不是参数错了，是暴露了原来被大栈掩盖的问题：
检查所有重写的 equals、hashCode、toString 方法，确认没循环引用；
查 AOP 切面是否对同一方法重复代理（比如事务+缓存+日志三层代理，调用链翻三倍）；
禁用 spring-boot-starter-validation 的级联校验（@Valid 嵌套太深），改手动校验；
把 Jackson 的 ObjectMapper 设为单例并复用，避免每次 new 都触发反射调用链；
用 -XX:StackTraceLimit=2000（默认 1024）让堆栈打印更全，定位到底哪一层开始异常膨胀。
高并发服务里-Xss和线程数的硬约束关系
总栈内存 = 线程数 × -Xss 值，这个和堆内存无关，但受 OS 地址空间限制：
假设你预期 2000 并发线程，设 -Xss1m → 光栈就占 2GB 虚拟内存；
设 -Xss256k → 同样线程数只要 500MB，省下的 1.5GB 可留给堆或元空间；
但别只算数学账：用 Runtime.getRuntime().availableProcessors() 看 CPU 核数，如果只有 4 核却开 2000 线程，瓶颈根本不在栈，而在上下文切换；
更关键的是 /proc/sys/kernel/threads-max 和 ulimit -u，这两个值低于你算出的理论线程数，-Xss 再小也没用。
实际调参时最容易被忽略的点：-Xss 改变后，必须重跑全链路压测，不能只测单接口。很多 StackOverflowError 出现在异步回调、CompletableFuture.thenCompose 链、或者自定义 ClassLoader 加载 class 的瞬间——这些路径平时不走，压测流量一上来才暴露。
