高并发读取场景下线程池间接影响内存：需禁用无界队列、控制线程数（IO密集型推荐CPU核数×3~8）、复用对象池、避免ThreadLocal泄漏、配合有界队列与拒绝策略，并监控队列深度与GC频率。
高并发读取场景下，线程池本身不直接管理堆内存，但其配置与任务行为会显著影响内存分配节奏、GC压力和对象生命周期。关键不在“线程池分配内存”，而在于它如何间接驱动对象创建、缓存复用与资源释放节奏。
任务对象生命周期要可控
读取类任务（如数据库查询、缓存获取、JSON解析）常伴随临时对象大量生成（如ResultSet、DTO、String、List）。若线程池长期持有大对象引用或未及时释放，易引发内存堆积。
- 避免在任务中缓存大对象到静态集合或ThreadLocal——尤其注意ThreadLocal未remove导致的内存泄漏
- 使用对象池（如Apache Commons Pool或HikariCP连接池）复用可重用结构体，减少GC频率
- 对高频读取返回结果做轻量封装（如用record替代传统DTO），降低堆内存占用
队列类型与容量直接影响内存水位
读取请求通常响应快、耗时短，但突发流量下若队列失控，会迅速吃光堆内存。
- 禁用无界队列（如
LinkedBlockingQueue无参构造）——它默认Integer.MAX_VALUE容量，极易OOM - 优先选用有界队列（如
ArrayBlockingQueue(512)），容量按“峰值QPS × 平均处理时长”粗略估算（例如：2000 QPS × 0.1s ≈ 200）并留2倍余量 - 配合拒绝策略（如
DiscardPolicy或CallerRunsPolicy），让上游限流或降级，而非让任务无限排队
线程数设置需匹配IO等待特性
纯读取操作多为I/O密集型（网络/磁盘等待远大于CPU计算），线程数过高反而加剧上下文切换与内存竞争。
立即学习“Java免费学习笔记（深入）”；
- 推荐公式：
corePoolSize = CPU核心数 × (1 + 平均等待时间 / 平均CPU时间)；典型Web读取场景中该比值常为3~8，即16核机器设48~128个核心线程已足够 - 避免设置过大的
maximumPoolSize——线程本身虽轻量，但每个线程栈（-Xss，默认1MB）叠加后仍占可观内存 - 对超短期读取任务（如毫秒级缓存命中），可考虑
SynchronousQueue+ 动态扩缩容，减少队列缓冲开销
监控与回收机制不可缺位
内存问题往往滞后暴露，需结合线程池运行态与JVM内存指标联动分析。
- 开启JFR或Prometheus+Micrometer，监控：
pool.getActiveThreads、pool.getQueue().size()、pool.getCompletedTaskCount() - 配合GC日志观察是否因任务提交速率过高导致Eden区频繁Minor GC（说明对象生成过快）
- 调用
executor.shutdown()后务必执行awaitTermination()，防止未完成任务持续占用内存
