线程池参数不直接改变jvm堆内存或线程栈大小，但通过控制活跃线程数和任务排队行为，显著影响栈内存占用（如corepoolsize=200、-xss=1m时占200mb）和堆内存压力（无界队列易致oom），并受操作系统线程上限约束。
线程池参数设定本身不直接改变 JVM 堆内存（-Xms/-Xmx）或线程栈大小（-Xss），但它会显著影响这两者在运行时的实际占用和压力分布。关键在于：线程池控制的是“活跃线程数量”和“任务排队行为”，而 JVM 内存参数决定的是“每个线程能用多少栈空间”以及“堆里总共能放多少对象”。两者协同作用，共同决定系统是否出现 OutOfMemoryError: unable to create new native thread 或 java.lang.OutOfMemoryError: Java heap space。
线程池核心线程数与 -Xss 的实际内存开销
每个线程启动时，JVM 都会为其分配独立的栈空间（由 -Xss 指定，默认 1MB）。即使线程处于空闲状态（比如线程池中未执行任务的 coreThread），只要没被销毁，其栈内存就持续占用。
- 若
-Xss=1m，线程池设为corePoolSize=200，仅核心线程就固定占用约 200MB 栈内存（不含堆内线程对象本身） - 若误将
-Xss设为 4m，同样 200 个核心线程将占用 800MB 栈内存——这可能直接挤占堆空间，尤其在总内存有限时 - 注意：线程对象本身（
java.lang.Thread实例）存在堆中，受堆大小限制；而它的栈是本地内存（native memory），不受-Xmx管控，但受操作系统进程内存上限约束
线程池队列容量与堆内存压力
当任务提交速率超过线程处理能力，多余任务会进入线程池的阻塞队列（如 LinkedBlockingQueue 或 ArrayBlockingQueue）。这些待执行的 Runnable 或 FutureTask 对象全部存放在堆中。
- 使用无界队列（如默认构造的
LinkedBlockingQueue）时，大量积压任务会持续申请堆内存，极易触发OutOfMemoryError: Java heap space - 使用有界队列（如
new ArrayBlockingQueue(1000)）可限制堆内任务对象数量，但需配合合理的拒绝策略（如AbortPolicy或CallerRunsPolicy），避免任务丢失或调用线程阻塞 - 特别注意：如果任务本身携带大对象（如 byte[]、DTO 集合），单个任务对象可能占用数 MB 堆内存，此时队列容量需按对象大小而非数量估算
最大线程数与操作系统线程限制的冲突
当线程池配置了较大的 maximumPoolSize，且任务持续激增导致不断创建新线程（超出 corePoolSize），JVM 就会尝试新建线程。此时真正卡住的往往不是 JVM 参数，而是操作系统层面的限制：
- Linux 默认单进程线程数上限通常为 1024 或 4096（可通过
ulimit -u查看），超过即抛unable to create new native thread - 即使堆和栈参数宽松，若
-Xss过大（如 2m），可用线程数 = 总可用内存 ÷ 每线程栈大小 → 实际能创建的线程远少于理论值 - 建议：生产环境
maximumPoolSize不宜盲目设高；优先通过压测确定合理上限，并确保-Xss与之匹配（例如 256k～512k 更适合高并发小任务场景）
拒绝策略对内存行为的间接影响
拒绝策略决定了任务无法入队或创建新线程时的处理方式，不同策略对内存的影响差异明显：
-
AbortPolicy（默认）：直接抛异常。调用方若未捕获，可能导致任务静默丢失，但不增加内存压力 -
CallerRunsPolicy：由提交任务的线程（可能是 Tomcat worker 线程等）同步执行任务。这会延长该线程的占用时间，可能造成请求线程池耗尽，间接引发更多线程创建需求 -
DiscardOldestPolicy：丢弃队首任务并重试提交。若任务本身构造开销大（如含初始化逻辑），反复丢弃+重试可能放大 GC 压力 - 自定义策略中若缓存被拒任务（如写入磁盘或 DB），则引入额外 I/O 和内存缓冲，需单独评估资源占用
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
