Java线程池最大容量由位运算硬编码限制：COUNT_BITS为29，低29位存workerCount，高3位存runState；CAPACITY=(1<<29)-1=536870911。

Java线程池的最大容量不是由配置参数直接决定的，而是由底层位运算机制硬编码限制的——关键就在 COUNT_BITS 和 CAPACITY 这两个静态常量。

COUNT_BITS 决定了状态与数量的位域划分

它等于 Integer.SIZE - 3，即 32 - 3 = 29。这表示：
ctl 变量（AtomicInteger）的低 29 位用于存储 workerCount（活动线程数），
高 3 位用于存储 runState（线程池运行状态）。
这种设计让一个 int 值同时承载两个关键维度，且保证原子更新。

CAPACITY 是低 29 位能表示的最大无符号整数

CAPACITY = (1 ，也就是：<br><code>(1 （约 5.37 亿）。<br> 这个值是线程池理论上支持的**最大活动线程数上限**，不是建议值，而是位宽决定的硬上限。

为什么是 29 位？3 位状态够用吗？

源码中定义了 5 种状态：RUNNING、SHUTDOWN、STOP、TIDYING、TERMINATED。
3 位二进制最多可表示 8 种状态（000 ~ 111），当前只用了 000 到 011（即 0~3），留有余量。
选择 3 位兼顾了未来扩展性与空间效率——再多一位会挤占线程数空间，少一位则不够表达状态变迁逻辑。

实际使用中远达不到 CAPACITY 上限

虽然理论支持超 5 亿线程，但真实场景受限于：
• JVM 堆内存与栈空间（每个线程默认 1MB 栈，5 亿线程需 500TB 内存）
• 操作系统线程句柄资源（Linux 默认 ulimit -u 通常为几千到几万）
• CPU 调度开销剧增，上下文切换成为性能瓶颈
• ThreadPoolExecutor 构造时若传入超过 CAPACITY 的 maximumPoolSize，会直接抛出 IllegalArgumentException