minor gc不直接修改c1/c2热点计数器，因其存储于元空间/c++堆而非java堆；但通过stw暂停、分配阻塞和tlab竞争间接拖慢调用/回边计数器累积节奏，延迟分层编译升级，导致方法长期卡在c1而无法进入c2。
分层编译下，Minor GC 本身不直接修改 C1/C2 编译器的热点计数器，但它会间接影响计数器的累积节奏和方法的编译决策路径。
计数器不是 GC 管理的对象
C1/C2 使用的调用计数器（Invocation Counter）和回边计数器（Backedge Counter）保存在方法的 Method* 结构体 中，属于 JVM 元数据，位于元空间或 C++ 堆，**不在 Java 堆内**。因此 Minor GC（只清理新生代堆内存）完全不会扫描、标记或重置这些计数器。
Minor GC 如何间接干扰计数器累积
虽然不碰计数器本身，但 Minor GC 的发生频率和停顿会改变方法实际被执行的节奏：
- 线程暂停打断执行流：每次 Minor GC 会 STW（Stop-The-World），正在执行热点循环的线程被强制中断，导致回边计数器增长变慢——同一段代码在相同 wall-clock 时间内触发的回边次数减少；
- 对象分配受阻拖慢调用频率：若应用频繁分配短生命周期对象（如 StringBuilder、临时包装类），Minor GC 频繁会抬高对象分配成本，使方法调用链变慢，间接拉低调用计数器增速；
- TLAB 耗尽引发同步开销：当 Eden 区 TLAB 频繁耗尽，JVM 需加锁分配新 TLAB 或直接在共享 Eden 分配，增加线程竞争，进一步稀释 CPU 时间在业务逻辑上的占比，削弱计数器“真实热度”的反映精度。
分层编译层级切换可能被 GC 延迟触发
分层编译（-XX:+TieredCompilation）按热度逐级提升编译级别（如从解释执行 → C1 → C1+profiling → C2）。而是否升级，依赖计数器是否达到各层级阈值（如 Tier3 触发 C1 编译，Tier4 触发带 profiling 的 C1，Tier5 触发 C2）。
如果 Minor GC 过于频繁，导致计数器长期卡在 Tier3 和 Tier4 之间，方法就始终无法进入 C2 编译队列——看似“够热”，实则因 GC 干扰未能达成连续、密集的执行窗口。
典型表现是：jstat -compiler 输出中 compiledMethodCount 持续增长，但 C2 compilation 数长期停滞，且 -XX:+PrintCompilation 日志里大量方法只停留在 “1”（C1）级别，极少出现 “2”（C2）。
验证与定位建议
- 用 jstat -gc
观察 Minor GC 频率（YGC）和平均耗时（YGCT/YGCT/YGC），若 YGC > 100 次/秒 或 平均 YGCT > 10ms，说明 GC 已构成显著干扰； - 开启 -XX:+PrintCompilation -XX:+UnlockDiagnosticVMOptions -XX:+PrintInlining，比对方法从首次记录到最终编译的时间跨度，若间隔远超预期（如数秒以上），大概率是 GC 或其他 STW 操作打断了计数累积；
- 配合 -XX:+LogCompilation -XX:LogFile=hotspot.log 查看 methodData 的 counter_update 记录，确认计数器是否稳定递增，还是呈现阶梯式缓慢爬升（暗示周期性中断）。
