线程池自定义 ThreadFactory：如何为线程池中的线程统一设置名称前缀、优先级与未捕获异常处理器

线程池自定义 ThreadFactory：如何为线程池中的线程统一设置名称前缀、优先级与未捕获异常处理器

在配置线程池时，一个常被忽视但至关重要的环节是线程的初始化。与其依赖默认工厂或事后补救，不如在源头上一劳永逸：通过实现 ThreadFactory 接口，在其 newThread 方法中，一次性完成线程的名称、优先级、异常处理器乃至守护状态的配置。这不仅是编码规范，更是保障系统可观测性与稳定性的基石。

命名要带业务上下文，且必须在创建时设好

面对日志中一堆 pool-1-thread-1 这样的默认名称，排查问题无异于大海捞针。真正有效的线程名，应该像路标一样清晰，直接指向业务模块和功能，比如 payment-notify-worker-1 或 mq-retry-consumer-2。

• 前缀+原子数：采用固定的业务前缀，搭配 AtomicInteger 生成的原子计数器作为后缀，简单且能保证唯一性。
• 命名规范：名称中应避免使用空格、斜杠等特殊字符，确保能被 Arthas 等诊断工具正常解析。
• 时机是关键：切忌在 Runnable.run() 方法内部调用 Thread.setName()。因为线程池会复用线程，此时改名，监控系统看到的依然是线程最初创建时的名字，导致信息错位。
• 避免随机后缀：使用 Random 生成后缀不仅缺乏业务含义，还可能带来不必要的性能开销。

优先级通常设为 NORM_PRIORITY，慎调高低

Ja va线程的优先级范围是1到10，其中 NORM_PRIORITY（值为5）是那个“黄金默认值”。提高优先级并不保证线程能绝对优先执行，它只是增大了被调度器选中的概率。更要紧的是，在生产环境中随意调高优先级，可能会引发线程饥饿，甚至干扰到JVM自身的核心线程（例如垃圾回收线程）。

• 显式设置：务必调用 t.setPriority(Thread.NORM_PRIORITY)，避免线程意外继承父线程的优先级。
• 保持克制：除非面对金融风控等对延迟有极致要求的特定路径，否则不建议偏离默认值。
• 注意平台差异：不同操作系统对Ja va线程优先级的映射和支持程度不同，依赖它来实现核心调度逻辑并不可靠。

未捕获异常必须由线程自己处理，不能靠外部兜底

线程内部抛出了未捕获的异常会怎样？结果是线程悄无声息地终止，任务丢失，且往往不留痕迹。默认行为仅仅是将堆栈打印到 System.err，这在线上环境中几乎等同于“看不见”。

• 绑定专属处理器：通过 t.setUncaughtExceptionHandler() 设置处理器，将异常信息规整地记录到日志文件，并上报至监控告警系统。
• 处理器要轻量：处理器内的逻辑应避免阻塞操作，如远程调用或大对象序列化，以防拖慢线程的正常销毁流程。
• 信息要全面：记录异常时，不能只打印堆栈，至少应包含线程名、时间戳和关键的业务上下文标识（如 traceId）。
• 明确边界：需要留意，这个处理器只捕获 run() 方法内未被 try-catch 的异常。对于通过 Future.get() 抛出的 ExecutionException，它无能为力。

守护状态需按业务显式指定

线程的守护状态（通过 setDaemon(true/false) 设置）决定了当JVM退出时，该线程是否会被强制终止。线程池本身并不会自动管理这个属性。

• 业务线程非守护：像订单处理、消息消费这类核心业务工作线程，应设为非守护线程（false），确保在主线程退出前，它们有足够的时间完成资源清理和任务收尾。
• 后台线程可守护：对于指标采集、心跳发送这类纯后台支撑型线程，可以设为守护线程，避免它们阻止JVM的正常关闭。
• 避免继承导致的不确定性：如果不显式设置，线程将继承创建它的当前线程的守护状态。这种隐式行为容易因程序启动的上下文不同而导致意料之外的结果，因此显式声明是最佳实践。