Java 线程数驱动 HPA 的指标前提
原笔记提出按 Java 线程数扩缩 Pod，但其 YAML 不能直接应用。本页保留指标设计问题，不把原示例视作已验证配置。
HPA 的 Pods 类型指标可把每个 Pod 的一个自定义指标与目标平均值比较。要把“活跃线程数”用于扩缩容，至少需要以下链条：
- 应用明确暴露的究竟是 JVM 当前存活线程、业务工作线程，还是线程池忙碌数；它们对负载的含义不同。
- 采集系统把指标按 Pod 关联，并由自定义指标适配器提供给 Kubernetes 的指标 API。只有 Prometheus 抓取到了指标，还不足以让 HPA 读取。
- HPA 指向正确的工作负载、指标名称与平均值目标，并在压力和空闲场景观察缺测、抖动、启动期和缩容行为。
原笔记通过 jps / jstack 统计线程转储中的状态行，可作为一次性诊断线索；它不是持续、低开销且语义稳定的 HPA 指标来源。常驻采集方式与目标阈值须根据应用实测决定。
原示例需要改写的地方
- 原 YAML 使用
autoscaling/v2beta2和metricName/targetAverageValue。目标集群应先查询支持的 API，再按该版本的Pods指标结构配置；不能直接沿用旧字段。 - 原文没有提供指标适配器或自定义指标 API 的证据，也没有说明线程数达到目标后是否能改善服务延迟。
- 平均值会掩盖单个 Pod 的热点。若线程池固定大小或被锁竞争耗尽，增加副本未必缓解根因；需要结合队列、吞吐、延迟与资源指标验证。
关联：调度与自动扩缩模块描述 HPA 的上下文；Pod Pending用于检查扩容后新副本无法调度的情况。