线程私有数据的核心是每个线程独立的栈空间，stackSize参数控制该空间大小，直接影响OS可分配的虚拟内存，从而成为并发线程数的硬性边界；其值为JVM向OS传递的建议值，受平台最小限制、ulimit-s及JVM实现适配，不保证强制生效。
线程私有数据的核心在于每个线程拥有独立的栈空间，而 Thread 类中 stackSize 参数正是控制这一空间大小的关键入口。它不改变线程逻辑行为，但直接影响操作系统能为该线程分配多少虚拟内存，从而成为限制并发线程数的硬性边界之一。
stackSize 参数的实际作用机制
Java 中 Thread 构造函数支持传入 stackSize（单位：字节），例如：
new Thread(null, runnable, "worker", 256 * 1024) 表示期望为该线程分配约 256KB 栈空间。
但该值并非强制生效——JVM 会根据平台能力做适配：
- 若指定值低于平台最小允许值（如 Linux 上通常不低于 128KB），JVM 自动提升至最小安全值
- 若指定值过高（如超过系统
ulimit -s限制），JVM 可能截断或忽略，仍按默认值分配 - 在部分 JVM 实现（如某些嵌入式或旧版 OpenJDK）中，该参数可能完全被忽略
- 设为 0 等价于不指定，使用 JVM 启动时的全局默认值（
-Xss）
为什么 stackSize 会限制最大线程数
每个 Java 线程对应一个 OS 级线程（pthread），其栈内存来自进程的用户态虚拟地址空间，而非堆内存（Heap）。创建失败时抛出的 java.lang.OutOfMemoryError: unable to create new native thread，本质是操作系统拒绝分配新线程栈，不是 JVM 堆溢出。
关键约束公式为：
(进程可用虚拟内存 − JVM 堆与元空间占用 − 系统保留内存) ÷ 单线程栈大小 ≈ 可创建线程上限
举例：在 32 位环境或容器中，进程总虚拟内存约 2–3GB；若 -Xss1m（1MB/线程），仅需 3000 个线程就耗尽地址空间；而改用 -Xss256k，理论线程数可提升至约 12000。
注意：JVM 堆越大（-Xmx 越高），留给线程栈的空间越少，线程数反而下降——这与直觉相反，却是常见线上事故根源。
底层实现中 stackSize 如何参与线程创建
从 OpenJDK 源码看，Thread.start() 最终调用 JVM 内部 JVM_StartThread，其中关键路径为：
size_t sz = (size > 0) ? (size_t)size : 0;native_thread = new JavaThread(&thread_entry, sz);
此处 sz 直接传入 JavaThread 构造函数，并在后续交由 OS 层（如 Linux 的 pthread_create）使用。若底层创建失败（如 pthread_attr_setstacksize 返回错误，或 mmap 分配失败），osthread() 返回空，JVM 即抛出 OOM 异常。
也就是说：stackSize 是从 Java 层向下透传的“建议值”，是否采纳、如何裁剪，取决于 JVM 移植层（os_*.cpp）对当前操作系统的适配逻辑。
实用调优建议
不追求统一配置，而是按场景分级处理：
- 普通业务线程（HTTP 处理、简单计算）：用
-Xss256k或512k足够，避免栈浪费 - 含深度递归、大局部数组或 JNI 调用的线程：单独构造时显式传入更大
stackSize（如 1MB），防止StackOverflowError - 高并发 I/O 密集型服务（如网关、客户端连接池）：优先考虑协程方案（如 Project Loom 的虚拟线程），绕过 OS 线程栈限制
- 容器部署时：同步检查宿主机
ulimit -s和容器memory.limit_in_bytes，确保两者匹配，避免 JVM 认为可用却实际被 cgroup 拦截
