线程池参数调优的核心在于根据任务类型（cpu密集型或io密集型）设定合理的核心线程数、最大线程数和队列容量，以平衡资源利用率与响应延迟。通常建议cpu密集型任务将线程数设为cpu核数加1，而io密集型任务则需根据等待时间比例大幅放宽限制，并配合有界队列防止内存溢出。
CPU密集型任务如何确定最佳线程数
对于计算密集型的任务，最佳线程数通常设置为CPU核心数加1，即N+1。这是因为过多的线程会导致频繁的上下文切换，反而降低性能；而少一个线程可以应对偶尔的页缺失或其他阻塞因素。在实际代码中，可以通过Runtime.getRuntime().availableProcessors()获取当前系统的处理器数量，然后据此构建线程池。
import java.util.concurrent.*;
public class CpuThreadPool {
public static void main(String[] args) {
int cpuCount = Runtime.getRuntime().availableProcessors();
// CPU密集型：核心线程数 = CPU核数 + 1
ThreadPoolExecutor executor = new ThreadPoolExecutor(
cpuCount + 1,
cpuCount + 1,
0L, TimeUnit.MILLISECONDS,
new LinkedBlockingQueue<>()
);
// 提交任务示例
executor.submit(() -> {
long sum = 0;
for (long i = 0; i < 1000000000L; i++) sum += i;
return sum;
});
executor.shutdown();
}
}
上述代码展示了针对CPU密集型场景的基础配置。由于使用了无界队列LinkedBlockingQueue，当任务提交速度超过处理速度时，队列会无限增长，可能导致OutOfMemoryError。因此，在生产环境中，即使对于CPU密集型任务，也强烈建议使用有界队列如ArrayBlockingQueue，并配合拒绝策略来处理过载情况。此外，如果任务包含少量IO操作，可以适当增加线程数，但一般不超过2N。
立即学习“Java免费学习笔记（深入）”；
IO密集型任务为何需要更多线程及队列选择
IO密集型任务（如数据库查询、网络请求）大部分时间在等待I/O完成，CPU处于空闲状态。此时增加线程数可以充分利用CPU的空闲周期。经验公式为 N * U * (1 + W/C)，其中N是CPU核数，U是目标CPU使用率（通常取1），W是等待时间，C是计算时间。若等待时间远大于计算时间，线程数可设为CPU核数的数倍甚至更高。同时，必须使用有界队列来保护系统稳定性。
import java.util.concurrent.*;
public class IoThreadPool {
public static void main(String[] args) {
int cpuCount = Runtime.getRuntime().availableProcessors();
// IO密集型估算：假设等待时间是计算时间的10倍
int ioThreads = cpuCount * 10;
ThreadPoolExecutor executor = new ThreadPoolExecutor(
ioThreads,
ioThreads * 2,
60L, TimeUnit.SECONDS,
new ArrayBlockingQueue<>(100), // 有界队列
new ThreadPoolExecutor.CallerRunsPolicy() // 拒绝策略
);
executor.submit(() -> {
try { Thread.sleep(100); } catch (InterruptedException e) {}
return "IO Done";
});
executor.shutdown();
}
}
在IO密集型场景中，除了调整线程数量，队列的选择和拒绝策略同样关键。ArrayBlockingQueue提供了背压机制，当队列满时触发拒绝策略。CallerRunsPolicy会让调用线程自己执行任务，这能有效减缓任务提交速度，给线程池喘息机会，避免快速失败。相比之下，AbortPolicy直接抛出异常，可能影响业务逻辑的连续性。开发者应根据业务对延迟和吞吐量的敏感度选择合适的组合。
队列满时拒绝策略对系统稳定性的影响
当线程池达到最大线程数且队列也满时，新提交的任务会触发拒绝策略。不同的拒绝策略对系统行为的影响截然不同。AbortPolicy抛出RejectedExecutionException，适合对数据一致性要求极高、不允许丢失任务的场景，但需要上层捕获处理。DiscardPolicy静默丢弃任务，适用于日志收集等非关键任务。DiscardOldestPolicy丢弃队列中最老的任务，保留最新任务，适合实时性要求高的场景。CallerRunsPolicy由调用线程执行，起到流控作用，适合希望平滑降级而非崩溃的系统。正确选择拒绝策略是线程池调优的最后一步，也是保障系统鲁棒性的关键。
