直接调小线程栈（-Xss）是分库分表海量连接场景下最见效的内存压榨手段——通过降低每个线程在虚拟地址空间中“占而不吃”的固定开销，800线程×1MB默认栈可省至256k，节省约600MB虚拟内存；需经摸底（jstack抽样）、试探（512k→384k→256k压测）、定值（确认无StackOverflowError等）三步实操，并配合有界队列、MySQL线程栈调优及虚拟线程落地。
直接调小线程栈（-Xss）是分库分表海量连接场景下最见效的内存压榨手段——不是省变量，而是砍掉每个线程在虚拟地址空间里“占而不吃”的固定开销。
先看为什么栈大小在此类场景特别敏感
分库分表后，应用层往往需维护数十甚至上百个数据源，每个数据源配独立连接池；若再叠加多租户、多分片路由、异步任务等逻辑，平台线程数极易突破500+。按默认 -Xss1m 计算：
- 800 个线程 × 1MB = 800MB 虚拟内存仅用于栈（不计堆、Direct Buffer、连接缓冲区）
- Docker 容器内存限制常为 1.5–2GB，栈就吃掉近半，极易触发 OOMKilled
- Linux 默认
/proc/sys/vm/max_map_count通常为 65530，1000+ 线程可能耗尽 mmap 区域，报 unable to create new native thread
安全下调的三步实操法
不能一刀切设成 128k，必须结合业务栈行为验证：
-
摸底：用
jstack <pid>抽样 10–20 个活跃业务线程，观察最大调用深度（如 WebFilter → Service → Mapper → DataSource → Netty ChannelHandler），若普遍 ≤ 15 层，说明无深度递归或复杂 AOP 嵌套 -
试探：从
-Xss512k开始，压测 15 分钟，检查 GC 日志是否新增StackOverflowError；再试-Xss384k→-Xss256k；IO 密集型（如基于 Netty 的分库路由网关）可压到-Xss192k -
定值：确认无
StackOverflowError、无 JNI 回调失败、无反射调用异常后，锁定参数；微服务常见终值为-Xss256k，比默认省 75% 栈空间
配合连接池与数据源设计放大效果
单调 -Xss 是节流，还需控源防爆：
- 禁用
LinkedBlockingQueue无参构造（即无界队列），改用有界队列（如ArrayBlockingQueue(200)）+CallerRunsPolicy，避免任务积压倒逼线程池扩容 - MySQL 连接层同步调优：
thread_stack=192k（MySQL 侧线程栈，与 JVM 分开），sort_buffer_size=1M、join_buffer_size=256K，避免高并发下连接内存雪崩 - 优先启用虚拟线程（Java 21+）承载分库分表的路由编排、结果聚合等轻量逻辑，平台线程池只留给真正阻塞 IO 或 CPU 密集型任务
哪些情况必须保留较大栈
以下场景若存在，-Xss 不宜低于 512k：
- 使用了全链路深度 AOP（如自定义事务传播 + 多级缓存拦截 + 审计日志切面）
- 存在手动或框架触发的深层递归（如树形权限计算、JSON Schema 递归校验）
- 大量调用 JNI 库（如加密 SDK、国产数据库驱动），其本地栈不可控
- 依赖老版本 Spring（
