如何在 Java 中使用 ThreadFactory 自定义线程的创建逻辑

在Ja va并发编程中，ThreadFactory是一个看似简单却至关重要的接口。它的职责非常纯粹：统一并定制化线程的创建过程。简单来说，它决定了“如何new出一个Thread对象”，包括线程名、优先级、守护状态以及未捕获异常处理器等属性。直接使用new Thread()虽然快捷，但在需要批量、规范管理线程的场景下，尤其是配合线程池使用时，往往会带来逻辑散乱和不可控的问题。

那么，为什么不能总是直接new Thread()呢？关键在于控制力。当代码中散落着各种new Thread()调用时，统一的线程命名、异常处理等逻辑就难以实施。更重要的是，在使用ThreadPoolExecutor等线程池时，池内线程的创建完全由内部的ThreadFactory驱动。如果使用默认工厂，产生的线程名将是pool-1-thread-1这类缺乏业务含义的标识，给线上问题排查带来困难。同时，未设置异常处理器的线程一旦抛出未捕获异常，就会静默消失，在日志中不留痕迹，成为难以追踪的“幽灵”问题。

如何实现一个带命名和异常处理的 ThreadFactory

一个典型的自定义ThreadFactory需要满足几个常见需求：为线程添加可识别的名称前缀、确保线程为非守护线程、绑定统一的未捕获异常处理器。实现时需要注意几个细节：

• 虽然ThreadFactory是函数式接口，可以用Lambda表达式，但更推荐将其实现为静态内部类或独立类。这可以避免Lambda闭包意外持有外部类引用，潜在导致内存泄漏。
• 线程名需要保证唯一性，否则在使用JMX监控或调试工具时容易混淆。通常使用AtomicInteger作为原子计数器来生成序列号。
• 未捕获异常处理器必须在newThread方法内部，针对新创建的Thread对象进行设置，而不是在ThreadFactory的构造函数中设置，因为那时线程对象尚未诞生。

下面是一个标准的实现示例：

public class NamedThreadFactory implements ThreadFactory {
    private final String prefix;
    private final AtomicInteger threadNumber = new AtomicInteger(1);

    public NamedThreadFactory(String prefix) {
        this.prefix = prefix;
    }

    @Override
    public Thread newThread(Runnable r) {
        Thread t = new Thread(r, prefix + "-" + threadNumber.getAndIncrement());
        t.setDaemon(false);
        t.setPriority(Thread.NORM_PRIORITY);
        t.setUncaughtExceptionHandler((thread, ex) ->
             System.err.println("Uncaught in " + thread.getName() + ": " + ex));
        return t;
    }
}

在 ThreadPoolExecutor 和 Executors 中怎么用

自定义好的ThreadFactory需要正确传递给线程池。所有标准线程池的构造器或工厂方法都支持传入ThreadFactory，但参数位置和方式略有不同，容易用错：

• ThreadPoolExecutor的构造器有7个参数，其中第5个参数才是ThreadFactory，需注意不要与第4个参数BlockingQueue混淆。
• Executors工具类提供的工厂方法（如newFixedThreadPool）通常有重载版本，必须显式调用接收ThreadFactory参数的那个版本，否则线程池仍会使用默认工厂。
• 在Spring框架的ThreadPoolTaskExecutor中，需要通过setThreadFactory()方法进行设置，而非通过构造器。

一个正确的使用示例如下：

ThreadFactory factory = new NamedThreadFactory("cache-loader");
ExecutorService executor = new ThreadPoolExecutor(
    2, 4,
    60L, TimeUnit.SECONDS,
    new LinkedBlockingQueue<>(100),
    factory, // ← 关键在这里传入自定义工厂
    new ThreadPoolExecutor.CallerRunsPolicy());

容易被忽略的坑：线程名重复、异常处理器失效、与线程池拒绝策略交互

理论清晰，但在实际应用中，细节决定成败。以下几个坑点值得特别注意：

• 线程名重复：如果多个线程池共享同一个NamedThreadFactory实例，那么它们将共享内部的AtomicInteger计数器，导致不同池中的线程可能出现重复名称（例如两个池中都出现io-1）。解决方案是为每个线程池创建独立的工厂实例，或者在命名前缀中加入更细粒度的标识（如io-db、io-cache）。
• 异常处理器“失效”：为线程设置了UncaughtExceptionHandler，但提交到线程池的任务抛出异常后，处理器却没有触发。这是因为线程池通常会将Runnable任务包装在FutureTask中，任务抛出的异常会被捕获并存储，等待通过Future.get()方法获取，因此不会上升到线程未捕获异常层面。解决方法是，要么改用Callable并显式处理Future.get()的异常，要么在Runnable的run方法内部进行try-catch处理。
• 与线程池拒绝策略的隐蔽交互：如果自定义的ThreadFactory在newThread方法中创建线程失败（例如因内存不足抛出OutOfMemoryError），线程池的addWorker方法会直接抛出RejectedExecutionException，即使此时工作队列尚未满。这个异常是由线程创建失败直接触发的，与配置的拒绝策略无关。

最后，一个核心原则是：保持ThreadFactory的newThread方法逻辑简洁高效。切忌在其中执行耗时操作，例如远程调用获取配置、初始化重型日志组件等。因为这些操作会直接拖慢线程池在需要时创建新工作线程（扩容）的速度，在高负载下甚至可能成为性能瓶颈或导致流程卡死。