Code Cache耗尽会导致JIT静默关闭，大量代码退化为解释执行，引发性能陡降；可通过jstat -compiler查看Failed持续增长、jstat -gccapacity观察CCSU接近CCCMX、jinfo确认ReservedCodeCacheSize来诊断，需结合-XX:ReservedCodeCacheSize调大（如512M/1G）和-XX:+UseCodeCacheFlushing启用驱逐机制协同解决。
Code Cache 耗尽是 JVM 应用运行中后期性能陡降的隐蔽元凶，不是 GC 问题、不是 CPU 过载、也不是内存泄漏，而是 JIT 编译器被静默关闭导致大量代码退回到解释执行。
怎么看 Code Cache 是否已满
直接查当前使用状态比猜更可靠。用
查看实时占用：
重点关注
（已编译方法数）、
（编译失败数）、
（失效编译数）三列。如果
持续增长，且
显示
（Code Cache 使用量）接近
（Code Cache 最大容量），基本可断定 Code Cache 已满。
也可用
确认预留大小：
注意：该值在 JVM 启动后不可动态修改，只读。
-XX:ReservedCodeCacheSize 设置多少才够用
默认值不等于安全值。OpenJDK 11+ 默认是
，但商用中间件（如 Volantis MCS）、大量反射/动态代理（Spring AOP、MyBatis）、或启用了分层编译（
）的场景，很容易在几小时内打满。
保守起见，生产环境建议设为
或
，尤其当应用含大量业务逻辑类或第三方 SDK 时
若用的是 JDK 8u292 之前版本，
不能超过
（受 32 位地址空间限制）
不要盲目设成
——Code Cache 是连续虚拟内存段，过大可能引发 mmap 分配失败，反而触发 JVM 启动异常
-XX:+UseCodeCacheFlushing 必须开吗
必须开，但仅靠它不够。这个参数启用后，JVM 会在 Code Cache 即将填满时主动驱逐冷代码（如长期未调用的非热点方法），避免 JIT 突然停摆。
默认是关闭的，JDK 8u292+ 和 JDK 11+ 均需显式添加
它不能解决“编译请求远超缓存吞吐”的根本问题，只是延缓崩溃——如果每秒新增 100 个编译任务，而驱逐只能释放 20 个旧槽位，依然会持续失败
配合
可在 GC 日志里看到驱逐详情，用于判断是否真在生效
为什么堆内存调大对 Code Cache 无效
Code Cache 和 Java 堆完全独立：前者是 JVM 进程内一块固定大小的 native 内存区域（由
分配），后者是 GC 管理的托管堆。增大
对 Code Cache 容量、命中率、编译行为零影响。
常见误操作包括：
看到 CPU 高 + 性能掉，第一反应加堆内存——徒增 GC 压力，掩盖真实瓶颈
用
查对象分布——Code Cache 溢出时堆对象可能很干净
依赖
看线程栈顶——解释执行的方法栈看起来“很轻”，但耗时翻倍，容易误判为 IO 或锁竞争
真正关键的信号藏在
的
计数里，以及应用日志中突然增多的 “
” 类似提示（某些框架会暴露 JIT 状态）。
jstatjstat -compiler CompiledFailedInvalidFailedjstat -gccapacity CCSUCCCMXjinfojinfo -flag ReservedCodeCacheSize 240m-XX:+TieredCompilation512m1gReservedCodeCacheSize2g4g-XX:+UseCodeCacheFlushing-XX:+PrintCodeCacheStatisticsmmap-Xmxjmap -histojstackjstat -compilerFailedjava.lang.RuntimeException: Not compiled