应使用线程池替代new thread()处理高并发请求，因其可避免线程资源耗尽导致的outofmemoryerror；需配置有界队列、合理核心数、拒绝策略，并结合监控、限流与虚拟线程优化。
直接用 new Thread() 处理高并发请求，是引发 OutOfMemoryError: unable to create new native thread 的最常见原因——这不是堆内存不够，而是操作系统线程资源被耗尽。关键在于：每个线程默认占用约 1MB 栈空间，并消耗内核线程、文件描述符等系统级资源；当每秒创建数百甚至上千个线程时，JVM 和 OS 都会迅速到达瓶颈。
用线程池替代裸线程创建
禁止在请求处理路径（如 Controller、RPC 回调、定时任务循环）中出现 new Thread().start()。统一交由 ThreadPoolExecutor 管理：
- 使用有界队列，避免任务无限堆积：优先选
new LinkedBlockingQueue(100)，而非无参构造的无界队列 - 设置明确的拒绝策略，比如
CallerRunsPolicy（让调用线程自己执行）或带告警的AbortPolicy - 避免
Executors.newCachedThreadPool()—— 它底层使用Integer.MAX_VALUE最大线程数 + 无界SynchronousQueue，高并发下极易失控
按业务类型合理配置核心参数
线程池不是越大越好，要匹配实际负载特征：
- CPU 密集型任务（如加解密、图像处理）：核心线程数设为
Runtime.getRuntime().availableProcessors() + 1，队列用SynchronousQueue - IO 密集型任务（如数据库查询、HTTP 调用）：核心线程数可设为
2 × CPU 核心数，队列用有界LinkedBlockingQueue，并配合超时控制 - 混合型场景建议拆分线程池，避免慢 IO 拖垮快计算
监控与主动限流
光靠配置不够，必须可观测、可干预：
- 定期采集
executor.getActiveCount()、executor.getQueue().size()、executor.getCompletedTaskCount()，接入 Prometheus 或日志告警 - 当队列积压超过阈值（如 >80% 容量），触发降级逻辑（如返回缓存、快速失败）
- 对突发流量，结合信号量（
Semaphore）或熔断器（如 Sentinel）做前置保护，防止线程池被瞬间打满
考虑虚拟线程（Java 21+）作为补充方案
对于大量短生命周期、高 IO 阻塞的场景（如网关转发、消息消费），可评估迁移到虚拟线程：
- 用
Executors.newVirtualThreadPerTaskExecutor()替代传统线程池，单 JVM 支持百万级并发 - 注意规避长时间阻塞操作（如
Thread.sleep(60_000)），否则会卡住底层载体线程池 - 虚拟线程仍需监控其载体线程池（ForkJoinPool）的活跃度，避免调度瓶颈
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
