JVM 代码缓存参数分析与性能优化方法

JVM 中 Code Cache 耗尽是一个极易被忽视却危害巨大的性能隐患——它不会触发 GC、不占用堆内存、不报错崩溃，却会悄然关闭 JIT 编译器，迫使大量代码退化为低效的解释执行，导致应用中后期性能断崖式下跌；通过 jstat -compiler 观察 Failed 持续增长、结合 jstat -gccapacity 和 jinfo 确认 CCSU 接近 CCCMX 即可精准定位，而真正有效的应对方案是双管齐下：将 -XX:ReservedCodeCacheSize 合理调大至 512M 或 1G（避免盲目设为 4G 引发 mmap 失败），并强制启用 -XX:+UseCodeCacheFlushing 以主动驱逐冷代码，唯有如此才能打破“编译请求持续压垮缓存”的恶性循环，让 JIT 稳定在线，守住性能生命线。

Code Cache 耗尽是 JVM 应用运行中后期性能陡降的隐蔽元凶，不是 GC 问题、不是 CPU 过载、也不是内存泄漏，而是 JIT 编译器被静默关闭导致大量代码退回到解释执行。

怎么看 Code Cache 是否已满

直接查当前使用状态比猜更可靠。用 jstat 查看实时占用：

jstat -compiler <pid>

重点关注 Compiled（已编译方法数）、Failed（编译失败数）、Invalid（失效编译数）三列。如果 Failed 持续增长，且 jstat -gccapacity 显示 CCSU（Code Cache 使用量）接近 CCCMX（Code Cache 最大容量），基本可断定 Code Cache 已满。

也可用 jinfo 确认预留大小：

jinfo -flag ReservedCodeCacheSize <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 状态）。

以上就是本文的全部内容了，是否有顺利帮助你解决问题？若是能给你带来学习上的帮助，请大家多多支持golang学习网！更多关于文章的相关知识，也可关注golang学习网公众号。