在组装高性能电脑后，很多人会尝试运行一些多任务程序，比如视频转码、批量图片处理或者本地服务器。这时候，程序能不能跑得顺，除了看CPU和内存，还得看代码里的线程池怎么管。
什么是核心线程数？
线程池就像快递站点的派送员团队，核心线程数就是常年在岗的固定员工。哪怕暂时没任务，他们也不会被辞退。设置合理的数量，能让程序在低负载时响应快，高负载时不卡死。
比如你写了个程序用来压缩照片上传到网盘，每张图开一个线程处理显然不现实——线程太多，系统反而忙于切换，效率下降。这时候就得靠线程池来控制并发量。
怎么设才合适？
一个常见做法是参考CPU的核心数。如果你装的是6核12线程的处理器，那把核心线程数设成6或8比较稳妥。Java里可以这样写：
int corePoolSize = Runtime.getRuntime().availableProcessors(); // 获取CPU核心数
ExecutorService executor = Executors.newFixedThreadPool(corePoolSize);但这不是铁律。如果是IO密集型任务，比如读写文件、网络请求，线程经常在等数据，就可以适当提高一点，比如设成核心数的1.5倍。
反过来，做大量计算的任务，比如图像识别，每个线程都吃满CPU，那就别贪多，老老实实按核心数来，避免资源争抢。
动态调整更灵活
有些场景下负载波动大，白天用户多，半夜几乎没人用。这时候可以用可伸缩的线程池：
ThreadPoolExecutor executor = new ThreadPoolExecutor(
4, // 核心线程数
16, // 最大线程数
60L, // 空闲超时时间（秒）
TimeUnit.SECONDS,
new LinkedBlockingQueue<Runnable>(100)
);上面这段代码的意思是：平时保持4个“正式工”，任务多了可以临时招到16个，但临时工空闲超过60秒就裁掉。队列最多存100个待办任务，防止内存爆掉。
这种配置适合家用NAS上跑的小型Web服务，既能应对突发访问，又不会长期占用过多资源。
别忽视拒绝策略
当任务太多，队列满了，线程也到上限了，新来的任务怎么办？默认会抛异常。你可以改成丢弃最老的任务，或者让调用者自己处理：
executor.setRejectedExecutionHandler(new ThreadPoolExecutor.CallerRunsPolicy());这相当于告诉系统：“你现在太忙，那这个事我自己动手干。”虽然慢点，但不至于直接失败。
在家用设备上跑程序，资源有限，合理设置线程池的核心线程数，等于给软件装了个智能调度器。硬件再强，代码没调好，照样卡顿。反过来，小机器也能跑出高效体验。