Just-In-Time (JIT) 编译器是现代高性能虚拟机（如 JVM、V8）的心脏，它通过将频繁执行的“热点”字节码编译为高度优化的本地机器码，实现了媲美原生应用的执行效率。然而，这些动态生成的机器码并非无处安放，它们被储存在一个专门的内存区域——代码缓存（Code Cache）中。这个缓存区是 JIT 性能发挥的基石，但它本身也是一个有限的、需要精心管理的宝贵资源。
如果对代码缓存的管理不当，可能会导致灾难性的性能衰退。一个典型的场景是，当代码缓存被填满时，JIT 编译器会被迫停止工作，后续的所有热点方法都只能通过低效的解释器执行，应用性能瞬间跌落谷底。因此，理解代码缓存的分配策略、回收机制以及如何对抗内存碎片化，是每一位追求极致性能的开发者必备的内功。
一、地基与规划：代码缓存的分配与容量设定
代码缓存本质上是虚拟机在启动时预留的一块非堆内存区域，拥有固定的最大容量。它的管理哲学与堆内存截然不同，更侧重于空间利用率和执行效率。对于 Java HotSpot VM 而言，以下几个参数是控制其行为的关键：
-XX:InitialCodeCacheSize: 指定代码缓存的初始大小。-XX:ReservedCodeCacheSize: 指定代码缓存的最大容量。这是最重要的调优参数之一。-XX:CodeCacheExpansionSize: 当空间不足时，每次扩展的大小。
当应用程序启动后，JIT 编译器会持续不断地将热点方法的编译结果（称为 nmethod）放入代码缓存。如果 ReservedCodeCacheSize 设置得过小，对于代码量庞大或长时间运行的应用，缓存很容易被耗尽。此时，JVM 会抛出一条严厉的警告：Java HotSpot(TM) VM warning: CodeCache is full. Compiler has been disabled. 这意味着 JIT 编译器已经“罢工”，新的优化将不再发生，性能天花板已然锁死。
因此，合理规划 ReservedCodeCacheSize 是第一步。监控代码缓存的使用情况，并为其设置一个既能满足应用全生命周期需求又不过度浪费内存的上限，是至关重要的。例如，可以通过 -XX:+PrintCodeCache 参数在 JVM 退出时打印使用情况，或使用 jcmd 工具进行实时监控。
jcmd <pid> Compiler.codecache
输出会清晰地展示总大小(size)、已用空间(used)、历史峰值(max_used)和可用空间(free)，为容量规划提供精确的数据支持。
二、新陈代谢：代码的回收与垃圾收集（GC）
代码缓存既然是“缓存”，就意味着其中的内容有生命周期，需要一套有效的回收机制来清理不再使用或价值不高的代码，为新的热点代码腾出空间。代码缓存的回收主要由两种机制触发：
- 类卸载：当一个类被垃圾回收器卸载时，其在代码缓存中对应的所有
nmethod 也会被一并回收。
- 缓存压力驱动的刷新（Flushing）：这是更主动、更核心的回收策略。当代码缓存的使用率达到某个阈值时，JVM 会启动一个刷新进程，扫描缓存中的
nmethod，并淘汰那些“不够热”的代码。
这种刷新机制通过 -XX:+UseCodeCacheFlushing 参数控制（在现代 JDK 版本中默认开启）。JVM 内部为每个 nmethod 维护一个“热度计数器”，如果一个已编译的方法在一段时间内不再被频繁调用，其热度就会衰减。当刷新操作被触发时，那些热度低于动态计算出的阈值的方法，就会被视为“冷却”代码，从缓存中驱逐出去。
这个过程堪称代码缓存的“垃圾收集”（GC）。关闭它（-XX:-UseCodeCacheFlushing）在生产环境中是极其危险的，因为它意味着代码缓存只能增不能减，最终必然导致溢出。
三、对抗熵增：用分段设计决战缓存碎片化
仅仅拥有回收机制还不够。随着 nmethod 的不断创建和销毁，代码缓存会像身经百战的磁盘一样，产生大量不连续的内存碎片。即使总的剩余空间很大，也可能因为缺少足够大的连续空间而无法编译一个较大的方法。这就是内存碎片化问题。
为了从根本上解决这个问题，自 Java 9 开始，HotSpot VM 引入了**分段代码缓存（Segmented Code Cache）**的设计。这个设计思想借鉴了堆内存中经典的“分代收集”理论，将代码缓存一分为三：
- 非方法段 (Non-Method Segment)：用于存放 JVM 自身使用的内部代码，如字节码解释器。这部分代码非常稳定，几乎没有变化。由
-XX:NonNMethodCodeHeapSize 控制大小。
- 待分析代码段 (Profiled-Code Segment)：专门存放由 C1 编译器（客户端编译器）生成的、带有分析探针（Profiling）的、轻度优化的代码。这类代码的生命周期通常较短，因为它们要么很快会变“冷”被回收，要么会因为足够“热”而被 C2 编译器重编译为更高质量的代码。此区域是代码“churn”（快速更替）的主要发生地。由
-XX:ProfiledCodeHeapSize 控制。
- 非分析代码段 (Non-Profiled Segment)：用于存放由 C2 编译器（服务器编译器）生成的、经过深度优化的、不带探针的机器码。这些是应用性能的精华所在，一旦生成，通常会长期存活。由
-XX:NonProfiledCodeHeapSize 控制。
这种分段设计的精妙之处在于隔离了不同生命周期的代码。高频次的回收操作（Code Cache Flushing）可以集中在“待分析代码段”这个“年轻代”中进行，而“非分析代码段”这个“老年代”则保持高度稳定。这带来了多重好处：
- 降低回收开销：回收器只需扫描更小的、变化频繁的区域，效率显著提升。
- 减少碎片化：将长期存活的优化代码紧凑地存放在
Non-Profiled Segment，避免了因“年轻”代码的频繁生死而在此区域造成碎片。
- 提升代码局部性：不同类型的代码各安其所，有助于提高 CPU 缓存的命中率。
结论
JIT 编译器的代码缓存远非一个简单的内存池，它是一套包含了空间分配、容量规划、垃圾回收与碎片整理等复杂机制的精密系统。作为开发者，理解其运作原理并掌握关键的调优参数，是确保应用在高负载下持续稳定输出高性能的必要前提。
核心要点总结如下：
- 合理规划容量：使用
-XX:ReservedCodeCacheSize 为你的应用预留充足但不过剩的空间，并借助 jcmd 等工具持续监控。
- 确保回收开启：
-XX:+UseCodeCacheFlushing 是防止缓存溢出的生命线，务必保持开启。
- 拥抱分段设计：在 Java 9+ 环境中，分段代码缓存是解决碎片化、提升管理效率的利器。了解三个段的用途有助于进行更精细的调优。
通过对代码缓存的精心“管理”，我们才能让 JIT 编译器这位“性能工匠”不受掣肘，最大限度地发挥其优化潜力，为我们的应用注入澎湃动力。