static变量仅在单jvm进程内有效，适用于spring boot单节点全量统计；需用atomicinteger或synchronized保障线程安全，并封装为可监控bean，严防内存泄漏与测试污染。
静态变量并不真正“贯穿全局”，它只在单个 jvm 进程内有效，不能跨服务、跨机器、跨类加载器共享。所谓“全量计数器”若指整个微服务集群的统一计数，static 无法胜任；但若指单节点内所有请求、所有线程、所有实例共享的累计值，那它恰恰是轻量、低开销的理想基础。
明确适用边界：仅限单节点 JVM 内全量统计
一个 Spring Boot 应用实例就是一个独立 JVM 进程。在此范围内：
- static 变量随类加载初始化，生命周期覆盖整个应用运行期
- 所有 Controller、Service、Filter、线程都读写同一份内存
- 重启后归零，扩容后各节点计数彼此隔离、互不干扰
- 它不是分布式方案，不替代 Redis、数据库序列或 Snowflake
必须保障线程安全：避免 count++ 丢数
count++ 是“读-改-写”三步非原子操作，多线程并发必丢值。正确做法只有两种：
- 高并发首选 AtomicInteger：
private static final AtomicInteger total = new AtomicInteger(0);，调用total.incrementAndGet() - 逻辑复杂需同步时，用 synchronized 块：
synchronized (Counter.class) { total++; } - 绝对不要写
public static int total = 0;—— 裸露变量会破坏封装，难以加锁、监控和重置
封装成可管理组件：暴露接口 + 集成监控
静态变量只是底层存储，上层必须封装为 Spring Bean：
- 提供
getCount()、reset()、incrementBy(int n)等标准方法 - 通过
@Endpoint或@ReadOperation暴露 HTTP 端点，如/actuator/metrics/app.requests - 在
@PostConstruct中注册到 Micrometer 的Gauge，接入 Prometheus 实时观测
严防典型陷阱：内存泄漏与测试污染
看似简单，实则易埋雷：
-
绝不存业务对象引用：比如
static Map<string httpservletrequest></string>会导致请求对象无法 GC，引发内存泄漏 -
单元测试必须重置：JUnit 复用类加载器，静态值残留会导致用例间干扰，应在
@BeforeEach中调用reset() -
初始化顺序要可控：避免静态变量依赖尚未加载的配置或环境变量，否则抛
ExceptionInInitializerError
