Java 线程池使用，Java线程池

在Java后端开发的日常实践里，线程池几乎是处理高并发任务、优化系统资源利用率时绕不开的核心组件，很多开发者对它的认知停留在“能复用线程、减少创建销毁开销”的表层，却常常因为参数配置不合理、使用方式不规范，反而引发线程耗尽、任务堆积甚至服务雪崩的问题。想要真正用好线程池，就得先理解它的核心设计逻辑，再结合业务场景匹配合适的实现方案，才能让它成为系统性能提升的助力而非隐患。

Java中的线程池核心实现类是ThreadPoolExecutor，它的构造函数包含7个关键参数，每一个参数的设置都直接影响线程池的运行行为。其中corePoolSize是核心线程数，默认情况下核心线程会一直存活，即使处于空闲状态也不会被回收，除非设置了allowCoreThreadTimeOut参数；maximumPoolSize是最大线程数，代表线程池能创建的线程上限；keepAliveTime是非核心线程的空闲存活时间，当线程数量超过核心线程数且空闲时间超过这个阈值，多余的线程就会被回收；workQueue是任务等待队列，当核心线程都在忙碌时，新提交的任务会先进入队列等待；threadFactory是线程工厂，用来创建线程，通常可以自定义线程名称方便排查问题；handler是拒绝策略，当线程池和队列都满了的时候，会按照指定策略处理新提交的任务。

很多开发者喜欢用Executors工具类提供的便捷方法创建线程池，比如newFixedThreadPool、newCachedThreadPool、newSingleThreadExecutor等，但这些封装好的线程池其实都存在一定的风险。newFixedThreadPool使用的是无界的LinkedBlockingQueue，在任务量突增的情况下，队列会无限堆积，最终可能导致内存溢出；newCachedThreadPool的最大线程数是Integer.MAX_VALUE，当大量任务同时提交时，会创建无数个线程，最终耗尽系统资源；newSingleThreadExecutor同样使用无界队列，也存在内存溢出的风险。因此在实际生产环境中，更推荐直接通过ThreadPoolExecutor的构造函数自定义线程池，根据业务场景精准控制每一个参数。

设置线程池参数时，要先区分任务的类型。如果是CPU密集型任务，比如大量的计算、加密解密操作，线程数不宜设置过多，通常可以将核心线程数设置为CPU核心数加1，避免线程频繁切换带来的开销；如果是IO密集型任务，比如数据库查询、网络请求、文件读写等，线程可以适当多一些，一般可以设置为2倍的CPU核心数，因为IO操作时线程处于阻塞状态，多一些线程可以提高CPU的利用率。当然这只是通用的参考值，具体的数值还需要根据实际的业务压测结果来调整，观察系统的吞吐量、响应时间等指标，找到最优的参数组合。

任务队列的选择也十分关键，常见的队列有ArrayBlockingQueue、LinkedBlockingQueue、SynchronousQueue、DelayQueue等。ArrayBlockingQueue是有界队列，基于数组实现，需要指定容量，可以控制队列的最大长度，避免任务无限堆积；LinkedBlockingQueue可以是有界也可以是无界的，基于链表实现，默认容量是Integer.MAX_VALUE，使用时一定要注意设置容量；SynchronousQueue没有容量，提交的任务会直接交给线程处理，如果没有空闲线程就会创建新的线程，适合执行大量短耗时的任务；DelayQueue是延迟队列，里面的任务需要达到指定的延迟时间才会被执行，适合处理定时任务、超时处理等场景。

拒绝策略同样不能忽视，JDK提供了四种默认的拒绝策略。AbortPolicy是默认策略，会直接抛出RejectedExecutionException异常，适合对任务提交要求严格的场景，能及时感知到线程池的饱和状态；CallerRunsPolicy会由提交任务的线程自己执行该任务，这种策略能起到一定的流量削峰作用，不会丢弃任务，但可能会阻塞提交任务的线程；DiscardPolicy会直接丢弃新提交的任务，不会抛出任何异常，适合那些可以容忍任务丢失的场景；DiscardOldestPolicy会丢弃队列中最老的任务，然后尝试重新提交当前任务，适合优先级比较高的新任务场景。如果这些默认策略都不能满足需求，还可以自定义拒绝策略，实现RejectedExecutionHandler接口即可，比如将任务持久化到数据库、消息队列中，等线程池空闲后再重新处理。

在使用线程池的过程中，还有很多容易踩的坑。比如很多人会在方法内部创建线程池，这样每次调用方法都会创建新的线程池，完全失去了线程复用的意义，正确的做法是将线程池作为全局的单例来使用；还有的人不关注线程池的状态，不知道线程池是否已经饱和、队列是否已经堆积，这就需要对线程池进行监控，可以通过ThreadPoolExecutor提供的getActiveCount、getQueueSize、getCompletedTaskCount等方法获取线程池的运行数据，结合监控系统做告警，及时发现问题；使用线程池的时候要注意任务的异常处理，如果任务抛出了未捕获的异常，线程可能会终止，虽然线程池会补充新的线程，但异常信息如果没有被捕获记录，就很难排查问题，所以最好在任务的run方法或者call方法里加上try-catch，或者自定义线程工厂设置未捕获异常处理器。

对于有不同业务优先级的场景，还可以考虑使用多个线程池来隔离不同的业务，比如核心业务用一个线程池，非核心业务用另一个线程池，避免非核心业务的任务耗尽线程池资源，影响核心业务的正常运行。如果是需要执行定时任务的场景，还可以使用ScheduledThreadPoolExecutor，它是ThreadPoolExecutor的子类，支持定时执行任务和周期执行任务，相比Timer来说更加灵活可靠，因为Timer是单线程的，而且如果任务抛出异常会导致整个Timer终止，而ScheduledThreadPoolExecutor可以多线程执行，异常也只会影响单个任务。

Java线程池是一把双刃剑，用好了能极大提升系统的并发处理