java线程池最大容量由位运算硬编码限制：count_bits为29，低29位存workercount，高3位存runstate；capacity=(1
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
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
