大厂严禁用默认线程名，因故障时无法定位责任方；默认名如thread-0无业务含义，导致日志、jstack、arthas等排查困难；必须采用“业务域-功能-角色”三段式结构化命名，兼顾安全与兼容性。
大厂严禁用默认线程名，根本原因是故障发生时无法定位责任方。默认线程名如 Thread-0、pool-1-thread-2 完全没有业务含义，导致在日志、jstack、Arthas 或监控系统中，根本看不出这个线程属于哪个模块、执行什么任务。
排查时全是“黑户”，靠猜效率极低
线上出问题，时间就是生命：
- CPU 飙升，jstack 输出几百个 pool-2-thread-47，长得一模一样，没法区分是支付回调卡住，还是风控规则扫描阻塞
- 压测发现某类任务延迟飙升，但监控大盘里线程维度全是“无标签”，无法按业务域聚合分析
- OOM 前堆内存暴涨，怀疑是异步任务堆积对象，却找不到对应线程归属的代码模块
必须结构化命名，一眼锁定模块与职责
规范强制采用 业务域-功能-角色 三段式命名，例如：
- order-pool-notify-thread-5：订单域 + 通知功能 + 工作线程
- risk-pool-scan-worker-2：风控域 + 规则扫描 + 后台工作者
- report-pool-export-cpu-1：报表域 + 导出任务 + CPU 密集型专用线程
这种命名让开发、SRE、运维在任意时刻都能通过线程名快速判断模块、功能、执行特征，也为 Prometheus 等监控工具打标提供结构化基础。
不命名会直接破坏可观测性链条
金融级系统要求秒级定位、分钟级告警、全链路追踪。默认线程名会让以下环节全部失效：
- MDC 上下文无法绑定到有意义的线程标识，日志链路断裂
- 线程池指标（活跃数、排队数、拒绝数）无法按业务归因，监控告警失去语义
- Arthas 的 thread -n 5 查高耗时线程时，只显示无意义编号，无法反查代码位置
命名还要兼顾安全与兼容性
手动命名不是随便拼字符串，有硬性约束：
- 线程名中禁用空格、斜杠、控制字符，否则 Arthas、JFR、部分 APM 工具解析失败
- 避免用 new Random().nextInt() 生成后缀，引入不确定性且有轻微性能开销
- 推荐用 AtomicInteger 计数，确保单机内唯一且可预期
- 务必调用 t.setDaemon(false)，否则主线程退出后线程池可能被静默销毁，引发资源泄漏
