getLargestPoolSize返回线程池生命周期中曾达到的最大线程数，仅在addWorker成功创建新线程时递增，反映系统压力下的并发能力上限，只增不减、重启归零，需结合时间戳与外部存储做跨周期分析。
getLargestPoolSize 是 ThreadPoolExecutor 提供的只读方法，返回线程池生命周期中曾达到过的最大线程数。它不实时、不可重置、不自动记录时间戳，但却是回溯历史峰值最轻量、最可靠的原生指标——关键在于“何时查、怎么存、如何用”。
理解 getLargestPoolSize 的真实语义
该值仅在 addWorker 成功创建新线程时递增（例如任务提交导致核心线程耗尽、且队列满后触发扩容），不是当前活跃线程数，也不是排队任务数。它反映的是“线程池被迫伸展到的最大宽度”，本质是系统在压力下实际启用的并发能力上限。
- 它不会因线程空闲超时回收而减小，只增不减
- 重启应用后归零，需配合外部存储做跨周期分析
- 若长期等于核心线程数（如
corePoolSize=10且getLargestPoolSize==10），说明从未触发扩容，可能有资源冗余或队列阻塞风险
实战采集：低侵入式峰值快照策略
不要轮询调用，避免性能干扰；改用“事件驱动 + 定期落盘”组合：
- 在自定义
RejectedExecutionHandler中记录一次：if (executor.getLargestPoolSize() > lastPeak) { lastPeak = executor.getLargestPoolSize(); log.warn("Peak hit: {}", lastPeak); } - 结合 JVM shutdown hook 或定时任务（如每5分钟）写入本地文件或上报监控系统：
Metrics.gauge("threadpool.peak", () -> executor.getLargestPoolSize()); - 若使用 Spring Boot Actuator，可暴露为自定义 endpoint：
return Map.of("largestPoolSize", executor.getLargestPoolSize(), "core", executor.getCorePoolSize(), "max", executor.getMaximumPoolSize());
校准并发参数：从峰值反推配置合理性
单看一个数字没意义，要和业务流量、响应延迟、错误率对齐：
- 若
getLargestPoolSize ≈ maximumPoolSize频繁出现，且伴随拒绝异常或高延迟，说明maximumPoolSize设置过小，或队列容量不合理（如用LinkedBlockingQueue无界队列会压制扩容） - 若
getLargestPoolSize ≈ corePoolSize且 CPU 使用率持续低于60%，可考虑降低corePoolSize节省资源；若此时 RT 却升高，说明任务本身 I/O 密集，应检查是否需要增加核心线程而非盲目扩容 - 观察连续多天峰值分布：若 95% 的日峰值 ≤ 24，但某天突增至 48，需查当天是否有定时任务叠加、上游重试风暴或慢 SQL 拖垮线程——峰值是现象，根因在线程阻塞点
补充验证：别只信 getLargestPoolSize
它回答“最多起了多少线程”，但不回答“为什么起这么多”。务必交叉验证：
- 配合
getActiveCount()看瞬时负载密度 - 用
getTaskCount() - getCompletedTaskCount()估算积压任务量 - 开启
-Djava.util.concurrent.ForkJoinPool.common.parallelism=1类似思路，对线程池做 JFR 录制，定位线程阻塞栈 - 在关键 submit 前打点：
log.debug("Submit task, queue size={}", executor.getQueue().size());
不复杂但容易忽略：峰值数据只有和时间、错误码、GC 日志、DB 连接池使用率一起看，才能把“线程数涨了”变成“下游接口超时导致线程卡住”。getLargestPoolSize 是钥匙，不是答案。
