电话
400 9058 355
corePoolSize是新任务提交时立即创建线程的阈值,而非“最小线程数”;当线程数未达corePoolSize时,新任务触发即时线程创建,否则进入队列或按拒绝策略处理。
很多人误以为 corePoolSize 是线程池“至少维持”的线程数,其实它更准确的角色是:**新任务提交时,是否立即创建线程的开关阈值**。只要当前线程数 corePoolSize,不管有没有空闲线程,都会新建线程去执行——哪怕已有 1 个线程正休眠在 Thread 中,第 2 个任务来了仍会起第 2 个线程(假设 
corePoolSize=2)。
allowCoreThreadTimeOut(true)
LinkedBlockingQueue 且未指定容量(即无界队列),maximumPoolSize 实际失效:因为队列永远不会满,永远不触发非核心线程创建ArrayBlockingQueue(10))+ corePoolSize
队列类型直接决定线程池是否能走到“扩容到最大线程数”这一步。常见错误是直接用 new LinkedBlockingQueue()(无界),结果无论并发多高、任务多猛,线程数永远卡在 corePoolSize,内存却悄悄涨到 OOM。
ArrayBlockingQueue:有界,推荐生产使用;队列满 → 触发扩容逻辑 → 达到 maximumPoolSize 后触发拒绝策略SynchronousQueue:不存任务,相当于“快递员直送”;适合 CachedThreadPool 场景,要求快速响应、任务轻量PriorityBlockingQueue:无界 + 优先级;注意:它不保证公平性,且拒绝策略可能因无法判断“最旧任务”而行为异常keepAliveTime 默认管不了核心线程——这是设计使然,不是 bug。它的本意就是让“临时工”干完活就走,而“正式工”(核心线程)常驻待命。如果你发现线程池缩容不下来,先检查是不是忘了设置 allowCoreThreadTimeOut(true)。
allowCoreThreadTimeOut(true) 后,所有线程(含核心)都受 keepAliveTime 约束unit 参数,写成 60, TimeUnit.MILLISECONDS 却期望等 60 秒?那线程会在 60 毫秒后全灭看到 RejectedExecutionException 别急着换 CallerRunsPolicy 来“假装没事”。它暴露的是真实瓶颈:要么队列太小、要么线程上限太低、要么下游处理太慢导致任务积压。
立即学习“Java免费学习笔记(深入)”;
AbortPolicy(默认):抛异常——适合开发/测试环境,快速暴露配置不合理DiscardOldestPolicy:丢队头任务——慎用!若任务有状态依赖或顺序敏感,会引发数据不一致RejectedExecutionException 并上报指标,作为扩容或限流的触发条件线程池不是设完参数就一劳永逸的组件,它的行为高度依赖 corePoolSize、workQueue、maximumPoolSize 三者之间的配合关系;少一个环节理解偏差,就可能让整个并发模型在高负载下失速或崩溃。
邮箱:8955556@qq.com
Q Q:8955556
本文详解如何将Go官方present工具(用于生成HTML5...
PySNMP在不同版本中对SNMP错误状态(errorSta...
time.Sleep仅阻塞当前goroutine,其他gor...
PHPfopen()创建含特殊符号的文件名失败主因是操作系统...
WooCommerce中通过代码为分组产品动态聚合子商品的属...
io.ReadFull返回io.ErrUnexpectedE...
本文详解Yii2中控制器向视图传递ActiveRecord数...
本文详解为何通过wp_set_object_terms()为...
Pytest中使用@mock.patch类装饰器会导致补丁泄...
带缓冲的channel是并发安全的FIFO队列;make(c...