核心在于主动监控与合理配置：通过jstat -codecache监控Used/Max比值（超90%即危险）、jstat -compiler观察Failed增长，按峰值×1.3设置ReservedCodeCacheSize（如峰值192M→256m），禁用非必要动态能力，并启用-XX:+UseG1GC降低碎片。

预防 JIT 代码缓存清理导致的性能退化，核心在于避免缓存被填满、碎片化或被动驱逐，而不是等它“快满了再救”。变量执行退化（如热点函数突然回退到解释执行）往往不是代码写得不好，而是 JIT 编译产物无法驻留或持续生效。

监控 Code Cache 使用率，别等失败才报警

缓存溢出前没有明显 GC 日志或堆异常，jstat -gc 看不出问题。必须主动查：

• jstat -codecache <pid>：重点关注 Used 与 Max 的比值，持续高于 90% 就已危险
• jstat -compiler <pid>：若 Failed 字段持续增长、Compiled 停滞，说明 JIT 已停摆
• jinfo -flag ReservedCodeCacheSize <pid>：确认当前限制值，老 JDK（如 8u192）默认仅 48M，极易触发降级

预留余量 + 合理设上限，不盲目堆大内存

ReservedCodeCacheSize 不是越大越好。设太大可能因 mmap 分配失败直接启动失败，尤其在容器中：

• 先用 jstat -codecache <pid> 1000 10 观察 10 秒内峰值用量
• 按峰值 × 1.3 设置，例如峰值 192M → 设为 -XX:ReservedCodeCacheSize=256m（单位必须小写 m）
• OpenJDK 11+ 默认 240M 可作起点；JDK 8 建议至少调至 256m，避免默认 48M/96M 坑

减少无效编译与动态膨胀源

UseCodeCacheFlushing 只能清理“冷代码”，对 Spring AOP 代理、Groovy 脚本、热 redefine 等持续注入型膨胀无效：

• 禁用非必要动态能力：关闭开发期热部署插件、限制 eval/exec 使用频次
• 收敛 Lambda 和匿名类生成：避免在循环内反复创建 Function 实例，改用静态方法引用
• 对高频反射调用（如 JSON 序列化）启用白名单缓存，减少 JIT 频繁重编译压力

配合运行时策略，延长有效编译生命周期

JIT 编译代码不是永久驻留，但可通过配置延缓失效：

• 启用 -XX:+UseG1GC：G1 对 Code Cache 元数据管理更友好，降低碎片概率
• 避免频繁 full GC 或 CMS 并发模式：某些 GC 策略会强制刷新 Code Cache 中的 profiled 方法
• 容器环境加 --memory-limit 时，把 ReservedCodeCacheSize 纳入预算，防止因 cgroup 内存回收误杀 JIT 区域