java线程池7个核心参数需科学配置：corepoolsize和maximumpoolsize按cpu或i/o密集型任务设定；workqueue必须用有界队列并估算容量；keepalivetime与拒绝策略（推荐callerrunspolicy）需配套；threadfactory和unit须显式配置，禁用executors工具类。
Java 线程池的核心参数共7个，全部定义在 ThreadPoolExecutor 的构造方法中。配置不合理会直接引发 OOM、线程爆炸或任务丢失，不能靠经验拍脑袋，必须结合任务类型、系统资源和流量特征来定。
corePoolSize 和 maximumPoolSize：按任务类型算，不是填数字
这两个数决定线程池的弹性边界，关键看任务是 CPU 密集型还是 I/O 密集型：
- CPU 密集型（如加解密、图像处理）：核心线程数建议设为 CPU 逻辑核数 + 1；最大线程数可设为核数 + 2 或 + 3，避免上下文切换开销过大
- I/O 密集型（如 HTTP 调用、数据库查询）：核心线程数建议设为 CPU 核数 × 2～4；最大线程数不超过核数的 3 倍，防止线程过多拖垮系统
- 注意：不要直接用
Runtime.getRuntime().availableProcessors()—— 容器环境（如 Kubernetes）有 CPU limit，需按实际限制折算
workQueue：必须用有界队列，容量要估算
无界队列（如 new LinkedBlockingQueue()）是线上事故高发区：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 队列无限 → 任务永远能塞进去 →
maximumPoolSize失效 → 非核心线程永不创建 → 拒绝策略永远不会触发 - 结果就是任务越堆越多，内存持续上涨，最终 OOM 或接口雪崩
- 推荐用
ArrayBlockingQueue(128)或LinkedBlockingQueue(256)，容量按公式粗估：
队列容量 ≈ 峰值 QPS × 平均处理时长（秒）
例如：QPS=100，平均耗时 200ms → 缓冲 20～50 个较安全
keepAliveTime 和 handler：必须配套选，不能默认
空闲时间不是越大越好，拒绝策略也不能只用默认：
-
keepAliveTime设 60 秒 比较通用；若业务波动大，可配合allowCoreThreadTimeOut(true)让核心线程也支持回收 - 拒绝策略优先选 CallerRunsPolicy：过载时让调用线程自己执行任务，天然限流，还能避免丢任务
- 慎用
AbortPolicy（默认）：抛异常容易被上层吞掉，问题难发现；DiscardPolicy更危险，静默丢任务可能引发数据不一致
threadFactory 和 unit：显式配置，别省略
看似可选，实则影响可观测性和稳定性：
- 自定义
ThreadFactory给线程起名，比如"order-process-pool-%d"，出问题时从线程 dump 里一眼定位来源 -
unit必须明确指定，如TimeUnit.SECONDS，避免单位混淆导致 keepAliveTime 失效 - 绝对不要用
Executors.newFixedThreadPool()或newCachedThreadPool()—— 阿里规范禁用，源码里藏着无界队列或无限线程
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
