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