容器内线程栈配置不当可数秒耗尽宿主机内存：java默认每线程1mb栈，500线程即占500mb堆外内存；叠加虚拟线程、directbuffer、元空间易超rss limit致oomkilled。
容器里线程栈大小配得不合理，真能几秒内把宿主机内存干崩——尤其 Java 应用默认每线程 1MB 栈，起 500 个线程就吃掉 500MB 堆外内存；再叠加虚拟线程、NIO DirectBuffer、元空间膨胀，RSS（实际驻留内存）轻松突破容器 limit，触发 OOMKilled。这不是 JVM 报错，是系统直接杀进程，毫无缓冲。
先搞清谁在吃栈内存
不是只有“线程数 × -Xss”这么简单：
-
平台线程（Platform Thread）：每个都独占固定栈，默认 1MB（Linux x64），由
-Xss控制 -
虚拟线程（Virtual Thread）：底层仍需载体线程执行，其栈大小受
-Xss和-XX:ThreadStackSize共同影响；虽按需分配，但深度递归或大量局部变量会触发栈扩容 - JNI/C 代码栈：JVM 调用本地库时可能额外开栈，不受 JVM 参数约束
- 线程创建本身开销：每个线程除栈外，还有线程对象、TLS（线程本地存储）、glibc 管理结构等，约几十 KB
高并发场景下推荐的栈大小配置
别死守默认值。根据真实负载压测后调：
-
微服务/API 网关类应用：线程数常达数百~数千，建议
-Xss256k或-Xss384k；配合--pids-limit=512（Docker）防 fork 炸弹 -
含深度递归或复杂表达式解析的服务：如规则引擎、编译器后端，可设
-Xss768k，但必须同步压测 RSS 上限，确保不突破容器--memory -
大量使用虚拟线程（Java 21+）：显式加
-XX:ThreadStackSize=512（单位 KB），避免载体线程栈过大；同时用-XX:MaxVectorSize=256k限制向量化调用栈深度
必须和容器限制对齐的三件事
光调 -Xss 不够，要让它真正生效：
-
容器内存 limit 必须 ≥ 预估最大栈占用：例如设
--memory=1g，则线程数上限 ≈ 1024MB ÷ 256KB ≈ 4000 个（仅算栈，未含堆/元空间）；实际建议留 30% 余量 -
JVM 必须启用容器感知：加
-XX:+UseContainerSupport，否则它仍按宿主机内存算默认值，-Xss可能被忽略或误判 -
验证是否真生效：启动时加
-XX:+PrintGCDetails，看 GC 日志首行是否有类似MaxHeapSize = ...且MaxRAM=...显示的是容器 limit（如 1073741824），不是宿主机总内存
快速定位栈异常增长的方法
上线后发现 RSS 持续上涨？别只看堆：
- 进容器执行
cat /proc/self/status | grep VmStk：查当前 JVM 进程栈总用量（KB） - 用
jcmd <pid> VM.native_memory summary</pid>查 NMT 报告，重点关注Thread和Internal区域 - Docker 侧监控：
docker stats --no-stream 容器名对比MEM USAGE和limit，若 usage 接近 limit 但堆内存（jstat）很低，大概率是栈或堆外泄漏
