线程池大小需基于CPU核心数和任务类型科学设定：CPU密集型取核心数或核心数+1；I/O密集型取核心数×2～4并压测验证；混合型建议拆分任务或按×3初始设置后依监控调优，同时禁用无界队列、选用CallerRunsPolicy拒绝策略、显式构造ThreadPoolExecutor。
线程池大小不能靠经验拍脑袋定，得从 CPU 核心数出发，结合任务特性算出合理范围。核心思路是：让 CPU 尽量不空闲，也不因线程太多而频繁切换。
CPU 密集型任务：核心数 + 1 是稳妥起点
这类任务持续占用 CPU（比如图像压缩、加解密、复杂算法），线程基本不等待。此时再多开线程只会增加上下文切换开销，降低效率。
- 推荐 corePoolSize = maximumPoolSize = CPU 核心数 或 CPU 核心数 + 1
- 多出的 1 个线程用于应对偶尔的页缺失、锁竞争或短暂 I/O 等非计算阻塞
- 获取核心数： Runtime.getRuntime().availableProcessors()
I/O 密集型任务：用“等待/计算比”估算倍数
数据库查询、HTTP 调用、文件读写等任务，线程大部分时间在等响应，CPU 处于空闲状态。这时可适当提高并发度，让空闲 CPU 去处理其他就绪任务。
Java注释规范Skills
下载
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
- 理论公式：线程数 ≈ CPU 核心数 × (1 + 平均等待时间 ÷ 平均计算时间)
- 实践中常取 CPU 核心数 × 2～4 作为初始值，再通过压测验证
- 例如：8 核机器，I/O 占比高，可先试 16 或 24 线程
混合型任务建议拆分或监控驱动调优
真实业务往往既有计算又有等待，统一设置容易顾此失彼。
立即学习“Java免费学习笔记（深入）”；
- 优先将 CPU 型与 I/O 型任务分离，各自使用独立线程池
- 若无法拆分，初始按 I/O 密集型偏上设置（如 ×3），再重点观察：
• getActiveCount() 是否长期接近最大值
• getQueue().size() 是否持续积压
• 拒绝任务数是否上升 - 根据指标反馈逐步下调或微调，而非一次性拉满
配套必须做好的三件事
光设数字不够，参数组合和运行反馈同样关键：
- 禁用无界队列：别用 new LinkedBlockingQueue()（默认容量 Integer.MAX_VALUE），改用有界队列如 ArrayBlockingQueue(256)
- 拒绝策略选 CallerRunsPolicy：当队列满且线程达上限时，由提交线程自己执行任务，天然限流，避免雪崩
- 不用 Executors 工厂方法：newFixedThreadPool、newCachedThreadPool 隐藏了关键参数风险，务必用 ThreadPoolExecutor 显式构造
