getLargestPoolSize 是线程池历史最大线程数的只增不减记录，反映真实并发压力峰值，用于反推配置合理性、识别阻塞瓶颈、业务变量膨胀及校准参数。
getLargestPoolSize 不是调优目标，而是调优的“压力刻度尺”——它不指导你该设多少线程，但能告诉你系统**实际扛过多少并发压力**，从而反推配置是否合理、业务是否存在隐性瓶颈。
它是历史峰值的唯一原生记录者
该方法返回线程池自创建以来达到过的最大线程数，只增不减、重启归零。它不依赖监控埋点或日志解析，是 JVM 层最轻量、最可信的历史压力快照。比如某次大促中它从 20 跳到 186，就说明系统在那一刻真实启用了 186 个线程来应对任务洪峰——这个数字比任何模拟压测值都更贴近生产实况。
判断线程池是否长期“顶格运行”
若 getLargestPoolSize 长期等于 maximumPoolSize（例如连续多天都是 200），说明线程池反复触达上限：
- 可能因慢 SQL、未设超时的远程调用、锁竞争等导致线程阻塞，无法及时释放
- 也可能因 workQueue 过大（如无界 LinkedBlockingQueue）压制了扩容时机，让任务持续堆积后突然爆发式扩容
- 此时应检查拒绝率、平均响应时间及 GC 日志，而非单纯调大 maximumPoolSize
识别业务变量膨胀的真实信号
当 getLargestPoolSize 短时飙升，同时出现以下现象，大概率指向业务层变量失控：
立即学习“Java免费学习笔记（深入）”；
- JVM 堆内存使用率同步陡升，且 Full GC 频次增加
- ThreadLocal 未 remove 导致 Old Gen 对象持续累积（MAT 分析可见大量 ThreadLocalMap$Entry）
- 关键路径中单请求新建对象数、DTO 实例量、JSON 解析深度等业务指标同步放大
这时调优重点不是改线程数，而是收缩对象生命周期、复用对象、清理 ThreadLocal。
校准核心参数的跨周期依据
单日峰值参考价值有限，需结合多日分布做决策：
- 若 95% 日峰值 ≤ 32，但某天突增至 68，应查当天是否有定时任务叠加、上游推送异常、缓存击穿等外部扰动
- 若连续一周 getLargestPoolSize ≈ corePoolSize（如都是 8），而 CPU 利用率长期低于 40%，说明核心线程冗余；但若 RT 反而升高，则提示任务 I/O 密集，需增线程而非降配
- 将历史 largest 值作为 baseline，用于设定告警阈值（如 > 1.5× 7日均值即触发容量评审）
