-xss是需严控、分治、让渡的约束参数，非“榨干”工具；盲目调小会触发outofmemoryerror或静默失败，应按连接模型、线程用途分级设置（如netty线程768k、tomcat线程256k、虚拟线程128k），并同步优化递归逻辑、深度限制及os/容器栈水位。
在分库分表+海量连接场景下，-Xss 不是用来“榨干”物理线程栈内存的工具，而是需要**严控、分治、让渡**的约束参数。盲目追求“榨干”，反而会触发 OutOfMemoryError: unable to create new native thread 或静默线程创建失败——这不是调优，是自毁。
先看清真实瓶颈：分库分表不等于高线程数
分库分表本身不直接增加 JVM 线程数；真正吃栈内存的是连接模型：
- 若用传统 JDBC + 每库每表配独立数据源 + 连接池（如 HikariCP），且每个连接池最小空闲连接设得过高（如 min-idle=20 × 16 分片 = 320），再叠加 Tomcat 同步线程池（maxThreads=500），总线程数可能轻松突破 800+ → 此时 -Xss 从 1m 降到 256k，可释放近 600MB 栈内存
- 若已迁移到 ShardingSphere-Proxy 或使用 Netty 异步驱动（如 R2DBC），实际工作线程常仅几十个，但单线程调用链极深（如解析分片路由规则→SQL重写→多数据源并发执行→结果归并）→ 此时需保障单线程栈够用，-Xss 反而要适度上浮（如 768k）
- 若启用 JDK 21+ 虚拟线程（
Thread.ofVirtual()），Carrier 线程才受 -Xss 约束，建议设为 128k；虚拟线程栈在堆中动态分配，不受此限
按连接生命周期分级设值
同一应用中，不同用途线程对栈深度敏感度差异极大，不能“一刀切”：
-
IO 处理线程（Netty EventLoop、ShardingSphere Worker）：调用链深、局部变量多 → 推荐
-Xss768k或-Xss1m -
业务请求线程（Tomcat HTTP 线程、Spring MVC Servlet 线程）：纯调度角色，不参与分片逻辑 →
-Xss256k已足够，避免因分片数增长导致线程总数失控 -
定时任务/异步补偿线程（Quartz、@Async）：通常递归浅、逻辑简单 →
-Xss192k即可，留出空间给连接池和业务线程 -
数据库连接池内部线程（HikariCP housekeeper）：仅做连接健康检查 →
-Xss128k安全冗余
必须同步做的三件事，比调 -Xss 更关键
参数只是安全边界，不是设计替代品：
- 所有分片路由、SQL 解析、结果合并逻辑，禁用深度递归；统一改用
Deque<routecontext></routecontext>+ while 循环驱动，栈帧完全在堆中，不受 -Xss 限制 - 在分片键解析、Hint 解析等入口处，强制加入深度计数器：
if (depth > 12) throw new IllegalArgumentException("Invalid sharding hint nesting") - 排查隐式递归：Lombok 的
@Data在循环引用实体上生成的toString()、Jackson 序列化分片上下文时的无限代理嵌套、AOP 对ShardingTransactionManager的重复代理 —— 这些 bug 调再大的 -Xss 也救不了
绕不开的系统级水位卡点
即使 JVM 参数合理，OS 和容器层仍会截断：
- Linux 执行
ulimit -s，确认软限制 ≥ 最大 -Xss 值（单位 KB）；例如设了-Xss1m，则需ulimit -s 1024或更高 - Docker/K8s 中，总栈内存 = 预估最大线程数 × -Xss；若容器 memory limit 为 4GB，按 1000 线程 × 512KB = 512MB 栈内存，尚有余量；但若设成 1000 × 1MB = 1GB，再叠加堆、元空间、本地内存，极易触达 cgroup 上限，线程创建失败无日志
- JDK 8u291 前 G1GC 下，-Xss 小于 256k 可能导致并发标记线程栈溢出；若仍在用该版本，
-Xss256k是底线，不可再降
