corePoolSize设太小不会直接拒绝任务，而是先排队；仅当队列满且线程数已达maximumPoolSize时才触发拒绝策略。
corePoolSize设太小会导致任务排队还是直接拒绝？
设得太小，新任务来时如果线程数已达corePoolSize且队列未满，会进队列；但若队列也满了，就触发拒绝策略——不是立刻拒绝，而是取决于队列容量和maximumPoolSize是否还有余量。
常见误判是以为“只要超corePoolSize就扩容”，其实只有当前线程数 maximumPoolSize 且队列已满时，才会新建非核心线程。所以corePoolSize本质是“常驻线程下限”，不是并发上限。
-
corePoolSize = 2、maximumPoolSize = 8、LinkedBlockingQueue（无界）→ 永远不会创建超过2个线程，所有任务都在2个线程里串行或靠队列缓冲 -
corePoolSize = 2、maximumPoolSize = 8、ArrayBlockingQueue(10)→ 第13个任务进来时，若已有2个线程在跑且队列满，才会启第3个线程 - 生产环境慎用无界队列，OOM风险高；推荐
SynchronousQueue配合合理maximumPoolSize，让线程数更贴近真实负载
keepAliveTime对核心线程生效吗？
默认不生效。核心线程默认永不销毁，哪怕空闲很久。只有显式调用allowCoreThreadTimeOut(true)后，keepAliveTime才对核心线程起作用。
这个开关很关键：不开，线程池缩容只发生在非核心线程上；开了，整个池子能真正“弹性收缩”。但要注意，频繁启停线程有开销，适合流量波峰波谷明显的场景（比如定时批处理）。
- 不调
allowCoreThreadTimeOut(true)：即使设置keepAliveTime = 10，2个核心线程也会一直存活 - 调了之后：所有线程（含核心）空闲超10秒就会被回收，池子可缩到0（除非设置了
corePoolSize = 0，但JDK不建议） -
keepAliveTime单位必须用TimeUnit.SECONDS这类枚举，传整数毫秒容易错——比如写60以为是1分钟，其实是60纳秒
拒绝策略选哪个？AbortPolicy是不是最安全？
AbortPolicy抛RejectedExecutionException，看似“失败即止”，实则最容易导致上游逻辑断裂。比如异步发通知，被拒后没重试也没日志，消息就静默丢了。
真正可控的策略是CallerRunsPolicy：由提交任务的线程自己执行该任务。它不丢任务、不抛异常、还能自然降速（调用方线程被占住，后续提交变慢），适合对一致性要求高的场景。
-
DiscardPolicy：静默丢弃，连日志都不打，调试时极难发现 -
DiscardOldestPolicy：丢队头任务，适合“最新数据才有意义”的流式处理（如实时行情） - 自定义策略务必重写
rejectedExecution方法，并确保不阻塞、不抛未捕获异常，否则可能卡死线程池的拒绝判断逻辑
workQueue用ArrayBlockingQueue还是SynchronousQueue？
这不是性能高低问题，而是语义选择：ArrayBlockingQueue强调缓冲能力，SynchronousQueue强调“直传”——它没有容量，每个put必须配一个take，本质上把任务交接变成了线程间同步点。
选SynchronousQueue时，maximumPoolSize必须设得足够大，否则稍有并发就触发拒绝；而ArrayBlockingQueue配较小maximumPoolSize，更适合稳态服务。
-
new ArrayBlockingQueue(100)+core=4, max=4→ 平滑承接短时突增，但积压超100会触发拒绝 -
new SynchronousQueue()+core=4, max=16→ 任务几乎不排队，线程数随负载快速伸缩，但监控要跟上，防止max被轻易打满 - 别用
LinkedBlockingQueue无参构造（默认容量Integer.MAX_VALUE），等于事实上的无界队列，OOM只差一个突发流量
allowCoreThreadTimeOut这种一开一关就彻底改变行为的开关。 
