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