线程池核心线程数与jvm私有栈内存呈可估算的线性关系：总私有栈内存≈核心线程数×-xss，但仅为虚拟内存上限，实际物理占用按需增长；空闲线程栈使用极少，深度调用才趋近-xss上限。
线程池核心线程数与JVM私有栈内存总消耗之间没有直接乘法关系，但存在可估算的线性关联：总私有栈内存 ≈ 核心线程数 × 单线程栈大小（-Xss值），前提是这些线程已全部启动并驻留。
核心线程数不等于实际栈内存占用
核心线程在空闲时默认不会销毁（除非设置allowCoreThreadTimeOut=true），但“存在”不等于“持续占用满栈空间”。栈内存是按需增长的——刚创建的线程只分配栈结构，局部变量和方法调用才逐步压入栈帧。因此：
- 刚初始化的100个核心线程，若都处于
WAITING状态（如阻塞在线程池的workQueue.take()），实际栈使用可能仅几百字节/线程 - 若全部并发执行深度递归或大量嵌套调用，才接近-Xss上限
- 操作系统为每个线程预留的是虚拟内存（virtual memory），物理内存（RSS）按需提交
单线程栈大小由-Xss决定，非固定物理占用
-Xss参数设定的是**每个线程栈的虚拟地址空间上限**，不是实时物理内存消耗。例如：
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
-
-Xss256k→ 每个线程最多可用256KB虚拟地址，但初始可能只用8KB - Linux x64 HotSpot 默认值通常为1MB，Windows略低
- 过小（如64k）易触发
StackOverflowError；过大（如4m）会快速耗尽进程虚拟地址空间，导致OutOfMemoryError: unable to create new native thread
总私有栈内存 = 核心数 × -Xss 是理论峰值上限
这是用于容量规划的保守估算模型，适用于以下场景：
- 评估JVM进程最大可支持的核心线程数：
可用虚拟内存 ÷ -Xss ≤ 最大线程数 - 排查
unable to create new native thread：检查系统级限制（ulimit -u）、JVM堆外内存总量、以及-Xss是否过大 - 对比不同线程池配置的内存压力：比如将
newFixedThreadPool(200)搭配-Xss512k，理论栈虚拟内存占用约100MB
别忽略其他线程私有区的开销
除虚拟机栈外，每个线程还独占：
- 程序计数器（几乎可忽略，几字节）
- 本地方法栈（若调用JNI，受
-XX:NativeMemoryTracking影响） - 线程自身对象（
java.lang.Thread实例）及附属结构（如ThreadLocal哈希表）
这部分开销虽小，但在万级线程场景下不可忽视，尤其ThreadLocal未清理会导致内存泄漏。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
