根本原因是大量轻量级线程在单核上密集争抢调度权、触发非线性上升的上下文切换并挤占l1/l2缓存，导致该核心陷入调度密集型高负载；每次new thread().start()均触发系统调用、分配栈与内核结构，耗尽单核调度资源。
高并发下滥用 new Thread().start() 会导致单核 CPU 打满，根本原因不是“线程太多”这个表象，而是大量轻量级任务在同一物理核心上密集争抢调度权、频繁触发上下文切换、并挤占关键缓存资源，最终让该核心陷入高负载僵局。
线程创建本身就在透支单核资源
每次 new Thread().start() 都会触发一次系统调用，向操作系统申请一个原生线程。OS 必须为它分配：
- 独立的内核栈（通常 2MB）和用户栈（默认 1MB）
- 调度队列节点、TLS 区、信号掩码等内核数据结构
- 一个宝贵的线程 ID 和文件描述符
这些动作全由当前执行线程所在的 CPU 核心完成。当每秒新建数百个线程时，该核心光处理线程创建/销毁开销就接近饱和，还没开始干活，CPU 就被调度器和内存管理拖垮了。
Codex Auth Cleaner
下载
一款AI工具，主要用于Monitor and clean up invalid Codex authentication files in CPA. Check quota status, disable files returning 401 errors, and perform dual verification before deletion.，适合需要提升相关任务效率的用户。
小线程扎堆引发调度雪崩
大量短生命周期线程（比如只做日志记录、发通知、简单计算）不会均匀分布到多核，而常被调度器集中塞进同一个空闲核心——尤其在 JVM 启动初期或虚拟机资源受限环境下。
- 线程数超过几十个后，上下文切换成本非线性上升：TLB 缓存失效加剧、L1/L2 缓存行反复刷写
- top -H 可见多个 tid 持续在同一个 CPU 列（如 %CPU0）显示 99%，状态为 Runnable，但实际没干多少业务逻辑
- 这不是计算密集，而是调度密集：CPU 大部分时间花在保存/恢复寄存器、跳转指令、更新红黑树队列上
与业务线程争抢关键资源
这些随手 new 出来的线程，往往和主线程、IO 线程、定时任务线程共享同一组 L1/L2 缓存和内存带宽。
- 它们频繁分配小对象、触发 minor GC，导致 Eden 区快速填满，进一步拉高 STW 时间
- 若使用无界队列或未设超时的阻塞操作（如
Thread.sleep(1)或queue.take()），还会制造出大量 虚假 Runnable 状态线程，持续占用调度器注意力 - 在虚拟机中尤为严重：VM 层对时钟中断模拟延迟，会让线程 start() 调用实际阻塞上百毫秒，放大排队效应
它和线程池满不是一回事，但后果更隐蔽
线程池满通常表现为拒绝任务、队列堆积；而滥用 new Thread 的典型症状是：
- 整体 CPU 使用率不高（比如才 40%），但 某一核长期卡在 95%+
- jstack 显示大量线程处于 RUNNABLE，但栈顶是
java.lang.Thread.sleep、Unsafe.park或空循环 - ps -eo tid,pid,comm,%cpu 输出里，一堆
java线程共用同一个 PID，且 TID 分布密集 - 应用响应变慢，但 GC 日志、慢 SQL、外部调用都正常——问题就藏在“线程太碎”里
